Физический смысл частоты в ПЛИС Опции

[plisel]

Здравствуйте.

В ПЛИС новичок, ранее только с МК работал.

Не могу понять физический смысл частоты в ПЛИС?

Например в EPM240T100C5 есть внутренний генератор на 3-5 МГц. Значит ли это что я не смогу обрабатывать сигналы частотой выше 5МГЦ ?
А что если схема комбинаторная, только из логики and,or, ... не значит ли это что данные операции будут выполняться тоже на выбранной частоте генератора?

Или это просто генератор который я могу завести например на триггер, а операции and,or будут выполняться так сказать "асинхронно" с небольшой задержкой ?

Требуется ли в обязательном порядке использовать внутренний или внешний генератор?

[SM]

Это просто генератор, который можно использовать, как душе угодно, а можно и не использовать. Можно с внешнего генератора завести тактовую, и не одну, и еще внутри сделать что-то путем ее (их) деления или умножения на PLL.

Частота работы у синхронной схемы вычисляется исходя из соображений того, что сигнал, сформированный по фронту тактовой частоты триггером, пройдя через всю цепочку логики и разводки, должен успеть дойти до триггера, его принимающего (с учетом требований Tco, Tsu и Th самих триггеров), до следующего фронта тактовой. То есть, показывает максимальную частоту, на которой эта схема будет корректно работать, как описано в исходном описании.

Для асинхронной схемы понятие частоты в этом смысле бессмысленно, там надо смотреть каждый конкретный случай.

[Torpeda]

Требуется ли в обязательном порядке использовать внутренний или внешний генератор?

Независимо от того, что вы делаете в ПЛИС (схему с тригерами, только комбинаторику итп.) тулза делающая физическую реализацию вашего проекта (Quartus напр.) всё равно представляет схему синхронной - т.е. как таковую в которой все события происходят по фронтах, заданного в обязательном порядке, клока.
Чтобы гарантировать правильность и работоспособность физической реализации (прошивки), тулза делает STA основываясь именно на этом клоке.
При этом, тулзе всё равно физическое происхождение этого клока, важно только как он задан (в SDC констрейнах напр.)

[SM]

Независимо от того, что вы делаете в ПЛИС (схему с тригерами, только комбинаторику итп.)

Еще как зависимо. Если в ПЛИС только комбинаторика, без триггеров или защелок, то для анализа клок, даже виртуальный какой-то, не нужен и не используется. Будут только задержки типа вход->выход, и все.

[Torpeda]

Еще как зависимо. Если в ПЛИС только комбинаторика, без триггеров или защелок, то для анализа клок, даже виртуальный какой-то, не нужен и не используется. Будут только задержки типа вход->выход, и все.

Не знал...
Наверное STA при этом автоматически отменяется....

[SM]

Наверное STA при этом автоматически отменяется....

Никуда он не отменяется. Он анализирует констрейны set_max_delay -from <input> -to <output> , ну и set_min_delay, которые, в данном случае, вычисляются непосредственно в виде задержки в пути, так как нет ни одной тактируемой точки отсчета.

[dvladim]

Обычно, все-таки, ставятся set_input_delay set_output_delay с виртуальными клоками.

[SM]

Обычно, все-таки, ставятся set_input_delay set_output_delay с виртуальными клоками.

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

[Torpeda]

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

А что будет когда вообще ничего тулзе не задавать?
Что STA проветит (выполнит) по умолчанию?

[SM]

А что будет когда вообще ничего тулзе не задавать?
Что STA проветит (выполнит) по умолчанию?

Честно говоря, не знаю. Вообще, раньше, памятуя еще MaxPlus, предшественник квартуса, там была таблица-матрица, где в строках входные сигналы, в столбцах выходные, а на пересечениях - значения задержки от этого входа до этого выхода, если там есть асинхронный путь.

[SM]

Вот так это выглядит в квартусе, если ничего не задано в констрейнах (отчет .tan.rpt):

Код

+-----------------------------------------------------------------+
; tpd                                                        ;
+-------+-------------------+-----------------+---------+---------+
; Slack; Required P2P Time; Actual P2P Time; From  ; To    ;
+-------+-------------------+-----------------+---------+---------+
; N/A ; None            ; 7.500 ns      ; BTMS5 ; J_TMS ;
; N/A ; None            ; 7.500 ns      ; BTMS5 ; J_TDI ;
; N/A ; None            ; 7.500 ns      ; BTCKI ; BTCK  ;
; N/A ; None            ; 7.500 ns      ; BEMU[0]; TBCTMS3;
; N/A ; None            ; 7.500 ns      ; BEMU[1]; TBCTMS2;
+-------+-------------------+-----------------+---------+---------+

