Констрейны на глобальные сигналы: как правильно?, Сделать из багов фичи Опции

[Koluchiy]

Здравствуйте, уважаемые гуру.

Хотца сделать банальнейшую вещь, а именно - использовать глобальные сигналы для передачи своих сигналов.
Ну например: секундный импульс.
Представляет из себя сигнал, который равен 1 один такт в секунду, всё остальное время он равен нулю.
Ну то есть, ____________________________/\________________________________/\__________

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

Фишка в том, что нет никаких проблем, если к логике этот сигнал будет приходить с задержкой на такт, лишь бы приходил на всей микросхеме в пределах одного такта и с соблюдением времен установки/удержания триггеров.

Как это правильно сделать?

Применим ли здесь Multicycle, например так:

Код

set_multicycle_path -from [get_registers {TCNTR_TimeCounter:CNTR_TimeCounter|Time_1S_Pulse}] -to * -setup -end 2
set_multicycle_path -from [get_registers {TCNTR_TimeCounter:CNTR_TimeCounter|Time_1S_Pulse}] -to * -hold -end 1

Ну то есть, насколько я понимаю эти констрейны, они требуют, чтобы сигнал Time_1S_Pulse анализировался относительно 2-го фронта, считая за 0 - фронт генерации Time_1S_Pulse.

Сможет ли фиттер обеспечить разводку по таким констрейнам, т.е. добавить необходимую задержку для "перекидывания" сигнала через 1-й фронт.

Всем заранее спасибо за ответы.

P.S. Altera, TimeQuest.

[barabek]

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

А если большой счетчик разбить на 2 или несколько счетчиков? Или в крайнем случае большой счетчик с периодом пол-секунды, а после него делитель на 2, ну т.е. один триггер. Он то быстро будет щелкать. И уже сигнал с него рассылать. Не пойдет?

[Hoodwin]

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

Ну, типа такого:

Код

if rising_edge( clk ) then
  count <= count + 1;
  flag_1s <= '0';
  if count = (PERIOD_IN_CYCLES-1) then
    count <= 0;
    flag_1s <= '1';
  end if;

  pulse <= flag_1s;
end if; -- rising edge

Транслятор будет автоматически делать register duplication для триггера pulse и в итоге всюду будет сфазированный.

Я правда, видимо, не понял главного, зачем пихать это в глобальный сигнал.

[Koluchiy]

Я правда, видимо, не понял главного, зачем пихать это в глобальный сигнал.

В глобальный сигнал - потому что много потребителей у этого импульса.

Транслятор будет автоматически делать register duplication для триггера pulse и в итоге всюду будет сфазированный.

Он как-то очень хаотично его делает - то делает, то не делает, причем когда не делает - потом на него же ругается, что из-за него всё тормозит.

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

Собственно, так и есть. TCNTR_TimeCounter:CNTR_TimeCounter|Time_1S_Pulse - это триггер как раз после компаратора.

А если большой счетчик разбить на 2 или несколько счетчиков? Или в крайнем случае большой счетчик с периодом пол-секунды, а после него делитель на 2, ну т.е. один триггер. Он то быстро будет щелкать. И уже сигнал с него рассылать. Не пойдет?

Проблема не в самом триггере, а в пути от него до потребителей - микросхема большая, потребителей много, чтобы всё это работало не слишком долго, фиттер тянет все потребляющие этот сигнал цепи к генератору секундного сигнала, что портит разводку.

[des00]

Проблема не в самом триггере, а в пути от него до потребителей - микросхема большая, потребителей много, чтобы всё это работало не слишком долго, фиттер тянет все потребляющие этот сигнал цепи к генератору секундного сигнала, что портит разводку.

logic/register duplication включить, max_fanout ограничить. Но вообще на частотах до 200МГц, 3000 нормальный фанаут что бы работало без этих танцев (сыклон 3)

[Koluchiy]

Попробовал так, как написал в корне:

Код

