Когда я был в 9 классе в 1985 году, в Киеве поставили заведовать компьютеризацией школьного образования человека по фамилии Долина, бывшего полковника танковых войск из Донецка. Сейчас я понимаю что Долина был голова. Он временно поставил компьютеры MSX Yamaha в физматшколу номер 145, а через неделю их забрал. Ясень пень, что десятки физматшкольников потянулись в его контору, которая располагалась через дорогу.

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

Если с мытием полов у всех было еще более-менее, то инструкции обламывались писать 95% пришедших. Осталось всего 4 человека - один из 145-й (это я), два из физмат-интерната (у них были свои Ямахи, но с монохромным экраном и ограниченным доступом) и еще один школьник из третьей физматшколы (забыл номер). Долина предоставил нам безлимитный доступ ко всем компьютерам, тонне софтвера и посодействовал посылке двоих из нас в Новосибирскую Летнюю Школу Юных программистов.

На Ямахах помимо Бейсика был MSX-DOS, три компилятора Си, два компилятора Паскаля (включая ранний Turbo Pascal), Z80 процессор, ассемблер и отладчики (в командной строке и оконный), видеопроцессор со спрайтами, интерпретатор Lisp, Nevada Fortran, интерпретатор подмножества Пролога и даже перенесенный из CP/M подмножество Ada.

Мы писали для Долины программы типа записи действий футболистов на стадионе в реальном времени, а также графические мультики на Бейсике, которые он показывал людям из киевской киностудии мультфильмов. Он также был популярен у нанятой им секретарши которая подходила к нему сзади и обнимала его за плечи, на что он говорил "ты создана чтобы любить мужчин". Короче один из ролевых фигур моего взросления.

После Долины я в 10 классе пошел в Киевский Институт Кибернетики, но это уже была другая история.

Уже в четвертый раз встречаю следующий психотип. Человек окончил университет в Канаде, где в программе были в том числе лабы по FPGA. Прилетел в Калифорнию чтобы говорить и тусоваться с людьми. С вопросом: "какие есть проблемы в дизайне электроники чтобы решить их с помощью AI?"

Для меня из его реакций на некоторые мои утверждения ясно как божий день, что у него нет достаточного трейнинга в проектировании чтобы видеть эти проблемы самому. Поэтому я ему предложил всю ту же задачку на SystemVerilog (1, 2), которую я в этом году даю всем и в которой как в микрокосме представлены проблемы дизайна электроники, по крайней мере в микроархитектурной части и в контексте проекта в большой компании с использованием кода и тестового стенда других людей. Типа "решишь - поймешь в чем проблема".

Вместо того, чтобы по моим рекомендациям решить задачку и понять о чем я говорю - человек продолжает тусоваться и задавать людям вопросы на основе информации которую он услышал у других людей. Например спросил меня, хожу ли я на выставки DAC, где все говорят что тулы (средства проектирования) ограничивают сложность дизайнов. Я ответил что хожу на эту выставку с 1996 года, и тогда тоже все так говорили. Спросил у меня, слышал ли я о Chisel. Ответил "его используют только SiFive и Беркли. То что Chisel за 10 лет не проник в другие компании - означает что он ничего принципиально не решает". Итд.

Я не понимаю - что человек пытается достичь тусованием и такими вопросами? Какая часть фразы "пока вы сами не попробуете решать микроархитектурные задачи на верилоге, вы не будете понимать что вам говорят люди о проблемах такой разработки" - какая часть этой фразы ему непонятна?

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

Причем это еще лучше чем технический человек понимают сами VC - они сразу идентифицируют и стараются выкинуть из сделки такого рода бессмысленных посредников.

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

Here is my take on Verilog-vs-VHDL

In the early 1990s many people thought that Verilog was a temporary language and was going away with VHDL standard adoption.

For example, Verilog was plagued by race conditions in the form:

always @ (posedge clock) a = b;
always @ (posedge clock) c = a;

