Записки CPU designer'a

RTL/Verif/PhysDesign-инженеры, теперь наша пора радоваться (либо трястись, что нас всех скоро сократят - смотря как вы относитесь к AI-ассистентам).
Anthropic хайрит Research Engineer, Chip Design RL - специалиста, который будет помогать прокачивать Claude в работе с chip design. Причём речь не только про кодогенерацию Verilog: в описании прямо фигурируют formal verification, physical design optimization, PPA и работа с EDA tools.
То есть идея примерно такая: взять реальный chip-design expertise и превратить его в задачи, evals и reward signals, на которых модели смогут учиться решать инженерные задачи из нашего домена.

Если вы счастливый обладатель разрешения на работу в США и у вас есть ASIC/FPGA background - можно попробовать свои силы и сходить на собес в Anthropic, лол.

https://job-boards.greenhouse.io/anthropic/jobs/5231612008

А потом не забудьте зашерить админу бета-доступ к прокачанной версии Claude👩‍🍳

How OpenAI Used Its Own LLMs to Design Its Jalapeño Chip

https://spectrum.ieee.org/llms-for-chip-design

tldr: последними работу потеряют backend инженеры, а всем остальным осваивать xls

Люблю технологии

ASUS driver - https://github.com/torvalds/linux/blob/master/drivers/hid/hid-asus.c#L550

Оригинальный твит - https://x.com/soragoto/status/2098983783085318491

Вышел новый формат от Истового Инженера - «Разгоны», где инженеры разных специальностей обсуждают какую-то тему. Тема же выпуска - скучное и очевидное «все профессии нужны, все профессии важны».

Формат прикольный, но как будто не хватает градуса накала, давайте исправлять.

Я как выпускник НИИшной школы проектирования заявляю: верификаторы не нужны в целом.

Всем давно известно, что маршрут называется RTL2GDS. RTL готовят, собственно, RTLщики, GDS - бэкендеры. А где тут верификаторы?

Правильно - 2. Та самая знаменитая формула, что на одного RTLщика нужно два верификатора. Ну согласитесь, что это безумие и пустое раздувание штата и бюджетов и явное принижение RTLщика как инженера, что якобы для проверки его работы нужно в 2 раза больше человеко-ресурса.

Для решения этих проблем давно придумали понятные паттерны дебага современных SoC, а именно - бут Linux на FPGA. Linux запустился? Ну всё: neofetch заранили, красивый скриншот сделали - и можно пилить лендос с успешным bring-up ядра.

Да и как RTLщик может называться RTLщиком, если сам не может раздебажить свой же код?

И давайте вспомним, что вообще такое верификация. Верификация - это проверка дизайна на соответствие спецификации.

Так а кто-то из вас эту самую документацию видел? На соответствие чему верификаторы проверяют дизайн? А если мы попросим RTLщика писать документацию, то кто будет писать RTL?

Замкнутый круг.

А вы что думаете? Я понимаю, что корпораты загоняют нас в рамки, но тут настоящая территория пост-разгонов. Приглашаю всех неравнодушных в комментарии.

https://youtu.be/I_Vg7Kog5TE

Jane Street запустили новый ASIC Challenge - на этот раз предлагают спроектировать настоящий open-source чип, а лучшие проекты обещают затейпаутить за свой счёт.

Задача довольно интересная: сделать general-purpose protocol emulator ASIC.

Идея в том, чтобы вместо отдельных UART, SPI и I2C контроллеров сделать универсальный программируемый контроллер, способный через GPIO реализовывать разные, в том числе кастомные, протоколы уже после изготовления чипа.

Первое, что тут приходит в голову, - PIO из Raspberry Pi RP2040. Собственно, сами Jane Street тоже приводят его в качестве одного из источников вдохновения.

https://rp2040pio-docs.readthedocs.io/en/latest/pio-programs.html

И тут, мне кажется, самое важное понять, где заканчивается FSM и начинается микроконтроллер 😁

Пару слов о формате. Когда задачка выходит за рамки одного дня, как мне кажется, она превращается из интересной головоломки в полноценный сайд-проект. Наверное, единственное, что подкупает в этом челлендже - Jane Street обещают затейпаутить самые интересные решения и отправить готовые чипы разработчикам. Честная это компенсация за такой объём работы или нет - решайте сами.

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

