От кода до кристалла: SoC Design Challenge 2025

Хакатон посвящен различным аспектам создания и проверки SoC — «системы на кристалле». Так называют чипы, в которых на одном кристалле объединены процессор, память и вспомогательные блоки — например, JPEG-декодер или контроллер интерфейсов.

Хакатон организован YADRO совместно с МИЭТ и охватывает сразу четыре направления: описание поведения блоков на языках HDL (RTL-проектирование), разработку компонентов UVM-окружения (UVM-верификация), поиск ошибок в работе модулей внутри всего чипа (системная верификация) и создание финальной физической структуры микросхемы (топологическое проектирование).

В этом треке участники работали на уровне RTL (Register-Transfer Level) — стадии разработки, где поведение цифровой схемы описывается в виде кода на языках HDL (Verilog, SystemVerilog). Такой код описывает, что должно происходить в микросхеме на каждом такте, то есть при каждом импульсе тактового сигнала: какие данные передаются, где хранятся и как обрабатываются. Такт — это базовый ритм работы схемы, синхронизирующий все ее действия. RTL-код не запускается как обычная программа, а используется для описания логики схемы — того, что она должна делать и как должны взаимодействовать ее блоки.

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

Задания были разделены на два уровня: Basic и Basic+.

В треке Basic участники работали с AXI Performance Monitor — модулем, собирающим статистику о работе интерфейса передачи данных. Студентам выдали полностью рабочую, но намеренно неэффективную версию. Нужно было разобраться в архитектуре и оптимизировать ее, чтобы уменьшить потребление ресурсов и не ухудшить пропускную способность. Скрипт для проверки автоматически подсчитывал итоговые баллы: он учитывал корректность работы и «штрафовал» за избыточную сложность. Подобные задачи регулярно встречаются в практике RTL-инженеров.

На уровне Basic+ участники работали с нейропроцессорным ускорителем (НПУ) — упрощенным модулем, выполняющим типовые операции из задач машинного обучения. В частности, он должен был перемножать входные данные с весами из матрицы — по принципу, похожему на те, что используются, например, при обработке изображений в нейросетях. Исходная реализация обрабатывала данные по одному байту за раз, без буферизации и оптимизации доступа к памяти. Участники должны были предложить улучшения: например, выстроить вычислительный конвейер или перейти от поэлементной обработки к блочной, учитывая ограничения на пропускную способность (не более 32 байт за такт). Это задание требовало уже не только понимания языка описания, но и архитектурного мышления — особенно в контексте аппаратной реализации ИИ.

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

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

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

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

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

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

Несмотря на сжатые сроки, команды добились впечатляющих результатов: за три дня они подготовили 73 баг-репорта, из которых лишь 8 оказались ложными. Некоторые участники настолько внимательно изучили спецификацию, что нашли две особенности, которые были упущены организаторами при составлении задания.

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

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

Блок — это функциональный компонент схемы, например JPEG-декодер — подсистема, отвечающая за сжатие изображений. Он может быть реализован в виде одного или нескольких модулей на Verilog. Но на уровне системной верификации нас интересует не только описание на языке Verilog, а поведение блока в системе: как он взаимодействует с другими частями, передает и получает данные, реагирует на команды.

Участникам нужно было по спецификации и документации к модели выявить ошибки в поведении JPEG-декодера и объяснить, почему система ведет себя неправильно. Организаторы подготовили более 10 вариантов подключения блока в системе с заранее внесенными ошибками, которые нужно было найти и описать.

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

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

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

Чтобы приблизить задание к реальности, организаторы взяли студенческий проект, который создают стажеры YADRO, и намеренно «испортили» его: перемешали расположение блоков, ячеек ввода/вывода, а также другие параметры. Участникам нужно было все восстановить, довести до работоспособности согласно требованиям и по возможности улучшить параметры: скорость, площадь, энергопотребление.

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

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

Организаторы стремятся к тому, чтобы SoC Design Challenge полностью покрывал маршрут разработки микропроцессора. Сейчас треки уже охватывают немало областей, и в перспективе их станет еще больше. Второе направление работы — это взаимная интеграция треков. Сейчас они изолированы, и в каждом даются свои уникальные задания. Было бы здорово объединить все в едином процессе, чтобы SoC Design Challenge полностью охватывал путь от идеи до готовой к использованию микросхемы.