Самое интересное, что мне по работе приходится общаться с большим числом ASIC-дизайнеров (зарубежных, разумеется) и большинство из них испытывают непонятный ужас перед FPGA и если надо что-то сделать, то просят кого-нибудь другого (иногда меня).
Мужик, немного самоиронии и тебе бы не помешало. А то так ты к успеху на Хабре не придешь. Здесь не ЖЖ, чтобы можно было всех в комментах обзывать хомячками, и тебе за это ничего не было бы.
попытался скачать файлы, а мне говорят: «The site is temporarily unavailable for we are making some important upgrades to its parts. We apologize for the inconvenience. We'll have it back online for you as soon as possible. Please try again in 598 seconds.»
Умные люди говорят, что заморочки с разводкой зависят не от частоты. Тем более то, что упомянул автор — это не заморочки, это то, что профессиональный разработчик делает на автомате — всегда!
В реальной жизни это зависит от сигналов. Если сигнал идет от АЦП с синхронным интерфейсом, который вы сами тактируете, то они будут синхронными. Если сигнал идет с кнопок, или с UART-а, или с другого устройства, которое работает на своей собственной частоте, независимой от частоты ПЛИС, то они не будут синхронными. В этом случае возможен вариант, когда входные сигналы изменятся слишком близко ко фронту клока в ПЛИС, что приведет к нарушению времени предустановки триггеров (setup violation). С этим можно бороться путем добавления синхронизаторов
С точки зрения протокола 2-wire JTAG и SWD не совместимы. Но я слышал, что есть возможность использовать одни и те же провода для подключения и SWD-, и 2-wire JTAG-устройств. Для этого там хитрый протокол перевода устройств в online- и offline-режимы, но поскольку руками я это не трогал, то не могу сказать, действительно ли это работает и есть ли подводные камни.
Разумеется это полный аналог assign, так как код делает то же самое. Я тоже предпочитаю assign, чтобы меньше букв писать, но когда логика на два экрана то assign уже не очень подходит.
На самом деле, я видел код «с первой строчкой» и в чистом Верилоге — стандарту он не противоречит, а все остальное — дело привычки. LEDA на такое не ругается :)
Здесь есть один нюанс. В спецификации AXI сказано: «There are no ordering restrictions between read and write transactions with the same AWID and ARID. If a master requires an ordering restriction then it must ensure that the first transaction is fully completed before the second transaction is issued». (пункт 8.1 для AXI3 и 8.2 для AXI4),
Таким образом, действительно мастер может потребовать, чтобы все запросы на запись выполнялись по порядку, и все запросы на чтение тоже, но потребовать, чтобы запросы на запись и чтение не переупорядочивались между собой, он не может, даже если ARID и AWID будут одинаковы.
Я сейчас сам не пишу код. Но поскольку наша контора продает RTL тем, кто делает ASIC-и, то к предупреждениям отношение очень серьезное. Наши индусы используют статический анализатор LEDA с нашим собственным набором правил (вроде бы, переделанным из IBM-овского), и релиз не пропустят, если есть хоть одно предупреждение. Если есть какие-то false-positive предупреждения, то они индивидуально маскируются.
Кстати always в Верилоге довольно часто применяют для описания сложной комбинаторной логики, типа функций переходов автоматов и т.д. Гораздо нагляднее, чем городить?: (?: (?: (?: (? :)))).
Но вот код автора действительно приведет к куче ворнингов при синтезе, например про неиспользуемые биты в data_d2.
Лично мне религия не позволяет написать так, как автор — описание очень похоже на inferred latch, если не заметить строку «new_data_c = data_d1;», но думаю, что это уж точно дело вкуса.
Подавляющее большинство фирм делают микросхемы на стандартных ячейках (уровень типа И, НЕ, ИЛИ, И-НЕ, И-ИЛИ-НЕ, отдельных триггеров и т.д. — на самом деле, обычно в библиотеке несколько сотен ячеек). Библиотеки разные для каждой фабрики и каждого техпроцесса, то есть разных библиотек тоже сотни (TSMC, UMC, Global Foundries, SMIC — можно купить все, что душе угодно, начиная от 180нм вплоть до 22нм). Можно купить любую, подключить ее к синтезатору типа Design Compiler, и синтезировать один и тот же Вериложный код под любой техпроцесс. Никто сам транзисторы не рисует, кроме разработчиков этих самый библиотек.
Ну а блоки памяти генерятся memory compiler'ами. Для однопортовой памяти — один компилятор, для двухпортовой — другой, для регистровых файлов — третий.
У меня нет полной раскладки на какой-нибудь проект, потому что я занимаюсь технической поддержкой, а не продажами (но даже если бы были, это конфиденциальная информация). Но могу примерно озвучить порядок.
1. Нужно купить софт. Как минимум, RTL-симулятор, синтезатор (RTL->Netlist) и средство для формальной верификации RTL vs Netlist. Три конторы, куда придется за этим пойти — Synopsys, Cadence и Mentor Graphics. Они делят, наверное, 99% рынка. Софт дорогой, порядок цен на все про все — несколько сотен тысяч долларов за рабочее место (разумеется, можно и впятером работать на одном симуляторе, или в три смены — у всего этого софта обычно floating license).
2. Купить библиотеку стандартных ячеек. Выбрать количество нанометров, Low Power или High Performance. Не могу сказать, сколько она стоит, но не думаю, что очень дорого. Возможно, что некоторые фабрики дают ее бесплатно при заказе кучи микросхем.
3. Купить IP-блоки. Обычно покупают процессоры, Bus Fabric-и (AXI, AHB/AHB-Lite, APB), контроллеры внешней памяти типа LPDDR3, PHY для PCIe/USB3/Ethernet и т.д. Цены могут быть совершенно разные. Кстати, PHY всегда продают под конкретные техпроцессы, потому что там внутри аналоговщина. Также покупают IP для верификации — модели шин и т.д. Все это, кроме PHY, можно сделать самому, но дешевле купить.
4. Разработать и верифицировать RTL. Цена зависит от размера проекта. Обычно от начала проекта до RTL-freeze, после которого начинают синтез и layout, проходит где-то от полугода до года. Для америкосов и европейцев стоимость — несколько сотен тысяч долларов, учитывая, что инженер стоит $100k в год. Для индусов и китайцев цифры, разумеется, гораздо меньше. Нужно учитывать, что RTL-дизайн и верификацию почти всегда делают разные люди. Для верификации ключевые слова — SystemVerilog и UVM. И если для RTL-дизайна можно сэкономить на симуляторе и взять бесплатный или условно-бесплатный, то для верификации такой фокус не пройдет, потому что нужен симулятор с полной поддержкой SystemVerilog.
5. Когда RTL готов, его синтезируют в нетлист, потом в нетлист добавляют всякие DFT-штуки типа scan test, BIST, контроллер JTAG-а. Проверяют при помощи формальной верификации, что в нетлисте ничего не сломалось (gate-level simulation почти не используют, потому что она чудовищно медленная — обычно запускают какой-нибудь примитивный тест и все).
6. Потом аутсорсят back-end — размещение, трассировку. Это совсем другой мир, лучше самому туда не лезть. Софт там еще дороже, возможностей накосячить еще больше. Забирают уже готовый GDSII. Наверное, если слать китайцам, то будет не очень дорого, но могут украсть нетлист :) А так цен я не знаю.
7. Шлют GDSII на фабрику. Цена подготовки к производству чудовищно большая, поэтому сначала делают test-chip на каком-нибудь шаттле ( www.tsmc.com/english/dedicatedFoundry/services/cyberShuttle.htm ). Это будет несколько десятков тысяч долларов за пару десятков микросхем.
8. Если тест-чип работает, запускают в серию. Подготовка к производству по техпроцессу 55нм, скажем, в Китае стоит ~$500k. Сами пластины с микросхемами стоят дешево. Поэтому чем больше серия, тем дешевле микросхема. Кстати, до сих пор огромное количество контор делает микросхемы по 130нм и 90нм, как бы это не казалось странным — правда, USB3 PHY для таких техпроцессов не купить.
Сложно сказать, какой техпроцесс нужен, когда не понятно, что именно нужно сделать и сколько МГц выжать. Но примерное представление можно получить, посмотрев на цифры для микроконтроллеров, например, вот из этого моего коммента: habrahabr.ru/company/intel/blog/194836/#comment_6770002
Вообще, понятна любовь соотечественников к FPGA в условиях почти полного отсутствия собственных ASIC-дизайн-центров (я думаю, на всю страну их раз в сто меньше, чем в одном только Израиле).
Идеи типа USB-флэшек для перекодирования видео на самом деле здравые и могли бы взлететь, но FPGA годятся только на роль прототипов, чтоб найти инвесторов и начать делать микросхемы. К сожалению, у нас с этим проблемы, хотя это отнюдь не rocket science.
Так что еще одна ссылка не помешала бы.
На самом деле, я видел код «с первой строчкой» и в чистом Верилоге — стандарту он не противоречит, а все остальное — дело привычки. LEDA на такое не ругается :)
if ( startofpacket_d1 ) new_data_c = { data_d1[1:0], data_i[7:4], data_d1[7:6] }; else if ( startofpacket_o ) new_data_c = {data_d2[5:2], data_d1[3:0]}; else new_data_c = data_d1;Таким образом, действительно мастер может потребовать, чтобы все запросы на запись выполнялись по порядку, и все запросы на чтение тоже, но потребовать, чтобы запросы на запись и чтение не переупорядочивались между собой, он не может, даже если ARID и AWID будут одинаковы.
@W:CL169: loop_l2.sv(30) | Pruning register data_d2[0][7:0]
@W:CL169: loop_l2.sv(30) | Pruning register data_d2[1][7:0]
@W:CL169: loop_l2.sv(30) | Pruning register data_d2[6][7:0]
@W:CL169: loop_l2.sv(30) | Pruning register data_d2[7][7:0]
Но вот код автора действительно приведет к куче ворнингов при синтезе, например про неиспользуемые биты в data_d2.
Лично мне религия не позволяет написать так, как автор — описание очень похоже на inferred latch, если не заметить строку «new_data_c = data_d1;», но думаю, что это уж точно дело вкуса.
Ну а блоки памяти генерятся memory compiler'ами. Для однопортовой памяти — один компилятор, для двухпортовой — другой, для регистровых файлов — третий.
У меня нет полной раскладки на какой-нибудь проект, потому что я занимаюсь технической поддержкой, а не продажами (но даже если бы были, это конфиденциальная информация). Но могу примерно озвучить порядок.
1. Нужно купить софт. Как минимум, RTL-симулятор, синтезатор (RTL->Netlist) и средство для формальной верификации RTL vs Netlist. Три конторы, куда придется за этим пойти — Synopsys, Cadence и Mentor Graphics. Они делят, наверное, 99% рынка. Софт дорогой, порядок цен на все про все — несколько сотен тысяч долларов за рабочее место (разумеется, можно и впятером работать на одном симуляторе, или в три смены — у всего этого софта обычно floating license).
2. Купить библиотеку стандартных ячеек. Выбрать количество нанометров, Low Power или High Performance. Не могу сказать, сколько она стоит, но не думаю, что очень дорого. Возможно, что некоторые фабрики дают ее бесплатно при заказе кучи микросхем.
3. Купить IP-блоки. Обычно покупают процессоры, Bus Fabric-и (AXI, AHB/AHB-Lite, APB), контроллеры внешней памяти типа LPDDR3, PHY для PCIe/USB3/Ethernet и т.д. Цены могут быть совершенно разные. Кстати, PHY всегда продают под конкретные техпроцессы, потому что там внутри аналоговщина. Также покупают IP для верификации — модели шин и т.д. Все это, кроме PHY, можно сделать самому, но дешевле купить.
4. Разработать и верифицировать RTL. Цена зависит от размера проекта. Обычно от начала проекта до RTL-freeze, после которого начинают синтез и layout, проходит где-то от полугода до года. Для америкосов и европейцев стоимость — несколько сотен тысяч долларов, учитывая, что инженер стоит $100k в год. Для индусов и китайцев цифры, разумеется, гораздо меньше. Нужно учитывать, что RTL-дизайн и верификацию почти всегда делают разные люди. Для верификации ключевые слова — SystemVerilog и UVM. И если для RTL-дизайна можно сэкономить на симуляторе и взять бесплатный или условно-бесплатный, то для верификации такой фокус не пройдет, потому что нужен симулятор с полной поддержкой SystemVerilog.
5. Когда RTL готов, его синтезируют в нетлист, потом в нетлист добавляют всякие DFT-штуки типа scan test, BIST, контроллер JTAG-а. Проверяют при помощи формальной верификации, что в нетлисте ничего не сломалось (gate-level simulation почти не используют, потому что она чудовищно медленная — обычно запускают какой-нибудь примитивный тест и все).
6. Потом аутсорсят back-end — размещение, трассировку. Это совсем другой мир, лучше самому туда не лезть. Софт там еще дороже, возможностей накосячить еще больше. Забирают уже готовый GDSII. Наверное, если слать китайцам, то будет не очень дорого, но могут украсть нетлист :) А так цен я не знаю.
7. Шлют GDSII на фабрику. Цена подготовки к производству чудовищно большая, поэтому сначала делают test-chip на каком-нибудь шаттле ( www.tsmc.com/english/dedicatedFoundry/services/cyberShuttle.htm ). Это будет несколько десятков тысяч долларов за пару десятков микросхем.
8. Если тест-чип работает, запускают в серию. Подготовка к производству по техпроцессу 55нм, скажем, в Китае стоит ~$500k. Сами пластины с микросхемами стоят дешево. Поэтому чем больше серия, тем дешевле микросхема. Кстати, до сих пор огромное количество контор делает микросхемы по 130нм и 90нм, как бы это не казалось странным — правда, USB3 PHY для таких техпроцессов не купить.
Сложно сказать, какой техпроцесс нужен, когда не понятно, что именно нужно сделать и сколько МГц выжать. Но примерное представление можно получить, посмотрев на цифры для микроконтроллеров, например, вот из этого моего коммента: habrahabr.ru/company/intel/blog/194836/#comment_6770002
Идеи типа USB-флэшек для перекодирования видео на самом деле здравые и могли бы взлететь, но FPGA годятся только на роль прототипов, чтоб найти инвесторов и начать делать микросхемы. К сожалению, у нас с этим проблемы, хотя это отнюдь не rocket science.