Тесты для микроконтроллеров и процессоров в ПЛИС

Hishnik

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

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

Total Vacuum

Давно хотел автоматизировать одну вещь для повышения плотности кода в Форт-процессорах, лишь недавно доделал.
У нас же Гарвард, поэтому нет возможности читать данные из сегмента кода. В итоге любая строковая константа прилично раздувала код, т.к. приходилось программно символ за символом выкладывать ее в RAM. Или, например, массив констант

Код:

const int sprite [] = {1,2,3,4,5};

превращался компилятором в громоздкое

Код:

1 sprite !
2 sprite 1 + !
...

До поры до времени этот недостаток компенсировался высокой плотностью прочего кода, тем не менее, революционная ситуация давно назрела. Никто ж не запрещает выделить нужное количество блоков BRAM персонально для строк и const-массивов... Короче, теперь код и строки/константы компилируются в разные области памяти, так что и без того тощие прошивки еще сильнее похудели. Раньше это делалось для шрифтов/спрайтов/... самодельными утилитками в полуручном режиме, а теперь достаточно лишь добавить/убрать const.

А заодно придумал более короткую запись для объявления const-массивов, вместо

Код:

create sprite 1 , 2 , 3 , 4 , 5 ,

пишу

Код:

::: sprite 1 2 3 4 5 ;

Собcтвенно, компилятор Си теперь в такой формат и компилирует константы для Форт-процессоров.

Кстати, для оценки плотности кода вполне подходит в т.ч. и Dhrystone

Например, tcc укладывается в 7Kb. А даже для 3-битного Форт-процессора теперь получается 11019 3-битных команд, ну а для 4-битного и вовсе 3900 полубайт. Плюс 1820 байт на строки. И за компанию размер под Commodore 64.

Код:

c/asm cpu    cmd   code   data   size
vbcc  6502                      10819
tcc   x86                        7168
uc    f3H  11019   4133   1820   5953
uc    f4B   3900   1950   1820   3770

Простенький интерпретатор basic из соседней темы:

Код:

c/asm cpu    cmd   code   data   size
tcc   x86                        5120
uc    f3H   9004   3377    109   3486
uc    f43   3369   1685    109   1794

DrMario в сравнении c оригиналом на NES и его портом на UzeBox:

Код:

c/asm cpu    cmd   code   data   size
asm   6502        32768  32768  65536
gcc   avr                       53654
uc    f44  14755   7378   7840  15218

И лишь для Pacman под CH32V003 RISC-V Mini Game Console паритет

Код:

c/asm cpu    cmd   code   data   size
gcc   ch32                       7084
uc    f44   8517   4259   2272   6531

Либо GCC под RISC-V достаточно хорош, либо мой компилятор все еще слишком плох. Но, вероятнее всего, тут и то и другое одновременно.

Hishnik

Total Vacuum писал(а):

У нас же Гарвард, поэтому нет возможности читать данные из сегмента кода.

Технически - есть!

Если один порт BRAM используется для чтения команд (pc -> cmd), а второй отдан на загрузку, то можно этот второй переключать на чтение процессором. Если есть отдельный reset, то его удобно использовать для переключения мультиплексора - когда процессор в reset, это означает, что сейчас его загружают по UART, а когда reset отпущен, второй порт переключается на процессорные addr-data.

Total Vacuum писал(а):

приходилось программно символ за символом выкладывать ее в RAM.

Память данных тоже можно инициализировать на старте из bit-файла, а также дозагружать по UART.

Total Vacuum писал(а):

Кстати, для оценки плотности кода вполне подходит в т.ч. и Dhrystone

Вот как раз есть ощущение, что Dhrystone не слишком-то показателен, потому что его примеры не особо применимы. Вот в Coremark пример с КА вполне похож на архитектуру средненькой (по меркам ПЛИС) программы, у которой есть основной цикл, и которая в нем начинает распределять приходящее по UART и с разных кнопок. И тут могут довольно хорошо сыграть "адресные литералы" - команды, которые делают call на заведомо короткий адрес, а еще - аналог продвижения данных в тракте управления, который позволяет не разворачивать код для экономии тактов, поскольку при продвижении вычисленного pc сразу на вход памяти мы получаем переходы call/ret без штрафов.

Вобщем, надо Манула уже дописать наконец, вот со всем вот этим архитектурным богатством...

Total Vacuum

Hishnik писал(а):

Технически - есть!

Если один порт BRAM используется для чтения команд (pc -> cmd), а второй отдан на загрузку, то можно этот второй переключать на чтение процессором.

Это да, но есть 2 более приоритетных (уже проверенных) сценария использования этого второго порта:
- одно ядро, но с возможностью чтения и выполнения двух команд за такт - это практически бесплатный с точки зрения потребления ресурсов способ заметного (процентов на 40 на Dhrystone, если не изменяет склероз) увеличения производительности;
- два ядра с общими RAM и памятью программ - потребление ресурсов (кроме BRAM) тут, конечно, побольше, но возможность иметь второе полноценное ядро и 2-кратный рост производительности в пике греет душу.
Поэтому держу этот порт в резерве как раз на один из таких случаев, на этом фоне потенциальная возможность чтения из память программ ваглядит как-то блекло

Hishnik писал(а):

Память данных тоже можно инициализировать на старте из bit-файла

Вот как раз этот трюк, к сожалению, так и не научился проделывать, сколько ни пытался.

Допустим, есть у нас код, который воспринимается как RAM, которая лежит в BRAM

Код:

always @ (posedge clk) begin
   if (we) data[addr] <= o;
   v <= data[addr];
