Comments 34
Описанные в посте технологии используются в российских компаниях Байкал Электроникс, НПО ЭЛВИС, Миландр, КМ211, НТЦ Модуль, НИИСИ, Syntacore, МЦСТ, НИИМА Прогресс, IVA Technologies и других.
Ну в общем-то любому дизайн-центру связанному с цифровой разработкой. МЦСТ, Байкал, Элвис, Миландр, Iva tech, Текон и другие.
Понятное дело используется не всё сразу и не во всех проектах. Но в целом — джентльменский набор.
Географически это Зеленоград, Москва, Воронеж, Нижний Новгород, Новосибирск, Питер, Брянск, Томск, Саратов.
Я очень много результатов знаю, но я за этим специально слежу. Если вы не следите или, например, не посещаете регулярно отраслевые выставки, то действительно на слуху не очень много всего.
Недавно мне, например, посчастливилось принять небольшое участие в создании ASIC для медицины, но я не думаю, что кто-то о ней будет много знать, кроме врачей и пациентов — и то, не о самой ASIC, а о приборе на ее основе. Типичная B2B история на всех уровнях, не требующая широкой рекламы ни для чего.
Хороший текст для песочницы. Хорошо бы чтобы после обзора шли бы конкретные примеры верификации интерфейсов (шин AXI), типичных блоков (кэшей, сетевого свитча), с объяснением на пальцах как работает рандомизация, covergroups, concurrent assertions, причем так чтобы было не нудно.
ИМХО, по крайней мере в ПЛИСах, все эти методы верификации надо очень сильно пересматривать. Просто подход к проектированию firmware для ПЛИС за последнее время настолько изменился, что классические методы практически не дают результата.
Вот у меня сейчас сидит один, точнее одна верификаторша на проекте, везде пытается просунуть свою UVM и говорит, что без этого ну никак. В итоге самый бесполезный человек.
В UVM для многих приложений много лишнего, что приводит к тому, что верификатора вместо верификации занимаются обхождением неудобств UVM. Например генерация последовательностей транзакций (sequences, virtual sequences) сделана громоздко и неполно: objections: программирование ради программирования: TLM2 порты не лучше mailbox-ов, автоматизация печати транзакций с помощью field macros — маразм, так как по умолчанию оно печатает нечитаемый лог; установка параметров через громоздкий API не особо лучше, чем серия простых присваиваний итд.
Я уже видел несколько компаний, которые внутри делают собственные самопальные библиотеки на SystemVerilog для верификации, и это оказывается проще для обучения работе новых инженеров, чем UVM.
Беда еще в том, что сам по себе он очень криво документирован, вернее, документация есть, а вот смысл и взаимосвязи понять — это просто превращается в кошмар. По опыту могу сказать, что бывают моменты, когда в нем можно забуксовать по абсолютно ерундовой причине именно в попытках найти взаимосвязи и идею, которая закладывалась в конструкции. Т.е. разбираешься не с проблемой по существу, а сражаешься с инструментом, безумно жалко время при этом.
Но с другой стороны, если его использовать, он превращается в некоторый «язык» команды верификации. Т.е. тут надо либо внутри создавать свои библиотеки/инструменты (тут нужен опыт и ресурсы), либо использовать готовое.
У себя мы вводим его постепенно (лет 6 уже), осваивая те или иные необходимые конструкции по необходимости и полностью осознавая зачем оно нам, хотя изначально знали практически все его возможности.
Думается, он может выявить некоторые ситуации (маловероятные, конечно, но на партии в 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.
Сам не использовал, сказать больше нечего. Возможно кто-то на этой площадке более адекватно и развернуто может рассказать.
Большие блоки логики тоже покрываются тестами практически полностью, при наличии времени. В составе системы это трудно сделать, но отдельно блок можно «вытрясти». Все декомпозируется. Сложные системы тоже по частям проверяются.
Я согласен, особенно с тем, что это надо делать на самых ранних стадиях. Я пытался сказать, что STA в чистом виде к верификации я не знаю как приладить, хотя это тоже средство проверки.
Давайте разведем два понятия. STA — как инструмент анализа (типа Tempus, PrimeTime, TimeCraft) и утилиты и алгоритмы синтезатора, используемые для правильной сборки схемы.
Я говорил про STA как про инструмент анализа.
Плюс, imho, в вашем сообщении цифровой и аналоговый маршрут смешался — не совсем понятно как Вы связываете STA+констрейны(цифровой маршрут) и экстракцию паразитов(аналоговый маршрут).
Экстракция паразитов делается в цифровом флоу на каждом этапе, включая синтез. Исключение — синтез с wireload моделями, который перестал быть актуальным для технологий ниже 100нм. Во всех остальных случаях делается экстракция — если не из реальной топлогии металлов, то из их оценки (режимы -topo в синтезаторе, trialroute в p&r туле и т.д.). Экстракция паразитов делается и в аналоговом флоу, тут нет противоречий
Верификация цифровых схем. Обзор