Пост на Хабре - https://habr.com/en/articles/1082650/

Почти три года назад, когда я начал митапы Verilog Mettup в Hacker Dojo, на них пришел Владимир Чурюкин и когда посмотрел на мою инфраструктуру Basic-Graphics-Music, где баш-скрипты по имени платы строят проект, сразу сказал “А давайте перепишем все на питон”. И переписал! С оговоркой что это PoC, то бишь Proof of Concept, то есть он это проверил только на 5-ти платах, а не на всех 45-ти, как мой исходный репозиторий.

А теперь посмотрим что из этого получилось.

Так как я в это индустрии 40 лет и читал книжки Брукса и других еще когда ездил в трамвае в физматшколу и работал у мамы на работе на СМ-4, то я знаком с этой ситуацией более чем. Разработчик приходит в новый проект. Ковыряться в том что есть ему неинтересно, то что есть ему видится отвратительным, а аргументы, что существующее решение достаточно он отвергает. На предложение заняться новой фичей поверх существующей инфраструктуры он исчезает на некоторое время, а потом возвращается с “вот, смотрите, как нужно!” и показывает переписанную инфраструктуру.

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

1. Лично сесть и написать все фичи, а не только proof of concept.

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

3. Уломать прользователей смириться, что отныне программа поддерживает не 45 плат, а только 5, а также теперь программа не умеет находить где установлены тулчейны, и их пользователь должен ручками ввести в YAML файл. А также пользователь должен сам отлаживать случаи когда не работает драйвер в Linux, потому что новая программа не сказала пользователю сделать update в /etc/udev. Или случаи когда macOS объявляет файл от FPGA вендора malware.

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

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

Также интересно, что спор как правило ведется в двух плоскостях. Старый разработчик говорит что новый подход требует преобразования проприетарных форматов от нескольких вендоров и ad-hoc файлов для мэппинга чего-то в один формат, но при этом новая преобразовалка недостаточно умна чтобы например парсировать ifdef-ы в преобразуемых файлах, а мануальное преобразование займет либо время, либо необходимость построчно проверять что там натворило AI с этими ifdef-ами, что нудно и противно. И непонятно ради чего, так как существующая инфраструктура и так работает, а что под капотом пользователю наплевать.

Новый разработчик отметает это как несущественную деталь и вещает о важности абстракций. Я книжки про важность абстракций стал читать еще когда СССР правил Генсек Константин Устинович Черненко (да, в СССР переводили в издательстве Мир книжки по программированию в том числе на эти темы), поэтому для меня важность абстракций разбивается в один момент: кто должен править вывод программ, которая написана на абстракциях, но не обрабатывает все случаи для пользователя, которые обрабатывает старая программа - я или он?

А вы что думаете? (Ссылки в посте на Хабре)

Два объявления:

27 сентября 2026 года митапа Verilog Meetup в Hacker Dojo не будет, потому что мы едем на Maker Faire в Вальехо!
4 и 11 октября 2026 года Verilog Meetup-ов тоже не будет, потому что Hacker Dojo переезжает в новый офис в Санта-Кларе!
Первый Verilog Meetup на новом месте предварительно запланирован 18 ноября 2026 года.

There will be no Verilog Meetup in Hacker Dojo on September 27, 2026, because we are going to Maker Faire in Vallejo!
There will also be no Verilog Meetups on October 4 and October 11, 2026, because Hacker Dojo is moving to a new Santa Clara office!
The first scheduled Verilog Meetup at the new location is tentatively scheduled for November 18, 2026.

Выступил с докладом через Zoom на конференции SEMICONUZ в Узбекистане. Заметил два момента:

Момент 1. Судя по вопросу преподавательницы из Ферганского политехнического института, в Узбекистане наверное ведутся дискуссии "кодописатели против физиков". То есть обсуждают, достаточно ли программировать софтвер на уже сделанных чипах и дизайнить на верилоге логику - или нужно вводить курсы физики полупроводников. Это впечатление подкрепил и доклад хорошо известного мне Нурсултана Кабылкаса про первый чип в Казахстане (Нурсултан делал PhD в Университете Калифорнии Санта-Круз и работал в AMD с Тимуром Палташевым).

Моя позиция по вопросу: хотя описанный мною в презентации процесс проектирования цифровых чипов в электронных компаниях (маршрут RTL2GDSII) построен так, чтобы максимально изолировать проектировщиков логики от физики - несмотря на это, физика в этом процессе все-таки проявляется:

1) Проектировщикам библиотек стандартных ячеек (ASIC standard cell library) нужно понимать физику того, из чего они строят всякие AND-OR, MUX2, DFF (D-Flip-Flop) примитивы и откуда берутся их параметры (пикосекундные задержки и фемтоваттное энергопотребление).

