Как расти верификатору: от джуна до сеньора

Дисклеймер: автор опирается на опыт в своем направлении и команде. В других проектах и компаниях требования к сотрудникам могут отличаться — и это нормально.

У верификатора два основных направления развития: в техническом стеке и в предметной области. При этом одно не должно существовать без другого: вы можете уйти глубже в оттачивание технических навыков верификации в целом, но в процессе работы всё равно будете углубляться в специфику своей отрасли. А если есть желание дорасти до сеньора, оба направления в себе придется уравновесить. Но давайте обо всем по порядку.

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

Но что это за навыки такие? Чтобы ответить на этот вопрос, предлагаю начать с базы: с чего вообще стартуют ребята в верификации, а дальше посмотрим на следующие уровни.

Добрая часть разработчиков со мной не согласится, но мои учителя строго вели меня по принципу: «Не можешь нарисовать, не садись кодить». Конечно, большую часть времени инженеры пишут код, но начинается всё на схеме из вентилей, модулей и примитивов. Верификатор должен понимать, как из одного появляется другое и какая «математика» за этим стоит, иначе он не сможет проверить суть происходящего.

Как я уже сказал, аппаратчики, как и программисты, пишут код, так что один из приоритетных навыков для нас — умение пользоваться системой контроля версий. А если человек базово работает с таск-трекингом и владеет инструментами планирования, это еще один плюс. Верификация — процесс творческий. Доказать, что система работает на 100% как надо, к сожалению, нельзя: всегда есть доля вероятности. Но с такой базой предсказать и упорядочить процесс работы будет проще.

Для верификации в подмножестве языка есть свои конструкции, не применимые в разработке. Сам язык делится на две неравные части: синтезируемая часть, которую разработчики используют для написания «железа», и несинтезируемая — классы, таски и особые операторы, доступные только для верификации.

Что нужно освоить на этом уровне:

• Классическое объектно-ориентированное программирование (ООП). SystemVerilog — это объектно-ориентированный язык с большим количеством сущностей.
• Конструкции для рандомизации воздействий (Random Constraints). Чтобы подавать случайные данные, а не писать направленные тесты на всё подряд: для сложных систем это невозможно.
• Написание функционального покрытия (Functional Coverage). Эта часть нужна, чтобы ответить на вопросы, где мы находимся во время верификации, всё ли покрыли и когда пора остановиться.
• SystemVerilog Assertions (SVA) — часть языка, которая позволяет проверять поведение протокола во времени. Писать сиквенсы, чтобы эти события происходили в определенной последовательности, с определенными задержками. Дальше, если события укладываются в рамки допустимого, всё работает. А если нет — поднимается «красный флаг», что что-то упало. Стоит быть готовым к тому, что SystemVerilog — язык сложный. В него входят несколько языков, и SVA — один из них.

Мир аппаратной разработки очень консервативный и развивается медленно. К сожалению, не все инструменты поддерживают полный стандарт языка. Есть три крупных вендора Siemens, Synopsys и Cadence с симуляторами Questa, VCS и Xcelium, соответственно. Понимание, как код ведет себя в каждом из этих симуляторов, какие есть нюансы и баги, — ценный навык. Объясню почему.

Представьте, что вы купили IP (Intellectual Property) у партнера, вставили к себе в дизайн, запустили тест — и ничего не работает. А всё потому, что ребята разрабатывают на одном симуляторе, а вы — на другом. У вас разные значения по умолчанию на проводах, подключенных к комбинационной логике. Это можно учесть и поправить, но понимание таких нюансов экономит команде время.

Конечно, симуляторы — не единственный инструмент верификаторов. Например, в направлении функциональной верификации мы динамически подаем воздействие и смотрим, что вышло на выходе. Еще есть формальная верификация — это когда мы пишем «утверждения» и пытаемся доказать, что они не верны. Для этого тоже есть свои инструменты, и уметь с ними работать — нужный и редкий навык для индустрии.

