И в дополнение к посту выше - практически исчерпывающий разбор доклада 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

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

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

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

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

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

--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

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

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 запустили новый 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/

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

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

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

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

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

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

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

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

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

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

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

https://youtu.be/I_Vg7Kog5TE

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

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

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

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

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

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