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

[plisel]

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

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

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

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

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

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

[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 - с сетапами. Поэтому, они не должны (а по моему опыту и не могут) игнорироваться - они проверяются и оптимизируются на разных этапах.