[Torpeda]

Вот так это выглядит в квартусе, если ничего не задано в констрейнах (отчет .tan.rpt):

Cadence RC Compiler

Код

path   1:

Pin      Type     Fanout  Load  Slew Delay Arrival  
                           (fF)  (ps)  (ps)   (ps)    
------------------------------------------------------
in1      in port        1   35.6  397  +229     229 R
i_25/A                                   +1     229  
i_25/Q   AO211X4        1 1016.8 2357 +2259    2489 R
Q        out port                       +15    2504 R
------------------------------------------------------
Timing slack :  UNCONSTRAINED
Start-point  : in1
End-point    : Q

Синтезатор просто показывает задержки во всей цепочке.
Наверняка нифига не оптимизирует и никакое время выполнять не собирается.
Для STA оно всё равно UNCONSTRAINED

Cadence Encounter:

Код

#  Command:           report_timing -from in1 -to Q -view worst -unconstrained
###############################################################
Path 1:Endpoint:   Q   (^)
Beginpoint: in1 (^) (unconstrained input)
Arrival Time                    2.396
Analysis View: worst
     + Input Delay                        0.000
     + Drive Adjustment                   0.170
     = Beginpoint Arrival Time            0.170
     +--------------------------------------------------------------------------------------------------------+
     |        Pin |  Cell   |    Net |    Arc     |  Delay  |  Load   |  Slew   | Fanout | Arrival | Required |
     |            |         |        |            |         |         |         |        |  Time   |   Time   |
     |------------+---------+--------+------------+---------+---------+---------+--------+---------+----------|
     | in1 ->     |         | in1    | in1 ^      |         |   0.025 |   0.299 |      1 |   0.170 |          |
     | i_25/Q     | AO211X4 | Q      | A ^ -> Q ^ |   2.215 |   1.007 |   2.340 |      1 |   2.385 |          |
     | Q ->       |         |        | Q ^        |   0.011 |   1.007 |   2.340 |        |   2.396 |          |
     +--------------------------------------------------------------------------------------------------------+

Роутер все времянки тоже игнорирует.
------------------------------------------------------------

Задаём set_max_delay 2.0 -from in1 -to Q

Синтезатор уже понимает заданный констрейн и пытается ускорить схему сильным буфером:

Код

path   1:

Pin      Type     Fanout  Load  Slew Delay Arrival  
                           (fF)  (ps)  (ps)   (ps)    
------------------------------------------------------
in1      in port        1   35.6  397  +229     229 R
i_25/A                                   +1     229  
i_25/Q   AO211X4        1   32.9  195  +711     941 R
i_24/A                                   +0     941  
i_24/Q   BUX12          1 1016.8  822  +950    1892 R
Q        out port                       +15    1907 R
------------------------------------------------------
Exception    : 'path_delays/io.tcl_line_0'    2000ps
Timing slack :      93ps
Start-point  : in1
End-point    : Q

и соответственно роутер выполнил заданное требование:

Код

#  Command:           report_timing -from in1 -to Q -view worst
###############################################################
Path 1: MET Path Delay Check
Endpoint:   Q   (^)
Beginpoint: in1 (^) triggered by  leading edge of '@'
Analysis View: worst
- External Delay                0.000
+ Path Delay                    2.000
= Required Time                 2.000
- Arrival Time                  1.788
= Slack Time                    0.212
     Clock Rise Edge                      0.000
     + Input Delay                        0.000
     + Drive Adjustment                   0.177
     = Beginpoint Arrival Time            0.177
