Здравствуйте все.
Как правильно описать констрейн?


здесь нужно описать максимальную задержку сигнала со входа IN_1 до if(IN_1) в модуле next_mod.

с порта куда? (-to [get_???(IN_1}])

Хотя я тоже пока только учусь... Но помочь хочу.
Сигнал IN_1 куда идет / как используется? Из верилоговского описания - видимо clock_enable или synchronous reset... А в целом - не понятно.
Пример применения с использованием get_pins есть в статьях des00 - асинхронные интерфейсы.
Обратите внимание - чтобы узнать имя, которое потом указывать в get_pins, необходимо сделать предварительную трансляцию проекта. Впрочем, именно такая последовательность рекомендуется в "Quartus Handbook" (volume 3, chapter 7, "Recommended Flow").

Можно также в качестве -to указать клок (get_clocks/all_clocks) или регистр (get_registers/all_registers). Это при условии, что сигнал идет на регистр (можно ли это использовать для сигнала асинхронной установки/сброса - я не знаю).

Надеюсь, нигде не соврал

Я делаю так set_max_delay -from [get_ports {IN_1}] -to [get_cells {IN_1}] 5ns и это работает, практически проверять приходится. А вот правильно ли ?

Боюсь, что нет. Похоже, что Вы прописываете максимальную задежку от порта IN_1 до входного I/O-буфера. Вы можете проверить это, запустив report_path и locate_path. Или даже запустив в квартусе Netlist Viewers (Post Mapping). Возможно что использование wildchars (*) даст более корректный результат.

Однако мне кажется, что прописывать задержку нужно все-таки от порта IN_1 до регистра. Потому что сигнал с порта IN_1 идет на триггер/регистр (always @(posedge clk) ...). И хотя имя регистра в приведенном Вами коде не указано, но оно точно не IN_1.

А впрочем, давайте просто обменяемся результатами. Скажите (а лучше покажите), как Вы проверяете, что "это работает, практически проверять не приходится"?

Практически, при измерении временных данных с заполнением 5МГц, если не вскармливать данный констрейн, результаты хаотично прыгают. С констрейном все отлично. На сколько
я помню если делать set_max_delay -from [get_ports {IN_1}] -to [get_pins {IN_1|combout}] (скорее всего вот так правильно), то тоже все нормально. Поэтому и вопрос как же все таки правильно?

Зачем практически? TimeQuest же есть!

Вот, смотрите

Собираем проект, запускаем в квартусе Tools->Netlist Viewers->Technology Map Viewer (Post-Mapping)

Отсюда получаем, что нужно прописать задержку от портов en1 и en2 до входа триггера - имя триггера (cell) "d".
Соответственно полное имя пины будет d|d (см. статьи des00 - ссылка выше)
В данном примере это можно сделать такими способами:
1) set_max_delay -from [get_ports {en*}] -to [get_pins {d|d}] 5.0
2) set_max_delay -from [get_ports {en*}] -to [get_registers {d}] 5.0

Чтобы вывести репорт о величине задержке (для данного примера), используйте в консоли TimeQuest-а следующие команды:
report_path -from [get_ports {en*}] -to [get_pins {d|d}] -panel_name "bla-bla )))" - выводит максимальную задержку
report_path -from [get_ports {en*}] -to [get_pins {d|d}] -min_path -panel_name "bla-bla )))" - выводит минимальную задержку

Попробуйте сначала вывести репорт, когда в sdc-файле не задана max_delay.
Потом задайте max_delay, пересоберите проект и посмотрите репорт опять. Убедитесь, что квартус Ваше желание удовлетворил (или вывел предупреждение, что он Ваше желание понял, но выполнить не смог ).
Можно таким же макаром задать min_delay и посмотреть, как квартус реагирует на ваши хотелки.

хмм... Интересно, а почему TimeQuest не выдает предупреждений, если требование по max_delay не выполняется?
set_max_delay -from [get_ports {en*}] -to [get_pins {d|d}] 2.0
TimeQuest рапортует, что максимальная задержка "From node en1 To node d|d" составляет 2.277 нс. Однако никаких предупреждений по этому поводу не выводит...
Нужен des00!!!


Попутно вопрос - а зачем Вы используете констрейнт set_max_delay? Какие условия задачи и какие цели? Ведь здесь не учитывается задержка клока...

Сообщение отредактировал winipuh - Nov 5 2012, 15:01

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

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

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

Сообщение отредактировал winipuh - Nov 5 2012, 16:32

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

Да возможна куча вариантов. Если посмотреть SDC and TimeQuest API Reference Manual то вот краткое описание команды set_max_delay

Так что вам предоставлен весь спектр возможностей по идентификации приемника сигнала %)


Писал про это вроде в публикациях, что я пришел в выводу что квартус задержки крутить/выравнивать практически не умеет. Более того, в пакетном тесте, проверки временных ограничений (Report Top Failing Paths), проверка задержек вообще не включена (до ква 9.1 точно). Потому и пользоваться надо этим очень осторожно.

И не стоит считать меня истиной в последней инстанции, на форуме есть куда более знающие разработчики, но они редко пишут %(


Вот это странно, при измерении периода асинхронного сигнала нарезкой опорным клоком, ЕМНИП ошибка должна быть 2*T, где T - период нарезки и не должно зависеть от длинны цепочки.

Вот, практически так. Измерение очень точное, поэтому сразу заметно. Возможно это в MAX II только, в др. девайсах не пробовал.