ViKo

называется "найдите хоть одно отличие" :) То i, что взято в скобках , добавляется к dq_8_inst само при генерации. Таким, образом, каждый экземпляр будет иметь свое имя.

Нужно, чтобы фронты синхросигналов не совпадали с моментом изменения данных. Аналогичным образом ведет себя Quartus при функциональном моделировании.

В стандарте на SystemVerilog тоже специально обращается внимание на это. И переводил я их так shall – должно (необходимо, обязательно) should – может (рекомендуется) may – может (разрешается, допускается) can – можно (возможно)

Может быть, ошибаюсь, но до этого все домены верхнего уровня (а было их 6 штук) принадлежали США. Сейчас что-то изменилось оттого, что кириллицу можно использовать?

Я уже заменил (автоматически), пользуюсь EditPlus. В начале кода были пробелы. А по-нормальному табуляция - 8 пробелов.

Спасибо за код. Любопытно будет посмотреть, особенно, когда потребуется для конкретной задачи. Одно маленькое замечание - в коде большие отступы, похоже, делались табуляцией по 8 символов. Понимаю, что у каждого свое понятие о красоте и целесообразности, но, может быть отступы в 2-3-4 пробела покажутся вам удобнее. Я лично пользуюсь отступами в 2 пробела.

Продолжая эксперименты по теме, обсуждаемой в http://electronix.ru/forum/index.php?showt...mp;#entry839222 создал 4-ступенчатый конвейерный сумматор-аккумулятор module exAdderPipe ( input wire [31:0] din, input wire clk, output logic [32:0] dout ); bit [31:8] din1st; bit [8:0] sum1st; bit [31:16] din2st; bit [16:8] sum2st; bit [7:0] dout2st; bit [31:24] din3st; bit [24:16] sum3st; bit [15:0] dout3st; bit [32:24] sum4st; bit [23:0] dout4st; always @(posedge clk) begin din1st <= din[31:8]; sum1st <= din[7:0] + sum1st[7:0]; din2st <= din1st[31:16]; sum2st <= sum1st[8] + (din1st[15:8] + sum2st[15:8]); dout2st <= sum1st[7:0]; din3st <= din2st[31:24]; sum3st <= sum2st[16] + (din2st[23:16] + sum3st[23:16]); dout3st <= {sum2st[15:8], dout2st[7:0]}; sum4st <= sum3st[24] + (din3st[31:24] + sum4st[32:24]); dout4st <= {sum3st[23:16], dout3st[15:0]}; end assign dout = {sum4st, dout4st}; endmodule И обнаружил одно неприятное свойство (замечал и раньше, но здесь - уже "вопиющее безобразие"). В Q9.1SP2 для EPM1270T144A5 с настройками Speed (эта, похоже - вообще ничего не решает никогда), Standard Fit, Default required fmax = 150 MHz, Classic Timing Analisis дает 171.82 MHz и проект укладывается в 135 LE. Стоит только убрать круглые скобки в выражениях суммирования в показанном коде (во всех 3-х местах), изменить порядок вычисления, как получается 114 MHz и 159 LE. Неужели Quartus настолько туп?!

Давайте внесем ясность. Просто так с одной ступени на следующую перенос не передается. Ведь те переносы, что формируются внутри каждой ступени, имеют разную длительность. Их нужно объединять по И - все предыдущие, для формирования разрешения счета для следующей ступени. На этом объединении быстродействие счетчика и ограничивается. Если на одном LUT можно объединить 4 таких переноса, значит, максимально быстродействующий счетчик может быть 4*4 + 4 = 20 разрядов (каждая ступень - 4-разрядная, всего их 4 для формирования переноса и еще одна 4-разрядная ступень, использующая этот перенос). Дальше потребуется несколько логических элементов, чтобы выработать разрешение счета. Можно и последовательно передавать перенос-разрешение из ступени в ступень, что, естественно, будет еще медленнее. В-общем, 64-разрядный счетчик с быстродействием 2-разрядного регистра сдвига - не получится. P.S. а так, как я описал в сообщении №28 (и как ошибочно предположил, было сделано у вас в сообщении №35)- можно сделать быстрый счетчик. Потому что там не нужно учитывать предыдущие переносы. Только считать будет "абы что".

Забросил книгу в закрома - аплоад/буукс Посильнее "Фауста" Гете будет :)

Похоже, здесь речь идет не о задержке распространения, а о дельта-задержках при симуляции поведения устройства. Может, уже всю статью приведете? :)

