Сложение чисел, Какой метод будет работать быстрее? Опции

[BlackOps]

вот к примеру простенкий код:

Код

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 в результате чего синтезатор сгенерит то что я прикрепил файлом? Что будет быстрее работать?

я сейчас понял это одинаковые реализации, просто в случае с синтезатором он сгенерил мультиплексоры, а та что на линке в виде гейтов показана..

значит я так понял использовать сложение также быстро и ничего в этом плохово нету

Сообщение отредактировал BlackOps - Oct 10 2010, 22:49

Эскизы прикрепленных изображений

 

[des00]

так вот я думаю... данная сгенерированная реализация ето не что иное как Carry-Lookahead-Adder?

нет, такие сумматоры в современных плис не используются

стоит ли однажды написать свою реализацию сумматора по принципу того что показан на линке вышеа потом инстанциировать его где нужно вместо того чтобы писать c <= a + b?

нет, это не имеет практического смысла

я сейчас понял это одинаковые реализации, просто в случае с синтезатором он сгенерил мультиплексоры, а та что на линке в виде гейтов показана..

неправильно поняли, рекомендую разобраться в особенностях хилого строительного кубика(на рисунке скрин с исешки вроде), и выяснить зачем нужен MUXCY

[BlackOps]

неправильно поняли, рекомендую разобраться в особенностях хилого строительного кубика(на рисунке скрин с исешки вроде), и выяснить зачем нужен MUXCY

отлично спасибо, пересмотрю.

[ViKo]

нет, такие сумматоры в современных плис не используются
нет, это не имеет практического смысла

Я бы добавил "в большинстве случаев". Потому что обычно не счетчик определяет быстродействие устройства. Ибо как тогда объяснить "муки творчества" в этой теме:
http://electronix.ru/forum/index.php?showtopic=80083
Обратите внимание, что когда включено IGNORE CARRY BUFFERS ON, то быстродействие счетчика увеличивается. Т.е. используется что-то подобное схемам на упомянутой BlackOps страннице.

[des00]

Я бы добавил "в большинстве случаев".

покажите современную плис (за исключением сыклона 1) в которой есть аппаратные цепи для Caryy Look Ahead? А описать можно всё что угодно, но вот смысл.

[ViKo]

покажите современную плис (за исключением сыклона 1) в которой есть аппаратные цепи для Caryy Look Ahead? А описать можно всё что угодно, но вот смысл.

LUT есть в каждом LE
Смысл? - я вам привел конкретную тему, дочитайте ее до конца.

[des00]

LUT есть в каждом LE

Какое отношение имеет LUT к схеме аппаратного переноса? Это совершенно разные вещи. И так повторю свой вопрос. Покажите FPGA, кроме cyclone I, в которой есть аппаратная реализация переносов, отличная от схемы последовательного переноса?.

Смысл? - я вам привел конкретную тему, дочитайте ее до конца.

та тема, не имеет никакого отношения, к этой, также как и LUT.

[ViKo]

Какое отношение имеет LUT к схеме аппаратного переноса?
Это совершенно разные вещи.

С чего вы взяли, что он должен быть аппаратным? Carry Lookahead означает, что перенос формируется не последовательно, а параллельно, на основании входных данных. В микросхемах счетчиков часто используется.

И так повторю свой вопрос. Покажите FPGA, кроме cyclone I, в которой есть аппаратная реализация переносов, отличная от схемы последовательного переноса?.

Повторю ответ - я могу в ПЛИС сделать что угодно, в том числе и Carry Lookahead.

та тема, не имеет никакого отношения, к этой, также как и LUT.

Да ну? Я думаю, на основании вышесказанного должно быть понятно.
Как по-вашему, если включено IGNORE CARRY BUFFERS, во что превращаются цепи переноса в любой ПЛИС, например, в Cyclone III?

[des00]

С чего вы взяли, что он должен быть аппаратным?