Почти во всех компаниях, в том числе в крупных, автоматизация запуска тестов и регрессионного тестирования часто ложится на верификаторов. Обычно это происходит так: у вас команда разработки под FPGA, тестировщиков в ней нет. Потом появляется условный Игнат и начинает писать тесты на свои разработки. Дальше их нужно запускать, а вручную не хочется. Кто будет писать скрипты? Тот же, кто пишет тесты. Так что умение автоматизировать, ставить на регресс и опыт работы с CI/CD-системами — тоже необходимые скилы для верификатора на этой ступени.

Допустим, какое-то время верификатор писал тесты на блоке DIV (делитель), а потом ему дали следующий блок ALU. Нужно что-то сложить, вычесть, провести какие-нибудь битовые операции — ничего сложного. Дальше он снова пишет на этот блок тесты и окружение. Внезапно выясняется, что их нужно писать с нуля, потому что предыдущий код непереиспользуемый.

На следующем блоке такая же проблема. Многим тяжело это признать, но верификация занимает больше времени, чем разработка. Представьте ситуацию: инженер написал ALU на 500 строчек за понедельник, а потом его попросили написать тесты для покрытия всех корнер-кейсов. Всю оставшуюся неделю он будет пилить тестовое окружение, чтобы всё это запускалось на регрессе, а покрытие выведено в насыщение. Лично я проходил такой путь много раз: понимал, что сейчас напишу код за день, а тестировать буду еще четыре дня. И ускорить процесс конкретно в этом моменте не получится.

Зато при переходе от подсистемы к подсистеме можно писать переиспользуемые компоненты, а потом «перетаскивать» их. Некоторые компании покупают уже готовые решения. И тут самое время перейти к общепринятому фреймворку Universal Verification Methodology (UVM). С одной стороны, это методология: она показывает, какие компоненты нужно создать в системе, чтобы верифицировать дизайн любой сложности. С другой — библиотека классов на SystemVerilog. Но UVM не просто говорит «создай сущности», но и вручает тебе их базовую реализацию: бери, расширяй и используй. Минус — сложность библиотеки. Но если ты ее осваиваешь, это уже действительно взрослый навык и хорошая строчка в резюме.

Идем дальше. Вот мы написали тесты, посмотрели отчет и увидели, что покрытие 90%. Разработчик говорит, что этого достаточно. Но оставшиеся 10% никуда не делись. Что с ними делать? Почти всегда в верификации есть фаза выведения покрытия в насыщение, и предсказать ее сложнее всего. Первые 90% покрытия даются быстрее, чем оставшиеся 10%. Есть даже шутка такая: «Не так страшны первые 90% процентов покрытия, как оставшиеся вторые 90%». Поэтому отдельный скил сеньора — уметь предсказать объем этой работы. Чтобы не было недопонимания, отмечу, что когда мы говорим про блоки уровня ALU, которые занимают 500 строчек, этой непредсказуемости нет: там всё достаточно линейно. Но если у нас сложные подсистемы (например, подсистема памяти или модуль, реализующий векторное расширение), история другая.

На этом же уровне есть еще одна ветка — стандартные протоколы. Самый распространенный стандарт — AMBA. В нем есть ряд широко известных протоколов: ACE, AHB, AXI и другие, один из самых сложных — когерентный CHI-протокол. Отсылая к важности понимания предметной области, отмечу, что CHI сложный не потому что «спека большая», а потому что там есть много нюансов, физический смысл которых невозможно понять без погружения в архитектуру кешей. Если специалист знаком с UVM и VIP, который умеет эти протоколы тестировать, он сможет сэкономить проекту несколько лет и будет высоко цениться на рынке.

Например, формальная верификация, Power Aware Verification или верификация нетлиста (netlist). Последнее — не так сложно, как предыдущие два направления, но такой опыт работы на рынке тоже востребован.

Выше я уже говорил об отличиях симуляторов, и с аппаратными комплексами — похожая история. Большинство компаний используют FPGA для прототипирования. Кто-то продает для него IP — например, пишут схему управления фюзеляжем, которая потом загружается в FPGA самолета и там работает. У нас в департаменте есть выделенные специалисты, которые валидируют наши дизайны на FPGA, но в других компаниях этим могут заниматься верификаторы.

Идем дальше. У вендоров могут быть свои эмуляторы — это такие «симуляторы на стероидах» в виде огромных серверных шкафов. Умение работать с ними — редкий и ценный навык для команды верификации. Один нюанс: такие стойки очень дорогие, но если компания может их себе позволить, обученные люди ей будут нужны.

