Некоторые товарищи, например Олег Чирухин на Фейсбуке утверждают, что LLM хорошо пишет на JavaScript / TypeScript и плохо на Verilog / SystemVerilog потому что первого в мире больше. Однако у верилога есть два критических фактора, которых у JS вообще нет. В JS если программа работает долго - это просто неудобство, в Verilog-е если нарушается тайминг внутри такта (задержки в пикосекундах) или результат приходит через 5 тактов, а он ожидался через 4 - все нафиг ломается. LLM не понимает ни тайминг внутри тактов, ни тайминг по тактам (латентность).

Никто не будет из-за этого дурацкого LLM ставить везде hanshake не зависящий от латентности подблоков, снижать пропускную способность блока на порядок или снижать в разы тактовую частоту - скажем вместо процессора с частотой 2 GHz выкатывать на рынок процессор с частотой 20 MHz. И с производительностью по тактам 2 СoreMark / MHz вместо 12 СoreMark / MHz. И при этом большой в разы и с высоким энергопотреблением. Это как продавать автомобили со скоростью и грузоподъемостью велосипеда и весом как самосвал - такое никто не купит.

Тайминг внутри такта (задержки в пикосекундах) только из кода определить нельзя, нужна процедура статического анализа тайминга, который знает задержки конкретной библиотеки ASIC (LLM не умеет делать STA (static timing analysis) и не знает задержек конкретной версии библиотеки скажем на 2 нанометра low power такого-то вендора).

С неумением LLM понимать что происходит в каком такте все интереснее. В принципе это понять можно, но это требует довольно вдумчивого анализа конкретного кода, а LLM это не просто не умеет, а в наглую пишет "for illustration, assume the latency is 1" - типа тоном профессора "для иллюстрации, предположим латентность подблока - 1 такт". А если не предполагать? С предположением все поломается.

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

Написал Олегу:

Тут есть два других фактора: 1. в реальных бизнес-задачах необходимо, чтобы разработчик мог понять например латентность кода подблоков - количество тактов на получение результата. LLM этого не понимает - оно из чужого кода часто и опытному разработчику не очевидно, а запустить симулятор и посмотреть это на диаграммах после симуляции LLM не может. 2. в верилоге есть составляющая которой вообще нет в программировании - таминг внутри такта в пикосекундах. Нужно чтобы схема синтезированная из кода в этот тайминг влезала. И если латентность (количество тактов) из чужого кода еще можно определить (если проанализировать цепочку присваиваний между комбинационной логикой и D-триггерами), то с таймингом вообще напряг. Хотя с таймингом у дизайнера вырабатывается интуиция, например что комбинационное умножение 4-х битных чисел в бюджет на 400 пикосекунд точно влезет, а вот комбинационное деление 32-битных точно не влезет - но все это нужно подтверждать запуском программы статического анализа тайминга, который (та-дам!!) LLM делать не может.