С того, что вопрос автора топика был такой "Так вот вопрос такой... стоит ли однажды написать свою реализацию сумматора по принципу того что показан на линке вышеа потом инстанциировать его где нужно вместо того чтобы писать c <= a + b?". На что был дан ответ, в современных ПЛИС, вы не получите эквивалентную по тактам реализацию быстрее, чем та что реализована аппаратно. К чему ваши рассуждения о том что можно сделать, а что нельзя?

Carry Lookahead означает, что перенос формируется не последовательно, а параллельно, на основании входных данных. В микросхемах счетчиков часто используется.

Спасибо, теорию я еще с вуза хорошо помню.

Повторю ответ - я могу в ПЛИС сделать что угодно, в том числе и Carry Lookahead.

Резко просев по производительности. Но это ваше право. Причины очевидны и находятся в любом даташите на целевую ПЛИС.

[ViKo]

Резко просев по производительности. Но это ваше право. Причины очевидны и находятся в любом даташите на целевую ПЛИС.

Правильно. В большинстве случаев. Но не всегда. В приведенной мной теме, когда складывается не пара чисел, а больше, аппаратные схемы последовательного переноса тормозят. Я тоже был удивлен... однако, факт!
Мне кажется, что при определенных размерах складываемых слов параллельный перенос в ПЛИС может оказаться быстрее последовательного. Лично я этих размерностей не нашел.

[des00]

Правильно. В большинстве случаев. Но не всегда. В приведенной мной теме, когда складывается не пара чисел, а больше, аппаратные схемы последовательного переноса тормозят. Я тоже был удивлен... однако, факт!

Если вы про пост №39, результат ваш видел, но считаю его неоднозначным, а ваш вывод не очевидным. Подробно разбираться с той темой не могу, и так работы много.

[Shtirlits]

Carry look ahead работает на длинных сумматорах, так как мультиплексор старших разрядов должен оказаться выгоднее прохождения переноса напрямую. Интуиция говорит что-то о 128 битах и больше. Нужно смотреть datasheet в разделе performance на конкретную микросхему и прикидывать.

Писание сумматора самому может быть осмыслено, если синтезатор не справляется на данной архитектуре.
Однако, использование самописного сумматора вместо абстрактоного оператора + ограничивает возможности портирования.

В упомянутой теме еще не все точки на i поставлены, так как было мало попыток для xilinx, где в принципе возможно ручное размещение и упаковка. Возможно, использование carry даст нужный результат, когда сумматоры будут расположены не кружочком, как их ставят роботы, а по уму.

[ViKo]

Если вы про пост №39, результат ваш видел, но считаю его неоднозначным, а ваш вывод не очевидным.

До этого еще был пост №36 (не мой), который, собственно, и дал толчок к дальнейшим "извращениям".
А выводов я, вроде, никаких не делал, только предположения. Пока - мой код самый быстрый.

Интуиция говорит что-то о 128 битах и больше. Нужно смотреть datasheet в разделе performance на конкретную микросхему и прикидывать.

Сомневаюсь. LUT в LE имеют 4 входа, и это убивает все возможности создания многоразрядных Carry Lookahead.

[Shtirlits]

LUT в LE имеют 4 входа, и это убивает все возможности создания многоразрядных Carry Lookahead.

Не понял, какая связь вообще, что имеется в виду?
Если речь идет о двух слагаемых большой длины?

[ViKo]

Не понял, какая связь вообще, что имеется в виду?
Если речь идет о двух слагаемых большой длины?

При параллельном вычислении переноса какого-нибудь разряда нужно учитывать все младшие разряды слагаемых. При LUT 4-х-входовой можно вычислить перенос только для 2-разрядных чисел. Дальше придется объединять несколько LUT. А это - задержки, куда большие, чем в аппаратных цепях последовательного переноса. Скорее всего, лучшим решением будет комбинированная схема, где есть и параллельные и последовательные переносы.

[Shtirlits]

Спасибо, дошло.

У меня все перемешалось, lookahead и prediction. Кстати, для маленьких сумматоров lookahead крайне выгоден несмотря на увеличение площади. А я имел в виду именно предсказание переноса(ов) в середине сумматора.