В этой статье я говорю про верификацию на SystemVerilog, но тесты и окружение не обязательно писать именно на нем. Есть инструменты на SystemC, C++ и веяние последний лет — cocotb на Python. Я бы не отнес владение cocotb к сеньорным умениям, но если вы знаете, как верификация может быть построена на разных подходах, — это классный навык. Он формирует кругозор и помогает не замыкаться в одной технологии. Давайте пример: у нас есть сложный модуль, который нужно проверефицировать, есть SW модель, скажем на C++, с уже готовыми для нее тестами. Правильный путь — эти тесты переиспользовать. И поможет нам в этом понимание, как достучаться из тестового окружения на SystemVerilog до тестов и модели на C++.

Выше я описал, как верификатор может расти в технических навыках. Но есть и другое направление развития — погружение в предметную область, в которой вы работаете. Например, вы тестируете DSP-блоки и параллельно начинаете изучать, как устроен тракт обработки сигнала в разрабатываемом чипе или устройстве. Профит в том, что знания о предмете, которые вы получаете, позволяют вам качественнее выполнять верификацию. Я лично работал с крутыми специалистами, которые знали матчасть (цифровая обработка сигнала, теория кодирования, навыки проектирования аппаратуры), стандарты Wi-Fi и других беспроводных систем как свои пять пальцев. Это помогало им придумывать новые решения, тестировать существующие и подтягивать команду.

Приведу пример из личного опыта. Когда я работал над верификацией тракта Wi-Fi сигнала, меня попросили проверить, что в цифровой части beamforming работает корректно. Из общего курса по DSP я представлял, что такое beamforming, SystemVerilog и UVM тоже знал на достаточном уровне, но что делать дальше — понятия не имел. На помощь пришел более опытный коллега: он объяснил, как эта функциональность встраивается в общий тракт и на какие параметры и сценарии работы стоит обратить внимание. Это именно те знания, без которых я бы не смог двигаться дальше и проверить такую фичу.

Еще один пример из моего департамента. Мы занимаемся процессорными архитектурами, и параллельная ветка развития для верификатора из моей команды — это погружение в архитектуру CPU: как устроен конвейер, вычислительные подсистемы, какие алгоритмы заложены в предсказатель и прочее. Это нужно для поиска багов на всех уровнях разработки — начиная от архитектурной проработки и ошибок в спецификации, заканчивая непосредственной реализацией на SystemVerilog. В реализации CPU спокойно может быть заложена функциональность, поднимающая производительность или роняющая ее в зависимости от ошибок в реализации или архитектуре. И чтобы проверифицировать такие решения, нужно знать, на какие параметры и сценарии работы стоит обратить внимание.

Если вы выбираете рост в предметной области, нужно учитывать риск. Прокачиваясь в одной сфере, вы становитесь «мастером одного клинка», и при переходе в другой проект или компанию ваши знания о предметной области могут не пригодиться. Например, если я всю жизнь работал с DSP-блоками или низкоскоростными интерфейсами (UART, I2C, cJTAG), а теперь перехожу в направление процессорных архитектур, мне придется с нуля узнавать, что такое когерентность, out-of-order и как связаны между собой компоненты ядра.

Пришло время поговорить о тех самых джунах, мидлах и сеньорах, но тут я сразу кого-то расстрою. Нельзя провести красную черту между уровнями для всех верификаторов в целом — мол, тут начинается мидл, а тут сеньор. Какие именно навыки соответствуют определенному грейду, зависит от специфики проекта и команды.

Например, если в нашей команде сотрудник знает, как при помощи осциллографа раздебажить специфичную плату (что очень круто), это не делает его сеньором. Ведь если при этом он не владеет UVM, у него не получится эффективно решать задачи по верификации. Еще один пример: можно идеально знать SystemVerilog, но не понимать, как устроен CPU. А для создания сложных тестовых воздействий — это необходимый навык.

И раз уж я заговорил о нашем отделе, покажу обещанную матрицу компетенций. Каждый из грейдов — это совокупность технических навыков и знаний в предметной области:

