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

[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. Добавлю - задержка на такт не дается "даром". В счетчике теряется одно из состояний, т.е., если бы он был загружаемым, он не смог бы делить на любое допустимое число.

[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 слоёв логики. С использованием цепей быстрого переноса такое реализовать на современных ПЛИСах вполне реально. Без цепей быстрого переноса частотка угробится сразу и очень сильно.