Всем привет! Меня зовут Алексей Ковалов, я руководитель отдела модульной верификации в YADRO в департаменте разработки процессорных архитектур. В прошлой статье я рассказывал, как расти верификатору. А сегодня хочу обсудить, как люди вообще приходят в эту профессию, ведь в вузах до недавнего времени верификаторов не готовили.
Дисклеймер: в статье нет технических деталей, так что матерые RTL-разработчики могут заскучать. А еще в ней нет лайфхаков, которые помогут за секунду определиться с карьерой и за три дня стать Илоном Маском. Зато есть реальный жизненный опыт. Я написал этот текст для ребят, которые еще не определились с карьерой после вуза или уже твердо решили связаться с «аппараткой», но пока выбирают между разработкой и верификацией. Надеюсь, он поможет сориентироваться.
Однажды у меня тоже была дилемма: кем пойти работать — разработчиком или верификатором. Тогда у меня не было четкого понимания, какие конкретно задачи я должен выполнять, если выберу второй путь, и насколько это мое. И вот я в верификации уже больше 6 лет. Как так сложилось и что меня тут «зацепило» — объясню ниже. А еще расскажу, какие специалисты чаще всего «перевоплощаются» в верификаторов и где вообще можно прикоснуться к этому направлению.
Откуда берутся верификаторы
Прежде чем с головой уйти в размышления о карьере, давайте разберемся, что вообще происходит с кадрами в верификации.
Раньше в России не было отдельного направления подготовки верификаторов. Это сейчас ситуация изменилась: в YADRO есть программа стажировок «Импульс» с направлением «Верификация» и своя кафедра в МИЭТ. Другие технические вузы тоже открывают смежные кафедры.
Тут показал, где можно прикоснуться к направлению верификации:
программа стажировки «Импульс» — есть отдельное направление «Верификация»;
магистратура по микроэлектронике от YADRO и МИЭТ: за два года студенты обучаются проектировать системы на кристалле (СнК);
практические курсы YADRO — есть направление «Верификация систем на кристалле»;
Школа синтеза цифровых схем — программа на базе курса MIT при поддержке YADRO.
Проверить свои силы и получить опыт можно и на хакатонах. На SoC Design Challenge есть трек по системной и UVM-верификации. Участники, показавшие высокие результаты, могут получить оффер в компанию. Но даже если занять призовые места не удалось, работодатели обычно ценят участие в хакатонах и соревнованиях. Проект, который вы подготовили и защитили, можно смело добавлять в резюме.
Но несколько лет назад максимум, что могло быть, — это короткий дополнительный курс, который заканчивался зачетом. Это привело к тому, что верификаторы обычно рождаются «в полях», и порог входа в профессию в зависимости от проекта сильно размыт.
Чаще всего в верификаторов «перевоплощаются» разработчики и FPGA-инженеры, когда в команде появляется такая потребность. По моему опыту также быстро переучиваются специалисты, чья работа так или иначе связана с «аппараткой» — например, если работали в НИИ над смежными проектами. А еще — программисты, которые интересуются «железом» и инструментами для его разработки.
Происходит это примерно так. Допустим, у вас есть небольшая команда — возможно, даже стартап. Ребята разрабатывают и пишут тесты, продукт крепнет, все в порядке. В какой-то момент появляется желание делать больше проектов для большего количества заказчиков. Релизов нужно выпускать уже не 10 в год, а, например, 40. Что делать? Растить команду и набирать новых людей, конечно.
Сначала вам хочется, чтобы каждый специалист мог делать все: и писать тесты, и разрабатывать, и верифицировать. Но когда проектов много, вы быстро начинаете понимать, что задачи будут выполняться качественнее, если специалист сфокусируется на одном направлении. Тогда-то и появляются два лагеря:
одни уходят в разработку и пытаются выжать каждый бит, сократить каждый проводочек, чтобы все было оптимально с точки зрения площади, частоты и потребления;
другие погружаются в верификацию, UVM, переиспользуемые компоненты и стек автоматизации, чтобы весь этот «праздник жизни» не только экономил площадь, но еще и функционировал.
Растить верификаторов можно и внутри своей команды, и приглашать специалистов извне уже с опытом. Но на своем проекте их в любом случае нужно будет «дотягивать». В своей прошлой статье я рассказывал, как мы помогаем верификторам адаптироваться в команде и расти по карьерной лестнице. Еще для инженеров любого грейда у нас в компании работает программа ротации: если специалист хочет поменять роль, он может обратиться к руководителю. Для него составят план перехода. Прямо сейчас моя коллега как раз готовит статью на эту тему: она перешла в верификацию из software. После публикации подтяну сюда ссылку.
Верификаторы нужны всегда
В верификации всегда дефицит кадров: каждый год появляются новые приложения для ASIC и FPGA, как в России, так и по миру. Например, бумом прошлых лет стали AI-ускорители, и многие компании ринулись их делать в надежде занять лидирующие позиции. То же самое с FPGA-ускорителями для супербыстрой торговли на бирже. Мне нравится этот пример, потому что на таких проектах всегда помнят про верификацию и стоимость ошибки. Активные инвестиции шли и идут в сетевое оборудование, где важна минимальная задержка и высокая пропускная способность системы.
А еще в России, помимо перечисленного, есть курс на импортозамещение и разработку собственного «железа». В итоге возможностей рождается кратно больше, чем верификаторов с профильных направлений. И ценятся в этой сфере далеко не только опытные специалисты, но и «начинашки», которые интересуются направлением и готовы быстро учиться.
Условно мир «аппаратки» можно разделить на две части — FPGA и ASIC. В дизайнах под них много отличий, но ключевое для верификации здесь вот что: FPGA можно перепрошить, исправив ошибку в дизайне. К слову, поэтому на FPGA-конференциях — например, FPGA-Systems — трек верификации представлен довольно скудно. Но ASIC «испекается» на фабрике. Это готовый чип, перепрошить его не получится. Ошибки в нем станут частью errata, потребуют SW-обходов или сделают партию чипов непригодными к использованию — на сленге разработчиков такие чипы называются «кирпичами». На производство партии ASIC уходят миллионы долларов, так что, сделав несколько партий кирпичей, компания рискует обанкротиться. Поэтому внимание к верификации максимально высокое именно при ASIC-разработке.
Сейчас в YADRO открыты вакансии:
— ведущий инженер системной верификации CPU IP;
— инженер по верификации (Wireless & Systems).
Присоединяйтесь!
Что насчет меня? Мой путь в верификацию
Давайте еще один дисклеймер: моя история — просто личный пример. Я не призываю ее повторить, а хочу донести мысли, которые могут помочь определиться с карьерным треком.
Я учился на кафедре информационной безопасности в Санкт-Петербургском государственном университете аэрокосмического приборостроения (ГУАП). Где-то на втором курсе меня и еще нескольких сильных студентов пригласили в маткружок изучать углубленно теорию кодирования. Вел его аспирант со смежного направления: ему было интересно развиться в навыках донесения информации и вскрыть возможные пробелы в собственных знаниях. А нам с товарищами было интересно абсолютно все, связанное с нашей специальностью.
Где-то через полгода занятий и расширения состава вовлеченных преподавателей, у меня с аспирантом-преподавателем произошел диалог, из-за которого эта часть истории и попала в статью:
— Почему ты вообще нами занимаешься? Ведь мы не отличники, нам просто хочется что-то делать…
— Толк выходит как раз с тех студентов, которые хотят что-то делать.
Его ответ очень помог мне сформировать свое видение того, как в принципе нужно развиваться.
Еще через полгода кружок было решено облечь в общественно полезную историю, и меня с товарищами передали в лабораторию на кафедре — там в основном занимались коммерческими проектами. Получается, я попал в первую в своей жизни команду, которая занималась аппаратной разработкой. Так начался мой путь в верификацию, хотя сам я об этом тогда еще не догадывался.
В лаборатории я работал с разными людьми и прокачивал навыки в разных направлениях. В основном в тех, которые можно отдать студенту — например, это была исследовательская работа несложных алгоритмов с реализацией на C++, работа со скриптами и инфраструктурой и все в таком духе. Параллельно я посещал курсы университета, которые помогали уложить новые знания по полочкам. Я видел, как теория из лекций реализуется на практике.
Криптографические алгоритмы, которые были самой любимой частью обучения, хорошо ложились на реализацию в «железе». Так что переход на аппаратную разработку был для меня очень естественным.
После бакалавриата встал вопрос магистратуры. Я поступил в Сколтех и на какое-то время выпал из рабочей активности. Акцент сделал целиком на учебе. Курсы шли исключительно на английском, преподавательский состав в большей степени, как и студенты, были из-за рубежа. Осложняло историю то, что тема для магистерской, о которой договорились при поступлении, была оторвана от уже полюбившегося мне «железа». Звучала она примерно так: «Машинное обучение для алгоритмов физического уровня обработки сигнала». На старте было страшно и сложно. Мне предстояло за лето дотянуть английский до уровня, чтобы понимать лекции и участвовать в рабочих группах. Но весь полученный опыт окупился с лихвой.
Не отказывайтесь от вызовов, берите сложные и интересные проекты, вписывайтесь в инициативы. Да, будет сложно. Но только через старание вы сможете достичь высоких результатов. Выбирая между заведомо трудным, но интересным вариантом, или средним и стабильным, заклинаю вас: возьмите первый.
После магистратуры в аспирантуру я решил уже не поступать: мне хотелось расти как инженеру, а в индустрии это получилось бы быстрее.
Работа после университета
Получив свою пачку дипломов, я практически сразу вышел на работу фултайм. Попал в свою старую команду со времен университета. Ребята отделились от вуза и стали отечественным аппаратным стартапом. Компания занималась и продолжает заниматься разработкой RISC-V CPU IP.
Принцип, на котором я основывал свой выбор, был почерпнут у моего преподавателя по английскому языку. Когда студенты спрашивали у него, какие учебные заведения лучше выбрать, он отвечал: «Лучше следовать за людьми, а не за школами». Так и у меня была абсолютная уверенность, что в этой команде я смогу научиться безумному количеству вещей. Тогда я еще не был верификатором: официально моя должность называлась «Инженер-программист», хотя через какое-то время меня повысили до инженера по аппаратному обеспечению.
Что у меня тогда было по скилам? Я умел писать на С и C++, хорошо знал STL. Понимал: умение писать на «плюсах» со словарем не означает, что нужно писать C++ к себе в CV. Еще писал на Python, а большое количество маткурсов загрузило в меня знание библиотек для работы с данными. Также с учебных курсов я помнил Java.
На работе в мои задачи входили разработка модулей и интеграция готового блока. Я писал тестовое окружение и базовые тесты, чтобы убедиться, что все корректно работает. Дальше интегрировал в общую платформу, где уже есть CPU, интерконнект и периферия. Проверял на тестах в симуляторе. Готовил сборку под прототип на FPGA. Писал bare-metal тесты, тесты системного уровня. Так на FPGA-прототипе можно было проверить, что разработанный Ethernet-контроллер действительно работает и две платы могут общаться друг с другом по сети.
Я поработал в компании почти три года, но стартап растет небыстро. В бэклоге было бесконечное множество задач, которые не требовали грандиозного роста, а расти мне очень хотелось. Я начал смотреть другие вакансии.
Сначала было страшно и сложно. Свой первый серьезный «собес» я вообще провалил. А потом в моей жизни появилась Quantenna. Ребятам были нужны разработчики, но еще нужнее им были верификаторы. На момент знакомства я набил неплохой опыт «в ширину» умел, как в разработку, так и в верификацию. В компании нужно было разрабатывать и верифицировать DSP-подсистемы, и мой опыт для этого подходил: из учебных курсов мне были близки инфотелекоммуникации, а DSP-блоки можно было представить в виде вычислительных элементов, по аналогии с CPU. Конечно, мне нужно было еще многому научиться: UVM я тогда совсем не знал. Но спустя несколько собеседований с командой понял, что мне все-таки интересно, и решил испытать себя.
Так я официально стал верификатором в крупной зарубежной Enterprise-компании. У нас было четкое разделение на команды: разработка, верификация и алгоритмисты. Многие аппаратные компании работают по такой схеме:
одна команда разрабатывает реф-модель, требования и документацию к тому, как все должно работать;
дальше модель вместе со спецификацией передается в команду разработки;
другая команда проводит тестирование и подтверждает, что работает, а что нет.
Теперь расскажу, чем конкретно занимался я.
Какие у меня были задачи
Допустим, есть фича. Я должен пойти разобраться, что она из себя представляет и как встраивается в общий конвейер. Потом вытащить требования из спецификации и на старте составить тест-план: что и как именно мы будем проверять, как будем подтверждать, что все работает. Еще мне нужно было решить, какие тесты писать самому, а какие взять уже готовыми из команды моделирования, ведь там ребята тоже тестировали свою модель.
Все это время я взаимодействовал с разработчиком, ведь он параллельно или переписывал модуль, или писал новый. Мне нужно было дать ему тестовое окружение, чтобы он мог в нем отладиться. При необходимости ставил модуль на регрессионное тестирование и помогал отлаживать крупные изменения.
На старте от меня не требовали глубокого погружения в предметную область и дали две недели на подтягивания UVM. Помню было даже что-то вроде напутствия: «У тебя есть пара недель, пока на тебя не начнут падать серьезные задачи. Используй их по максимуму». Это мне правда очень помогло. По сути, на тот момент я был на седьмом небе: мог осваивать новую технологию, задавать вопросы коллегам с разных частей мира, а за это мне еще и платили. Помимо UVM, меня учили формальным вещам, без которых двигаться дальше было невозможно.
Допустим, я сделал тестовое окружение, написал тесты или взял уже готовые, запустил на RTL, но… ничего не работает. Дальше мне нужно было разобраться и оформить проблему в читаемом виде. Не просто «тест падает», а зависает этап декодирования символа в режиме передачи на частоте 60 МГц (это режим работы приемника, а не тактовая частота). А потом оформить это в таск-трекинге.
Составлять отчеты важно для экономии времени всей команды. Если ты плохо оформил тикеты или недостаточно все расписал, коллеги не поймут, как им использовать информацию. Дальше вы потратите время на выяснение деталей, переделки и синхронизацию. Поэтому сам процесс передачи артефактов между командами стал для меня ценным навыком.
Еще мне нравилось работать с «легаси» тестовым окружением, которому было больше 10 лет. Изучать механизмы, которые уже обросли вековыми кольцами: неоптимально написанные скрипты запуска или SV-конструкции внутри тестбенча. Разматывая отдельные скрипты, я видел, какие были изменения, кто и сколько лет назад их написал. Дальше приходил кто-то другой, писал костыли сверху, а потом быстро увольнялся. И так по кругу. Иногда от «колец» веяло «сильной аурой»: было понятно, что их написал хороший инженер. И вот ты сидишь, распутываешь все это и правишь проблемы.
Давайте пример. Когда я только пришел в команду, после запуска тестов нам приходилось 15 минут ждать, чтобы система просто «продышалась». На старте каждой симуляции одни и те же файлы открывались и перезачитывались сотни раз на каждый тест. Разумеется, необходимости в этом не было. Мне это сильно не нравилось, ведь я пришел из мира, где была минимальная терпимость к таким вещам (стараюсь нести этот подход до сих пор). Поэтому параллельно к моим рабочим задачам я улучшал общую инфраструктуру. Уже через месяц тесты запускались практически сразу. Это было приятно, так как я физически ощутил пользу от этой активности. Да и коллегам стало сильно комфортнее работать с большими регрессиями.
С первых месяцев работы я понял, что хочу продолжать заниматься верификацией и дальше. Мне нравилось сочетание аппаратных задач с огромным количество околософтварных. Если первые — это работа вдолгую, то вторые позволяют получить быстрый дофамин от того, что ты что-то быстро пофиксил или внедрил улучшение, и теперь все работает лучше.
А потом Quantenna не стало — с крупными компаниями так тоже бывает. Получается, в ней я проработал больше двух лет, и это было замечательное время.
Дальше я попал в Синтакор, который уже стал частью YADRO. Здесь все завертелось очень быстро. В скором времени я дорос до лидирующей роли и теперь вместо технических статей пишу мотивационные.
Чем меня «зацепила» верификация
Как вы уже прочитали, аппаратная разработка интересовала меня еще со времен университета. Но как большинство студентов-программистов, я писал программы на C, C++, Java, Python, да простят меня коллеги, PHP. Программа на C в конечном итоге превращается в машинный код, который так или иначе исполняется последовательно (с оговорками, конечно).
В «аппаратке» ты тоже пишешь код – на SystemVerilog, например, но все процедурные блоки, которые ты порождаешь, работают в параллель. Получается, в разработке у тебя был двухмерный взгляд на мир: последовательность инструкций, исполняемых на CPU, а тут он резко становится трехмерным. Ко всему, что ты создаешь прямо сейчас, добавляется еще измерение времени. Оно неотрывно от каждого компонента, который ты написал.
Можно заметить, что есть многопоточные программы, и это хороший пример. А теперь представьте, что каждая строчка вашей программы, каждый оператор — это отдельный поток. Сложно. Но именно этот вызов и смотивировал меня с головой уйти в эту сферу.
Чтобы стать хорошим специалистом, тебе нужно одновременно быть сильным и в программировании, и в электронике, и в UVM, и в своей предметной области. А еще — уметь общаться с людьми, чтобы баги фиксились, а не зависали в «пинг-понге» между разработкой и верификацией.
Если резюмировать, самые привлекательные черты верификации для меня:
нестандартный взгляд на разработку: нужно научиться мыслить в парадигме, что все строчки кода «параллельные»;
здесь важно выжать каждый битик для оптимизации и сокращения стоимости изготовки чипа, а это то�� еще вызов;
высокая экспертиза и обмен опытом: во всех командах, где я работал, у верификаторов можно было научиться огромному количеству навыков, да и в целом это всегда были очень приятные люди.
Разработчик или верификатор — что выбрать?
Выше я рассказывал, что однажды передо мной стоял выбор: быть или не быть кем пойти работать — разработчиком или верификатором. Если вы сейчас задаете себе примерно тот же вопрос, постараюсь помочь вам внести немного ясности.
Вот что я заметил за время работы в сфере:
Если у вас есть интерес к аппаратуре и софтверному стеку, С/С++, вам может зайти верификация. Если нравится разбираться с open-source-инструментами, это тоже мэтч. Нравится находить слабые места в системе, строить сценарии и доказательства того, что процессы не сломаются при самых безумных условиях, — вам точно сюда.
Если интересует электроника, схемы и руки сами тянутся к осциллографу, стоит присмотреться к разработке. Часть людей привлекает сама предметная область: только здесь можно разобраться, как устроен компьютер на самом базовом уровне логических компонентов.
Простите, профориентационного опросника на 100 вопросов не будет. Главная мысль тут такая: нужно выбрать направление, которое вам действительно интересно, и постепенно развиваться в нем. Шаг за шагом разбираться, как все устроено.
Отдельные направления IT-рынка перенасыщены молодыми кадрами после онлайн-курсов и использованием AI в и��тервью. Но хорошие специалисты будут нужны везде и всегда. А стать крутым экспертом легче всего в сфере, где вам действительно интересно. Поэтому мой совет: выбирайте то, что ближе.
Хайповые отрасли в моменте могут предложить более эффектную зарплатную вилку, но гнаться за трендами — так себе стратегия. Ситуация на рынке быстро меняется, а сотрудники, работающие не по призванию, выгорают еще быстрее. В долгосрочной перспективе выбор роли, которая соответствует вашим интересам, всегда выгоднее. Именно навыки, усвоенные не только в работе, но и «just for fun» — просто потому, что вам интересно — и делают из вас экспертов, которые будут высоко цениться и оплачиваться и в разработке, и в верификации, и во всех других направлениях.
На такой жизнеутверждающей ноте я и закончу эту статью. В комментариях готов ответить на любые вопросы по теме.