Привет, Хабр! Меня зовут Алексей Ковалов, я руководитель отдела модульной верификации в YADRO в департаменте разработки процессорных архитектур. Сейчас в моей команде 30+ талантливых ребят. Некоторые из них пришли к нам стажерами и росли на моих глазах, другие вливались в команду уже уверенными мидлами и «перепрыгивали» в сеньоров и выше. Но где та тонкая грань, когда заканчивается один грейд (числовая интерпретация Junior — Middle — Senior) и начинается другой? Как вообще расти верификатору и какими навыками должен обладать условный джун, мидл или сеньор? 

Сегодняшняя статья как раз об этом: покажу нашу матрицу компетенций и возможные пути развития специалиста. Но сначала дисклеймер: опираться буду на опыт в нашем направлении и команде. Конкретно у вас может работать по-другому — и это нормально.

У верификатора два основных направления развития: в предметной области и технических навыках. Причем на практике они должны дополнять друг друга. Разберем по порядку. 

Ветка прокачки № 1. Рост в предметной области

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

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

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

Теперь о риске. Если прокачивать только эту ветвь развития, верификатор становится «мастером одного клинка». При переходе в другой проект или компанию знания предметной области могут не пригодиться. 

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

Из жизни отдела: для развития своих сотрудников, нынешних и будущих, мой коллега сделал простую вводную лекцию по когерентному AMBA CHI-протоколу CHI zero to hero, которая заняла всего 5 часов, но это уже тема для другой статьи. И таких приключений множество.

Сейчас мы ищем в команду новых верификаторов и RTL-дизайнеров. Если хочешь работать над инженерными проектами и расти среди профессионалов, обрати внимание на наши вакансии:

— инженер по UVM-верификации,

— старший инженер по верификации,

— старший инженер по разработке RTL.

Ветка прокачки № 2. Рост в навыках верификации

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

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

Level 0

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

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

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

Level 1

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

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

  • ООП. Классическое, потому что SystemVerilog — это объектно-ориентированный язык с большим количеством «магических» сущностей, но это другая история.

  • Конструкции, которые нужны для рандомизации воздействий (Random Constraints). Чтобы подавать случайные данные, а не писать направленные тесты на все подряд: для сложных систем это невозможно.

  • Написание функционального покрытия (Functional Coverage). Эта часть нужна, чтобы ответить на вопросы, где мы находимся во время верификации, все ли я покрыл и когда пора остановиться.

  • SystemVerilog Assertions (SVA) — часть языка, которая позволяет проверять поведение протокола во времени. Писать сиквенсы, чтобы эти события происходили в определенной последовательности, с определенными задержками. Дальше, если события укладываются в рамки допустимого, все работает. А если нет — поднимается «красный флаг», что что-то упало. Стоит быть готовым к тому, что SystemVerilog — язык сложный. В него входят несколько языков, и SVA — один из них. Так исторически сложилось.

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

Level 2

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

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

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

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

В моей команде ребята знают Python, Make, владеют Jenkins. В зависимости от прошлого опыта, к этому добавляются скриптовые языки Perl, Tcl и другие.

Подытожим. На этом уровне верификатор умеет писать тесты, владеет SystemVerilog на том уровне, чтобы делать это эффективно. Понимает, как код ведет себя в разных симуляторах с учетом их особенностей и как работать с CI/CD-системами. Умеет автоматизировать запуск. Что дальше?

Level 3

Третий уровень — владение методологией и разработка переиспользуемых компонентов. Итак, какое-то время верификатор писал тесты на блоке 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, который умеет эти протоколы тестировать, он сможет сэкономить проекту несколько лет и будет цениться на рынке.

Итог уровня. Верификатор научился писать тесты не с нуля для каждого дизайна и говорить на всемирном языке верификаторов (UVM). Может взять готовый AXI VIP (Verification IP) и подключить его в тестовое окружение. Успех, он на коне. Но можно ли лучше?

Level 4

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

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

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

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

Итак, что мы имеем. Основная задача верификатора — проверить, что железо работает согласно спецификации. Но решить эту задачу можно по-разному: в помощь вам FPGA, эмуляторы, тестовые окружения на C++ или на SystemC и так далее. Понимать, какие именно технологии выбрать для конкретного проекта и почему — это навык уверенного сеньора. Это и будет верхушкой нашего финального уровня. 

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

*Опять же, актуально для нашей команды

Рост грейда = рост ответственности

Рынок верификации сложный — и это реально тот случай, когда кадров действительно дефицит. До недавнего времени в России этому направлению в принципе не обучали, максимум были курсы на кафедре. Зарождались верификаторы в уже существующих командах, как правило, из разработчиков и FPGA-инженеров — так называемая кузница кадров. На навыках это, конечно, тоже сказалось: они у всех очень разные. На проекте в любом случае придется доучивать специалистов «под себя», и нюансов здесь может быть много. Если команда делает не ASIC, а проект на FPGA, стоимость ошибки у них ниже: FPGA можно перепрошить, а ASIC уходит на фабрику. Во втором случае, если вы допустили ошибку, устройство будет работать некорректно или вообще не запустится, и вы рискуете потерять много миллионов (не рублей “=(“ ). Поэтому на ASIC требования к квалификации специалистов самые высокие. К чему я это пишу?

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

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

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

Если новичок проявляет инициативу и сам подтягивается до нужного уровня — это классно, но ментор всегда приглядывает за ним через плечо. Если мы видим затык или что человек сворачивает не туда, подключаемся и направляем. 

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

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

Степень роста специалиста коррелирует со степенью ответственности, которую он несет. 

Рост в команде, опять же, происходит через рабочие активности. Допустим, сотрудник выполняет свои базовые задачи и параллельно начинает больше контрибьютить в какие-либ�� подсистемы или компоненты. Со временем он может стать их владельцем, потому что уже сделал много чего и отлично погружен в контекст. Если это история не через собственную инициативу, иногда вмешивается случай лид. Например, мы знаем, что у нас в команде есть классный Игнат и он хочет развиваться. Тогда на годовом планировании мы решаем выдать ему ту или иную систему на владение, чтобы он мог на ней проявить себя.

А бывает, человек постепенно прокачивается в своем направлении через прокачку экспертизы. Сначала у него была простая задачка (реализуй транзактор для APB), потом — более сложная (портируй тесты для кеша второго уровня из легаси окружения в новое), потом — еще сложнее (напиши тест план для нового списка фичей в подсистему памяти). И мы видим, что он справляется с ними и становится мощной боевой единицей.

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

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

Хочу расти: план действий

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

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

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

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

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

Напоследок ловите ресурсы, которые помогут вкатиться в профессию верификатора.

Книги:

  • «Цифровая схемотехника и архитектура компьютера: RISC-V», Дэвид М. Хэррис

  • SystemVerilog for Verification, C. Spear

  • Computer Architecture: A Quantitative Approach. 6th ed., 2017. Hennessy and Patterson

Курсы:

Что еще:

На сегодня у меня все, но в ближайших планах — рассказать, как я сам стал верификатором. А пока подступаюсь к новой статье, буду рад вопросам по теме!