2) Разработчикам программ автоматизации проектирования, Electronic Design Automation (EDA), в частности статического анализа тайминга и физического проектирования, размещения и трассировки - нужно тоже понимать физику процесса, так как она там все время просачивается: значения на проводах скачут и устаканиваются только к концу такта (период которого нужно вычислить, причем задержки зависят от физических эффектов не только в транзисторах, но и на проводах.

3) В каждом ASIC-е есть не только цифровая, но и аналоговая часть, даже всякие датчики температуры внутри самого чипа, чтобы регулировать частоты и напряжения динамически.

Короче Узбекистан - это достаточно крупная страна, чтобы готовить специалистов по всему спектру микроэлектронной экосистемы. "Отец алгебры" Аль-Хорезми, аль-Бируни и Улугбек не одобрили бы что потомки вообще задают такие вопросы.

Момент 2. Судя по программе конференции и по докладу Нурсултана, в Средней Азии очень популярна китайская программа One Student One Chip. Программа действительно великолепна, появилась в правильное время (2019) в правильном месте (китайский институт ICT делал суперскалярные чипы Loongson еще 25 лет назад), с правильным контентом (от RISC-V до tapeout) и получила заслуженный успех (больше 10 тысяч студентов).

Вы ожидаете частицы "но"? (как писал Александр Сергеевич Пушкин в "Оде Его Светлости князю А. Н. Голицыну") Да, это "но" есть у меня. Насколько я понял (поправьте если я ошибаюсь), программа OSOC центрируется вокруг процессора общего назначения, CPU, и взаимодействия хардвера и софтвера. Но (!) на этом мир микроэлектроники не заканчивается: быстрый интернет, быстрая трехмерная графика и быстрые ИИ-ускорители стали возможны именно потому что создатели сетевых чипов (Juniper конца 1990-х), GPU и ML ускорителей (Google TPU и другие) - вывели большую часть обработки данных из процессора общего назначения. Что я упомянул в своих слайдах.

Все слайды и видео по идее будут на сайте конференции после ее окончания.

ИИ раскаялось, но это заняло пять итераций

Я чего-то не понимаю с этим ИИ. Медия с фанфарами хором поет "ИИ решил сотни математических Проблем Столетия за которые дают Филдсовские медали", а у меня сегодня GPT-6_Astra xHigh efforts сделала две глупости - одну на уровне второго курса университета, вторую в инструкции для 5 класса средней школы. Я разумеется заставил ИИ покаяться, но в своих извинениях оно изворачивалось и пыталось подать свою ошибку как "неудачную формулировку". Полное раскаяние потребовало пяти итераций. Вот первый случай:

1. Сначала ИИ заявило, что в моем примере для студентов содержится однозначная (definite) функциональная ошибка:

2. Я спросил: «Почему же тогда проходит тестовый стенд / testbench?»

3. ИИ ответило: «Я изучу реализацию и тестовый стенд, а затем проверю, была ли это действительно функциональная ошибка или же случай, который просто не покрыт тестами». Типа даже не пыталось предположить что это оно тупит.

4. Спустя несколько минут ИИ сообщило, что это все-таки оно виновато: «Нет, ваша реализация корректно обрабатывает это условие. Формулировка в моем отчете была неудачной, прошу прощения. Я описал гипотетическую ошибку в разделе "Проблемы" (Issues), хотя в вашем RTL-коде она уже предотвращена».

5. Но я тут же заметил, что оно извивается как уж на сковородке, говорит "Формулировка в моем отчете была неудачной" вместо "я по своей глупости ложно обвинило Юрия Панчула в элементарной ошибке в верилоге, хотя весь код был у меня перед глазами". Я его заставил признаться и в этом.

ИИ добавило формулировку:

6. ИИ : "Фраза «Формулировка в моём отчёте вводила в заблуждение» преуменьшала мою ответственность, представляя случившееся как редакционную проблему. Это была ошибка в моём техническом анализе. Более прямое исправление: Я ошибочно представил корректную реализацию Юрия Панчула как содержащую элементарную ошибку в микроархитектуре на SystemVerilog. Его код уже предотвращает извлечение операндов, когда FIFO результатов не может принять их сумму. Я не сумел последовательно применить базовые принципы анализа протокола обмена FIFO и высказал необоснованную критику с неоправданной уверенностью. Приношу извинения."

7. И (на пятом раунде раскаяния) ИИ дополнило: "В своём ответе я должен был поставить под проверку собственную оценку, вместо того чтобы строить проверку вокруг предполагаемого дефекта в реализации Юрия Панчула или пробела в его тестбенче.".

Пример о котором идет речь:

https://github.com/yuri-panchul/basics-graphics-music/blame/main/labs/4_microarchitecture/4_2_fifo/4_2_9_a_plus_b_using_wrapped_fifos/a_plus_b_using_wrapped_fifos.sv

Последняя версия раскаяния от ИИ:

https://panchul.com/lssk/ai_sessions/20261015/lssk_codex/codex_confused_20261016_variant_5.html