set_multicycle_path -from [get_registers {TCNTR_TimeCounter:CNTR_TimeCounter|Time_1S_Pulse}] -to * -setup -end 2
set_multicycle_path -from [get_registers {TCNTR_TimeCounter:CNTR_TimeCounter|Time_1S_Pulse}] -to * -hold -end 1

В результате, картина маргарином.

Период тактового сигнала T = 5.714нс (175 Мгц).
Я хочу, чтобы сигнал Time_1S_Pulse приходил в интервале между T и 2*T, т.е. (если не считать времен установки и удержания) от 5.714нс до 11.428.

После компиляции, максимальная задержка - 7.968 (нормально, Tsetup выдерживается с запасом), минимальная - 5.209, т.е. время установки не выдерживается больше чем на пол-наносекунды.

=> то ли я не так задал констрейн на hold, то ли здесь мультициклы вообще неприменимы.

Но вообще на частотах до 200МГц, 3000 нормальный фанаут что бы работало без этих танцев (сыклон 3)

Там фанаут тысяч 5...
Stratix-IIGX в самой медленной градации...

[des00]

Попробовал так, как написал в корне:

скрин бы отчета TQ по этому пути.

я бы сделал так -to [all_clocks {}]

Период тактового сигнала T = 5.714нс (175 Мгц).
Я хочу, чтобы сигнал Time_1S_Pulse приходил в интервале между T и 2*T, т.е. (если не считать времен установки и удержания) от 5.714нс до 11.428.

этого, мультицикл не гарантирует.

Там фанаут тысяч 5...
Stratix-IIGX в самой медленной градации...

не вижу проблем, дуплицирование двух-четырех регистров должно решить проблему.

[ViKo]

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

[Koluchiy]

Мне бы хотелось, чтобы мне посоветовали, как сделать через констрейны (если это возможно), а все советуют на регистрах...

Всё как всегда...

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

[des00]

Мне бы хотелось, чтобы мне посоветовали, как сделать через констрейны (если это возможно), а все советуют на регистрах...

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

[Koluchiy]

я бы сделал так -to [all_clocks {}]

Результат идентичный.
Скрин положу в понедельник.

[Stewart Little]

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

Что-то я не могу проникнуться глубиной мысли...
Если нужно какой-то сигнал засандалить на глобальную линию, то можно воспользоваться примитивом GLOBAL .
Только что это в данном случае даст? Предположим, что сигнал по глобальной линии добегает до всех ALM'ов примерно в одно время. Что с ним ALM'у делать дальше? Насколько я понял, этот сигнал должен попасть в ALUT. Как его вытягивать на Local Interconect с глобальной линии?
Или я не прав?

[des00]

Как его вытягивать на Local Interconect с глобальной линии?

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

меня другое в ква удивляет : поставим Max_Fanout в 200, вот если их будет например 205, то он дуплицирует логику, на одну точку повесит 200 точек подключения, а на другую 5. Даже попытку балансировать нагрузку не предпринимает (до 9.1 версии включительно).

[Stewart Little]

правда задержка чтобы затащить и вытащить сигнал с этой линии порой перекрывает весь возможный выигрыш Лучше дуплицировать.

О то ж, я именно это и имел в виду

[Koluchiy]

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

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

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

Если нужно какой-то сигнал засандалить на глобальную линию, то можно воспользоваться примитивом GLOBAL .

Логично, так и затягиваю. А что, есть еще способы?

нормально он вытягивается, правда задержка чтобы затащить и вытащить сигнал с этой линии порой перекрывает весь возможный выигрыш

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

Лучше дуплицировать.

Тоска у него с дуплицированием. Ставлю цепочку из нескольких триггеров, чтобы дуплицированием сделал иерархическое дерево и развел сигнал куда надо.
Смотрю результат фиттера - никакого дерева нет, вся цепочка спиралькой расставлена в центре, к концу цепочки стянуты потребители. TimeQuest ругается на то, что часть потребителей не удалось притянуть достаточно близко.

Вручную, наверное, дерево можно сделать и результат будет лучше (если сделать так, чтобы синтезатор не выкинул дублирующие триггеры ).

[MHC]

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