Основные правила: дедлайн - 18 января 2027 года, технода - IHP 130 nm CMOS5L, площадь - примерно 1 мм^2.

Остальные подробности смотрите в блоге Jane Street.
https://blog.janestreet.com/protocol-emulator-asic-competition/

AI EDAs: Is It Real?

В последнее время на канале мы всё чаще обсуждаем, как AI меняет индустрию. Мы уже разбирали достаточно уморительную статью, где авторы утверждали, что LLM якобы смогли спроектировать Linux-bootable ядро, а в итоге это оказался обычный 5-стадийник по Харрису.

Потом были последние новости про Astra от OpenAI, которая за один промпт якобы подготавливает schematic и полноценный PCB design. А в итоге оказывалось, что половина разъёмов вывернута внутрь платы, placement вызывает вопросы, а сам результат ещё требует довольно много работы со стороны инженера.

Так есть ли вообще что-то стоящее от AI в мире chip design или пока это в основном красивые демки и хайп в твиттере?
Мне кажется, это видео от Asianometry довольно хорошо отвечает на этот вопрос.

Спойлер - есть. Если грамотно построить цикл проектирования с постоянным feedback по PPA и другим QoR-метрикам, то уже сейчас можно получать неплохой буст в производительности труда.
Но до момента смены парадигмы с RTL2GDS на Prompt2GDS мы пока всё-таки не дошли.

К просмотру обязательно:

https://youtu.be/GzhfZy8-CjU

А вот и разборы решений пазла от Jane Street подъехали🫪

https://mummanajagadeesh.github.io/blogs/janestreet-asic-puzzle/

Давайте в комментариях хвастаться кто сколько пасхалок нашел, а кто проглядел морязнку в KLayout, как я?😑

Кстати, есть тут кто в канале, кто уже тестировал Astra на schematic/PCB-задачах?

В Twitter, конечно, каждый второй пост в духе «ONE SHOTTED/ЭТО КОНЕЦ/ONE PROMT RESULT». Но буквально под каждым таким постом приходит PCB-инженер и разносит результат работы Astra
это невероятно уморительно читать, особенно когда автору поста буквально нечего ответить

Интересно услышать опыт тех, кто реально пробовал: насколько оно уже применимо в работе и какие рутинные задачи уже хорошо автоматизируются?

Astra появилась в Codex

--x-initial-edge в Verilator: зачем он нужен

В Verilator есть флаг --x-initial-edge. Он решает давнюю проблему разницы в поведении между Verilator и big3 симуляторами (VCS, Questa, Xcelium).

В чём суть проблемы?
В стандарте IEEE 1800 SystemVerilog (см. Table 6-7 default values) в момент времени T = 0 4-state переменные имеют значение 'X'. Согласно стандарту system verilog переход из 'X' в '0' расценивается как negedge, а из 'X' в '1' - как posedge (см. Table 9-2).
В Verilator по умолчанию начальное значение сигналов для такой edge-детекции считается равным 0. Из-за этого установка сигнала в 0 в момент T=0 выглядит как 0 -> 0 и не генерирует negedge.

Почему это критично?
Это казалось бы незначительное отличие особенно заметно при отладке схем с Clock Gate контроллерами. Если clock подмодуля во время reset загейчен (clock отсутсвует), асинхронный reset может быть единственным событием, которое переводит внутреннее состояние блока в reset state.
Но код на скриншоте в Verilator не срабатывал, поскольку Verilator по умолчанию не моделировал начальный переход X -> 0 как negedge.

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

1) 0 (T0) -> 1 -> 0 // создаём настоящий negedge
2) 0 -> 1 // снимаем reset

Теперь такие костыли городить не нужно, подробности:

https://veripool.org/guide/latest/exe_verilator.html#cmdoption-x-initial-edge

Ещё один сайт с коллекцией die shots.

Можно выбрать несколько чипов и сравнить их на одном preview в одинаковом масштабе - удобно для визуального сравнения размеров die:

https://kurnal-insights.com/en/tools/die-composer/

Ещё есть интерактивный roadmap, где чипы можно смотреть с сортировкой по годам выпуска:

