На IT-рынке всегда есть спрос на верификаторов, но на старте карьеры бывает сложно понять, что это за профессия: чем она отличается от разработки, какие задачи решает и какие навыки нужны для входа. Так происходит потому, что до недавнего времени отдельно этому направлению не обучали и требования к верификаторам в вакансиях довольно размыты. Часто в верификаторов «перевоплощаются» другие специалисты, когда в команде появляется такая потребность.
Алексей Ковалов, руководитель отдела модульной верификации в YADRO, расставляет все точки над «и». Если вы думаете о переходе в верификацию, эта статья поможет понять, как устроена эта роль и чем она отличается от других инженерных направлений. А если только присматриваетесь к профессии — даст ориентиры, с чего начать и где можно учиться.
- кому подойдет профессия верификатора
- какие задачи верификатор решает на практике
- как становятся верификаторами
- почему эта профессия всегда востребована
И сразу небольшой спойлер. Вот что привлекло автора в верификации: «Мне нравилось сочетание аппаратных задач с огромным количеством околософтверных. Если первые — это работа вдолгую, то вторые позволяют получить быстрый дофамин от того, что ты что-то быстро пофиксил или внедрил улучшение, и теперь всё работает лучше». Детали — в тексте ниже.
Кому подходит верификация
Когда-то передо мной стояла дилемма: кем пойти работать — разработчиком или верификатором. И если вы сейчас задаете себе примерно тот же вопрос, постараюсь помочь внести немного ясности:
- Верификация подходит тем, кто интересуется аппаратурой и софтверным стеком, С/С++. Если вам нравится разбираться с open-source-инструментами, находить слабые места в системе, строить сценарии и доказательства того, что процессы не сломаются при самых безумных условиях, — вам здесь понравится.
- Разработка ближе тем, кто интересуется электроникой, схемами и работой с осциллографом. Часть людей привлекает сама предметная область: только здесь можно разобраться, как устроен компьютер на самом базовом уровне логических компонентов.
Отдельные направления IT-рынка перенасыщены молодыми кадрами после онлайн-курсов и использованием AI в интервью, но хорошие специалисты будут нужны везде и всегда.
Всегда есть хайповые отрасли, которые в моменте могут предложить более эффектную зарплатную вилку. Но гнаться за трендами — провальная стратегия: ситуация на рынке быстро меняется, а сотрудники, работающие не по призванию, выгорают еще быстрее. В долгосрочной перспективе выбор роли, которая соответствует вашим интересам, всегда выгоднее.
Какие задачи решают верификаторы
Чтобы раздел получился нагляднее, расскажу, какие задачи я решал на старте своей карьеры.
В 2020 году я впервые устроился на роль верификатора в компанию Quantenna: там нужно было разрабатывать и верифицировать DSP-подсистемы. У нас было четкое разделение на команды: разработка, верификация и алгоритмисты. Многие аппаратные компании работают по такой схеме:
- одна команда разрабатывает реф-модель, требования и документацию к тому, как всё должно работать;
- дальше модель вместе со спецификацией передается в команду разработки;
- другая команда проводит тестирование и подтверждает, что работает, а что нет.
Допустим, есть фича. Как верификатор, я должен был разобраться, что она из себя представляет и как встраивается в общий конвейер. Потом вытащить требования из спецификации и на старте составить тест-план: что и как именно проверять, как подтверждать, что все работает. А еще мне нужно было определить, какие тесты писать самому, а какие взять уже готовыми из команды моделирования.
Всё это время я взаимодействовал с разработчиком, ведь он параллельно или переписывал модуль, или писал новый. Мне нужно было дать ему тестовое окружение, чтобы он мог в нем отладиться. При необходимости ставил модуль на регрессионное тестирование и помогал отлаживать крупные изменения.
На старте от меня не требовали глубокого погружения в предметную область и дали две недели на подтягивания UVM. Это очень помогло. По сути, на тот момент я мог осваивать новую технологию, задавать вопросы коллегам с разных частей мира, а за это мне еще и платили. Золотые времена!
Помимо UVM, меня учили формальным вещам, без которых двигаться дальше было невозможно. Допустим, я сделал тестовое окружение, написал тесты или взял уже готовые, запустил на RTL, но ничего не работает. Дальше мне нужно было разобраться и оформить проблему в читаемом виде. Не просто «тест падает», а «зависает этап декодирования символа в режиме передачи на частоте 60 МГц» — это режим работы приемника, а не тактовая частота. Потом оформить это в таск-трекинге.
Составлять отчеты важно для экономии времени всей команды. Если ты плохо оформил тикеты или недостаточно всё расписал, коллеги не поймут, как им использовать информацию. Дальше вы потратите время на выяснение деталей, переделки и синхронизацию. Поэтому сам процесс передачи артефактов между командами стал для меня ценным навыком.
Мне нравилось работать с «легаси» тестовым окружением, которому было больше 10 лет. Изучать механизмы, которые уже обросли вековыми кольцами: неоптимально написанные скрипты запуска или SV-конструкции внутри тестбенча. Разматывая отдельные скрипты, я видел, какие были изменения, кто и сколько лет назад их написал. Дальше приходил кто-то другой, писал костыли сверху, а потом быстро увольнялся. И так по кругу. Иногда от «колец» веяло «сильной аурой»: было понятно, что их написал хороший инженер. И вот ты сидишь, распутываешь всё это и правишь.
Приведу пример. Когда я только пришел в команду, после запуска тестов нам приходилось 15 минут ждать, чтобы система просто «продышалась». На старте каждой симуляции одни и те же файлы открывались и перезачитывались сотни раз на каждый тест. Разумеется, необходимости в этом не было. Мне это сильно не нравилось, ведь я пришел из мира, где была минимальная терпимость к таким вещам — стараюсь нести этот подход в свою команду до сих пор. Поэтому параллельно своим рабочим задачам я улучшал общую инфраструктуру. Уже через месяц тесты запускались практически сразу. Это было приятно, я физически ощутил пользу от этой активности. Да и коллегам стало сильно комфортнее работать с большими регрессиями.
Чем меня «зацепила» верификация
Аппаратная разработка интересовала меня еще со времен университета. Как большинство студентов-программистов, я писал программы на C, C++, Java, Python и PHP. Для примера возьмем путь, который проходит программа на C. В конечном итоге она превращается в машинный код, который так или иначе исполняется последовательно (с оговорками, конечно):
В аппаратной разработке ты тоже пишешь код — например, на SystemVerilog. Но здесь все блоки работают в параллель. Если в обычном программировании ты смотрел на разработку как на последовательность инструкций для CPU, то теперь взгляд становится трехмерным. К каждому компоненту, который ты создаешь, добавляется измерение времени, неотрывное от того, что ты пишешь.
Можно заметить, что есть многопоточные программы, и это хороший пример. А теперь представьте, что каждая строчка вашей программы, каждый оператор — это отдельный поток. Сложно. Но именно этот вызов и промотивировал меня с головой уйти в верификацию.
Если резюмировать, самые привлекательные черты верификации для меня:
- нестандартный взгляд на разработку: нужно научиться мыслить в парадигме, что все строчки кода параллельные;
- максимальная оптимизация всего: RTL, скорости, ресурсов для работы тестового окружения, чтобы отладка дефектов шла быстрее, а тестов можно было запускать как можно больше;
- высокая экспертиза: во всех командах, где я работал, у верификаторов можно было научиться множеству навыков, да и в целом это всегда были очень приятные люди.
Как становятся верификаторами
Раньше в России не было отдельного направления подготовки верификаторов, но сейчас ситуация изменилась: технические вузы в коллаборации с IT-компаниями открывают профильные кафедры, появляются новые курсы и программы стажировок.
Вот несколько примеров, в которых я точно уверен (а если у вас есть, чем дополнить список, пишите в комментариях):
- Если интересно углубиться в тему, присмотритесь к практическим курсам YADRO — направление «Верификация систем на кристалле». Сюда же Школа синтеза цифровых схем, программа на базе курса MIT при поддержке YADRO.
- Если серьезно настроены получать профессию, вам будет интересна магистратура по микроэлектронике от YADRO и МИЭТ. За два года студенты обучаются проектировать системы на кристалле (СнК).
- Если хотите попробовать свои силы в реальной работе, приходите на стажировку в «Импульс» — тут тоже есть отдельное направление по верификации.
Как попасть в профессию без специального обучения
Несколько лет назад студенты в лучшем случае могли «пощупать» верификацию лишь на коротких дополнительных курсах, которые заканчивались зачетом. Отдельно этому направлению не обучали. Это привело к тому, что верификаторы обычно рождаются «в полях», и порог входа в профессию в зависимости от проекта сильно размыт.
Чаще всего в верификаторов «перевоплощаются» разработчики и FPGA-инженеры, когда в команде появляется такая потребность. По моему опыту также быстро переучиваются специалисты, чья работа так или иначе связана с аппаратной разработкой — например, если работали в НИИ над смежными проектами. А еще — программисты, которые интересуются «железом» и инструментами для его разработки.
Чаще всего это происходит так. В небольшой команде — возможно, даже стартапе — сотрудники разрабатывают и пишут тесты, продукт крепнет. В какой-то момент появляется желание делать больше проектов для большего количества заказчиков. Нужно уже не 10, а 40 релизов в год. Что делать? Растить команду и набирать новых людей, конечно.
Сначала вам хочется, чтобы каждый специалист мог делать всё сам: и писать тесты, и разрабатывать, и верифицировать. Но когда проектов много, вы быстро начинаете понимать, что задачи будут выполняться качественнее, если специалист сфокусируется на одном направлении. Тогда-то и появляются два лагеря:
- одни уходят в разработку и пытаются выжать каждый бит, сократить каждый проводочек, чтобы все было оптимально с точки зрения площади, частоты и потребления;
- другие погружаются в верификацию, UVM, переиспользуемые компоненты и стек автоматизации, чтобы весь этот «праздник жизни» не только экономил площадь, но еще и функционировал.
Верификаторы нужны всегда
Как я уже писал выше, в верификации всегда дефицит кадров: каждый год появляются новые приложения для ASIC и FPGA, как в России, так и по миру. Например, бумом прошлых лет стали AI-ускорители, и многие компании ринулись их делать в надежде занять лидирующие позиции. То же самое с FPGA-ускорителями для супербыстрой торговли на бирже. Мне нравится этот пример, потому что на таких проектах всегда помнят про верификацию и стоимость ошибки. Активные инвестиции шли и идут в сетевое оборудование, где важна минимальная задержка и высокая пропускная способность системы.
Условно мир аппаратной разработки можно разделить на две части — FPGA и ASIC. Ключевое для верификации различие между ними такое: FPGA можно перепрошить, исправив ошибку в дизайне, а ASIC «испекается» на фабрике. Ошибки в нем станут частью errata, потребуют SW-обходов или сделают партию чипов непригодными к использованию — на сленге разработчиков такие чипы называются «кирпичами». На производство партии ASIC уходят миллионы долларов, так что, сделав несколько партий кирпичей, компания рискует обанкротиться.
Внимание к верификации максимально высокое именно при ASIC-разработке.
В России, помимо перечисленного, есть курс на разработку собственного «железа». В итоге возможностей рождается кратно больше, чем верификаторов с профильных направлений. Важно, что ценятся в этой сфере далеко не только опытные специалисты, но и «начинашки», которые готовы быстро учиться. Ключевое здесь — интересоваться своим направлением, а дальше всё шаг за шагом подтянется.