+-------------------------------------------------------------------------------------------------------+
|        Pin|  Cell   |    Net |    Arc     |  Delay  |  Load   |  Slew   | Fanout | Arrival | Required |
|           |         |        |            |         |         |         |        |  Time   |   Time   |
|-----------+---------+--------+------------+---------+---------+---------+--------+---------+----------|
| in1 ->    |         | in1    | in1 ^      |         |   0.026 |   0.309 |      1 |   0.177 |    0.389 |
| i_25/Q    | AO211X4 | n_0    | A ^ -> Q ^ |   0.660 |   0.020 |   0.165 |      1 |   0.836 |    1.049 |
| i_24/Q    | BUX12   | Q      | A ^ -> Q ^ |   0.931 |   1.009 |   0.828 |      1 |   1.767 |    1.979 |
| Q ->      |         |        | Q ^        |   0.021 |   1.009 |   0.828 |        |   1.788 |    2.000 |
+-------------------------------------------------------------------------------------------------------+

Задаём виртуальный клок без "set_input_delay\set_output_delay".
Эквивалентно - UNCONSTRAINED

---------------------------------------

Задаём "set_input_delay\set_output_delay с виртуальными клоками"

Код

path   1:

       Pin             Type      Fanout  Load  Slew  Delay Arrival  
                                         (fF)  (ps)  (ps)    (ps)    
---------------------------------------------------------------------
(clock virtualClk)    launch                                     0 R
(io.tcl_line_0)       ext delay                     +50000   50000 R
in1                   in port         1   35.6  397   +229   50229 R
i_25/A                                                  +1   50229  
i_25/Q                AO211X4         1 1016.8 2357  +2259   52489 R
Q                     out port                         +15   52504 R
(io.tcl_line_0_4_1)   ext delay                     +40000   92504 R
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(clock virtualClk)    capture                               100000 R
---------------------------------------------------------------------
Cost Group   : 'virtualClk' (path_group 'virtualClk')
Timing slack :    7496ps
Start-point  : in1
End-point    : Q

Код

#  Command:           report_timing -from in1 -to Q -view worst
###############################################################
Path 1: MET Late External Delay Assertion
Endpoint:   Q   (^) checked with  leading edge of 'virtualClk'
Beginpoint: in1 (^) triggered by  leading edge of 'virtualClk'
Analysis View: worst
Other End Arrival Time          0.000
- External Delay               40.000
+ Phase Shift                 100.000
+ CPPR Adjustment               0.000
= Required Time                60.000
- Arrival Time                 52.396
= Slack Time                    7.604
     Clock Rise Edge                      0.000
     + Input Delay                       50.000
     + Drive Adjustment                   0.170
     = Beginpoint Arrival Time           50.170
     +-----------------------------------------------------------------------------------------------------+
     |       Pin|  Cell   |    Net|    Arc     |  Delay  |  Load   |  Slew   | Fanout | Arrival | Required |
     |          |         |       |            |         |         |         |        |  Time   |   Time   |
     |----------+---------+-------+------------+---------+---------+---------+--------+---------+----------|
     | in1 ->   |         | in1   | in1 ^      |         |   0.025 |   0.299 |      1 |  50.170 |   57.774 |
     | i_25/Q   | AO211X4 | Q     | A ^ -> Q ^ |   2.215 |   1.007 |   2.340 |      1 |  52.385 |   59.989 |
     | Q ->     |         |       | Q ^        |   0.011 |   1.007 |   2.340 |        |  52.396 |   60.000 |
     +-----------------------------------------------------------------------------------------------------+

ВЫВОДЫ:
-----------------------------
1) Мы можем задавать констрейны как через "set_max_delay" так и через "set_input_delay set_output_delay с виртуальными клоками"

2) Если ничего не задавать (UNCONSTRAINED) - то и никакие времена проверяться\выполняться не будут - тул только отрепортит что у него случайно вышло.

3) Задание только только виртуального клока без указания "set_input_delay\set_output_delay" эквивалентно - UNCONSTRAINED (я думал раньше, что этого достаточно для нашего случая, но был не прав...).
При одновременном задании "set_input_delay\set_output_delay с виртуальными клоками" тул начинает выполнять задержки.

P.S
Какой способ лутше, в случае простой комбинаторики, не могу пока ответить.... Мне больше нравится с виртуальным клоком....

[SM]

Мне больше нравится с виртуальным клоком....

А мне с from-to. Потом, ведь, еще и документировать Tpd на получившийся путь в микросхеме (Вы ведь явно не ПЛИСовый тул приводите в пример), а в документации будут отнюдь не виртуальные клоки, а непосредственное время распространения, которое логично и прямо обконстрейнить через пару set_min_delay и set_max_delay

[Torpeda]