end

Но если я пытаюсь инициализировать, например, так

Код:

always @ (posedge rst) begin
   data[0]=0;
   data[1]=1;
end

,тогда ругается "driven from multiple places" (не дословно)

А если пытаюсь дописать проверку на rst в исходный вариант, например, как-то так:

Код:

always @ (posedge clk) begin
   if (!rst) begin
      if (we) data[addr] <= o;
      v <= data[addr];
   end else begin
      data[0]=0;
      data[1]=1;
   end
end

,то синтезатор перестает понимать эту запись как RAM в BRAM, пытается реализовать эту RAM на регистрах и вываливается с ошибкой по причине нехватки оных.

Пробовал, наверное, с десяток-другой разных вариантов, но либо "driven from...", либо нехватка регистров, увы.

Как такую штуку описать на verilog'e, к сожалению, не понимаю.

Hishnik

Total Vacuum писал(а):

Вот как раз этот трюк, к сожалению, так и не научился проделывать, сколько ни пытался.

Код:

initial begin
  $readmemh("program.mem", memory);
end

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

Total Vacuum

Hishnik писал(а):

Код:

initial begin
  $readmemh("program.mem", memory);
end

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

Вот это я лопух! Попробовал только что в Gowin - прекрасно работает такая конструкция. Спасибо!

Почему-то вбил себе в голову, что блоки initial не синтезируются, а только в режиме симуляции могут быть использованы. Хм... :shock:

Может они раньше не синтезировались, а с какого-то момента начали? В Xilinx ISE 14.7 только через неделю смогу проверить.

Hishnik

Total Vacuum писал(а):

Почему-то вбил себе в голову, что блоки initial не синтезируются

В целом оно так и есть

Просто разработчики "тяжело вздохнули" и сделали так, чтобы некоторые полезные операции стали синтезироваться как надо. Инициализация работает и так:

Код:

shared variable MatchINIT : TMatchINIT :=(
0 => x"0000000000000000000000000000000000008000000000000000000000000000",
1 => x"0000000000000000000000000000000000000040000000000000000000000000",
2 => x"0000000000000000000000000000000000000000000000000000200000000000",
others => (others => '1')

Это что под руку попало, в VHDL, то есть прямо при объявлении сигнала или переменной.

Раньше был, например, gated clock при синтезе

Код:

if clk'event and clk = '1' and ce = '1'

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

Gated clock синтезировался, и тактовое дерево в этом месте разваливалось. Потом перестало - синтезаторы переписали под вылавливание этой стилистической ошибки. Процесс привязывания часто используемых шаблонов кода к правильным конструкциям в целом продолжается, но зависит от производителя.

Total Vacuum

О сколько нам открытий чудных
Готовят просвещенья дух
И Опыт, [сын] ошибок трудных,
И Гений, [парадоксов] друг,
[И Случай, бог изобретатель]

Total Vacuum

Total Vacuum писал(а):

В Xilinx ISE 14.7 только через неделю смогу проверить.

Эх, вот ведь какая жаль... :cry:

В Gowin IDE работают варианты

Код:

initial $readmemh(...);

и

Код:

initial begin
   `include "..."
end

А в Xilinx ISE 14.7, увы, такое не синтезируется.

Hishnik

ISE давно перестали поддерживать. Можно загрузить Oracle VM с ней, так что даже на новые версии Windows не пересобрали, держат только из-за возможности купить Spartan-6 (то есть Spartan-3 это совсем уже древность). Сейчас на Artix-7 довольно много приличных плат, есть и на Zynq-7010 или 7020, там еще и ARM со своей соответствующей частью. Они в целом приятнее, периферия посовременнее, да и Vivado по многим показателям лучше ISE (совершенно точно быстрее разводит). Опять же, в 7-й серии сделали унификацию компонентов, даже последующие семейства от архитектуры ячейки далеко не ушли, только в деталях.

Total Vacuum

Ха!

А жизнь-то налаживается!

Или накладывается

Не все так плохо, как казалось изначально. В Xilinx ISE 14.7, оказывается, работают оба варианта:

Код:

initial $readmemh(...);

и

Код:

initial begin
   `include "..."
end

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

Total Vacuum

Hishnik писал(а):

Можно было бы подумать про операции с массивами в памяти

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

) А еще простые, но достаточно полезные в хозяйстве вещи вроде memcpy/strcmp/strcpy. Архиватор какой-нибудь простенький вроде LZSS или даже RLE.

Hishnik

Total Vacuum писал(а):

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

О, интересно! Добавление в копилку наблюдений...

Hishnik

Total Vacuum писал(а):

А еще простые, но достаточно полезные в хозяйстве вещи вроде memcpy/strcmp/strcpy.

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

Total Vacuum

Hishnik писал(а):

Это как раз то, что напрашивается на аппаратную реализацию.

А, кстати, как? Все те вещи роднит то, что они берут много данных из памяти и результаты складывают туда же. Т.е. в каком-то роде будут конфликтовать с командами @/!. И придется либо заводить в системе команд какое-то подобие инструкций x86 rep stos/lods/movs/cmps, либо делать что-то типа DMA и отдавать ему для работы второй порт BRAM.

Да, наверное, как-то можно один такой аппаратный ускоритель посадить на основной порт BRAM и вклинить по времени в промежутках между командами @/! (благо, что редко такое в коде нужно, когда эти команды пулеметными очередями идут) Но тогда простое решение "прибить гвоздями вершину стека к шине адреса" не будет работать.

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

Тесты для микроконтроллеров и процессоров в ПЛИС

Кто сейчас на конференции