You had to use non-blocking assignments or delays in simulation to counteract the fact that the order of always block evaluation is indeterminate. This led to a pre-synthesis-post-synthesis simulation mismatch. At the same time, many people complained that VHDL has different incompatible arithmetic packages (numeric_std and std_logic_arith) and writing something like

wire [3:0] a, b;
wire [4:0] c = a + b;

becomes something like

signal a, b : std_logic_vector (3 downto 0);
signal c : std_logic_vector (4 downto 0);
c <= std_logic_vector (resize (unsigned (a), 5) + resize (unsigned (b), 5))

Finally John Cooley, the first blogger of EDA industry (he started his blog http://deepchip.com even before the word "blogger" appeared in the press) decided to make a hackathon in 1997 (at that moment the word "hackathon" was also unknown) to find out who is more productive - Verilog or VHDL engineers.

John Cooley published the results in an article

"The Unexpected Results From A Hardware Design Contest:  Verilog Won & VHDL Lost? -- You Be The Judge!"

https://www.angelfire.com/in/rajesh52/contest.html

He found that the Verilog engineers were more productive in his challenge.

After that more and more companies started to switch to Verilog, especially when Verilog-2001 and SystemVerilog integrated all the features of VHDL (packages, generate, records/structs etc).

In the early 2000s Synopsys developers thought that VHDL was going to die soon. However they continued to maintain VHDL support for die-hard VHDL users like Texas Instruments, IBM and the military. But even the Pentagon eventually back in 2008 allowed contractors to mix VHDL RTL designs with SystemVerilog testbenches (before they used a mix of VHDL and Specman e language).

However, VHDL at some moment stopped declining and stabilized. For example PowerVR GPU used in Apple iPhone 1-4 was written in VHDL by the British company Imagination. VHDL is still used but EDA companies give SystemVerilog priority when implementing language support in their tools.

Некоторые товарищи, например Олег Чирухин на Фейсбуке утверждают, что 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 делать не может.

У меня есть коллега (не по Самсунгу, а по образовательным программам), который влюблен в ИИ. У меня есть опасения что он может использовать ИИ для написания некой инструкции, которая включает теоретическую базу SystemVerilog-а. С моей точки зрения это очень дурная идея, так как LLM не следует стандарту, а генерит то, что людям интуитивно "кажется". Для иллюстрации спросил у ChatGPT 4.0 чем отличается wire, reg и logic. Словил 3 ошибки и 2 недочета:

1. Недочет: LLM (как и большинство людей, даже экспертов) забыл упомянуть про разницу в контексте инициализации ("wire a = b" это continuous assignment то есть "wire a; assign a = b;", а вот "logic a = b" это инициализация в момент 0, то есть "logic a; initial a = b;")

2. Ошибка: LLM почему-то думал что "wire a = 1'b0" несинтезируемо в Verilog, но синтезируемо в SystemVerilog.

3. Ошибка: LLM думал, что "always_ff" можно использовать для создания D-защелки (D-latch).

4. Ошибка: LLM думал, что "always_comb" может infer latch.

5. Недочет: LLM забыл про "always_latch".

То есть если скажем преподаватель ленится читать стандарты и книги, но вздумал писать методичку с помощью ChatGPT, то его студенты жестоко пострадают (баг от (1) трудно отлаживать) и будут понимать все "приблизительно".

15 лет назад я думал что образование в области компьютерной архитектуры поломано только в России, а на Западе с этим все хорошо. Что значит "поломано"? Студент может поговорить про суперскалярные процессоры и многоядерные кластеры, но не может ничего спроектировать.

Но потом я поинтервьировал кучу западных студентов, и обнаружил что такое явление есть даже в вузе X с хорошими учебниками и стоимостью образования $90 тысяч в год.

Просишь студента написать модуль на верилоге на десять строк строк с простой (хотя и не из учебника) функциональностью, и он начинает извиваться, как уж на сковородке: пишет какие-то временные переменные, пытаясь затянуть интервью чтобы вышло время и/или по моему выражению лица пробует угадать идет ли он в правильную сторону или пишет ерунду.

И я выдвинул теорию, что им профессор дает готовый код процессоров посимулировать и посинтезировать, а сами они на верилоге ничего не пишут. То есть у меня в голове образовалась модель такого студента, своего рода теоретический Бозон Хиггса, который умозрительно представили задолго до обнаружения.

И вот сегодня я такой Бозон Хиггса засек на LinkedIn. Выпускник этого самого вуза X написал пост, как он изучал учебник Хеннесси-Паттерсона. Он показал фото листка бумаги, испещренного заметками и диаграммами. Он просто сидел, читал по частям учебник и делал такие заметки.

Проблема с такого рода обучением заключается не только в том, что у студента может образоваться каша в голове - например он может путать обычный кэш с кэшем трансляций адресов в TLB. Он может также понять некоторые вещи наоборот и протащить такое понимание до конца, так как у него нет практики, которая бы отсекла такую ошибку сразу. Ну и то что он 90% информации забудет по пути - это тоже данность.

Ну я короче написал ему, что нужно каждую концепцию подтверждать для себя упражнением. Выучил статический конвейер CPU - написал процессорик с несколькими инструкциями на несколько сот строк. Выучил кэш - написал модуль на несколько сот строк. Предсказатель перехода итд. И ради бога, без чатгпт - с ним это не выучится.

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

Для Бозона Хиггса эта идея была в новинку. А между тем такой же подход нужно делать и с курсами по компиляторам, и ядрам OS.

Хотя зачем я все это говорю. Сейчас грянет LLM и наша цивилизация исчезнет.

У меня есть знакомый энтузиаст LLM, который также изучает верилог. Я попросил его написать инструкцию к упражнению с неким сенсором, который он интегрировал. Он разумеется сбросил это на LLM, я почитал и понял, что LLM нужно запретить как распостранение Экстази и "солей" среди молодежи. Точно так же как "дизайнерские наркотики" дают ощущение счастья и достижения без труда, сгенеренная LLM документация выглядит как реальная, вот только читателю она не поможет.

Что нужно читателю? Картинку как подцепить сенсор к плате, временную диаграмму сигналов которые от него выходят и пару слов про проблемы, которые у него возникнут (дребезг) и как их стоит решать. Так чтобы было достаточно информации, чтобы сесть и написать код на верилоге.

Что выдал LLM? Сначала пять абзацев мутного словестного описания что "изменения переключателей проходят некоторую последовательность, позволяющую определить направление", с галлюцинациями что движется и что неподвижно. Потом не имеющую отношения к задаче информацию, из каких материалов делаются эти сенсоры в разных странах мира, чтобы быть дешевыми для хоббистов и образовательных учреждений. Далее про разные способы решения проблемы дребезга, в том числе способы, не имеющие отношения к данной ситуации. И наконец, куски определения пинов из QSF и XDC файлов из случайных примеров в интернете, которые не имеют отношения к описанному примеру, так как в нем во-первых эти файлы не используются (другой вендор, другой способ задания пинов), а во-вторых, в нем эта часть проекта абстрагирована (пользователю вообше это не нужно это делать).

То есть текст просто водит читателя за нос, не давая ему никакой полезной информации для решения проблемы. Но даже это не важно, потому что читатель этот текст читать не будет, так как учует LLM в заголовке и убедится в третьем предложении, после чего перестанет читать. Текст является иллюстрацией терминов "сделать на отцепись" и "из дерьма и палок".

UPD: И самое страшное: это 27 страниц вместо 1 страницы полезной инструкции, которую я ожидал. ДВАДЦАТЬ СЕМЬ СТРАНИЦ ЛАБУДЫ !!!

Я хочу обратно в годы, когда этого ужаса не было. Нашу цивилизацию ждут тяжелые времена. Я уже видел в ЖЖ посты агитирующие на перевод всей порноиндустрии на generative AI.

На ютюбе вышло видео Сергея Сафонова Как Intel создал ARM, ARM похоронил MIPS, на очереди X86? Видео хорошее, в нем нет крупных косяков, но есть крупная дыра (или я просто смотрел невнимательно и пропустил?), отсутствующая информация о ключевом событии. В нем упадок RISC-процессоров в районе 2000 года рассматривается как некая загадочная энигма, а между тем все не просто, а очень просто. Вся индустрия в конце 1990-х ждала выхода процессора Intel Itanium, которому предсказывали взрывной рост и распостранение. Всем остальным процессорам предписывалось в организованном порядке идти на кладбище истории.

Из-за прогнозируемого триумфа Итаниума, HP отказались от своего RISC-процессора HP-PA, который в лучшие годы занимал 40% рынка рабочих станций для автоматизации проектирования электроники. DEC забила на свой RISC-процессор Alpha, на который еще в середине 1990-х спортировали Windows NT. Silicon Graphics перестали использовать MIPS для графики для Голливуда и отделили от себя MIPS Technologies которые стали специализироваться на лицензировании процессорных ядер для встроенных устройств. IBM и даже Sun собирались перейти на Itanium.

Однако когда Itanium вышел, его продажи были в десятки раз ниже чем прогнозировалось. Процессор строился на архитектуре VLIW, как современный российский Эльбрус, и имел те же проблемы. В частности, на такой архитектуре, с несколькими параллельными инструкциями в одном командном слове, трудно добиться хороших бенчмарк на программах общего назначения. Эти параллельные инструкции соединяет в одно слово компилятор, и ему трудно предсказать задержки при работе с памятью, которые при промахе кэша могут быть десятки и даже пару сотен тактов (при многоуровневом кэше, особенно с многоядерностью). Обычный суперскалярный процессор в таком случае просто запускает следующие независимые от доступа к памяти инструкции (см. алгоритм Томасуло), а вот VLIW процессору приходится простаивать.

VLIW процессоры хороши чтобы просчитывать какую-нибудь физику, с одновременной обработкой массивов данных, но запускать на нем браузеры или Микрософт Офис - это наблюдать посредственную производительность. Но в 1997 году, после анонса Itanium-а и до его выхода в 2001 - компании об этом не то что не знали, но думали что каток хайпа от Интела повторит каток хайпа от Микрософта по поводу Windows, и Итаниум будет везде.

Об этом есть известная статья Джона Дворака "Как Итаниум убил компьютерную индустрию".

Другое замечание: Сергея Сафонова в видео смешивает архитектуру (систему команд, видимую программисту сторону процессора) и микроархитектуру (аппаратную организацию, устройство конвейера и блоков процессорного ядра). RISC-архитектура способствует эффективной конвейерной микроархитектуре, но это не одно и то же. См. мою заметку "Что означает информация в заметке Коммерсанта «Британия морозит «Байкал»"

И где можно было бы дополнить:

1. Мода на RISC возникла не просто так, а в результате анализа использования инструкций в пользовательских программах. Такое масштабное исследование провела группа профессора Джона Хеннесси в Стенфорде в 1978-1980 году.

2. История RISC-процессоров в 1980-е тесно переплетается с историей кэшей. Они стали популярны именно в 1980-е потому что скорость арифметических операций росла в те годы гораздо быстрее, чем скорость доступа к основной памяти, DRAM.
   
   Если раньше, в 1960-е годы, арифметическая операция занимала больше, чем чтение или запись из памяти, то сейчас за одну транзакцию к памяти при промахе кэша можно выполнить десятки сложений. Поэтому стало рости и количество регистров (в x86 их изначально было меньше, а 6502 в ранних Apple - вообще аккумуляторные процессоры) и стал требоваться кэш, а иначе конвейер бы простаивал.

3. На то, что индустрия отвернулась от MIPS и повернулась к ARM, повлияла и история о том, как MIPS стал судить стартап Lexra. Lexra типа нарушала патент на инструкции с невыравненным доступом к памяти. Процесс был высосан из пальца, но MIPS затянул разбирательство и у стартапа кончились деньги на юристов.

Как разводят венчурных капиталистов на бабки по поводу процессоров

Когда в СМИ публикуют статью про новый революционный процессор, но в статье нет бенчмарок, тут все понятно: статью можно игнорировать, это просто мусорный набор символов на экране. А если бенчмарки есть? Тут тоже не все так просто. Лет 10 назад был стартап, который показывал венчурным капиталистам слайды, что их революционно гибкий процессор (который динамически выделял потоки) по тактам в 3 раза быстрее чем старшее ядро ARM. Измерение было с помощью симуляции на уровне регистровых передач и в качестве бенчмарки была то ли Dhrystone, то ли CoreMark/MHz. Но они "забыли" указать на слайдах, что если синтезировать их процессорное ядро c библиотекой ASIC на том же техпроцессе, на котором и ядро ARM, против которого они конкурируют - то статический анализ тайминга покажет, что максимальная тактовая частота, которую они могут использовать - втрое меньше, чем у ARM. То есть втрое лучше по тактам умножаем на втрое хуже по частоте = никакого улучшения. Об этом факте я случайно услышал на парти - человек сказал цифру и я сложил два плюс два, то бишь умножил 3 на 1/3.

Также замечу что развод на бабки VC ничуть не менее аморален, чем развод на бабки пенсионеров по телефону, так как в фонды VC вкладывают в том числе и частные пенсионные фонды.

Только что вышел первый коммерческий маршрут синтеза для FPGA на Apple Mac - его надо срочно протестировать! Прошу всех у кого есть Apple Mac и плата от Gowin - скачать Gowin V1.9.10.03 Education (Mac) и клонировать с гитхаба примеры BGM и попробовать запустить их вместе. Для этого возможно понадобиться модифицировать bash скрипты в директории scripts, но если кто-нибудь это сделает и пришлет pull request, это будет здорово - можно будет сообщить и Gowin-у, и использовать для Школы Синтеза.

К нам на митапы в Hacker Dojo в Маунтин-Вью, Калифорния, часто приходят студенты с маковскими ноутбуками и на вопрос "как запустить софт для разработки на Маке", мне приходилось отвечать: "на Маке пока работает только симуляция с Icarus Verilog, а также нестабильный открытый софт для синтеза на основе OSS CAD Suite, с которым нужно обходить разные проблемы, так что пока купите на eBay старый x86 компьютер, поставьте на него Линукс и упражняйтесь на нем". Но с новым софтом от Gowin картина радикально меняется!

Замечу, что синтез у Gowin гораздо быстрее чем у Xilinx и Altera, а платы - дешевле и достаточные. Поэтому Gowin может реально отобрать кусок образовательного рынка - Xilinx/AMD и Intel/Altera просто слишком медленно шевелятся.

Большинство университетских профессоров в мире - ленивые. Как выдумали в 1970-е годы преподавать дизайн конечных автоматов примером FSM для светофора (Traffic Light Controller FSM), так и тянут эту бодягу и по 21-му веку. При том, что современные дизайнеры чипов не светофоры конструируют, а ускорители тренировки нейросетей.

Короче мы на Школе Синтеза Цифровых Схем решили преломить эту дурную традицию (которая встречается от Южной Америки до Средней Азии и Филиппин, с провинциальными вузами в Штатах включительно) и ввести в преподавание современный хардкор. То есть сделать домашку с конструированием FSM для управления блоками FPU выдранными из современного реального открытого RISC-V процессора.

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

Пример домашки: сконструировать FSM (а потом и конвейер) для вычисления такого-то ряда Маклорена (для синуса, экспоненты итд), имея в наличии N блоков умножения, M сложения и R деления с плавающей точкой - с разными латентностями.

При обсуждении такой домашки возник вопрос нужно ли для операций с плавающей точкой устанавливать флаг error для нечисел и бесконечностей. Конечно нужно, потому что это удобный повод рассказать про концепцию NaN и Infinity. Полез в википедию и в шоке обнаружил, что статья IEEE_754 на русском отсутствует, хотя есть на украинском. Это непорядок, нужно срочно поправить!