Как стать автором
Обновить

Комментарии 34

Интересно было бы почитать, где в России есть компании, которым все это нужно.

Описанные в посте технологии используются в российских компаниях Байкал Электроникс, НПО ЭЛВИС, Миландр, КМ211, НТЦ Модуль, НИИСИ, Syntacore, МЦСТ, НИИМА Прогресс, IVA Technologies и других.

Ну в общем-то любому дизайн-центру связанному с цифровой разработкой. МЦСТ, Байкал, Элвис, Миландр, Iva tech, Текон и другие.


Понятное дело используется не всё сразу и не во всех проектах. Но в целом — джентльменский набор.

По-хорошему, нужно всем, кто хоть как-то применяет «цифру» в проекте. Другой вопрос — какие инструменты применять. И тут уже начинаем балансировать между временем, ресурсами, затратами (стандартный набор как и везде). Цифровая схема хороша тем, что ее функционально можно проверить даже малейшие ее детали, но незначительная ошибка может привести к серьезным финансовым и временным затратам, а порой, к бессмысленности дальнейшего продолжения работ.
В России, по разным оценкам, от 40-50 до 150-200 команд, занимающихся дизайном микросхем. И ещё как минимум не меньше команд, работающих с ПЛИС.
Географически это Зеленоград, Москва, Воронеж, Нижний Новгород, Новосибирск, Питер, Брянск, Томск, Саратов.
Интересно, где результат деятельности этих команд, кроме тех, что на слуху?
А где результат деятельности 90% айтишных команд, кроме тех, которые Яндекс и Касперский? Кто пиарится сам — про тех слышно обывателю, а кто-то не пиарится, потому что ни для чего не нужно, чтобы было слышно обывателю.
Я очень много результатов знаю, но я за этим специально слежу. Если вы не следите или, например, не посещаете регулярно отраслевые выставки, то действительно на слуху не очень много всего.
Недавно мне, например, посчастливилось принять небольшое участие в создании ASIC для медицины, но я не думаю, что кто-то о ней будет много знать, кроме врачей и пациентов — и то, не о самой ASIC, а о приборе на ее основе. Типичная B2B история на всех уровнях, не требующая широкой рекламы ни для чего.
Я даже не про микросхемы, а про приборы, в которых они используются.
Первое поколение упомянутого в моем предыдущем комментарии прибора, тоже с разработанной в России ASIC, давно и успешно производится серийно и спасает жизни людям.
Но не рекламируется для широкой публики — потому что в этом нет надобности. И подобных историй есть какое-то количество.
Есть команды, которые сидят на больших и не очень предприятиях, делают специально под свои нужды. Порой натыкаешься на коллег совершенно случайно, там где и не подозреваешь.

Хороший текст для песочницы. Хорошо бы чтобы после обзора шли бы конкретные примеры верификации интерфейсов (шин AXI), типичных блоков (кэшей, сетевого свитча), с объяснением на пальцах как работает рандомизация, covergroups, concurrent assertions, причем так чтобы было не нудно.