А мне с from-to. Потом, ведь, еще и документировать Tpd на получившийся путь в микросхеме (Вы ведь явно не ПЛИСовый тул приводите в пример), а в документации будут отнюдь не виртуальные клоки, а непосредственное время распространения, которое логично и прямо обконстрейнить через пару set_min_delay и set_max_delay

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

PS
Одновременное задание set_min_delay и set_max_delay часто игнорируется тулзами, и не есть хорошо...
Особенно если это "окошко" оч мало.

[SM]

Одновременное задание set_min_delay и set_max_delay часто игнорируется тулзами, и не есть хорошо...

Вообще, set_min_delay проверяется вместе с холдами, а set_max_delay - с сетапами. Поэтому, они не должны (а по моему опыту и не могут) игнорироваться - они проверяются и оптимизируются на разных этапах.

[Torpeda]

Вообще, set_min_delay проверяется вместе с холдами, а set_max_delay - с сетапами. Поэтому, они не должны (а по моему опыту и не могут) игнорироваться - они проверяются и оптимизируются на разных этапах.

set_min_delay\set_max_delay с сетап\холдами не связан.
Это отдельный констрейн.
если оба сразу заданы на одну цепь, то тулзе труно их выполнить, изза расброса задержек буферов итд...
Вот и игнорит иногда... просто говорит что не выполнено...

[SM]

set_min_delay\set_max_delay с сетап\холдами не связан.
Это отдельный констрейн.

Да, отдельный. НО!!! С холдами связан! Синтезатор на него вообще плюет с высокой колокольни (если его не пнуть специально, но, в общем случае, это обычно не делают, оставляя холды и min_delay на роутер), а вот разводчик занимается оптимизацией на тему min_delay именно во время этапа коррекции холдов, а в остальном процессе игнорирует. По крайней мере, так работают Synopsys DC в связке с IC Compiler или Astro. Да и FPGA-тулы работают точно так же. Да и анализируется он всегда вместе с холдами, на fast корнере.

[SM]

ВЫВОД:
set_min_delay - игнорируется

Вывод почти неверный. Он не игнорируется роутером, когда ему дать команду коррекции холдов (а это процесс отдельный, делается после разводки, когда слаки по сетапам и max_delay уже положительные)! Вот тогда он поправит и холды, и ошибки по min_delay (при этом, если вилка слишком жесткая, может испортить max_delay, этот процесс его не проверяет). А на почти всех других этапах таки да, игнорируется, но я об этом сразу сказал.

Почему "почти" - потому, что Synopsys DC делает вот так (цитата из dcug):
If fix_hold is not specified on any clocks, the minimum delay cost is not considered during compilation. If fix_hold or min_delay is specified, the minimum delay cost is a secondary optimization cost.

То есть, как бы это не было странным, но если не указан синтезатору set_fix_hold хотя бы одному клоку, то и все set_min_delay будут проигнорированы.

[Torpeda]

Я таки ошибся свыводами....

При
set_max_delay 10.0 -from in1 -to Q
set_min_delay 5.0 -from in1 -to Q

мы имеем:

Код

#  Command:           report_timing -early -from in1 -to Q -view worst > res
###############################################################
Path 1: VIOLATED Path Delay Check
Endpoint:   Q   (v)
Beginpoint: in1 (v) triggered by  leading edge of '@'
Analysis View: worst
- External Delay                0.000
+ Path Delay                    5.000
= Required Time                 5.000
  Arrival Time                  2.153
  Slack Time                   -2.847
     Clock Rise Edge                      0.000
     + Input Delay                        0.000
     + Drive Adjustment                   0.128
     = Beginpoint Arrival Time            0.128
     +--------------------------------------------------------------------------------------------------------+
     |        Pin|  Cell   |    Net  |    Arc     |  Delay  |  Load   |  Slew   | Fanout | Arrival | Required |
     |           |         |         |            |         |         |         |        |  Time   |   Time   |
     |-----------+---------+---------+------------+---------+---------+---------+--------+---------+----------|
     | in1 ->    |         | in1     | in1 v      |         |   0.019 |   0.204 |      1 |   0.128 |    2.975 |
     | i_24/Q    | AO211X4 | Q       | A v -> Q v |   2.014 |   1.007 |   1.843 |      1 |   2.142 |    4.989 |
     | Q ->      |         |         | Q v        |   0.011 |   1.007 |   1.843 |        |   2.153 |    5.000 |
     +--------------------------------------------------------------------------------------------------------+

