Сегодня в некоторой русско-американской группе по QA (я не даю ссылку потому что она закрытая, хотя и многочисленная) некий молодой человек задал вопроc как войти в Quality Assurance Automation. Я сказал, что могу показать путь в Design Verification, который является фактически специализированным QA в области проверки функциональности цифровых аппаратных блоков процессоров и сетевых чипов, спроектированных с помощью синтеза из кода на языке описания аппаратуры SystemVerilog (я их собственно и проектирую). Так как получить ответ захотело еще человек десять, я понял, что нужно писать пост. К счастью, я об этом писал более 10 лет, так что можно делать выжимки из предыдущих постов.
Карьера Design Verification Engineer с писанием сред тестирования на SystemVerilog может понравится опытным программистам, которые хотят сменить карьеру с например писания программ на Джаве. В SystemVerilog есть элементы объектно-ориентированного и симулированно-многопоточного программирования. Суть деятельности заключается в создание фреймворков, которые тестируют хардверные дизайны на прочность, бомбардируя их превдослучайными транзакциями и учитывая покрытие интересных сценариев (functional coverage).
Для успеха в этой работе нужно пять составляющих:
Быть хорошим программистом с чутьем на особые случаи (corner cases).
Понимать основы цифровой логики на уровне регистровых передач: комбинационную и последовательностную логику, такты, алгоритм работы симулятора.
Понимать основы микроархитектуры хардвера: конвейеры, очереди, протоколы типа AXI, контроль потока данных с помощью valid/ready и кредитных счетчиков.
Понимать уже упоминавшиеся специализированные технологии верификации: ограниченно-случайные транзакции и их последовательности, функциональное покрытие, утверждения темпоральной логики и нахождение контрпримеров к ним с помощью специальных тулов (formal verification).
Владеть скриптовыми языками, так как в любой большой компании огромная куча скриптов для билдов, регрессии, генерации кода и анализа логов. Bash, Tcl, Python, Make, кое-где остались Ruby и Perl.
Из учебных учреждений: много вводных курсов как по основам цифрового проектирования (RTL design для ASIC и FPGA), так и по Design Verification в University of California Santa Cruz Extension in Silicon Valley. Это недорогие вечерные курсы, на которые можно ходить параллельно с основной работой. Посещение этих курсов могут даже оплачивать некоторые работодатели (если это для вас расширение навыков, а не нечто, что требовалось для начала работы).
Также есть коммерческие тренеры, которые работают по электронным компаниям и берут ~$600 с ученика в день. И производители средств автоматизации проектирования. Но вы можете эти деньги съэкономить и выучить эту часть по книжкам, подкрепляя открытыми проектами. Потому что все быстрые курсы учат конструкциям языков и использованию тулов, а не опыту строительства среды верификации. Это из моих слайдов:
Перед рекомендациями по книжкам - пару слов об организации труда в электронных компаниях, чтобы вы поняли общую картину. Сначала из моей заметки "Как вырастить культуру чиподелов в стране, где есть только программисты?"
Типичная команда, разрабатывающая блок чипа в игровой приставке или роутере, работает так:
Четыре инженера получают архитектурную спецификацию от архитектора, после чего:
Инженер по моделированию пишет программу, которая имитирует, как ведет себя блок, но без погружения в детали на уровне тактов.
Инженер по логическому проектированию добавляет от себя эти детали, то бишь пишет микроархитектурную спецификацию (не путать с просто архитектурной), а затем и код на языке Verilog, который описывает, что блок делает в каждом такте. Эту специальность также называют "проектировщих на уровне регистровых передач", RTL Design Engineer (RTL = Register Transfer Level).
Инженер-верификатор пишет тесты, которые проверяют, что модель первого инженера и RTL код второго инженера одинаково реагируют на одинаковые события.
Инженер по физическому проектированию помогает RTL инженеру превратить его код на верилоге в схему, которая вписывается в тактовую частоту, бюджет размера и энергопотребления.
Теперь из моей заметки "Темное искусство функциональной верификации цифровых микросхем":
Мельчайшая ошибка в описании схемы на уровне регистровых передач (RTL коде) может привести к необходимости выпустить чип на фабрике заново (ASIC respin) и потерям в десятки миллионов долларов. Особенно к тяжелым последствиям может привести ситуация, когда компания упустит временное окно для выпуска нового чипа, и лидером рынка становятся конкуренты. Поэтому электронные компании используют развитые и изощренные методы контроля качества.
Одна голова - хорошо, а три головы - лучше. Так как корень самых больших ошибок - это неоднозначность в интерпретации функциональной спецификации (fSpec), в промышленности применяется концепция повторной сходимости, reconvergence. Она проверяет интерпретацию спецификации RTL инженера интерпретациями двух других людей - инженера по моделированию и инженера по верификации:
Для каждого значительного RTL блока пишется поведенческая или функциональная модель - просто программа, которая на основе вводов и внутреннего состояния, без попыток делать что-либо эффективно, реализует поведение блока по спецификации. Эту программу пишет инженер по моделированию, на основе своего видения fSpec. Программа может быть на SystemVerilog, Си и даже на Питоне, если скорость работы модели на компьютере некритична.
Инженер-верификатор, под контролем менеджера-верификатора, составляет план тестирования, на основе своего восприятия fSpec. В плане описываются сценарии работы блока, причем для каждого случая указывается, как его автоматически проверить, сравнивая поведение RTL блока и модели, а также как проверить (тоже автоматически) то, что этот сценарий произошел во время тестирования. Последнее называется "проверка функционального покрытия" (functional coverage).
План тестирования проходит ревью, после чего на его основе на языке SystemVerilog пишется тестовое окружение, тесты и специальные конструкции под названием "группы покрытия" (covergroups). Последнее нужно для контроля, что все тесты, обещанные в плане тестирования, были действительно написаны.
Многие тесты делаются с ограниченно-случайными данными и ограниченно-случайными последовательностями событий по времени. Для этого в языке SystemVerilog есть встроенный генератор случайных данных на основе правил зависимостей (constraint solver). В комбинации с проверкой функционального покрытия такие тесты дают возможность сгенерировать сценарии, о которых не думал инженер, пишущий тесты. Например у NPU может возникать ситуация, когда транзакции через две независимые AXI шины к многобанковой памяти, в которой лежат веса и поток команд, начинают конфликтовать и вызывать ошибки при дистанции между ними ровно 3 такта, а не 0, не 1 и не 10.
Может случиться так, что функциональная спецификация описывает не все аспекты блока, и что RTL инженер дополнил блок на основе устной договоренности с архитектором. Инженер-верификатор может не знать об этой договоренности и не реализовать дополнительные тесты. После этого прогон тестов может выдать в лог "покрыто 100%", хотя это не будет соответствовать действительности (часть реализованной функциональности не будет покрыто тестами). На этот случай в методологии используется страховка в виде автоматической проверки покрытия кода (code coverage) во время симуляции - она выявит RTL код, который не был задействован в процессе тестирования.
Теперь вернемся к рекомендуемой литературе. Если вы хотите выучить основы цифровой схемотехники с нуля, годится Харрис & Харрис, причем для DV инженера достаточно понять что такое тактовый сигнал и потом прочитать главу 4 про SystemVerilog:
Далее из заметки "Следущие шаги в черной магии процессоростроения после того, как вы освоили Харрис & Харрис"
Лучшая книга по языку SystemVerilog — на картинке ниже слева. Справа же — довольно старая книжка по написанию сред тестирования, обновленная для SystemVerilog. Это книжка нудная, но подходит для регулярного чтения, по полчаса в день, в общественном транспорте типа электрички, чтобы перенять опыт предыдущих поколений пользователей верилога.
В центре я привел очень простую и тонкую книжку, которая содержит элементарное введение в Universal Design Methology (UVM). UVM — это библиотека классов на SystemVerilog для создания средств тестирования на уровне блоков. Методология UVM не так универсальна, как обещают ее консультанты менеджменту, но практически каждому верификационному инженеру полезно иметь о ней представление. Эта книжка про UVM нелохая, хотя и не описывает, как присать драйверы для конвейерных трназакций (это часто нужно). Прочитайте эту книгу за викенд и передайте другому — она реально такая короткая. Хороших длинных книг про UVM нет (они все плохие), поэтому я рекомендую читать стандарт и общаться с коллегами. При использовании UVM желательно использовать здравый смысл, иначе вместо реальной работы вы начнете бесконечно искать способы как обойти довольно жесткую структуру, навязываемую UVM.
Для понимания работы симулятора SystemVerilog на уровне регистровых передач полезно прочесть приложение к последней инкарнации книжки Дональда Томаса, который писал на эти темы 25 лет:
Ну и разумеется нужно упомянуть российскую Школу Синтеза Цифровых Схем, к которуй можно подключиться и из США онлайн, и на которой будет бесплатная программа верификации этой осенью (программа еще не выставлена, но я ее уже видел). При добросовестном прохождении этой программы можно получить примерно те же или лучшие знания, что и на вводном курсе по SystemVerilog в University of California Santa Cruz Extension in Silicon Valley (который берет $1000) или на курсах типа Willamette HDL, но с бОльшим количеством практики и бОльшей привязкой к микроархитектуре устройств.
Еще один важный лайфхак - EDA Playground. Это вебсайт, на котором вы можете бесплатно получить доступ к дорогим (обычно десятки тысяч долларов лицензия) EDA тулам для упражнений по книгам. Вот кстати как выглядит код на SystemVerilog. Слева тестбенч, справа дизайн:
Если вас это заинтересовало - успеха в изучении! DV - это надежная и интересная профессия, востребованная как в крупных электронных компаниях, так и в стартапах по ускорению ML аппаратными акселераторами.
Комментарии (7)
SentinelOfDoom
16.08.2023 14:10Вопрос по "типичной команде". В реалиях Российских компаний после симуляции часто идет коррекция начальной спецификации и как следствие самого тестбенча, как подобное реализуется в "правильных" компаниях?
В подобных постах для RTL вы несколько раз затрагивали типичные требования или базовые задания для собеседований. А как обстоят дела с этим для верифитатора, о чем спрашивают, что считается порогом, ниже которого не возьмут?YuriPanchul Автор
16.08.2023 14:10В крупных электронных компаниях (и частично в некрупных) спецификация идет в два этапа: сначала архитектурная (на уровне транзакций что входит что выходит в подблоки целой большой конструкции - системы на кристалле, CPU итд), потом микроархитектурная - устройство блока - конвейеры, очереди. И еще до высокоуровневой спецификации, когда тестбенча на уровне RTL еще может не быть, делается performance modeling на основе высокоуровневой модели. Вот моя другая картинка на эту тему:
YuriPanchul Автор
16.08.2023 14:10+1Что касается вопросов на интервью для верификаторов, то он (как и RTL инженер) должен понимать последовательностную логику, то есть решать задачки на верилоге типа "сгенерите такую-то последовательность сигналов на временной диаграмме в ответ на другую последовательность", но ему, в отличие от RTL инженера, совсем не нужно понимать статический анализ тайминга внутри такта.
Точно так же, DV инженеру (как и RTL инженеру) нужно понимать концепцию конвейера и очереди FIFO, но ему не нужно уметь их реализовывать со всеми подробностями (типа решать задачки "реализуй FIFO которое может в одном такте принимать или один, или два трансфера).
При этом DV инженеру нужно куда больше программировать, то есть писать всякие классы, потоки fork, динамические структуры данных итд, чего нет в RTL коде, а также делать интерфейс с кодом на других языках (Си, питон итд).
alinkagalichina
16.08.2023 14:10Юрий, добрый день.
SV+UVM это, конечно, база для верификатора. А что вы думаете про cocotb? Последние 6 месяцев ни одно собеседование на верификацию не обходится без вопросов на питон и использование cocotb.
На ощупь подход через cocotb оказался достаточно эффективным для небольших и средних RTL блоков: скорость разработки как будто бы выше + легче найти спеца по питону, чем по SV. Но есть подозрение, что на больших RTL будут сильные просадки по перфомансу.
YuriPanchul Автор
16.08.2023 14:10Только минуту назад обсуждал cocotb. Это популярный вопрос в России потому что там ограниченая возможность доступа к SV и много питонистов, но в штатах такие работы встречаются реже, чем SV, например https://g.co/kgs/dPDXpT
Именно по причине, по которой вы описали: когда имеется миллион строк кода и регрессия идет ночь, никому не хочется чтобы она шла неделю.
megamrmax
Спасибо большое за статью! Не могу поставить плюсик по причине идиотских правил Хабра, поэтому просто утащу в закладки.
Пробежался по LinkedIn по вакансиям - зарплаты весьма вкусные.
vvvictor
Аналогично. Многое от Юрия закидываю в закладки.