Когда задал в Q9.1SP2 Fitter Effort - Standard Fit, для кода Sergey'F из сообщения №43 получилась частота 159.92 MHz. (До этого у меня стояла - Auto Fit, и частота была 127.88 MHz. Вроде, по-умолчанию так стоит) Когда задал Default required fmax - 150 MHz, частота выросла до 175.72 MHz. и все-то Quartus нужно "подпихивать" :)

2 sazh Разобрался в вашем коде. Вот это меня, действительно, впечатлило! Теперь мне уже странно, что до сих пор я пребывал в уверенности, что подобное невозможно. А оказалось все просто. Это ж можно ценой латентности складывать сколь угодно большие числа с максимальным быстродействием, невзирая на обратную связь. а я выставил в настройках "отображать 80 (кажется) сообщений на странице", и у меня все на одной:) upd. Q9.1SP2 для последнего кода и той же микросхемы выдал "реалистичных" 127.88 MHz при оптимизации Balanced или Speed. Может быть, что-то нужно подкрутить в настройках?

2 sazh Пока я читаю ваш код, сходите по приведенной мной ссылке. И прокомментируйте, если можно.

Пока ехал домой, сообразил, что можно проверять на условие на 1 меньше (или больше в вашем случае, для вычитающего счетчика). И тогда, действительно, код всего счетчика будет изменяться, как положено. Получается, так можно сделать счетчик любой длины. Если делать счетчик с перезагрузкой, придется с загружаемыми кодами "поработать". Но это работает для счетчика. Для сумматора нельзя предсказать, когда он должен выработать перенос заранее. Допустим, сумматор насчитал 0xfe, откуда знать, что придет на вход для суммирования? P.S. Насчет кода от sazh - это самое подходящее решение для поставленной задачи. Оно работает благодаря тому, что входные данные - 8-разрядные. Поэтому за один такт нужно выполнять суммирование 8 разрядов входного сигнала с 8-разрядной накопленной суммой. Старшие разряды накопленной суммы можно вычислять в следующем такте. Если бы, однако, входное слово имело все 24 разряда, конвейерная обработка была бы невозможна. upd. то же самое и у DmitryR (я, кажется, слегка попутал эти коды, когда отвечал) P.P.S. Приведу ссылку на разговор в не столь отдаленном прошлом http://electronix.ru/forum/index.php?showt...st&p=732059

Это вы меня опять отсылаете к стандарту? За что? :) А мое сообщение №11?

Вот на этом каскадировании и возникает конвейер. Потому что следующий счетчик считает не сразу после того, как предыдущий был в состоянии 1111, а в следующем такте. Я тоже делал практически также счетчик на 24 разряда с перезагрузкой, только выход переноса, подобный вашему, у меня был один. Работать мне нужно было на 100 MHz. А загружать приходилось число, на 2 меньше требуемого периода. Из-за той самой латентности, или как-там еще ее назвать... P.S. у вас сделано в точности с моим сообщением №28 :)

Это вы топикстартеру скажите. Можете поподробнее - что это, CLA? А, нашел, в ссылке. Carry LookAhead - как же, говорили об этом на форуме, совсем недавно. Там тоже есть ограничения по быстродействию. 64 разряда - фантастически выглядит. Не зря там дальше идет RCLA :)

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

А с остальными доводами - согласны? Не обязательно так, как написал, делать. Есть сигнал переноса у счетчика. Его подавать на разрешение следующей микросхемы. А чтобы эти сигналы все были короткими (один период тактовой частоты), их можно на триггерах формировать.

Правильно, так можно и на 1024 разряда сделать счетчик. С конвейером. С латентностью. Автор темы хотел за такт получать результат. Как пример, можно обычных микросхем - счетчиков соединить друг за другом, выход предыдущего - на клок следующего. И - никаких проблем с быстродействием. Весь счетчик будет считать на максимальной рабочей частоте, как для одной микросхемы.

Это вопрос терминологии. У вас в каждом такте будет выдаваться результат. Причем, старшая часть будет содержать результат от предыдущего суммирования, а младшая от последнего. Чтобы их выровнять, неплохо бы и младшую часть результата задержать на такт.

Как это? А распространение переносов по всем разрядам счетчика? Например 0xffffffffffffffff + 1

Когда не станет хватать M4K, Quartus сделает это на регистрах. Граница проходит по размеру LAB, похоже (т.е. 8).

но за два такта :)

На Verilog должно быть написано always @(negedge rst_n, posedge clk) if (!rst_n) ... else ... а что, на VHDL в списке чувствительности фронты/срезы задавать не нужно? А проверяется уже непосредственно внутри блока?