Может начать рисовать комиксы против проповедников ИИ, которые говорят "не смотри в генерируемый код, просто проверяй его в тестовом стенде"? Ниже первый эксерсиз.

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

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

А ведь если поставить такой блок в реальное устройство, там накрутится за полчаса триллион транзакций (гигагерц - миллиард в секунду - умножить на 20 минут по 60 секунд = 1200 миллиардов).

Это что же - поставить в чип двести триллионов D-триггеров для flop-based FIFO которое оно сгенерило? А если рассматривать худший сценарий работы за сутки - ставить квадриллион D-триггеров? Это чип размером с приусадебный участок.

Сделал в LinkedIn пост на английском:

Have you met AI proselytizers with a dogma “Thou shouldst not peer into the code thus wrought?” In plain English: “You should not look into the code AI generated; just verify it in the functional testbench and check the metrics, area and frequency.” Well, I can show you two real cases when it did not work in SystemVerilog:

In one case, an AI engine was not able to figure out the flow control logic. So it created a giant FIFO to store all the incoming transactions from the given testbench. Now, if you double the number of transactions in the testbench, everything goes up in flames.

In another case AI engine (Claude two weeks ago) for whatever reason created only FIFO with power of two depth. I.e. instead of a 13-deep FIFO created 16-deep, and for a 20-deep FIFO created 32-deep FIFO. Imagine how such a strategy would bloat the area of your chip if you don't look into the code AI generates.

UPD: И да, кстати. В хардвере размер таких структур как встроенные в ASIC блоки SRAM памяти, и особенно структур из D-триггеров - это не просто размер. Это прежде всего энергопотребление. Поэтому все такие размеры очень жестко контролируют. Это в софтвере вы можете везде аллокировать маллоком все по степеням двойки. Память стерпит, особенно виртуальная. А в харвере у вас или будет батарейка телефона садиться посередине дня, или для роутерного чипа в магистральном роутере понадобится жидкостное охлаждение.

Упомянутые в посте задачки описаны в моей статье на конференции SNUG.