Код

#  Command:           report_timing -late -from in1 -to Q -view worst > res
###############################################################
Path 1: MET Path Delay Check
Endpoint:   Q   (^)
Beginpoint: in1 (^) triggered by  leading edge of '@'
Analysis View: worst
- External Delay                0.000
+ Path Delay                   10.000
= Required Time                10.000
- Arrival Time                  2.396
= Slack Time                    7.604
     Clock Rise Edge                      0.000
     + Input Delay                        0.000
     + Drive Adjustment                   0.170
     = Beginpoint Arrival Time            0.170
     +-----------------------------------------------------------------------------------------------------+
     |       Pin|  Cell   |    Net|    Arc     |  Delay  |  Load   |  Slew   | Fanout | Arrival | Required |
     |          |         |       |            |         |         |         |        |  Time   |   Time   |
     |----------+---------+-------+------------+---------+---------+---------+--------+---------+----------|
     | in1 ->   |         | in1   | in1 ^      |         |   0.025 |   0.299 |      1 |   0.170 |    7.774 |
     | i_24/Q   | AO211X4 | Q     | A ^ -> Q ^ |   2.215 |   1.007 |   2.340 |      1 |   2.385 |    9.989 |
     | Q ->     |         |       | Q ^        |   0.011 |   1.007 |   2.340 |        |   2.396 |   10.000 |
     +-----------------------------------------------------------------------------------------------------+

Роутер видит все минимальные задержки и репортит.

---------------------------------
Задаём только set_min_delay 5.0 -from in1 -to Q

Код

path   1:

Pin      Type     Fanout  Load  Slew Delay Arrival  
                           (fF)  (ps)  (ps)   (ps)    
------------------------------------------------------
in1      in port        1   35.6  397  +229     229 R
i_25/A                                   +1     229  
i_25/Q   AO211X4        1 1016.8 2357 +2259    2489 R
Q        out port                       +15    2504 R
------------------------------------------------------
Timing slack :  UNCONSTRAINED
Start-point  : in1
End-point    : Q

МАХ задержка UNCONSTRAINED

Теперь роутер:

Видит МІN

Код

#  Command:           report_timing -early -from in1 -to Q -view worst > res
###############################################################
Path 1: VIOLATED Path Delay Check
Endpoint:   Q   (v)
Beginpoint: in1 (v) triggered by  leading edge of '@'
Analysis View: worst
- External Delay                0.000
+ Path Delay                    5.000
= Required Time                 5.000
  Arrival Time                  2.093
  Slack Time                   -2.907
     Clock Rise Edge                      0.000
     + Input Delay                        0.000
     + Drive Adjustment                   0.092
     = Beginpoint Arrival Time            0.092
     +------------------------------------------------------------------------------------------------------+
     |        Pin|  Cell   |    Net|    Arc     |  Delay  |  Load   |  Slew   | Fanout | Arrival | Required |
     |           |         |       |            |         |         |         |        |  Time   |   Time   |
     |-----------+---------+-------+------------+---------+---------+---------+--------+---------+----------|
     | in1 ->    |         | in1   | in1 v      |         |   0.013 |   0.161 |      1 |   0.092 |    2.998 |
     | i_25/Q    | AO211X4 | Q     | A v -> Q v |   2.002 |   1.000 |   1.824 |      1 |   2.093 |    5.000 |
     | Q ->      |         |       | Q v        |   0.000 |   1.000 |   1.824 |        |   2.093 |    5.000 |
     +------------------------------------------------------------------------------------------------------+

и МАХ (как unconstrained):

Код

#  Command:           report_timing -late -from in1 -to Q -view worst > res
###############################################################
No constrained timing paths with given description found.
Paths may be unconstrained (try '-unconstrained' option) or may not exist.

Надо учится репорты получать
Задав таки только set_min_delay или set_min_delay\set_max_delay без задания клоков - мы получим что хотели

[SM]

интересно.... в случае простой комбинаторики холда нету...как нет и клоков...

Да вообще, на этапе синтеза нет никакого смысла ни в fix_hold, и в min_delay, так как эти проблемы решаются именно роутером, специальным проходом с удлинением разводки и вставлением буферов.