plisel 0 3 ноября, 2014 Опубликовано 3 ноября, 2014 · Жалоба Здравствуйте. В ПЛИС новичок, ранее только с МК работал. Не могу понять физический смысл частоты в ПЛИС? Например в EPM240T100C5 есть внутренний генератор на 3-5 МГц. Значит ли это что я не смогу обрабатывать сигналы частотой выше 5МГЦ ? А что если схема комбинаторная, только из логики and,or, ... не значит ли это что данные операции будут выполняться тоже на выбранной частоте генератора? Или это просто генератор который я могу завести например на триггер, а операции and,or будут выполняться так сказать "асинхронно" с небольшой задержкой ? Требуется ли в обязательном порядке использовать внутренний или внешний генератор? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 3 ноября, 2014 Опубликовано 3 ноября, 2014 · Жалоба Это просто генератор, который можно использовать, как душе угодно, а можно и не использовать. Можно с внешнего генератора завести тактовую, и не одну, и еще внутри сделать что-то путем ее (их) деления или умножения на PLL. Частота работы у синхронной схемы вычисляется исходя из соображений того, что сигнал, сформированный по фронту тактовой частоты триггером, пройдя через всю цепочку логики и разводки, должен успеть дойти до триггера, его принимающего (с учетом требований Tco, Tsu и Th самих триггеров), до следующего фронта тактовой. То есть, показывает максимальную частоту, на которой эта схема будет корректно работать, как описано в исходном описании. Для асинхронной схемы понятие частоты в этом смысле бессмысленно, там надо смотреть каждый конкретный случай. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
topor_topor 0 4 ноября, 2014 Опубликовано 4 ноября, 2014 · Жалоба Требуется ли в обязательном порядке использовать внутренний или внешний генератор? Независимо от того, что вы делаете в ПЛИС (схему с тригерами, только комбинаторику итп.) тулза делающая физическую реализацию вашего проекта (Quartus напр.) всё равно представляет схему синхронной - т.е. как таковую в которой все события происходят по фронтах, заданного в обязательном порядке, клока. Чтобы гарантировать правильность и работоспособность физической реализации (прошивки), тулза делает STA основываясь именно на этом клоке. При этом, тулзе всё равно физическое происхождение этого клока, важно только как он задан (в SDC констрейнах напр.) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 4 ноября, 2014 Опубликовано 4 ноября, 2014 · Жалоба Независимо от того, что вы делаете в ПЛИС (схему с тригерами, только комбинаторику итп.) Еще как зависимо. Если в ПЛИС только комбинаторика, без триггеров или защелок, то для анализа клок, даже виртуальный какой-то, не нужен и не используется. Будут только задержки типа вход->выход, и все. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
topor_topor 0 4 ноября, 2014 Опубликовано 4 ноября, 2014 · Жалоба Еще как зависимо. Если в ПЛИС только комбинаторика, без триггеров или защелок, то для анализа клок, даже виртуальный какой-то, не нужен и не используется. Будут только задержки типа вход->выход, и все. Не знал... Наверное STA при этом автоматически отменяется.... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 4 ноября, 2014 Опубликовано 4 ноября, 2014 · Жалоба Наверное STA при этом автоматически отменяется.... Никуда он не отменяется. Он анализирует констрейны set_max_delay -from <input> -to <output> , ну и set_min_delay, которые, в данном случае, вычисляются непосредственно в виде задержки в пути, так как нет ни одной тактируемой точки отсчета. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dvladim 0 5 ноября, 2014 Опубликовано 5 ноября, 2014 · Жалоба Обычно, все-таки, ставятся set_input_delay set_output_delay с виртуальными клоками. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 6 ноября, 2014 Опубликовано 6 ноября, 2014 · Жалоба Обычно, все-таки, ставятся set_input_delay set_output_delay с виртуальными клоками. Обычно, когда, к примеру, ПЛИС реализует логику выборки адреса на асинхронном интерфейсе процессора, или нечто подобное, никто себе жизнь виртуальными клоками не усложняет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
topor_topor 0 6 ноября, 2014 Опубликовано 6 ноября, 2014 · Жалоба Обычно, когда, к примеру, ПЛИС реализует логику выборки адреса на асинхронном интерфейсе процессора, или нечто подобное, никто себе жизнь виртуальными клоками не усложняет. А что будет когда вообще ничего тулзе не задавать? Что STA проветит (выполнит) по умолчанию? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 6 ноября, 2014 Опубликовано 6 ноября, 2014 · Жалоба А что будет когда вообще ничего тулзе не задавать? Что STA проветит (выполнит) по умолчанию? Честно говоря, не знаю. Вообще, раньше, памятуя еще MaxPlus, предшественник квартуса, там была таблица-матрица, где в строках входные сигналы, в столбцах выходные, а на пересечениях - значения задержки от этого входа до этого выхода, если там есть асинхронный путь. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 6 ноября, 2014 Опубликовано 6 ноября, 2014 · Жалоба Вот так это выглядит в квартусе, если ничего не задано в констрейнах (отчет .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; +-------+-------------------+-----------------+---------+---------+ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
topor_topor 0 7 ноября, 2014 Опубликовано 7 ноября, 2014 · Жалоба Вот так это выглядит в квартусе, если ничего не задано в констрейнах (отчет .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 0 8 ноября, 2014 Опубликовано 8 ноября, 2014 · Жалоба Мне больше нравится с виртуальным клоком.... А мне с from-to. Потом, ведь, еще и документировать Tpd на получившийся путь в микросхеме (Вы ведь явно не ПЛИСовый тул приводите в пример), а в документации будут отнюдь не виртуальные клоки, а непосредственное время распространения, которое логично и прямо обконстрейнить через пару set_min_delay и set_max_delay Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
topor_topor 0 10 ноября, 2014 Опубликовано 10 ноября, 2014 · Жалоба А мне с from-to. Потом, ведь, еще и документировать Tpd на получившийся путь в микросхеме (Вы ведь явно не ПЛИСовый тул приводите в пример), а в документации будут отнюдь не виртуальные клоки, а непосредственное время распространения, которое логично и прямо обконстрейнить через пару set_min_delay и set_max_delay Самое интересное, что репорты с задержками идентичны в обеих случаях. А в документацию какраз не задаваемую величину надо вписывать, а по тайминг репорту. PS Одновременное задание set_min_delay и set_max_delay часто игнорируется тулзами, и не есть хорошо... Особенно если это "окошко" оч мало. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 10 ноября, 2014 Опубликовано 10 ноября, 2014 · Жалоба Одновременное задание set_min_delay и set_max_delay часто игнорируется тулзами, и не есть хорошо... Вообще, set_min_delay проверяется вместе с холдами, а set_max_delay - с сетапами. Поэтому, они не должны (а по моему опыту и не могут) игнорироваться - они проверяются и оптимизируются на разных этапах. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
