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

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

[des00]

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

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

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