Верификатора на любом проекте всегда доучивают «под себя», к этому нужно быть готовыми. Так и у нас в YADRO: людей со знанием процессорной архитектуры и глубокими техническими навыками, которые нам нужны, единицы. Поэтому определенный багаж знаний мы даем почти в академическом формате. Джуны проходят онбординг и несколько недель изучают архитектуру CPU, чтобы прокачаться по веточке общего знания. Дополнительно мы загружаем в новичка стандарт SystemVerilog (избранные разделы) и UVM, чтобы он овладел инструментарием и мог работать с нашей кодовой базой. Подключаем к регулярным внутренним семинарам департамента, где ведущие инженеры делятся своим опытом. К тому же внутри компании регулярно проходят лекции по различным областям разработки и верификации CPU и аппаратуры в целом — на них тоже можно быстро восполнить пробелы.

Дальше начинаются реальные рабочие задачи, через которые специалист растет. Насколько они будут сложными, зависит от навыков. Стажерам мы даем что-то простое: они верифицируют небольшие блоки, усваивают, как устроен процесс, и не закапываются в сложную технику. Потом поручаем им модуль объемом побольше или отправляем помогать в уже идущую верификацию. То есть на старте они «прощупывают» процесс в безопасном режиме, а дальше с серьезными задачами им помогает ментор.

У нас есть базовый принцип «15−45». Если сотрудник берет задачу, мы не вмешиваемся и даем ему возможность справиться самому, поискать решения. На это нужно потратить как минимум 15 минут и не беспокоить лида решаемыми вопросами. Но если сдвинуться с мертвой точки не получается уже 45 минут, нет смысла дальше терять время — иди к ментору или коллеге старшего грейда за советом. Самостоятельность — это хорошо, но практика показывает, что уйти в себя можно надолго. Пока ты застрял на одной задачке, процесс не двигается.

Процесс верификации и его фазы у нас понятно задокументированы. Это помогает выстраивать работу между командами и объяснять новичкам, чего мы от них ждем и на каких фазах верификации. Забыл о чем-то — вернись, посмотри. Со временем они понимают, как складывать эти кирпичики в целостную конструкцию. Да, это бывает сложно, но мы рядом, чтобы помогать.

Так выглядит сценарий для новичков, а что с остальными грейдами? Степень роста верификатора всегда коррелирует со степенью ответственности, которую он несет.

Если вы понимаете, что заскучали на своем уровне и хотите большего, вам нужно сделать всего один простой шаг — обратиться к руководителю. Скажите, что нынешние задачи вас не развивают, что вы застопорились. Даже если процесс обратной связи в команде налажен неидеально, большинство руководителей пойдут вам навстречу, потому что верификаторы — ценные специалисты, которых мало. Лучше дать интересную задачку завтра, чем потерять вас послезавтра.

Хочу поделиться железным правилом. Если вы уже три года выполняете одни и те же задачи и понимаете, что не растете в своих навыках, срочно запускайте диалог с руководством. К сожалению, в некоторых направлениях, особенно в аппаратной индустрии, можно решать одни и те же задачи 10−15 лет и при этом не развиваться. Я регулярно вижу такие случаи, и это очень грустно. Например, недавно к нам на собеседование приходил человек, который 15 последних лет работал на одном месте. У него максимально широкий стек, он много чего делал, но, к сожалению, ни во что не погружался глубоко. Получается, количество лет работы у него как у сеньора, а нужные нам навыки как у джуна. К сожалению, с такими кандидатами приходится вежливо прощаться.

Бывают обратные случаи, когда джун практически моментально превращается в мидла. Однажды к нам пришел парень, который изучал софтверные фреймворки и интересовался аппаратной разработкой просто из интереса. На собеседовании оказалось, что он уже изучил материалы, которые мы считаем базовыми для джунов в нашем направлении. У него не было практического аппаратного опыта, но теория уже была — причем получил он ее Just for Fun. Мы сразу поняли, что он идеально вольется в команду. В итоге он блестяще прошел онбординг, быстро разобрался с библиотекой знаний и научился использовать UVM за пару недель. Этот пример показывает, что высокого результата можно добиться даже без опыта. Главное — не стоять на месте и пробовать.