[ViKo 1]

Наверное, ответ на такой вопрос - очевиден. Конкретизируйте.

Если сигнал на входе, предназначенном для тактов ПЛИС будет соответствовать требуемым характеристикам (размах, частота), то такты внутри ПЛИС будут работать. Требуемые характеристики описаны в даташите. Как эти такты будут использованы внутри, зависит от разработчика.

P.S. Если ногу какую-нибудь нужную не припаять к питанию или земле - тоже работать не будет.

[SergeyF 0]

Если я заведу clk от мезонинной платы и частота порядка 200 МГц, будет работать нормально?

Ставьте низкочастотный и задействуйте PLL.

 

А насчет быстродействия все-таки попробуйте просто задействовать altaccumulate. Разрядов до 40-50 EP1C с любой градацией по быстродействию аккумулятор 200МГц должен вытянуть без всякой конвейеризации.

[skilful 0]

спасибо

[lexus.mephi 0]

Вопрос по теме.

Сделал схему суммирования в структурном виде на Verilog'e, но выигрыш во времени оказался недостаточным.

Попробовал использовать сумматоры из библиотеки DesignWare. Результат получился лучше, но возник вопрос:

Нет ли каких-нибудь побочных эффектов от использования элементов DesignWare? Могут ли возникнуть проблемы при смене библиотеки?

И может кто-нить знает что там за схемы такие синтезируются? Просто я много времени потратил, чтобы найти реализацию самой быстрой схемы переноса,

и мне очень интересно за счет чего сумматор из DesignWare переплюнул мой сумматор. Вот мой:

module fourbitadd(a,b,c_in,sum,c_out);
// i/o declarations
input [3:0] a,b;
input c_in;
output [3:0]sum;
output c_out;
wire [3:0] p,g,c;
assign p[0]=a[0]|b[0];
assign p[1]=a[1]|b[1];
assign p[2]=a[2]|b[2];
assign p[3]=a[3]|b[3];
assign g[0]=a[0]&b[0];
assign g[1]=a[1]&b[1];
assign g[2]=a[2]&b[2];
assign g[3]=a[3]&b[3];
assign c[0]= g[0]|(p[0]&c_in);
assign c[1]= g[1]|(p[1]&g[0])|(p[1]&p[0]&c_in);
assign c[2]= g[2]|(p[2]&g[1])|(p[2]&p[1]&g[0])|(p[2]&p[1]&p[0]&c_in);
assign c[3]= g[3]|(p[3]&g[2])|(p[3]&p[2]&g[1])|(p[3]&p[2]&p[1]&g[0])|(p[3]&p[2]&p[1]&p[0]&c_in);
assign sum[0]=a[0]^b[0]^c_in;
assign sum[1]=a[1]^b[1]^c[0];
assign sum[2]=a[2]^b[2]^c[1];
assign sum[3]=a[3]^b[3]^c[2];
assign c_out=c[3];
endmodule

[SergeyF 0]

и мне очень интересно за счет чего сумматор из DesignWare переплюнул мой сумматор.

Ну наверняка это обсуждалось. Надо ориентироваться на архитектуру ПЛИС.

 

Вы сделали классический четырехбитный модуль с предсказанием переноса (carry look-ahead adder). Теоретически в сумматоре с предсказанием переноса перенос из старшего разряда группы формируется быстрее, чем в архитектуре, например, c последовательным переносом. Но ни в одной известной мне ПЛИС такая схема аппаратно не поддерживается.

 

В Cyclone II, III, IV используется теоретически самая медленная схема с последовательным переносом. Но зато там один уровень переноса в несколько раз быстрее, чем обратная связь в логическом блоке. Аппаратное ускорение, скажем так. См. даташит.

В Cyclone и Stratix была вообще реализована схема с выбором переноса (carry select adder) - тут перечисленные выше архитектуры сумматоров просто курят в сторонке.

В Stratix II,III,IV сумматоры реализованы отдельно от таблиц перекодировки, и они тоже быстрые.

 

Поэтому разрядов до 16-32 смысла дергаться вообще нет. Пишите a+b и пусть синтезатор это сам делает для конкретной архитектуры. При очень больших разрядностях можно попробовать подробить сумматор на блоки небольшой разрядности с последовательным переносом и попробовать из них построить более быстрый сумматор. Какие есть варианты ускорения:

1. С предсказанием переноса - то, что сделали Вы. Надо, по сути, не использовать перенос из старшего разряда блока, а сформировать его комбинаторно:

assign c[3]= g[3]|(p[3]&g[2])|(p[3]&p[2]&g[1])|(p[3]&p[2]&p[1]&g[0])|(p[3]&p[2]&p[1]&p[0]&c_in);

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

2. С выбором переноса. Думаю будет быстрее, но так как каждый блок будет дублироваться для случая входного переноса 0 и 1, а потом их выходы будут мультиплексироваться, схема потребует порядка 3n логических элементов против n логических элементов для последовательного переноса.

[Des333 0]

lexus.mephi:

 

А чем Вас такой вариант не устраивает?

 assign {c_out, sum} = c_in + (a + b);

 

Для Cyclone III дает 524МГц против 389МГц Вашей реализации.

[SM 0]

И может кто-нить знает что там за схемы такие синтезируются?

Документация на дизайнварь (на конкретную синтетическую библиотеку) и знает. Пример от сынопсуса:

 

Для альтеры DW мапится на LPM как я понимаю, а описание LPM есть в квартусе.

dw01_add.pdf

[lexus.mephi 0]

Огромное спасибо за помощь.

Из всего вышеизложенного можно сделать вывод, что с развитием средств синтеза поведенческое описание стало давать лучший результат, нежели структурное.

По крайней мере для арифметических операций.

[SM 0]

Из всего вышеизложенного можно сделать вывод, что с развитием средств синтеза поведенческое описание стало давать лучший результат, нежели структурное.

По крайней мере для арифметических операций.

Естественно лучше, потому что поведенческое подлежит дополнительной оптимизации, такой как шаринг и datapath optimization, а потом один хрен мапится на тот же DW или LPM для синтеза уже конкретного оператора. А что касается описания жесткой структуры - это просто бывает необходимо в ряде случаев.

[Des333 0]

А что там врубаться? Гляньте на свою картинку в первом посте - там стоит один регитср. А вы поставьте два, или три, один за другим последовательно. И включите register retiming и pipelinig в настройках фиттера в квартусе. Он автоматически конвейеризирует схему, синтезированную по Вашему описанию, "протащив" эти регистры внутрь сумматора. У синплифая, кстати, тоже эти галки аж чуть ли не жирным шрифтом в главном окне проета торчат.

 

А Вы уверены, что ничего не путаете?

 

 

По-моему, Квартус такого не умеет.