topor_topor

1) правильно 2) ничего ненадо если..... Если дизайн сделан синхронным - т.е. к каждому тригеру (и в той и другой части) подведён один и тот-же провод CLK ..тоже можна...но зачем так сложно? для FPGA такой вариант противоестественный но можно запихнуть да - это и называется синхронный дизайн!!! какими клоками не описывай физически асинхронную схему - такой она и останется. Другое дело - это написать правильные констрейны, чтобы они гарантировали правильную физическую реализацию изначально синхронной схемы.

FPGA и процесор асинхронны. Для избежания чтения данных в момент их изменения, процесор должен получить сигнал готовности данных - например после обновления регистра FPGA выставляет запрос прерывания и держит данные, пока процесор не прочитает их. Ну и как обконстрейнить. время регистр-пин FPGA не критично (регистр устанавливается, выдаётся прерывание, пока отреагирует процесор...), но лутше таки задать максимальное значение, чтобы оно было под контролем (а вдруг процесор такой быстрый). Обычно всё что относится к внешним пинам констрейнится через виртуальные клоки. А вот время срабатывания мультиплексора (процесор шина адреса\RD - PCB задержка - FPGA пины - FPGA шина адреса - FPGA декодер - FPGA пины - PCB задержка - процесор шина данных) нужно задать как set_maх_delay -from FPGA пин -though FPGA декодер -to FPGA пины , чтобы данные гарантировано приходили в ожидаемое процесором время.

SDF переписывает то что в Verilog модели описано при помощи специальных конструкций типа (забыл как называются): (SN +=> QN) = (0.02, 0.02); (negedge RN => (QN -: RN)) = (0.02, 0.02); (posedge C => (QN -: QN)) = (0.02, 0.02); $setuphold (posedge C &&& c_SH_D, posedge D, 0.02, 0.02, NOTIFY_REG,,, delay_C, delay_D); если библиотека описана так - то должно работать. Также в вашем SDF должны быть аналогичные пути и чеки описаны (они берутся с LIB - т.е. LIB должен соответствовать Verilog модели). Ну и правильность загрузки SDF в симулятор по репортам проверьте.

И Encounter может SPEF екстрагировать... Лишние тулзы за отдельные деньги необязательны.... " в цифровых библиотеках Design Kits" похоже имеются ввиду Verilog модели вентилей для симуляции.... "в каждом вентиле указана задержка, причем одинаковая." - Ну то что указана одинаковая - это вопрос к создателю библиотеки..это от лени с одной стороны :) А с другой - именно эта библиотека не содержит реальных задержек. Выбрано какое-то средне-худшее значение. Точные задержки имеются только в LIB. С учётом того, что применение этой Verilog модели без SDF практического смысла особо не имеет, то фаб и не особо утруждался. Как уже и сказано было - задержки с SDF перебивают задержки Verilog модели вентилей. ----- А зачем вам вообще симуляция с SDF?

"Хочу разобраться с маршрутом цифрового моделирования в среде Cadence. Вопрос в следующем. Имеется схема, представленная verilog нетлистом. Я ее промоделировал в NC-Verilog с использованием verilog библиотеки без учета задержек." Ну если есть verilog библилтека с 0 задержками то можно и промоделировать.... "Создал lib и tlf формат вентильной библиотеки" - круто. И синтез с ними сработал? Обычно правда ни входят в комплект DesignKit для целевой технологии. "использование какого тула Cadence позволит опредилить количество входов вентилей, подключенных к каждому выходу" - ну как минимум синтезатор (RC Compiler) и роутер (Encounter) имеют встроенные команды типа fanout\report_fanout... А зачем это и как оно с SDF связано? "создать sdf файл задержек" можно как в RC Compiler так и Encounter (команда write_sdf). В Encounter можно это сделать построут с большой точностью (используя capTabl & GDS для SPEF екстракта с последующей конвертацией в SDF (всё таже команда write_sdf)) "с чего начать обучение основам, если нужно разработать отдельную тестовую микросхему памяти СОЗУ (например 64к)" - начать изучать аналоговую микросхемотехнику :) "Как моделируют такие схемы?" Это смотря для чего моделируют.... Аналоговый дизайнер моделирует аналоговую схему на транзисторном уровне. RTL цифровой дизайнер использует Verilog поведенческую модель (без задержек) Моделирование с SDF использует Verilog модель с задержками Для Синтеза и Роута нужно также LEF & LIB модели

