ViKo 1 10 марта, 2010 Опубликовано 10 марта, 2010 · Жалоба Наверное, ответ на такой вопрос - очевиден. Конкретизируйте. Если сигнал на входе, предназначенном для тактов ПЛИС будет соответствовать требуемым характеристикам (размах, частота), то такты внутри ПЛИС будут работать. Требуемые характеристики описаны в даташите. Как эти такты будут использованы внутри, зависит от разработчика. P.S. Если ногу какую-нибудь нужную не припаять к питанию или земле - тоже работать не будет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SergeyF 0 10 марта, 2010 Опубликовано 10 марта, 2010 · Жалоба Если я заведу clk от мезонинной платы и частота порядка 200 МГц, будет работать нормально? Ставьте низкочастотный и задействуйте PLL. А насчет быстродействия все-таки попробуйте просто задействовать altaccumulate. Разрядов до 40-50 EP1C с любой градацией по быстродействию аккумулятор 200МГц должен вытянуть без всякой конвейеризации. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
skilful 0 10 марта, 2010 Опубликовано 10 марта, 2010 · Жалоба спасибо Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
lexus.mephi 0 11 марта, 2010 Опубликовано 11 марта, 2010 · Жалоба Вопрос по теме. Сделал схему суммирования в структурном виде на 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 11 марта, 2010 Опубликовано 11 марта, 2010 · Жалоба и мне очень интересно за счет чего сумматор из 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 11 марта, 2010 Опубликовано 11 марта, 2010 · Жалоба lexus.mephi: А чем Вас такой вариант не устраивает? assign {c_out, sum} = c_in + (a + b); Для Cyclone III дает 524МГц против 389МГц Вашей реализации. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 12 марта, 2010 Опубликовано 12 марта, 2010 · Жалоба И может кто-нить знает что там за схемы такие синтезируются? Документация на дизайнварь (на конкретную синтетическую библиотеку) и знает. Пример от сынопсуса: Для альтеры DW мапится на LPM как я понимаю, а описание LPM есть в квартусе. dw01_add.pdf Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
lexus.mephi 0 12 марта, 2010 Опубликовано 12 марта, 2010 · Жалоба Огромное спасибо за помощь. Из всего вышеизложенного можно сделать вывод, что с развитием средств синтеза поведенческое описание стало давать лучший результат, нежели структурное. По крайней мере для арифметических операций. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 12 марта, 2010 Опубликовано 12 марта, 2010 · Жалоба Из всего вышеизложенного можно сделать вывод, что с развитием средств синтеза поведенческое описание стало давать лучший результат, нежели структурное. По крайней мере для арифметических операций. Естественно лучше, потому что поведенческое подлежит дополнительной оптимизации, такой как шаринг и datapath optimization, а потом один хрен мапится на тот же DW или LPM для синтеза уже конкретного оператора. А что касается описания жесткой структуры - это просто бывает необходимо в ряде случаев. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Des333 0 16 марта, 2010 Опубликовано 16 марта, 2010 · Жалоба А что там врубаться? Гляньте на свою картинку в первом посте - там стоит один регитср. А вы поставьте два, или три, один за другим последовательно. И включите register retiming и pipelinig в настройках фиттера в квартусе. Он автоматически конвейеризирует схему, синтезированную по Вашему описанию, "протащив" эти регистры внутрь сумматора. У синплифая, кстати, тоже эти галки аж чуть ли не жирным шрифтом в главном окне проета торчат. А Вы уверены, что ничего не путаете? По-моему, Квартус такого не умеет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться