Перейти к содержанию
    

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

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

 

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

 

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

 

Например в EPM240T100C5 есть внутренний генератор на 3-5 МГц. Значит ли это что я не смогу обрабатывать сигналы частотой выше 5МГЦ ?

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

 

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

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Чтобы гарантировать правильность и работоспособность физической реализации (прошивки), тулза делает STA основываясь именно на этом клоке.

При этом, тулзе всё равно физическое происхождение этого клока, важно только как он задан (в SDC констрейнах напр.)

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Не знал...

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

А что будет когда вообще ничего тулзе не задавать?

Что STA проветит (выполнит) по умолчанию?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А что будет когда вообще ничего тулзе не задавать?

Что STA проветит (выполнит) по умолчанию?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вот так это выглядит в квартусе, если ничего не задано в констрейнах (отчет .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;
+-------+-------------------+-----------------+---------+---------+

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вот так это выглядит в квартусе, если ничего не задано в констрейнах (отчет .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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

 

PS

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

Особенно если это "окошко" оч мало.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...