Я таки ошибся свыводами.... При 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 без задания клоков - мы получим что хотели

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

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

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 Какой способ лутше, в случае простой комбинаторики, не могу пока ответить.... Мне больше нравится с виртуальным клоком....

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

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

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

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

За 10 лет один раз такое понадобилось и то потому, что корпус нестандарт, с дыркой и микромеханический датчик был наклеен на кристал (от температуры коробило корпус с дыркой и это сказывалось на датчике...). Нанимали стороннюю фирму для моделирования.... Мож оно вам и ненадо?

Наверное это: Certe Testbench Studio delivers a powerful Eclipse-based environment that enables rapid creation and complete understanding of UVM and OVM based testbenches. http://s3.mentor.com/public_documents/data...e_datasheet.pdf Или это: "Questa lets you see the component hierarchy, class definition tree, and other UVM settings specific to your testbench to make it easier to understand the operation of your verification environment."]Questa lets you see the component hierarchy, class definition tree, and other UVM settings specific to your testbench to make it easier to understand the operation of your verification environment

А интересно, существует-ли среда розработки под UVM, похожая на поддержку класов MFC в Visual Studio? Чтобы появлялись подсказки с методами\свойствами обекта, были визарды для создания подклассов, автоматически добавлялись нужные макросы и т.п, а не только подсветка ключевых слов SV

Извините не удержался ....Скачал...почитал... Если грубо не выражаться - я понял что я дурак :( Поясните мне пажалуста шо афтар имел в виду и зачем мне это написал? смотрите прикреплённые цитаты Для тренировок подходит всё, даже это. Только проверьте что последняя версия квартуса поддерживает EPM7128SLC84-15

1. Дизайн харда делать - это не на Си алгоритмики писать.... 2. Вам извиняюсь на русском или как должно быть? Паходу недорасли наши афтары до глубины изложения как в рекомендованном учебнике (ненаю я таких, штаб так правильно о цифрах понаписали)...да и перевода тож нету.... И опятьже-ж, английский в электронике нынче, шо латынь в медицине - без него никак.

Зато Verilog почти от С не отличиш ;) Постановка задачи равносилен следующиму: Я рисую цветочки в графическом редакторе, какую мне книжку прочитать чтобы создавать Windows приложения с красивым графическим интерфейсом. Хочу быстренько состряпать редактор с новыми фишками, а-то готовые продукты не нравяться. Слышал, есть возможность графического ввода алгоритмов, мне так проще после рисования.... ------------ "пока что вообще не ясно, как на уровне схем что- то создавать" - вот это ключивой вопрос... То чем вы собираетесь заниматься к програмированию вообще никаким боком. язык Verilog - он только используется для описания заранее придуманной схемы электрической принципиальой harris & harris - digital design and computer architecture - хорошая книга для старта ------------ "Тот же эзернет модуль- как его описывать?" 1) сначала читаем пару тыщ страниц невнятного стандарта который описывает Ethernet протокол, особенно ту часть которая реализоваться должна аппаратно - MAC уровень. ну это примерно как изучить архитектуру Windows на уровне системного програмиста.... 2) Придумываем схему электрическую принципиальную (как соединить логические гейты И\ИЛИ\НЕ чтобы реализовать логику протокола). Это похоже на то, как скомпоновать с if\for\case логику протокола. 3) Далее описываем эту схему синтезабельном подмножестве языка Verilog. 4) С учётом сложности Ethernet надо-бы верифицировать это.... Вот верификация таки похожа на програмирование. В данном случае лутше использовать язык SystemVerilog (это типа C++) и соответственно есть смысл использовать уже придумманую библиотеку классов типа UVM (типа MFC под винду). 5) Грузим исходники в квартус и жмём зелёную кнопку (типа компилим исходник). Дальше квартус сам вам и ПЛИС подберёт и прошивку для неё выкотит (это то чё с конфигурационной флешки потом в ПЛИС втянется, типа прошивки ROM в микроконтроллере). остальными деталями пока не надо заморачиваться (типа условия эсплуатации, тайминг констрейны и т.п - это всё настроено по дефолту, типа как опции линкера и мейка под винду) И всё - дело в шляпе.