Я для начала хотел сделать немного вводных статей, что бы потом с опорой на них можно было бы объяснять примеры. Про рандомизацию и пр. согласен, полагаю, имеет смыс объяснить «на пальцах» некоторые принципы и дать отсылку на существующие материалы, для «расширения сознания». Правда, они все на английском.
Я думаю, это даже «объяснить на пальцах» уже достаточно большая работа, которая уместится в достаточно большое количество статей. Хотя я очень «За!» такие статьи, иногда их нехватает даже на зарубежных источниках :(

ИМХО, по крайней мере в ПЛИСах, все эти методы верификации надо очень сильно пересматривать. Просто подход к проектированию firmware для ПЛИС за последнее время настолько изменился, что классические методы практически не дают результата.
Вот у меня сейчас сидит один, точнее одна верификаторша на проекте, везде пытается просунуть свою UVM и говорит, что без этого ну никак. В итоге самый бесполезный человек.

В UVM для многих приложений много лишнего, что приводит к тому, что верификатора вместо верификации занимаются обхождением неудобств UVM. Например генерация последовательностей транзакций (sequences, virtual sequences) сделана громоздко и неполно: objections: программирование ради программирования: TLM2 порты не лучше mailbox-ов, автоматизация печати транзакций с помощью field macros — маразм, так как по умолчанию оно печатает нечитаемый лог; установка параметров через громоздкий API не особо лучше, чем серия простых присваиваний итд.


Я уже видел несколько компаний, которые внутри делают собственные самопальные библиотеки на SystemVerilog для верификации, и это оказывается проще для обучения работе новых инженеров, чем UVM.

UVM штука хорошая, но неободимо применять обдумано. Там порой куча способов сделать одно и то же. Есть несколько ресурсов, вендров, которые приводят исходные коды, там бывают сильно разные подходы.
Беда еще в том, что сам по себе он очень криво документирован, вернее, документация есть, а вот смысл и взаимосвязи понять — это просто превращается в кошмар. По опыту могу сказать, что бывают моменты, когда в нем можно забуксовать по абсолютно ерундовой причине именно в попытках найти взаимосвязи и идею, которая закладывалась в конструкции. Т.е. разбираешься не с проблемой по существу, а сражаешься с инструментом, безумно жалко время при этом.
Но с другой стороны, если его использовать, он превращается в некоторый «язык» команды верификации. Т.е. тут надо либо внутри создавать свои библиотеки/инструменты (тут нужен опыт и ресурсы), либо использовать готовое.
У себя мы вводим его постепенно (лет 6 уже), осваивая те или иные необходимые конструкции по необходимости и полностью осознавая зачем оно нам, хотя изначально знали практически все его возможности.
Кстати, если совсем мутит от UVM, то можно посмотреть вот эту книгу для начала: Chris Spear, Greg Tumbush. SystemVerilog for Verification, там про методы неплохо написано. UVM только взял это все и обернул в библиотеку (большую такую библиотеку).
А в такой верификации применяют фаззинг?
Думается, он может выявить некоторые ситуации (маловероятные, конечно, но на партии в 10 миллиардов устройств и вероятность в одну миллионную в день (попадание частицы в кристалл, например) превращается в десяток тысяч сбоев каждый день (если эти ошибки реально приводят к сбоям).
А что такое фаззинг по существу?
При функциональной верификации мы можем исказить любые сигналы. Тактовую частоту «покачать» по нестабильности фазы, частоты и пр. Это устройствам, которые с внешнего мира забирают сигналы в свой частотный домен, может помочь проверить блоки фильтрации и синхронизации.
Есть еще способы введения искажений в ОВ, т.е. можно случайным способом исказить состояние в модели и посмотреть как она «выкарабкается» из этого неловкого положения.
Я имел в виду прежде всего случайные искажения в работе блоков.
То есть, условно, если по всем правилам блок должен выдать 0x00 а он всё же (несомненно ошибочно) выдаёт 0x11 — тестируется ли способность других блоков справиться с такой ошибкой и хотя бы выдать софту внятную ошибку (с которой софт сможет совладать), а не зависнуть намертво, и не скорраптиться.

Это вроде все называется Fault Injection. Что-то типа этих инструментов используется: https://www.cadence.com/en_US/home/tools/system-design-and-verification/simulation-and-testbench-verification/incisive-functional-safety-simulator.html, https://www.synopsys.com/verification/simulation/z01x-functional-safety.html.
Сам не использовал, сказать больше нечего. Возможно кто-то на этой площадке более адекватно и развернуто может рассказать.

Если имеется ввиду вариация фаз клоков в CDC, как и вообще методы проверки CDC на стрессоустойчивость — во время симуляции, то про такое было бы очень интересно почитать.
Плохо, что об STA нет ни слова. Вообще временнОй аспект верификации не затронут. А между тем, симуляция нетлиста не дает полной гарантии работы схемы, особенно если в схеме есть CDC, и особенно, если библиотеки статистические. То же касается покрытия тестами — некоторые схемы, такие как большие блоки логики, не покрыть тестами — слишком много комбинаций требуется.
STA специально не упоминал, в маршрут проектирования он должен входит, конечно же. Но он ближе к back-end, с ним специалисты по синтезу и физической имплементации должны обниматься, как и с инструментами анализа ограничений (constraints). Ну, на данный момент, такая моя точка зрения.

Большие блоки логики тоже покрываются тестами практически полностью, при наличии времени. В составе системы это трудно сделать, но отдельно блок можно «вытрясти». Все декомпозируется. Сложные системы тоже по частям проверяются.
Static timing analysis относится и к front-end, и к back-end. На front-end он делается вместе с logic synthesis, на back-end он уточняется после floorplanning, place & route. Писание RTL может и должно делаться параллельно с писанием testbench / verification environment, а писание RTL без периодического синтеза с sta — это непрактично и опасно, так как сильное нарушение тайминга в STA может потребовать пересмотр микроархитектуры.

Я согласен, особенно с тем, что это надо делать на самых ранних стадиях. Я пытался сказать, что STA в чистом виде к верификации я не знаю как приладить, хотя это тоже средство проверки.

А между тем, симуляция нетлиста с задержками (задержки получаются с помощью STA) является одной из главных задач верификатора. Полагаю, Вам просто не приходилось проектировать для ASIC

Задержки получаются синтезатором. STA — это средство анализа.

Задержки получаются синтезатором, STA — это средство анализа.
Задержки выписываются при участии STA. Сначала пускается rc-экстрактор паразитных задержек в проводах, затем запускается STA с учетом наложеных констрейнтов и настроек тула. И только потом полученные задержки сбрасываются в файл для симуляции. Соответственно, весь пессимизм (и ошибки — констрейнтов, настроек и т.д.), присутствующий в STA, попадает в симуляцию. В виде бонуса так же получаются критические пути, которые необходимо рассмотреть и при необходимости — просимулировать. Таким образом, получаем еще один аспект верификации — результатов STA и констрейнтов. Как выше написал YuriPanchul, часто это приводит к правкам в логической модели, а иногда и к изменениям в архитектуре.

Давайте разведем два понятия. STA — как инструмент анализа (типа Tempus, PrimeTime, TimeCraft) и утилиты и алгоритмы синтезатора, используемые для правильной сборки схемы.
Я говорил про STA как про инструмент анализа.

В таком случае правильнее было бы говорить о GLS(Gate level simulation) как этапе верификации, а не о STA.

Плюс, imho, в вашем сообщении цифровой и аналоговый маршрут смешался — не совсем понятно как Вы связываете STA+констрейны(цифровой маршрут) и экстракцию паразитов(аналоговый маршрут).
STA необходим для проверки временных характеристик получающейся схемы. Если характеристики не вписываются в ТЗ, необходима правка кода/архитектуры. Рассматривайте это как часть флоу (фронтэнд) и/или как верификацию. Симуляция нетлиста подразумевается.

Экстракция паразитов делается в цифровом флоу на каждом этапе, включая синтез. Исключение — синтез с wireload моделями, который перестал быть актуальным для технологий ниже 100нм. Во всех остальных случаях делается экстракция — если не из реальной топлогии металлов, то из их оценки (режимы -topo в синтезаторе, trialroute в p&r туле и т.д.). Экстракция паразитов делается и в аналоговом флоу, тут нет противоречий
Таким статьям, мне кажется, не хватает своего профильного хаба. Впрочем и статьи на подобную тематику (разработка «цифры») пока довольно редки.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории