Comments 42
Монументально! Буду на следующей неделе читать, извлекать что не знаю
Вот это талмуд, мое почтение. Программировал когда-то давно на VHDL и SystemC в магистратуре, и с тех пор остались положительные впечатления от первого и не очень положительные от второго.
В связи с Yosys рекомендую обратить внимание на проект Glasgow Interface Explorer и другие проекты уважаемой WQ.
Спасибо, интересно. Пару раз пробовал погрузиться в тему ПЛИС, но получал больше вопросов, чем ответов. А тут написано гораздо понятнее, чем вводные мануалы, что мне попадались.
Подскажите, имеет ли смысл начинать знакомство с ПЛИС сразу со SpinalHDL, или лучше сначала разобраться с Verilog или VHDL. Синтаксис Verilog на первый взгляд показался приятным.
Можно конечно начать сразу со SpinalHDL, но в какой-то момент знания Verilog-а всё равно Вам потребуются. Без него в этой теме всё еще никак не обойтись. Поэтому, рекомендую все же начать с basics-graphics-music - это очень простые обучающие примеры, с ними легко постичь основы цифровой схематехники и синтеза. Выполнить первые 7-10 лаб, проникнуться темой и потом попробовать всё то же самое на SpinalHDL.
SpinalHDL становится интересен тогда, когда в Вашем проекте появляются сложные сущности - вычислительные ядра, контроллеры различной аппаратуры и т.д.
Во-вторых, весь код комбинационной и последовательностной логики описывается в одном блоке под одним условным оператором when(). Я уверен, что для большинства разработчиков, давно пишущих код на Verilog и/или VHDL, такое решение будет просто шокирующим. На SpinalHDL такой стиль является нормой, и он позволяет существенно сократить число строк кода, а сам код сделать более понятным и читаемым.
Иногда таки нужно разделять блокирующие и неблокирующие присваивания, чтобы не наплодить случайно лишних D-триггеров
Жду продолжения! Очень активно использую iverilog+verilator+yosys для разработки своего лампового компьютера :) И стараюсь как можно больше о них рассказывать, ведь чем больше таких статей хороших и разных - тем активнее развиваются тулы.
Не совсем понятна суть заголовка - почему "нетрадиционный" метод разработки? Вполне себе традиционный, а вот инструменты специфические. Качество синтеза того же yosys пока оставляет желать лучшего. Впрочем после обновления до v0.37 он приятно удивил.
Еще бы нормальный визуализатор RTL или нетлиста найти, а то что по дефолту из dot-файла yosys выходит - критики не выдерживает.
Далее я перечислю список известных производителей микросхем ПЛИС, некоторые из популярных моделей, а также среды разработки (тулы).
Все, конечно, поняли, что следующий абзац про Xilinx/AMD, но можно было бы и явно написать )
Для того, чтобы компилировать Си программы для архитектуры RISC-V нам потребуется установить один из доступных опенсорсных компиляторов, а именно «GNU C Toolchain for RISC-V».
Я игрался с llvm/clang - там поддержка RISC V в бэкенде появляется вместе с другими архитектурами при стандартном cmake;make , дальше надо только явно собрать компиляторный рантайм.
Когда автор то ли сам не понимает, то ли намеренно лжетвводит в заблуждение в самом начале, как-то читать дальше становится не интересно. Verilog действительно более лаконичен, но приведенные примеры на рис 4-5 используют разные методики описания, сравнивать которые по объему бессмысленно.
Дело вообще не в Verilog versus что-то там. Порой путь OpenSource приводит нас к очень странным результатам.
Yosys как стандарт на вход поддерживает только Verilog, есть конечно сахарок от SystemVerilog, но не как стандарт IEEE 1800-2023. Поэтому в маршруте проектирования нет особой разницы на чем вы разрабатываете дизайн: SystemVerilog, SpinalHDL, или Аmaranth, это все равно все будет преобразовано в Verilog и потом уже синтезировано на ПЛИС или ASIC. Поэтому все, что кажется странным и бесполезным для Enterprise в случае с Yosys является логичным и понятным.
Приведите пожалуйста свой пример 4-х битового сумматора на VHDL. Я посмотрю и может быть заменю в статье.
Видимо как-то так:
use ieee.numeric_std.all;
...
architecture rtl of Ripple_Adder is
signal sum : unsigned(4 downto 0);
begin
sum <= unsigned('0' & A) + unsigned('0' & B) + unsigned("0000" & Cin);
S <= std_logic_vector(sum(3 downto 0));
Cout <= sum(4);
end rtl;
Если не нравятся кастинги - можно
использовать пакет numeric_std_unsigned, но лично я его идейно не принял;
std_logic_vector в entity заменить на unsigned, но это вопрос согласования типов интерфейсов в проекте.
Спасибо. Заменил на Ваш вариант. Кода получилось не на много меньше. :)
А если использовать пакет ieee.std_logic_unsigned.all, то кода будет поменьше.
Предлагайте свой (полный) вариант.
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
entity ripple_adder is
port (
a : in std_logic_vector(3 downto 0);
b : in std_logic_vector(3 downto 0);
cin : in std_logic;
cout : out std_logic;
s : out std_logic_vector(3 downto 0));
end entity;
architecture rtl of ripple_adder is
signal sum : std_logic_vector(4 downto 0);
begin
sum <= ('0'&a)+('0'&b)+("0000"&cin);
cout <= sum(4);
s <= sum(3 downto 0);
end architecture;Спасибо, Ваш вариант выглядит красиво и понятно. Заменил в статье на Вашу версию.
Так как я сам на VHDL ничего никогда не писал, то я решил погуглить разные варианты. И, доложу я Вам, я был неприятно удивлен тем, что все варианты которые выдавал мне google, были один другого монстроидальнее. То-ли в гугле сломалась нейронка, то-ли в мире VHDL так принято, но у меня сложилось впечатление, что разработчикам на VHDL платят даже не застроки кода, а за килобайты кода - каждая строка кода на VDHL в два-три раза длиннее аналогичной на Verilog-е. А так же у VHDL очень стойкий бюрократический запашок.
Пару лет назад я прочел книгу Х&Х "Цифровая схемотехника и архитектура компьютера". В ней, по ходу повествования, авторы приводят варианты цифровых схем на двух языках - SystemVerilog и VHDL. По мере чтения, в какой-то момент я заметил, что совсем не понимаю что изложено в варианте на VHDL и как достигается то, что требуется получить. Короче, в примеры на VHDL я перестал даже заглядывать. :-)
Я начал активно работать в этой области лет 10 назад, и начал с VHDL, т.к. вокруг были люди, которые его использовали, и которые неодобрительно смотрели на Verilog.
Да, VHDL более многословный. Но не так, как пугают: на заре был более многословных, а сейчас - терпимо. Да и почему-то не любят использовать "нестандартизированные" библиотеки типа ieee.std_logic_unsigned , которые заметно сокращают объем кода.
Я смирился с его многословностью: пишу некоторыми синтаксическими шаблонами, к которым привык. Но ни за что не променяю его типы и строгую типизацию. Поэтому с интересом приглядываюсь с SpinalHDL: имеет строгую типизацию и добавляет то, чего мне не хватает в VHDL: параметризации типов, модулей и т.п. Я пока писал только что-то совсем мелкое, и пока не убедил себя на него перейти: у меня нет проблем со скоростью написания многословного кода, т.к. основное время приходится думать что написать, а не писать ;).
P.S. Да, я пишу практически только синтезируемый код с небольшими тестами. Поэтому на богатство Verilog/SystemVerilog и других инструментов по симуляции смотрю равнодушно.
"Ничтожно низкая стоимость ошибки" - может это всё таки только желаемое, с учётом даже не до конца описанных технологий?)) Да и в обычном программировании эта низкая стоимость наблюдается только в бесплатных сервисах и приложениях, где, по большому счёту, на пользователя наплевать и необходимость немедленно устранять ошибку отсутствует.
Если плис используется в более менее сложной массовой аппаратуре, то даже на тестирование этой аппаратуры уходят существенные ресурсы - автоматизация, симуляция, помещение, стойки, логи, люди. Ошибка требует исправления, верификации, и, как правило, полного цикла тестирования перед выводом в релиз, это меняет графики текущей разработки, сдвигает сроки.
Всё таки ниша FPGA, на мой взгляд, не очень изменилась за 25-30 лет - малосерийное и специальное применение там, где неэффективно использовать ASIC и готовый контроллер-чип.
Но в остальном очень интересная и информативная статья, 20 лет назад ничего подобного не проприентарного для полного цикла проектирования не было.
Если плис используется в более менее сложной массовой аппаратуре, то даже на тестирование этой аппаратуры уходят существенные ресурсы - автоматизация, симуляция, помещение, стойки, логи, люди. Ошибка требует исправления, верификации, и, как правило, полного цикла тестирования перед выводом в релиз, это меняет графики текущей разработки, сдвигает сроки.
И всё же цена ошибки получается на порядки меньше цены ошибки для ASIC-ов, не правда ли? Ведь не требуется делать респин, выкладывая за это очередные миллионы долларов и месяца времени ожидания. Время обратной связи, имхо, критический фактор, в случае FPGA респин занимает от пары минут до нескольких часов. NRE существенно меньше в случае FPGA даже для сложной массовой аппаратуры, вот пример, где Microsoft делится своими восторгами по поводу скорости разработки хардвера, которая была у них при использовании FPGA. Их начинку Azure-карточек на всех стадиях делала команда из 5 FPGA-шников и горстки программистов.
Кстати, не вижу публикаций от проекта Catapult после 2018го - наигрались и прикрыли или просто отдали в production и исследовать больше нечего?
Насколько понял, Catapult где-то тогда разделился на ветку ускорителей ИИ Brainwave и ветку прочих ускорителей для Azure. Brainwave что-то исследовали, поначалу что-то получалось, но сейчас уже всё, уступили место GPU. В Azure ускорители ушли зарабатывать деньги в продакшн, поделившись ещё на какие-то ветки. Одна, Azure Boost примерно соответствует функциональности Catapult и здравствует до сих пор, но про исследования не слышно.
Разговор про ничтожную стоимость ошибки, как в программировании. Я участвовал в одном проекте лет 20 назад - да, можно быстро править алгоритмы, да, можно на ходу использовать отладочные прошивки, да, разрешённой альтернативы у нас этим 8 stratix-ам вообще не было. Но вот издержки должны учитываться и не следует убеждать начальство, что они ничтожны)) Майкрософт просто отлаживался на бесплатных пользователях не неся никакой ответственности, а попробуйте крупному корпоративному клиенту продать что то необкатанное, а потом ещё быстро не починить. По мне так эта фраза является очень вредной как в обычном программировании, так и в технологиях вокруг плис, которые, как следует из статьи, становятся всё ближе к разработчику без пары десятков тысяч на вход)
Разговор про ничтожную стоимость ошибки, как в программировании.
Но вот издержки должны учитываться и не следует убеждать начальство, что они ничтожны))
Также должны учитываться издержки на 1 итерацию и скорость итераций, как быстро может быть получена ценность. FPGA по этим критериям позволяют приблизиться к гибким методологиям в софте, получать рабочие промежуточные результаты, адаптироваться к изменениям в требованиях и тестировать в приближенных к реальным условиях. Частые итерации позволяют снизить стоимость ошибки и уменьшить требования к кадрам.
Вы говорите про очень тяжелый вариант использования ПЛИС - как относительно дешевый вариант замены ASIC. Да, там затраты на разработку будут сопоставимы с разработкой микросхемы. Я же вещаю про вариант "ПЛИС вместо МК". Во второй части будет про это.
Вопрос. Я выполняю make и получаю ошибку
$ make
mkdir -p build/src/
/usr/bin/riscv64-unknown-elf-gcc -c -march=rv32i -mabi=ilp32 -DNDEBUG -g -Os -MD -fstrict-volatile-bitfields -fno-strict-aliasing -o build/src/main.o src/main.c
In file included from src/main.c:2:
/usr/lib/gcc/riscv64-unknown-elf/10.2.0/include/stdint.h:9:16: fatal error: stdint.h: No such file or directory
9 | # include_next <stdint.h>
| ^~~~~~~~~~
compilation terminated.
make: *** [makefile:111: build/src/main.o] Error 1
Какой stdint.h ищет если уже stdint.h найден и открыт?
Беда с тими новыми компиляторами. Вот тут человек нашел решение:
At the end,
i resolved the problem by adding to KBUILD_CFLAGS += $(call cc-option,-ffreestanding)
That restricts gcc use standard stdint stdint-gcc.h
То есть нужна опция -ffreestanding в CFLAGS.
Очень интересно ! Спасибо ! До конца не разобрался ибо "многабукафф". Пока хочу спросить про SpinalHDL. Поглядел Ваши примеры, и он мне показался каким-то "непрозрачным" что ли. Если я вижу код на верилоге (по крайней мере в той манере, в которой пишу я сам), я довольно легко могу себе представить, во что он соберется на железке. Более того, я и пишу представляя себе регистры, провода, и как по ним бегают сигналы. Ваши примеры и исходники VexRiscv мне представляются скорее написанными программистом. Я не понимаю во что они соберутся. Скажите, это просто дело привычки ??? Или такая проблема на самом деле есть ???
Ваши примеры и исходники VexRiscv мне представляются скорее написанными программистом. Я не понимаю во что они соберутся. Скажите, это просто дело привычки ??? Или такая проблема на самом деле есть ???
Проблема в том, что такие штуки как вычислительные ядра это очень сложные вещи инкапсулирующие в себя ряд других сложных сущностей как матрешки. Автор VexRiscv разбил своё ядро на множество отдельных блоков и оперирует ими как обьектами в ООП. Такой подход не позволит в полной мере (без подглядывания в генерируемый Verilog) понять во что именно синтезируется код, но он позволяет легко управлять сложностью, подобно тому как это происходит при программировании на языках высокого уровня. Когда Вы пишите программу на C++, Вы же не задаетесь вопросом в какие машинные коды она будет преобразована компилятором и как этот машинный код будет выглядеть после оптимизации ? Для решения поставленной задчи Вам просто этого не требуется, Вы полностью доверяете компилятору. Всё то же самое касается SpinalHDL и VexRiscv. При желании, Вы всегда можете подсмотреть в результирующий Verilog, только что-либо понять из него будет еще сложнее - собственно как и с программи транслированными с высокоуровневых языков. В целом, SpinalHDL и VexRiscv созданны программистом для программистов, для людей которые не видят смысла "программировать сложные задачи на ассемблере". SpinalHDL это высокоуровневый язык по отношению к Verilog-у, как C++ по отношению к ассемблеру. Аппаратчики такой подход не понимаю и не приемлют и продолжают тянуть лямку Verilog-а оборачивая его в различные макросы и скрипты на Tcl, bash и Python, от чего в ихнем коде разобраться не может решительно никто. SpinalHDL делает код простым и понятным с точки зрения выбранного уровня абстракции, а не с точки зрения сигналов, проводов и отдельных регистров.
Да, SpinalHDL и VexRiscv написаны человеком который очень хорошо знает синтаксис и особенности Scala, по этому разбираться с внутренностями VexRiscv неподготовленому человеку тяжело. Я не специалист по Scala и у меня много вопросов к тому как VexRiscv внутри устроен и функционирует. Но на верхем уровне с VexRiscv очень удобно работать. У него хорошо специфицированный интерфейс позволяющий легко настраивать ядро и подключать к нему другие аппаратные блоки, легко дописывать их самостоятельно, что я и продемонстрировал на примере компонента Sram.
В конце концов, на SpinalHDL кода получается существенно меньше.
В статью не вошла еще одна глава про blackbox-а - способ подключения произвольного модуля написанного на Verilog или VHDL, позволяющего работать с ними как с обьектами SpinalHDL.
Конечно, весьма привлекательно использовать SpinalHDL, но это дополнительный слой абстракции. Недостаточно будет знать этот HDL, всё равно потребуется разбираться в языке, в который он транслируется. И любой баг в трансляторе может стоить много часов отладки. Как правильно написано в статье, иногда требуется погружаться на несколько уровней ниже Verilog'a/VHDL'a чтоб понять какие чудеса натворил оптимизатор.
PS: посылаю лучи ненависти Libero SoC от MicroSemi, даже 20 лет назад тулчейн от Altera был лучше чем это современное поделие (v2024.1).
PPS: собирал icestorm из исходников под WSL чтоб залить битстрим на плату с iCE40 - заняло считаные секунды.
Конечно, весьма привлекательно использовать SpinalHDL, но это
дополнительный слой абстракции. Недостаточно будет знать этот HDL, всё
равно потребуется разбираться в языке, в который он транслируется. И
любой баг в трансляторе может стоить много часов отладки.
Все так, да не так. Когда Вы программируете на C++ или на Java Вы же не опускаетесь до уровня ассемблера или байт-кода ? А почему ? Почему при разработке сложной цифровой аппаратуры Вам все еще нужен уровен абстрации в виде проводов и D-триггеров ? Может быть пора оторваться и перейти на уровень повыше ? В программировании этот принцип работает очень давно и успешно. Не вижу причин по которым этот же подход не может работать в цифровой схемотехнике.
Вопрос доверия транслятору в программировании тоже был, но эта эпоха давно прошла. Вангую, с цифровым синтезом будет всё то же самое. Помимо SpinalHDL есть еще Chisel, причем вполне коммерчески успешный.
Почему при разработке сложной цифровой аппаратуры Вам все еще нужен уровен абстрации в виде проводов и D-триггеров ?
Ну вот так получается :) Сами же упоминали важность изучения вывода низкоуровневых утилит. Бывает что нужно разбираться куда пропадают сигналы, которые в исходниках есть, а из netlist'a пропадают, или почему появилась метастабильность.
Может быть пора оторваться и перейти на уровень повыше ?
Я бы рад, но увы пока даже перейти на уровень Verilog'a не всегда выходит. Возможно это потому что у меня недостаточно опыта.
Вангую, с цифровым синтезом будет всё то же самое.
Хорошо если так, но проект пока ИМХО слишком молод и ментейнеров/контрибьюторов не так много.
Ну вот так получается :) Сами же упоминали важность изучения вывода
низкоуровневых утилит. Бывает что нужно разбираться куда пропадают
сигналы, которые в исходниках есть, а из netlist'a пропадают, или почему
появилась метастабильность.
Да, в лог приходится смотреть. У Yosys-а есть неприятная фича - он молча проглатывает код с опечатками в именах сигналов, а на последующих стадиях оптимизирует такие сигналы до нуля. Возможно это как-то отключается, но на вскидку я не нашел. Ох, сколько часов было убито зря в поиске "неисправности" из-за таких косяков. В SpinalHDL с этим проще - запнется либо на стадии компиляции из Scala, либо на стадии генерации из SpinalHDL в Verilog.
Хорошо если так, но проект пока ИМХО слишком молод и ментейнеров/контрибьюторов не так много.
Дык подключайтесь. Я, пока писал статью, наткнулся на пару багов и написла об этом Шарлю Папону, он тут же поправил. Баги не существенные, связанные с переходами между версиями.
Все просто великолепно. А как можно у вас купить эту плату?
Разработка цифровой аппаратуры нетрадиционным методом: Yosys, SpinalHDL, VexRiscv (ч.1)