| |
 Физический смысл частоты в ПЛИС |
|
|
|
|
 Nov 3 2014, 14:11
|
Группа: Новичок
Сообщений: 1
Регистрация: 3-11-14
Пользователь №: 83 507
|
Здравствуйте.
В ПЛИС новичок, ранее только с МК работал.
Не могу понять физический смысл частоты в ПЛИС?
Например в EPM240T100C5 есть внутренний генератор на 3-5 МГц. Значит ли это что я не смогу обрабатывать сигналы частотой выше 5МГЦ ?
А что если схема комбинаторная, только из логики and,or, ... не значит ли это что данные операции будут выполняться тоже на выбранной частоте генератора?
Или это просто генератор который я могу завести например на триггер, а операции and,or будут выполняться так сказать "асинхронно" с небольшой задержкой ?
Требуется ли в обязательном порядке использовать внутренний или внешний генератор?
|
|
|
|
|
|
|
|
Nov 3 2014, 14:17
|
Гуру
Группа: Свой
Сообщений: 7 946
Регистрация: 25-02-05
Из: Moscow, Russia
Пользователь №: 2 881
|
Это просто генератор, который можно использовать, как душе угодно, а можно и не использовать. Можно с внешнего генератора завести тактовую, и не одну, и еще внутри сделать что-то путем ее (их) деления или умножения на PLL.
Частота работы у синхронной схемы вычисляется исходя из соображений того, что сигнал, сформированный по фронту тактовой частоты триггером, пройдя через всю цепочку логики и разводки, должен успеть дойти до триггера, его принимающего (с учетом требований Tco, Tsu и Th самих триггеров), до следующего фронта тактовой. То есть, показывает максимальную частоту, на которой эта схема будет корректно работать, как описано в исходном описании.
Для асинхронной схемы понятие частоты в этом смысле бессмысленно, там надо смотреть каждый конкретный случай.
|
|
|
|
|
|
|
|
Nov 4 2014, 11:48
|
Местный
Группа: Свой
Сообщений: 426
Регистрация: 23-02-12
Пользователь №: 70 424
|
Цитата(plisel @ Nov 3 2014, 17:11)  Требуется ли в обязательном порядке использовать внутренний или внешний генератор? Независимо от того, что вы делаете в ПЛИС (схему с тригерами, только комбинаторику итп.) тулза делающая физическую реализацию вашего проекта (Quartus напр.) всё равно представляет схему синхронной - т.е. как таковую в которой все события происходят по фронтах, заданного в обязательном порядке, клока. Чтобы гарантировать правильность и работоспособность физической реализации (прошивки), тулза делает STA основываясь именно на этом клоке. При этом, тулзе всё равно физическое происхождение этого клока, важно только как он задан (в SDC констрейнах напр.)
|
|
|
|
|
|
|
|
Nov 4 2014, 14:13
|
Гуру
Группа: Свой
Сообщений: 7 946
Регистрация: 25-02-05
Из: Moscow, Russia
Пользователь №: 2 881
|
Цитата(Torpeda @ Nov 4 2014, 14:48) Независимо от того, что вы делаете в ПЛИС (схему с тригерами, только комбинаторику итп.) Еще как зависимо. Если в ПЛИС только комбинаторика, без триггеров или защелок, то для анализа клок, даже виртуальный какой-то, не нужен и не используется. Будут только задержки типа вход->выход, и все.
|
|
|
|
|
|
|
|
Nov 4 2014, 15:05
|
Местный
Группа: Свой
Сообщений: 426
Регистрация: 23-02-12
Пользователь №: 70 424
|
Цитата(SM @ Nov 4 2014, 17:13) Еще как зависимо. Если в ПЛИС только комбинаторика, без триггеров или защелок, то для анализа клок, даже виртуальный какой-то, не нужен и не используется. Будут только задержки типа вход->выход, и все. Не знал... Наверное STA при этом автоматически отменяется....
|
|
|
|
|
|
|
|
Nov 6 2014, 06:33
|
Гуру
Группа: Свой
Сообщений: 7 946
Регистрация: 25-02-05
Из: Moscow, Russia
Пользователь №: 2 881
|
Цитата(dvladim @ Nov 5 2014, 22:20) Обычно, все-таки, ставятся set_input_delay set_output_delay с виртуальными клоками. Обычно, когда, к примеру, ПЛИС реализует логику выборки адреса на асинхронном интерфейсе процессора, или нечто подобное, никто себе жизнь виртуальными клоками не усложняет.
|
|
|
|
|
|
|
|
Nov 6 2014, 08:20
|
Местный
Группа: Свой
Сообщений: 426
Регистрация: 23-02-12
Пользователь №: 70 424
|
Цитата(SM @ Nov 6 2014, 09:33) Обычно, когда, к примеру, ПЛИС реализует логику выборки адреса на асинхронном интерфейсе процессора, или нечто подобное, никто себе жизнь виртуальными клоками не усложняет. А что будет когда вообще ничего тулзе не задавать? Что STA проветит (выполнит) по умолчанию?
|
|
|
|
|
|
|
|
Nov 6 2014, 08:23
|
Гуру
Группа: Свой
Сообщений: 7 946
Регистрация: 25-02-05
Из: Moscow, Russia
Пользователь №: 2 881
|
Цитата(Torpeda @ Nov 6 2014, 11:20) А что будет когда вообще ничего тулзе не задавать?
Что STA проветит (выполнит) по умолчанию? Честно говоря, не знаю. Вообще, раньше, памятуя еще MaxPlus, предшественник квартуса, там была таблица-матрица, где в строках входные сигналы, в столбцах выходные, а на пересечениях - значения задержки от этого входа до этого выхода, если там есть асинхронный путь.
|
|
|
|
|
|
|
|
Nov 7 2014, 17:48
|
Местный
Группа: Свой
Сообщений: 426
Регистрация: 23-02-12
Пользователь №: 70 424
|
Цитата(SM @ Nov 6 2014, 12:52) Вот так это выглядит в квартусе, если ничего не задано в констрейнах (отчет .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 Какой способ лутше, в случае простой комбинаторики, не могу пока ответить.... Мне больше нравится с виртуальным клоком....
|
|
|
|
|
|
|
|
Nov 10 2014, 08:21
|
Местный
Группа: Свой
Сообщений: 426
Регистрация: 23-02-12
Пользователь №: 70 424
|
Цитата(SM @ Nov 8 2014, 18:45) А мне с from-to. Потом, ведь, еще и документировать Tpd на получившийся путь в микросхеме (Вы ведь явно не ПЛИСовый тул приводите в пример), а в документации будут отнюдь не виртуальные клоки, а непосредственное время распространения, которое логично и прямо обконстрейнить через пару set_min_delay и set_max_delay Самое интересное, что репорты с задержками идентичны в обеих случаях. А в документацию какраз не задаваемую величину надо вписывать, а по тайминг репорту. PS Одновременное задание set_min_delay и set_max_delay часто игнорируется тулзами, и не есть хорошо... Особенно если это "окошко" оч мало.
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
