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

[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

[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, результат ваш видел, но считаю его неоднозначным, а ваш вывод не очевидным. Подробно разбираться с той темой не могу, и так работы много.