https://kurnal-insights.com/en/roadmap/

И в дополнение к посту выше - практически исчерпывающий разбор доклада OpenAI о Jalapeño с конференции Hot Chips 2026.

Там довольно много сильных архитектурных инсайдов: memory locality, организация NoC, работа с KV cache, latency hiding и в целом подход к проектированию inference ASIC.

Всем, кому интересны современные AI-accelerator архитектуры - читать. Ближе к выходным разберём самые интересные моменты подробнее в чатике канала.

https://zartbot.github.io/blog/arch/jalapeno/en.html

Jalapeño chip:
• OpenAI: https://openai.com/index/jalapeno-first-results/
• Semianalysis: https://newsletter.semianalysis.com/p/openai-jalapeno-better-than-nvidia
• Ian Cutress: https://www.youtube.com/watch?v=Ic0kYWjffjI

Наконец-то EDA-компании разобрались, как нужно продавать свои тулы инженерам💻

Новый инструмент для работы с Verilator-based регрессиями - wzv. record now, get waveforms later

Как обычно выглядит регрессионное тестирование RTL?

На условный IP есть большой набор тестов. Писать полный waveform dump для каждого из них - плохая идея: очень быстро закончится место на диске, а сама симуляция из-за tracing может замедлиться.

Поэтому regression обычно запускают без waves.
А дальше начинается классический debug workflow:

1) Запускаем regression без tracing.
2) Тест из regression коллекци падает, допустим, через 40 минут.
3) Видим error и время падения.
4)Пересобираем или перезапускаем тест с --trace-fst.
5) Ждём, ждём, ждём.
6) Получаем огромный FST файл, где информация нужна не вся, а в некотором окне от момента падения.

wzv решает именно эту проблему.
Вместо полного waveform dump симуляция запускается практически как обычно, но wzv записывает только информацию, которую Verilator не сможет потом восстановить самостоятельно:
- значения top-level inputs при каждом eval();
- simulation/tick time;
- периодические checkpoints состояния модели через VerilatedSave.

Такая запись получается очень маленькой и почти не влияет на скорость основной regression.
После падения теста workflow становится примерно таким:

1) Запускаем regression + wzv.
2) Тест падает. Получаем failure time.
3) Запускаем wzv replay только для небольшого окна, относительно failure time.
4) Получаем небольшой FST для интересующего участка.

То есть вместо того, чтобы заранее сохранять огромные дампы значений внутренних сигналов, мы сохраняем stimulus + checkpoints, а waveform восстанавливаем post-mortem только там, где он реально понадобился.
Причём можно восстановить как произвольное временное окно, так и весь run целиком.

Как же это работает?

This works because a Verilator model (2-state, --no-timing) is a deterministic function of its state and its inputs: the waveform carries no information beyond the input stream, so it doesn't have to be stored — only replayed. Checkpoints exist purely so replay can start near the window you ask for instead of at time 0.

Больше деталей - https://github.com/muzafferkal/wzv

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

Есть ли среди подписчиков выпускники школ или студенты, которые пошли учиться на направления, связанные с ASIC design, микроэлектроникой или цифровой схемотехникой?

Поделитесь опытом:

1) Куда и на какую программу вы поступили?
2) Как сейчас обстоят дела с конкурсом в вашей стране или регионе? Насколько сложно попасть на такие направления?
3) Если уже учитесь - какие впечатления от университетской программы? Чего в ней не хватает, что хотелось бы добавить или изменить?
4) Насколько много практики именно по RTL, цифровому дизайну, архитектуре, verification и работе с реальными инструментами?

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

Отдельно любопытна тема массовой доступности нейросетей и AI-ассистентов. Как они повлияли на обучение техническим специальностям? Стало ли проще разбираться в сложных темах и делать проекты или, наоборот, стало сложнее отделять реальное понимание предмета от возможности быстро получить готовый ответ и убедить себя в том что тема усвоена?

Будет интересно почитать опыт из разных стран и университетов😎

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

Половина из них к тому же разработана инженерами, с которыми я знаком👀

Так что спасибо LLM-кам и инженерам, которые находят свободное время, чтобы контрибьютить в эти проекты и делать жизнь людей в индустрии немножечко лучше😺