Как найти свое направление в цифровом дизайне: опыт студентов Школы синтеза

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

RTL-разработчик отвечает за то, как алгоритм будет реализован в аппаратной схеме. Нужно придумать архитектуру блока, разбить ее на модули, организовать передачу данных, учитывать параллельную работу элементов и ресурсы, которыми располагает FPGA или ASIC.

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

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

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

Разобраться в этих направлениях только по описанию непросто: понятнее, когда можно самому попробовать спроектировать блок, написать RTL, собрать для него окружение и увидеть, что из этого действительно ближе. Такой подход лежит в основе Школы синтеза.

Можно интересоваться FPGA, хорошо знать SystemVerilog и успешно закончить RTL-проект и при этом обнаружить, что больше удовольствия приносит проверка схемы на работоспособность. Или, наоборот, понять, что интереснее самостоятельно создавать работающий блок, чем искать способы его проверить.

В Школе синтеза теория становится базой для дальнейшей практики: студенты изучают основные принципы цифровой схемотехники и RTL-разработки, а затем закрепляют полученные навыки на проектной работе с наставником.

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

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

У проектов Школы синтеза разные темы, но логика у них похожая: студенту дают задачу, которая по устройству напоминает реальную инженерную работу. Кирилл Алексеев, ведущий инженер по разработке аппаратного обеспечения YADRO, предложил в качестве проекта процедурную реализацию КИХ-фильтра в котором задействовали сразу несколько тем курса: цифровые автоматы, регистровые пространства, RTL-разработка и оптимизация цифровых схем. Задача связана с реальной областью работы команды YADRO — цифровой обработкой сигналов в модемах базовых станций.

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

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

Кристина Тельнова, ведущий инженер по разработке аппаратного обеспечения YADRO, предложила проект по реализации ядра Radix2, на основе которого Даниил Симоновский реализовал уже быстрое преобразование Фурье (БПФ), — это стандартная задача, с помощью которой можно разобраться с fixed-point арифметикой, конвейерами, DSP-блоками и блоками памяти.

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

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

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

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

Кириллу было интересно прежде всего поработать со старшим инженером: получить обратную связь на свои решения, проверить собственную базу и понять свои сильные и слабые стороны.

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

Сначала студент написал программную модель фильтра, затем RTL-реализацию и верификационное окружение. Параллельно он думал об оптимизации блока под архитектуру ПЛИС. В результате на одном проекте он попробовал задачу сразу с нескольких сторон: как программист, RTL-разработчик и верификатор.

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

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

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

Проект дал Кириллу и больше уверенности в собственных решениях. Раньше он часто сомневался, правильно ли делает ту или иную вещь. Работа с наставником помогла убедиться, что он способен самостоятельно принимать корректные инженерные решения.

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

Когда позже Кирилл выбирал направление стажировки «Импульс», у него были варианты и в RTL, и в верификации. В итоге он пошел в команду UVM-верификации.

Школа синтеза помогла решить задачу, которая шире самой разработки фильтра. Кирилл пришел проверить и укрепить знания по FPGA и RTL, а в процессе попробовал соседнюю роль и понял, что именно она подходит ему больше.

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

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

Работу разбили на последовательные этапы. Раз в неделю Даниил созванивался с наставником Андреем Рябковым, обсуждал результаты и следующие задачи. При этом способ реализации оставался за студентом.

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

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

Даниил пользовался материалами наставника, документацией и дополнительными источниками, а сложные задачи разбивал на части: сначала разбирался, как должен работать нужный фрагмент и только затем переносил его в RTL.

В отличие от Кирилла, которого проект в итоге привел к верификации, для Даниила работа скорее подтвердила уже появившийся интерес к RTL. До цифрового дизайна он успел заниматься и аналоговой схемотехникой, и топологией. Постепенно ему захотелось найти область, где можно одновременно работать с программированием и микроэлектроникой.

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

Подробнее про топологию интегральных схем можно почитать в статье старшего инженера по разработке систем на кристалле YADRO.

Даниил Симоновский пришел в Школу синтеза уже знакомым с Verilog и RTL: он изучал их и в бакалавриате, и в магистратуре. Поэтому проект по Radix2 и БПФ был для него не первым знакомством с цифровой схемотехникой, а возможностью проверить, насколько ему действительно подходит такая работа.

В рамках проекта Даниил прошел несколько главных этапов разработки: изучил особенности fixed-point арифметики, конвейерной обработки и использования DSP-блоков, разобрался в принципах выбора архитектуры, реализовал RTL-описание и проверил корректность полученного решения.

Даниил созванивался с Кристиной Тельновой примерно раз в неделю. В начале наставница больше помогала с архитектурой и объясняла, почему-то или иное решение лучше реализовать определенным способом. Постепенно Даниил становился самостоятельнее, и в финале сам написал весь блок FFT — аппаратный модуль, который выполняет быстрое преобразование Фурье и позволяет разложить сигнал на составляющие его частоты. После они вместе провели code review и разобрали участки, где можно повысить эффективность реализации.

При этом проект помог Даниилу лучше понять главное отличие RTL от привычного программирования. В аппаратном описании нужно постоянно представлять схему, элементы которой работают параллельно.

Во время проекта Даниил понял, что RTL ему в целом интересен, но сам характер такой работы не совсем подходит. Больше всего мешало то, что приходилось писать много кода и постоянно держать в голове множество взаимосвязанных сигналов.

Это не случайная сложность конкретного проекта, а одна из особенностей RTL-мышления:

Для человека, которому нравится низкоуровневая работа, именно это может стать преимуществом профессии: интересно оптимизировать схему, уменьшать количество ресурсов, ускорять обработку и видеть результат аппаратной реализации.

Параллельно со Школой синтеза студент пробовал направление микроконтроллеров и в процессе понял, что оно ему ближе. Поэтому при выборе дальнейшего трека Даниил не стал подаваться на RTL-направление и выбрал работу с микроконтроллерами.

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

Условно эти направления можно представить как четыре разных типа инженерного удовольствия.

RTL-разработчику важно придумать, как алгоритм будет работать в железе: разбить его на блоки, выстроить pipeline, учитывать параллельную работу схемы, ресурсы и ограничения архитектуры, а затем оптимизировать решение.

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

У верификатора другой фокус. Его задача — не создать сам дизайн, а убедиться, что тот работает правильно: придумать разные сценарии, проверить граничные случаи, построить модели и найти ситуации, которые разработчик мог не предусмотреть.

Иногда становится ясно, насколько тебе нравится эта работа, только после того, как попробуешь ее наравне с RTL. Так произошло с Кириллом Котовым.

Позже Кирилл выбрал именно направление верификации.

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

Здесь фокус смещается с логического описания на физическое воплощение схемы на кристалле. В проектах Школы синтеза студенты до этого этапа не доходили, но топология несколько раз возникала как важная точка сравнения.

Если RTL и базовую верификацию сравнительно легко попробовать самостоятельно — с помощью доступных инструментов, учебных задач и FPGA-плат, — то для физического дизайна гораздо важнее доступ к специализированным САПР. Поэтому попробовать эту профессию вне университета, лаборатории или компании может быть сложнее.

Главный вывод трех историй довольно простой: надежного теста, который заранее определит подходящую специализацию, нет. Нужно попробовать сам тип работы.

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