и всем тем, кто тут предлагает "делить счетчик пополам и т.д":
кто Вам всем сказал, что разрядности счётчика или компаратора влияют на задержку выхода результата? upcounter представляет из себя конвейерную цепочку триггеров и, соответственно, работает с задержками одного триггера. Только не надо путать счетчик и сумматор. в последнем используются переносы битов, со всеми вытекающими задержками.

[Bad0512]

и всем тем, кто тут предлагает "делить счетчик пополам и т.д":
кто Вам всем сказал, что разрядности счётчика или компаратора влияют на задержку выхода результата? upcounter представляет из себя конвейерную цепочку триггеров и, соответственно, работает с задержками одного триггера. Только не надо путать счетчик и сумматор. в последнем используются переносы битов, со всеми вытекающими задержками.

Вы бы хоть почитали немного о том, как устроены счётчики и что такое перенос к примеру прежде чем со своими умными замечаниями лезть...
Правильно советуют. Счётчик на 175000000 легко пилится на 2 14-разрядных параллельных счётчика. Второй счётчик получает на свой вход CE перенос от первого счётчика предварительно пропущенный через триггер дабы задержки переноса в первом счётчике не суммировались с задержками второго. Второй счётчик своим переносом (опять же протактированным) кормит всю оставшуюся часть схемы с большим fanout. Если цепь с большим fanout плохо разводится (во что я честно говоря не верю, ибо речь идёт о стратиксах 4 и частотке всего 175 МГц) то этот fanout можно уменьшить несколькими способами.
Синтезатор сам где надо навтыкает дуплицирующих триггеров.Fanout можно поменять глобально (в любом синтезаторе есть такая настройка), а можно и локально - атрибутом на конкретную цепь. Как делать - это ваш выбор. Но ничего сверхужасного, что требовало бы плясок с бубном вокруг глобальных цепей и constrains я тут не вижу. Всё тривиально.

[des00]

кто Вам всем сказал, что разрядности счётчика или компаратора влияют на задержку выхода результата? upcounter представляет из себя конвейерную цепочку триггеров и, соответственно, работает с задержками одного триггера. Только не надо путать счетчик и сумматор. в последнем используются переносы битов, со всеми вытекающими задержками.

Как минимум синтезаторы, которые последние лет 5-8, на всех современных плис синтезируют счетчики на основе ячеек аппаратных суммторов с быстрым переносом. А вот некоторые разработчики до сих пор мыслят в рамках К155, вместо примитивов целевой ПЛИС %)

Результат идентичный.
Скрин положу в понедельник.

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

[Koluchiy]

что-то вы умалчиваете

Только давайте не будем Шерлоками Холмсами.
Любой интересующийся может в любой момент соорудить проект (или взять имеющийся) и попробовать.

не может ква так тупить

Ага .
меня другое в ква удивляет : поставим Max_Fanout в 200, вот если их будет например 205, то он дуплицирует логику, на одну точку повесит 200 точек подключения, а на другую 5. Даже попытку балансировать нагрузку не предпринимает (до 9.1 версии включительно).

[des00]

Только давайте не будем Шерлоками Холмсами.
Любой интересующийся может в любой момент соорудить проект (или взять имеющийся) и попробовать.

да что пробовать, у меня проекты с фанаутом 2000 - 3500 на третьем сыклоне под 200 МГц и нет таких проблем как у вас на стратиксе

ЗЫ. да фанауты меньше, но и сыклон не стратикс

[Koluchiy]

Я не буду всех убеждать в совершенстве своего проекта - он несовершенен, и я это знаю лучше всех .

Тем не менее, мне бы хотелось обсуждать не совершенство/несовершенство моего проекта, и не пути его улучшения, а именно то, что мне хотелось бы обсуждать - а именно, использование глобальных тактовых сигналов для цепей с большим фанаутом и компенсация задержек ввода/вывода сигналов на глобальные сигналы и из них.

[des00]

- а именно, использование глобальных тактовых сигналов для цепей с большим фанаутом и компенсация задержек ввода/вывода сигналов на глобальные сигналы и из них.

