Работе по фронтам не клокового входа, чем черевато? Опции

[Golikov A.]

Всем привет!

Волею судеб так получилось что spi клок пришелся на не клоковый вход.

Чем грозит использование его в конструкциях вида

Код

always @(posedge clk_pin)
begin

end

?

[Golikov A.]

теперь бы еще узнать как это делается. Я совсем совсем не силен в констрейнах....

[SM]

теперь бы еще узнать как это делается. Я совсем совсем не силен в констрейнах....

А Вы почитайте подробный отчет анализа SETUP-ов и HOLD-ов - там должно быть написано, что он там с чем суммировал в каком анализе, что получилось, и какой запас (или нарушение) - проанализируйте это, и придет ясность, как правильно обконстрейнить. К сожалению, повторю, я с ксилинкс дела не имел, поэтому гарантировано точно не могу подсказать, как правильно описать HOLD (удержание старых данных после клока, не менее, чем на сколько то) - я говорю по аналогии с другими средами разработки.

Но "анализ отчета анализатора", подробного отчета, должен по идее все расставить по своим местам.

----------------------
UPD:
Хмммм.... Пожалуй, я был неправ... Поверхностное чтение документации на констрейны xilinx показывает, что там нет возможности обконстрейнить HOLD для выходов (для входов однако есть - OFFSET IN ... VALID ....), есть только возможность его узнать, какое оно получилось, анализом минимального времени. И у самого есть вопрос к знатокам хилых - что, внатуре нет?

Странно все это...

[Dr.Alex]

Странно все это...

А каким образом вообще можно управлять минимальным холдом выхода? Он что, задержки там будет вставлять?

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

[SM]

А каким образом вообще можно управлять минимальным холдом выхода? Он что, задержки там будет вставлять?

Латис, как и альтера, например, после разводки, когда все SETUP-ы утрясли, проводят (опциональный) "Par hold correction" (ниже привожу лог, как они, конкретно латис в данном случае, это делают в одном из проектов). Реально, они удлиняют пути от тех регистров, от которых оказался слишком быстрый путь на выход, либо удлиняя разводку, либо вставляя лишние буфера. Кстати. Точно так же делают и среды разводки заказных ИМС, тот же encounter например, втыкая лишние буфера куда надо, когда запускается коррекция холдов.


И вопрос стоял не "зачем", и не "как это внутри делается", а как это описать констрейнами:

дано: Спецификация PCI rev 3.0, Table 7-4, Tval, значения min=2нс, max=6нс, CLK=66МГц

для латиса:

CLOCK_TO_OUT PORT "pci_nTRDY" MAX 6.00 ns MIN 2.00 ns CLKPORT "pci_CLK" ;

для альтеры:

set_output_delay 9.1515 -clock pci_CLK -max [get_ports pci_nTRDY]
set_output_delay -2.00 -clock pci_CLK -min -add_delay [get_ports pci_nTRDY]

UPD: для пояснения, 9.1515 это период клока 66 МГц (15.1515) минус те самые 6 нс спецификации PCI/66


кстати. вот заодно и ответ на "зачем" - для PCI например. где 2 нс минимум по спецификации - и у кучи путей, разведенных "кое как", но с соблюдением MAX_DELAY, получается ошибка по MIN_DELAY из-за образовавшихся "коротких и быстрых путей" !


А для XILINX как это написать?

CODE

Start NBR section for re-routing
Level 4, iteration 1
0(0.00%) conflict; 0(0.00%) untouched conn; 0 (nbr) score;
Estimated worst slack/total negative slack: 0.886ns/0.000ns; real time: 3 mins 1 secs

Start NBR section for post-routing

End NBR router with 0 unrouted connection

NBR Summary
-----------
Number of unrouted connections : 0 (0.00%)
Number of connections with timing violations : 0 (0.00%)
Estimated worst slack : 0.886ns
Timing score : 0
-----------
Notes: The timing info is calculated for SETUP only and all PAR_ADJs are ignored.

Par hold correction will be run with extra effort.

Hold time optimization iteration 0:
There are 91 hold time violations, the optimization is running ...
End of iteration 0
43027 successful; 0 unrouted; real time: 3 mins 28 secs

Hold time optimization iteration 1:
There are 3 hold time violations, the optimization is running ...
Starting iterative routing.
End of iteration 1
43027 successful; 0 unrouted; real time: 3 mins 36 secs

Hold time optimization iteration 2:
There are 3 hold time violations, the optimization is running ...
End of iteration 2
43027 successful; 0 unrouted; real time: 3 mins 44 secs

Hold time optimization iteration 3:
All hold time violations have been successfully corrected in speed grade M

Total CPU time 4 mins 7 secs
Total REAL time: 4 mins 17 secs
Completely routed.
End of route. 43027 routed (100.00%); 0 unrouted.
Checking DRC ...
No errors found.

Hold time timing score: 0, hold timing errors: 0

Timing score: 0