Если кому интересно.... --------------------------------------------------------------- Для 035 wire_load_table ("0_5k_4m") { fanout_capacitance (5, 0.0130) ; fanout_resistance (5, 0.0299) ; fanout_area (5, 11.07) ; fanout_length (5, 124.17) ; Берём фаноут гейта 5 (типично) . Имеем для вайров С=0.0130pf \ R=0.0299кОм Ёмкость входов нагрузки для 5 гейтов: cell (BULHDX2) { pin (A) { direction : input; capacitance : 0.0040; С=5*0.0040=0.02pf Общая ёмкость линии Сw=0.0130pf+0.02pf=0.033pf Таким образом, задержка в межсоединениях: Тw=3*RCw=3*0.033pf*0.0299кОм=0.0029нс Задержка в межсоединениях 035 определяется её собственной ёмкостью и резистивным сопротивлением, а также ёмкостю входов гейтов нагрузки. Смотрим задержеку гейта при input_net_transition=1.2: lu_table_template (BU1_timing_2D) { variable_1 : input_net_transition; variable_2 : total_output_net_capacitance; index_1("0.06 0.6 1.2 2.4 4.8"); index_2("0.0020 0.0349 0.0698 0.1396 0.2791"); } cell_rise (BU1_timing_2D) { values("0.1690, 0.4209, 0.6805, 1.1994, 2.2363",\ "0.2290, 0.4812, 0.7404, 1.2591, 2.2959",\ "0.2503, 0.5040, 0.7633, 1.2812, 2.3176",\ "0.2490, 0.5125, 0.7731, 1.2909, 2.3263",\ "0.1817, 0.4632, 0.7327, 1.2618, 2.2988"); } Тbuf1 (при Сw=0.033pf) = 0.5040нс - В 035 мы имеем соотношения задержек в межсоединении к задержке в гейте 0.0029нс\0.5040нс или 1\173. Вся задержка сосредоточена в гейте. При этом, ёмкость типичного межсоединения (фаноут 5) в данной технологии увеличивает задержку гейта с 0.2503 до 0.5040 т.е в 2 раза (см. 3-ю строку BU1_timing_2D)! --------------------------------------------------------------- для 018 wire_load_table (5k) { fanout_area (5, 2.65); fanout_capacitance (5, 0.0018); fanout_length (5, 99.97); fanout_resistance (5, 0.041); Имеем для вайров С=0.0018pf \ R=0.041кОм Ёмкость входов нагрузки для 5 гейтов: cell (BU1) { pin (A) { direction : input; capacitance : 0.003201; С=5*0.003201=0.016pf Общая ёмкость линии Сw=0.0018pf+0.016pf=0.0178pf Таким образом, задержка в межсоединениях: Тw=3*RCw=3*0.0178pf*0.041кОм=0.0022нс Задержка в линии 018 технологии определяется только ёмкостью входов гейтов нагрузки и её резистивным сопротивлением. lu_table_template (TIMING_TEMP_1_2D) { variable_1 : input_net_transition; variable_2 : total_output_net_capacitance; index_1 ("0.0108, 0.1284, 0.2454, 0.480, 0.9492, 1.8876, 3.7644"); index_2 ("0.00100, 0.0186, 0.0312, 0.0519, 0.0864, 0.144, 0.240"); } cell_rise (TIMING_TEMP_1_2D) { values ("0.078796, 0.139521, 0.180945, 0.248608, 0.361001, 0.548422, 0.860681", \ "0.111564, 0.172588, 0.214054, 0.281758, 0.394213, 0.581647, 0.893816", \ "0.130034, 0.191773, 0.233171, 0.300882, 0.413318, 0.600755, 0.912829", \ "0.149527, 0.214052, 0.25529, 0.322875, 0.435329, 0.62261, 0.934493", \ "0.162109, 0.232954, 0.274269, 0.341518, 0.453854, 0.641113, 0.953011", \ "0.151271, 0.234228, 0.27716, 0.344678, 0.456789, 0.643955, 0.955758", \ "0.080574, 0.181599, 0.230327, 0.300692, 0.414288, 0.603211, 0.916342"); } Тbuf1 (при Сw=0.0178pf) = 0.214052нс - В 018 мы имеем 0.0022нс\0.214052нс или 1\97 Ёмкость типичного межсоединения (фаноут 5) в данной технологии увеличивает задержку гейта с 0.149527 до 0.214052 т.е в 1.5 раза (см. 4-ю строку TIMING_TEMP_1_2D)! ----------------- 1) Задержка сигнала на линиях межсоединений определяется входной ёмкостью гейтов нагрузки и резистивным сопротивлением самой линии. 2) Ёмкость типичной нагрузки (5 входов) увеличивает задержку на выходе гейта примерно в 2 раза 3) С уменьшением технологических норм, задержка линии приближается к задержке гейта (035 - 1\173, а в 018 - 1\97, т.е. в почти в 2 раза) Можно предположить, что при норме в 40нм это соотношение будет примерно 1\20, т.е. уже не пренебрежимо мало (мож у кого есть дезайн кит на 40нм или ниже?).... Для 035 и 018 можно сказать что задержка в межсоединениях пренебрежимо мала и что входная ёмкость нагрузки вносит наибольший вклад в задержку выхода самого гейта. При этом, чем меньше технологические нормы, тем ближе величины задержки в межсоединениях (R линии + Cвходов) к выходным задержкам гейтов-драйверов.

3.0e+8 м/с * - это типа скорость света? А если учесть что сигнал не по вакуму а по распределённой RC линии задержки бежит? Да и задержка гейта это при какой RC нагрузки?

Я-бы так сказал: В техгологиях меньше 0.35мкм, задержки в межсоединениях (хоть ASIC хоть FPGA) становяться больше чем в гейтах. Оптимизировать RTL таки надо, ибо чем сложнее комбинаторика, тем и соединений больше.

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

Как все много букаф понаписали... Это наверное потому, что подсознание пытается оправдать необходимость существования своего разума с навыками проектирования ПЛИС :) А почему-бы не посмотреть на вопрос с другой стороны.... ПЛИС - это учебная платформа для освоения технологий цифрового дизайна. Цифровой дизайн в мире ASIC совсем не ограничен гигагерцами и гигасемпелами... В ASIC вы вполне можете найти задачи по сложности сравнимые с миганием светодиода (например многие "аналоговые" микросхемы имеют цифру построенную на простой FSM, для тримирования внутренних аналоговых блоков...) И опятьтаки, ктото-же создаёт эти микроконтроллеры, и другие микросхемы - внутри всё это по большей части цифровой дизайн. Такчто, если вы решили войти в мир ASIC - ПЛИС идеальная тренировочная база.

Если цифровых то: 1) Математические основы цифровой техники (Булева алгебра и т.п.) 2) Язык Verilog 3) Для начинающих цифровых дизайнеров ничего не надо знать про расчёты резисторов, технологию полупроводников и т.п. Это за вас уже сделали всё умные дядьки и снабдили ваш Xilinx ISE большой зелёной кнопкой :) 4) Учите прикладную математико в разделе DSP