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

[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.

[MHC]

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

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

[des00]

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

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

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

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

[MHC]

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

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

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

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

[ViKo]

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

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

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

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