Вам же уже сказали %)
1. Вы не можете гарантировать точные времена задержек, у квартуса тоже нет возможности выровнять их, т.к. он этому не обучен.
2. Назначая мультицикл вы не сможете гарантировать задержку, вы всего лишь облегчаете условия выполнения tsu/th для определенного сигнала. Но это не означает что этот сигнал добежит до ВСЕХ остальных именно через такт. Почему у вас не сработало задание мультицикла для вашего проекта, по "фотографии" вылечить нельзя. Как минимум нужно посмотреть full_path отчет о tsu/th по конкретным путям.
3. Задавать max_net_delay/min_net_delay для асинхронных путей опять же бессмысленно, квартус не умеет выравнивать такие пути и эти параметры задаются скорее для успокоения совести, фиттер на них не смотрит и они даже не входят в комманду проверки валящихся путей (ну до 9.1 точно не входили, врядли что-то изменилось в 11 ой версии).

В таких условиях, в вашем случае лучше всего мультиплицировать регистры и вот тут начинается вопрос : почему у вас ква не хочет этого делать автоматически. Что бы это выяснить по "фотографии" нужны нехилые телепатические способности. Поэтому ИМХО либо ждите телепата, либо перестаньте обижаться и давайте обратную связь.

ЗЫ. если бы не стояла задача обеспечить однозначность прихода импульса на все ваши блоки, то задача решается элементартно. set_false_path + два тригера в каждом модуле, куда приходит сигнал.

ЗЫ.

меня другое в ква удивляет : поставим Max_Fanout в 200, вот если их будет например 205, то он дуплицирует логику, на одну точку повесит 200 точек подключения, а на другую 5. Даже попытку балансировать нагрузку не предпринимает (до 9.1 версии включительно).

лечится как раз разрешением дуплицирования логики, на автомате и этой функции квартус порой творит чудеса по утаптыванию проектов, как по времянке, так и по уменьшению ресурса(!!!)

[dvladim]

да что пробовать, у меня проекты с фанаутом 2000 - 3500 на третьем сыклоне под 200 МГц и нет таких проблем как у вас на стратиксе

Да какая разница какой фанаут? Это ж ПЛИС, а не АСИК. Все нагрузки уже есть и их меньше не станет в зависимости от фанаута. Для задежки важно лишь относительное расположение источника и приемников нэта.

[Bad0512]

Да какая разница какой фанаут? Это ж ПЛИС, а не АСИК. Все нагрузки уже есть и их меньше не станет в зависимости от фанаута. Для задежки важно лишь относительное расположение источника и приемников нэта.

Вот тут позволю не согласиться. По крайней мере для Xilinx существует такое понятие как ресурс интерконнекта. И этот ресурс тоже конечен. Это значит что если вы директивами маппера запихаете всю вашу логику в очень ограниченный кусок, то это совсем не означает, что в этом ограниченном куске цепь с большим фанаутом разведётся лучше (с точки зрения времянки естественно).

[MHC]

Вы бы хоть почитали немного о том, как устроены счётчики и что такое перенос к примеру прежде чем со своими умными замечаниями лезть...
Правильно советуют. Счётчик на 175000000 легко пилится на 2 14-разрядных параллельных счётчика. Второй счётчик получает на свой вход CE перенос от первого счётчика предварительно пропущенный через триггер дабы задержки переноса в первом счётчике не суммировались с задержками второго.
.....

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

Как минимум синтезаторы, которые последние лет 5-8, на всех современных плис синтезируют счетчики на основе ячеек аппаратных сумматоров с быстрым переносом. А вот некоторые разработчики до сих пор мыслят в рамках К155, вместо примитивов целевой ПЛИС %)

гм... либо я не те ПЛИС пробую, либо не с тем синтезатором, либо просто отстаю от жизни...
по поводу "ячеек аппаратных сумматоров с быстрым переносом" -- это как? к примеру, у виртексов 4-5-х из основных элементов я знаю только clb-блоки, ram-блоки и блоки dsp48 (я ничего не пропустил?). И я сильно разочаровался бы, если б синтезатор сделал мне данный счётчик на dsp48. У последних имеется уйма куда более полезных применений. Но, к счастью, синтезатор от ise13.1 в 5-м виртексе и с дефолтными настройками выдал мне в качестве результата 28-ми битный upcounter на clb-блоках (проверено в "technology schematic").

[dvladim]

Но, к счастью, синтезатор от ise13.1 в 5-м виртексе и с дефолтными настройками выдал мне в качестве результата 28-ми битный upcounter на clb-блоках (проверено в "technology schematic").

В clb блоках как раз есть аппаратные ускорители цепи переноса. ug190.pdf стр. 198. Fast Lookahead Carry Logic

[MHC]

В clb блоках как раз есть аппаратные ускорители цепи переноса. ug190.pdf стр. 198. Fast Lookahead Carry Logic

ага, понятно, спасибо.

[ViKo]

покажите пальцем: где зависимость задержки выхода от разрядности счетчика?

Давайте я вам покажу -
см на элемент, формирующий сигнал T4 (AND4), и на элемент, формирующий сигнал TC (уже AND5). Сигнал T4 участвует в формировании сигнала TC. То есть, пока T4 не сформируется, TC не начнет формироваться. Дальше - больше. Потребуются AND6, AND7, AND8, AND9... В конце концов перенос съедается совсем. И не cможет сформироваться за период тактовой частоты.
Схемы быстрого переноса не меняют в принципе формирования переноса ничего. Также рано или поздно съедаются. Спасает задержка на такт на триггере. Появляется целый такт времени для формирования переносов.

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

P.S. Добавлю - задержка на такт не дается "даром". В счетчике теряется одно из состояний, т.е., если бы он был загружаемым, он не смог бы делить на любое допустимое число.

[MHC]

Давайте я вам покажу - см на элемент, формирующий сигнал T4 (AND4), и на элемент, формирующий сигнал TC (уже AND5).

это совсем другая задержка, которая отвечает лишь за то, что счётчик тупо будет или не будет работать на выбранной тактовой частоте. 28 -- сложно судить: много это или мало но, как бы там ни было, это меньше 2^5. и, пусть даже "энды" делались бы на 2-х входовых элементах, то с оптимизацией синтезатора по скорости (как и выставлено по дефолту в ise13.1) имеем в худшем случае последовательный проход сигнала через 5 элементов, согласно рисунку:
.
Но, во-первых, мы уже давно имеем дело с четырех и более -входовых LUT'ами.
И, во-вторых, речь идет совсем о другой задержке: о задержке выдачи результата относительно времени прихода клока. И эта задержка, по-прежнему, остается равной задержке одного триггера.

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

угу, сейчас попробовал с теми же условиями: оптимизация по объему -- 350 МГц, оптимизация по скорости (дефолтная) -- 550 МГц.

[Bad0512]

это совсем другая задержка, которая отвечает лишь за то, что счётчик тупо будет или не будет работать на выбранной тактовой частоте. 28 -- сложно судить: много это или мало но, как бы там ни было, это меньше 2^5. и, пусть даже "энды" делались бы на 2-х входовых элементах, то с оптимизацией синтезатора по скорости (как и выставлено по дефолту в ise13.1) имеем в худшем случае последовательный проход сигнала через 5 элементов, согласно рисунку:
.
Но, во-первых, мы уже давно имеем дело с четырех и более -входовых LUT'ами.
И, во-вторых, речь идет совсем о другой задержке: о задержке выдачи результата относительно времени прихода клока. И эта задержка, по-прежнему, остается равной задержке одного триггера.


угу, сейчас попробовал с теми же условиями: оптимизация по объему -- 350 МГц, оптимизация по скорости (дефолтная) -- 550 МГц.

Вы нарисовали сейчас бинарное дерево формирования преноса для n-го бита. Для формирования только одного переноса такая схема пойдёт вполне. Однако в реальной жизни для работы счётчика также необходимо сформировать переносы для ВСЕХ предыдущих n-му разрядов. Поэтому в реальности переносы формируются последовательно дабы не дуплицировать нарисованные вами бинарные деревья для КАЖДОГО разряда. Таким образом, количество "слоёв логики" необходимое для формирования м-разрядного счётчика при r-входовых LUT будет равно (м-1)/(r-1) . Вторая минус единица тут появляется потому, что один вход как раз и занят под переносы со всех младших разрядов. Для первой группы этот вход можно не пользовать (поэтому минус первая единица). Тогда к примеру для 34-разрядного счётчика и 5-входовой LUT необходимо 9 слоёв логики. С использованием цепей быстрого переноса такое реализовать на современных ПЛИСах вполне реально. Без цепей быстрого переноса частотка угробится сразу и очень сильно.

[des00]

по поводу "ячеек аппаратных сумматоров с быстрым переносом" -- это как?....

правильно ли я понимаю, что вопрос о реализации счетчиков на современных ПЛИС снят с повестки дня ?

Если вы не против и вам не лень, то вот вам еще пищи для мозга, на сыклоне 1, 32 битный счетчик, описаный в коде как pipa <= pipa + 1'b1 свободно работал до частоты близкой к максимальной, на 2/3 сыклонах этого можно было добиться только с помощью дроблений счетчика на более мелкие. Опираясь на даташиты попробуйте ответить почему так.

[Мур]

...на 2/3 сыклонах этого можно было добиться только с помощью дроблений счетчика на более мелкие.

Ух ты!...
Простите, а где об этом можно почитать? Мне это предстоит как раз в ближайшие пару дней...

Спасибо!

[bogaev_roman]

Простите, а где об этом можно почитать? Мне это предстоит как раз в ближайшие пару дней...

Хотя бы в блоге у des00 в статье по timequest для чайников во второй части есть конкретный пример разбивки 32-разрядного на 2 16-разрядных http://embedders.org/content/timequest-dly...-litsom-k-litsu

[des00]

Простите, а где об этом можно почитать? Мне это предстоит как раз в ближайшие пару дней...

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

Код

logic [31 : 0] fcnt;
logic  [3 : 0] cnt   [0 : 7];
logic          carry [0 : 7];

always_ff @(posedge iclk) begin
  for (int i = 0; i < 8; i++) begin
    cnt[i]   <= (i == 0) ? (cnt + 1'b1) : (cnt + carry[i-1]);
    carry[i] <= (cnt[i] == 4'd14);
  end
end

assign fcnt <= {cnt[7], cnt[6], cnt[5], cnt[4], cnt[3], cnt[2], cnt[1], cnt[0]};

[Мур]

Да!.. Я Verilog не очень знаю. Идея формирования в явном виде переносов от 8ми 4-х разрядных счетчиков? Я пытался в Алдеке код пустить на симулятор.(Чтобы ничего не пропустить перед переводом в VHDL) При моем "знании" языка пустое занятие... Буду корячиться!

Спасибо огромное!

[bogaev_roman]

Да!.. Я Verilog не очень знаю.

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

[Мур]

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

Все замечательно!.. Буду в железо заливать..

Прикрепленные файлы

 cnt16.vhd ( 2.96 килобайт ) Кол-во скачиваний: 32

 

[Koluchiy]

Я смотрю, тема ушла не то, чтобы не туда, а прямо совсем не туда .

Впрочем, если

Вы не можете гарантировать точные времена задержек, у квартуса тоже нет возможности выровнять их, т.к. он этому не обучен.

то исходная тема себя исчерпала.

[des00]

недавно решал похожую задачу, есть дсп блок, с него шина 36 бит идет на регистр, потом на 16 аккумуляторов, никак квартус не мог это место автоматом разрулить (а надо то всего поставить 2 регистра). Использование manual logic duplication тоже не помогло. В итоге maxfanout 8 быстро и однозначно решил вопрос %) (190МГц на С8, занятость 76%)

В случе ТС, можно сделать maxfanout = 1, может помочь %)