Programming microcontrollers *

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) трудно отлаживать) и будут понимать все "приблизительно".

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

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

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

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

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

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

Artery AT32F407 и scanf()

Речь пойдет об отладке AT-START-F407 V1.3. В составе платы находится программатор/отладчик AT-Link-EZ V1.2, который подключается по USB к ПК, где он виден как COM порт.

Его же можно использовать для целей отладки, а именно выводить информацию на ПК с помощью printf(). На эту тему а Artery есть AN0015_Printf_Debug_Demo, описанные там переопределения уже содержатся в файле at32f403a_407_board.c:

FILE __stdout;

#define PUTCHAR_PROTOTYPE int fputc(int ch, FILE *f)

PUTCHAR_PROTOTYPE
{
  while(usart_flag_get(PRINT_UART, USART_TDBE_FLAG) == RESET);
  usart_data_transmit(PRINT_UART, (uint16_t)ch);
  while(usart_flag_get(PRINT_UART, USART_TDC_FLAG) == RESET);
  return ch;
}

Все что нужно сделать, это добавить в код функцию инициализации uart_print_init(115200), где 115200 скорость COM порта.

Аналогичным образом можно с консоли передавать данные в МК с помощью функции scanf(). (На эту тему я не нашел AN). Добавим в файл at32f403a_407_board.c:

FILE __stdin;

#define GETCHAR_PROTOTYPE int fgetc(FILE * f)

GETCHAR_PROTOTYPE
{
  uint8_t cha = 0;
  usart_flag_clear(PRINT_UART, USART_ROERR_FLAG);  // Clear Overrun flag
  while(usart_flag_get(PRINT_UART, USART_RDBF_FLAG) == RESET);	
  cha = usart_data_receive(PRINT_UART);  
  usart_data_transmit(PRINT_UART, (uint16_t)cha); // Echo 
  return cha;
}

Все работает? Нет. Надо еще вызвать функцию

usart_receiver_enable(PRINT_UART, TRUE);

scanf("%d", &k);
k = 2*k;
printf(" \n\r You entered = %d", k);

И, теперь все работает.

Простое крепление проводов в контроллерах idiBus. Без кабельных каналов. Дешево и сердито.

Выходящие провода крепятся хомутами прямо к плате через отверстия по краю платы.

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

Принимаются предложения и идеи по всяким полезным видам крепления проводов.