BlackOps 0 10 октября, 2010 Опубликовано 10 октября, 2010 (изменено) · Жалоба вот к примеру простенкий код: entity test1 is port ( b : in std_logic_vector(7 downto 0); c : in std_logic_vector(7 downto 0); a : out std_logic_vector(7 downto 0) ); end entity; architecture Behavioral of test1 is begin a <= b + c; end Behavioral; а вот РТЛ реализация прикреплена. так вот я думаю... данная сгенерированная реализация ето не что иное как Carry-Lookahead-Adder? К примеру который приведен на етой страничке: Carry-Lookahead-Adder хотя..если сравнивать подробнее то это разные реализации... Так вот вопрос такой... стоит ли однажды написать свою реализацию сумматора по принципу того что показан на линке вышеа потом инстанциировать его где нужно вместо того чтобы писать c <= a + b? Или вполне нормально писать c <= a + b в результате чего синтезатор сгенерит то что я прикрепил файлом? Что будет быстрее работать? я сейчас понял это одинаковые реализации, просто в случае с синтезатором он сгенерил мультиплексоры, а та что на линке в виде гейтов показана.. значит я так понял использовать сложение также быстро и ничего в этом плохово нету Изменено 10 октября, 2010 пользователем BlackOps Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 11 октября, 2010 Опубликовано 11 октября, 2010 · Жалоба так вот я думаю... данная сгенерированная реализация ето не что иное как Carry-Lookahead-Adder? нет, такие сумматоры в современных плис не используются стоит ли однажды написать свою реализацию сумматора по принципу того что показан на линке вышеа потом инстанциировать его где нужно вместо того чтобы писать c <= a + b? нет, это не имеет практического смысла я сейчас понял это одинаковые реализации, просто в случае с синтезатором он сгенерил мультиплексоры, а та что на линке в виде гейтов показана.. неправильно поняли, рекомендую разобраться в особенностях хилого строительного кубика(на рисунке скрин с исешки вроде), и выяснить зачем нужен MUXCY Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
BlackOps 0 11 октября, 2010 Опубликовано 11 октября, 2010 · Жалоба неправильно поняли, рекомендую разобраться в особенностях хилого строительного кубика(на рисунке скрин с исешки вроде), и выяснить зачем нужен MUXCY отлично спасибо, пересмотрю. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 11 октября, 2010 Опубликовано 11 октября, 2010 · Жалоба нет, такие сумматоры в современных плис не используются нет, это не имеет практического смысла Я бы добавил "в большинстве случаев". Потому что обычно не счетчик определяет быстродействие устройства. Ибо как тогда объяснить "муки творчества" в этой теме: http://electronix.ru/forum/index.php?showtopic=80083 Обратите внимание, что когда включено IGNORE CARRY BUFFERS ON, то быстродействие счетчика увеличивается. Т.е. используется что-то подобное схемам на упомянутой BlackOps страннице. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 11 октября, 2010 Опубликовано 11 октября, 2010 · Жалоба Я бы добавил "в большинстве случаев". покажите современную плис (за исключением сыклона 1) в которой есть аппаратные цепи для Caryy Look Ahead? А описать можно всё что угодно, но вот смысл. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 11 октября, 2010 Опубликовано 11 октября, 2010 · Жалоба покажите современную плис (за исключением сыклона 1) в которой есть аппаратные цепи для Caryy Look Ahead? А описать можно всё что угодно, но вот смысл. LUT есть в каждом LE :) Смысл? - я вам привел конкретную тему, дочитайте ее до конца. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 11 октября, 2010 Опубликовано 11 октября, 2010 · Жалоба LUT есть в каждом LE :) Какое отношение имеет LUT к схеме аппаратного переноса? Это совершенно разные вещи. И так повторю свой вопрос. Покажите FPGA, кроме cyclone I, в которой есть аппаратная реализация переносов, отличная от схемы последовательного переноса?. Смысл? - я вам привел конкретную тему, дочитайте ее до конца. та тема, не имеет никакого отношения, к этой, также как и LUT. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 11 октября, 2010 Опубликовано 11 октября, 2010 · Жалоба Какое отношение имеет LUT к схеме аппаратного переноса? Это совершенно разные вещи. С чего вы взяли, что он должен быть аппаратным? Carry Lookahead означает, что перенос формируется не последовательно, а параллельно, на основании входных данных. В микросхемах счетчиков часто используется. И так повторю свой вопрос. Покажите FPGA, кроме cyclone I, в которой есть аппаратная реализация переносов, отличная от схемы последовательного переноса?. Повторю ответ - я могу в ПЛИС сделать что угодно, в том числе и Carry Lookahead. та тема, не имеет никакого отношения, к этой, также как и LUT. Да ну? Я думаю, на основании вышесказанного должно быть понятно. Как по-вашему, если включено IGNORE CARRY BUFFERS, во что превращаются цепи переноса в любой ПЛИС, например, в Cyclone III? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 11 октября, 2010 Опубликовано 11 октября, 2010 · Жалоба С чего вы взяли, что он должен быть аппаратным? С того, что вопрос автора топика был такой "Так вот вопрос такой... стоит ли однажды написать свою реализацию сумматора по принципу того что показан на линке вышеа потом инстанциировать его где нужно вместо того чтобы писать c <= a + b?". На что был дан ответ, в современных ПЛИС, вы не получите эквивалентную по тактам реализацию быстрее, чем та что реализована аппаратно. К чему ваши рассуждения о том что можно сделать, а что нельзя? Carry Lookahead означает, что перенос формируется не последовательно, а параллельно, на основании входных данных. В микросхемах счетчиков часто используется. Спасибо, теорию я еще с вуза хорошо помню. Повторю ответ - я могу в ПЛИС сделать что угодно, в том числе и Carry Lookahead. Резко просев по производительности. Но это ваше право. Причины очевидны и находятся в любом даташите на целевую ПЛИС. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 11 октября, 2010 Опубликовано 11 октября, 2010 · Жалоба Резко просев по производительности. Но это ваше право. Причины очевидны и находятся в любом даташите на целевую ПЛИС. Правильно. В большинстве случаев. Но не всегда. В приведенной мной теме, когда складывается не пара чисел, а больше, аппаратные схемы последовательного переноса тормозят. Я тоже был удивлен... однако, факт! Мне кажется, что при определенных размерах складываемых слов параллельный перенос в ПЛИС может оказаться быстрее последовательного. Лично я этих размерностей не нашел. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 11 октября, 2010 Опубликовано 11 октября, 2010 · Жалоба Правильно. В большинстве случаев. Но не всегда. В приведенной мной теме, когда складывается не пара чисел, а больше, аппаратные схемы последовательного переноса тормозят. Я тоже был удивлен... однако, факт! Если вы про пост №39, результат ваш видел, но считаю его неоднозначным, а ваш вывод не очевидным. Подробно разбираться с той темой не могу, и так работы много. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shtirlits 0 11 октября, 2010 Опубликовано 11 октября, 2010 · Жалоба Carry look ahead работает на длинных сумматорах, так как мультиплексор старших разрядов должен оказаться выгоднее прохождения переноса напрямую. Интуиция говорит что-то о 128 битах и больше. Нужно смотреть datasheet в разделе performance на конкретную микросхему и прикидывать. Писание сумматора самому может быть осмыслено, если синтезатор не справляется на данной архитектуре. Однако, использование самописного сумматора вместо абстрактоного оператора + ограничивает возможности портирования. В упомянутой теме еще не все точки на i поставлены, так как было мало попыток для xilinx, где в принципе возможно ручное размещение и упаковка. Возможно, использование carry даст нужный результат, когда сумматоры будут расположены не кружочком, как их ставят роботы, а по уму. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 11 октября, 2010 Опубликовано 11 октября, 2010 · Жалоба Если вы про пост №39, результат ваш видел, но считаю его неоднозначным, а ваш вывод не очевидным. До этого еще был пост №36 (не мой), который, собственно, и дал толчок к дальнейшим "извращениям". А выводов я, вроде, никаких не делал, только предположения. Пока - мой код самый быстрый. Интуиция говорит что-то о 128 битах и больше. Нужно смотреть datasheet в разделе performance на конкретную микросхему и прикидывать. Сомневаюсь. LUT в LE имеют 4 входа, и это убивает все возможности создания многоразрядных Carry Lookahead. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Shtirlits 0 11 октября, 2010 Опубликовано 11 октября, 2010 · Жалоба LUT в LE имеют 4 входа, и это убивает все возможности создания многоразрядных Carry Lookahead. Не понял, какая связь вообще, что имеется в виду? Если речь идет о двух слагаемых большой длины? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 11 октября, 2010 Опубликовано 11 октября, 2010 · Жалоба Не понял, какая связь вообще, что имеется в виду? Если речь идет о двух слагаемых большой длины? При параллельном вычислении переноса какого-нибудь разряда нужно учитывать все младшие разряды слагаемых. При LUT 4-х-входовой можно вычислить перенос только для 2-разрядных чисел. Дальше придется объединять несколько LUT. А это - задержки, куда большие, чем в аппаратных цепях последовательного переноса. Скорее всего, лучшим решением будет комбинированная схема, где есть и параллельные и последовательные переносы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться