Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Вопрос по описанию констрейна.
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
Iptash
Здравствуйте все.
Как правильно описать констрейн?
Код
module XX ( input clk, input IN_1);

next_mod YY (
                  .clk(clk),
                  .IN_1(IN_1)
                  );
endmodule

module next_mod (input clk, input IN_1);
  always @ (posedge clk) begin
      if(IN_1) begin
        ...
       end
endmodule


здесь нужно описать максимальную задержку сигнала со входа IN_1 до if(IN_1) в модуле next_mod.
Код
set_max_delay -from [get_ports {IN_1}] -to [get_??? {IN_1}] 5ns

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

winipuh
Хотя я тоже пока только учусь... sm.gif Но помочь хочу.
Сигнал 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). Это при условии, что сигнал идет на регистр (можно ли это использовать для сигнала асинхронной установки/сброса - я не знаю).

Надеюсь, нигде не соврал sm.gif
Iptash
Я делаю так set_max_delay -from [get_ports {IN_1}] -to [get_cells {IN_1}] 5ns и это работает, практически проверять приходится. А вот правильно ли ?
winipuh
Цитата(Iptash @ Nov 5 2012, 09:02) *
Я делаю так 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. laughing.gif

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

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

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

Вот, смотрите
Код
"tst.v"
module tst (input clk, input en1, input en2, output dout);
    reg d;
    always @(posedge clk)
        if (en1 & en2) d <= ~d;
    assign dout = d;
endmodule

"test.sdc
derive_clock_uncertainty
create_clock -period 50MHz -name {clk} [get_ports {clk}]

Собираем проект, запускаем в квартусе 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, пересоберите проект и посмотрите репорт опять. Убедитесь, что квартус Ваше желание удовлетворил (или вывел предупреждение, что он Ваше желание понял, но выполнить не смог sm.gif ).
Можно таким же макаром задать 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!!! sm.gif


Попутно вопрос - а зачем Вы используете констрейнт set_max_delay? Какие условия задачи и какие цели? Ведь здесь не учитывается задержка клока...
Iptash
Спасибо. Осталось далее поизучать до полного понимания процессов, что-куда-и зачем.
Цитата(winipuh @ Nov 5 2012, 18:36) *
Попутно вопрос - а зачем Вы используете констрейнт set_max_delay? Какие условия задачи и какие цели? Ведь здесь не учитывается задержка клока...

Задача, точное измерение периодов. Задержку клока не учитываю, потому что его переод очень мал по отношению ко вх. сигналу. Во всяком случае работает нормально. А вот
вх. сигналы без задания констрейнов, так не работает.
winipuh
Цитата(Iptash @ Nov 5 2012, 20:18) *
вх. сигналы без задания констрейнов, так не работает.

Я так понимаю, что входной сигнал асинхронный по отношению к клоку в ПЛИС? Против метастабильности цепочку триггеров поставили? Потому что тогда величина задержки уже ни на что влиять не будет.
Iptash
Входной фильтр конечно же стоит. Без него никак. Только фильтр в виде сдвигового регистра не работает, чем длинее цепочка, тем хуже результат.
des00
Цитата(Iptash @ Nov 5 2012, 08:42) *
Поэтому и вопрос как же все таки правильно?

Да возможна куча вариантов. Если посмотреть SDC and TimeQuest API Reference Manual то вот краткое описание команды set_max_delay
Цитата
Specifies a maximum delay exception for a given path.
The maximum delay is similar to changing the setup relationship (latching clock edge - launching clock edge), except that it can be applied to input or output ports without input or output delays assigned to
them. Maximum delays are always relative to any clock network delays (if the source or destination is a register) or any input or output delays (if the source or destination is a port). Therefore, input delays and
clock latencies are added to the data arrival times. Clock latencies also added to data required times and output delays are subtracted from data required times.

The -from and -to values are collections of clocks, registers, ports, pins, or cells in the design. If the -from or -to values are not specified, the collection is converted automatically into [get_keepers *]. It is worth
noting that if the counterpart to the unspecified collection is a clock collection, it is more efficient to explicitly specify this collection as a clock collection but only if the clock collection also generates the
desired assignment.

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

Цитата(winipuh @ Nov 5 2012, 09:36) *
хмм... Интересно, а почему 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 нс. Однако никаких предупреждений по этому поводу не выводит...

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

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

Цитата(Iptash @ Nov 5 2012, 12:21) *
Входной фильтр конечно же стоит. Без него никак. Только фильтр в виде сдвигового регистра не работает, чем длинее цепочка, тем хуже результат.

Вот это странно, при измерении периода асинхронного сигнала нарезкой опорным клоком, ЕМНИП ошибка должна быть 2*T, где T - период нарезки и не должно зависеть от длинны цепочки.
Iptash
Цитата(des00 @ Nov 5 2012, 22:56) *
Вот это странно, при измерении периода асинхронного сигнала нарезкой опорным клоком, ЕМНИП ошибка должна быть 2*T, где T - период нарезки и не должно зависеть от длинны цепочки.

Вот, практически так. Измерение очень точное, поэтому сразу заметно. Возможно это в MAX II только, в др. девайсах не пробовал.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.