Комментарии 27
О, я только недавно публиковал новость в новостном FPGA канале про это, а тут уже и полноценный обзор тулы. Пасиба.
Спасибо! Подскажите, с чего можно начать изучение FPGA в 2024, какую dev board использовать, на какие инструменты обратить внимание?
Личное мнение. Начните с китайцев как ни странно - Gowin. Их платы дешевые и поморгать лампочкой, вывести hdmi или risc-v ядро хватит. Плюс их среда разработки простая, все в коде. Можно разобраться.
Обратить внимание стоит на инструменты симуляция - Icarus Iverilog или Verilator (посложнее будет). Результат работы смотреть в GTKWave. Пока вы не увидите как работает ваш код в симуляции, вы не будете понимать почему не работает в железе.
Дальше можно взять Intel Altera - они уже посложнее и хоть как-то ценятся на рынке труда.
Последний этап это Xilinx.
А под линуксом этим можно заниматься? Есть инструменты под эту платформу?
Обратить внимание стоит на инструменты симуляция - Icarus Iverilog или Verilator (посложнее будет).
Не тратьте время на Icarus Iverilog - ещё на серединке первого (любого) учебника его возможностей перестанет хватать. Например, в нём не работают поясняющие текстовые сообщения в assert
со школы синтеза цифровых схем https://engineer.yadro.com/chip-design-school/
Lattice и отчасти Gowin хорошо поддержаны в опенсорсном тулчейне. Xilinx работает только с монструозной фирменной оболочкой. Lattice дешевы, а еще есть очень дешевая "плата управления световыми эффектами" с Али, фактически представляющая собой жирную ECP5 с памятью, Ethernet и кучей преобразователей уровней на выходах. Преобразователь уровней можно отпаять и закоротить, тогда выход превратится во вход (из коробки входов плата не имеет). Стоимость платы сравнима со стоимостью самой ECP5 в розницу.
Закоротить можно, но зачем? Вот то, о чём вы говорите: https://habr.com/ru/articles/589329/ — там же проскакивает более нормальная dev-плата, куда можно вставить so-dimm модули как с Lattice ECP5 на 25K и 45K LUT4 ячеек (первый у меня есть), так и на ECP3 (не искал), Xilinx XC6SLX16 (нашёл продавца, но закончились) и Xilinx XC7AA50T (и этот есть). Последний также поддерживается open source toolchain, как и ECP5. (См. последние комментарии к статье.)
Вот на этой куча внешних I/O и к ней продаётся куча PMOD-модулей за вполне разумные деньги на Али. Для этой dev-платы, кстати, не нужен внешний программатор.
Похоже на очередной "прорыв" в HDL языках. Скобки безусловно удобнее begin...end, но где решение остальных проблем SV?
Где верификационные возможности этого языка? Если он только под синтез, то зачем он вообще нужен?! VHDL и Verilog с этим вполне справляются.
Про какие именно проблемы SystemVerilog идет речь ? Я согласен, что у меня не такой обширный опыт, но SV ощущается гораздо лучше того же Verilog. Так что я не очень понимаю какие именно проблемы SV вы хотите решить.
Согласен это довольно странно, что нет ни какой реализации встроенных тестов, по принципу тестов из Rust. VHDL - так сложилось для меня, что он просто не читаем. Verilog более скудный чем SV. Считаю что выбор в сторону более современного SV был сделан логично. Плюс он поддерживается средами разработки для ПЛИС (да полной поддержки стандарта ни где нет, но большая часть возможностей, покрывает большую част задач)
VHDL на самом деле довольно удобен, привыкнуть к нему несложно. И он более строг, чем Verilog и SV, особенно ощущается после Rust. При выборе между SV и VHDL я скорее выберу VHDL. Но его синтаксис громоздкий. Скорее всего можно сделать очень хороший современный язык, взяв именно VHDL как базу, слегка переработав синтаксис, буквально на уровне препроцессора, не вмешиваясь в логику. Там только длинные слова читаемости мешают.
Ну, у VHDL нет полноценного аналога интерфейсам из SystemVerilog (во всяком случае, нет в тех версиях, которые реально доступны в средствах синтеза; в самом последнем стандарте, может, и ввели, но поддерживать его начнут хз когда). Плюс громоздкий, да, но реально меня в нём бесят в этом плане только to/downto. Так что, в общем и целом, я предпочитаю SV, но если выбирать между просто Верилогом и VHDL, выберу последний.
В VHDL есть похожая вещь - называется record. Позволяет объединять разные типы в один. Вот пример:
type bus_10g is record
data : array_vector8(7 downto 0); -- Данные
ce_data : std_logic_vector(7 downto 0); -- ce для данных
rts : std_logic; -- Ready to start (должен ставиьтся за такт перед sop)
sop : std_logic; -- указывает 1-е слово в пакете
last_byte : std_logic_vector(7 downto 0); -- 1 для последнего байта данных
terminate : std_logic_vector(7 downto 0); -- 1 для байта, следующего за last_byte
word_count : unsigned(11 downto 0); -- счетчик слов (по 8 байт), начиная от sop
end record;Здесь в примере объединены в один как простые типы, так и составные, так и свои собственные. Более того, затем можно создать тип, являющийся массивом этих записей:
type array_bus_10g is array(natural range <>) of bus_10g;И потом использовать его в модуле как массив с переменным количеством элементов:
Generic (
BUS_NUM : positive range 1 to 16 := 16 -- Задаваемое количество шин
)
Port (
-- Массив входных шин
bus_arr_in : in array_bus_10g(BUS_NUM-1 downto 0)
);В итоге получаем параметризованный модуль с переменным количеством входных шин, настраиваемый перед компиляцией (синтезом).
Причем это всё синтезируемые конструкции.
Это прямой аналог struct {}, а не интерфейса.
Интерфейс заметно удобнее:
-не требуется таскать его обьявление через импорт в каждый модуль иерархии, сквозь которые проходит
-параметры могут быть в объявлении самого интерфейса, чаще это удобнее/логичнее
-модпорты. Синтезатор Xilinx их игнорировал, может и в крайних версиях также осталось, но при отладке в симуляторе доп.защита
-связывание на этапе "линковки" модулей, а не синтеза конкретного модуля, чаще плюс, чем минус
-доп несинтезируемые плюшки, вроде возможности интеграции функций и clocking block. Их не применял, поэтому не скажу насколько полезны и поддерживаются софтом.
Объявления для типа record, как и для других типов делаются элементарно. Создается пакет, в нем вы описываете нужные вам типы. Можете добавить к ним функции, в которых этот тип используется или ими возвращается. А затем одной строкой сразу всё подключаете:
use work.my_pack.all;Всё очень легко и удобно
Это кунг-фу я помню, но это в каждом модуле, в которые заходит интерфейс, 2 строчки
use work.my_pack.all;
input t_my_record my_record;
против одной
interface my_interface;
И глобальный суперпак со всеми "интерфейсами"(если хочется потом обходится 2 строчками для применения), что само по себе неочень.
Против более локализованного и структурированного объявления интерфейсов в sv.
И такое во многом:
-использование многомерных массивов
-почти обязательное явное приведение типов, зачастую многократное в одном выражении для обычной операции над двумя,тремя числами
-двукратное написание шапки модуля. Да в версиях посвежее можно и почти:) однократно, но чаще пишут по старому(легаси/привычка/недоверие к софту)
-конкурирющие стандартные пэкеджи арифметики numeric_std или arith+signed/unsigned
-просто больше букв и меньше логики чтобы написать тоже самое.
И это только про консервативное синтезируемое подмножество.
Вообщем мне vhdl напоминает латынь - используется римлянами-долгожителями, аптекарями и классическими гимназистами, чаще не по своей воле.
Ну и главное - видно что и производители софта к нему так относятся.
Впрочем sv тоже смотрится уже совсем так себе, просто вроде пока чтото повысокоуровневее не особо у производителей плис/софта получается, но видно что очень хотят и будут додавливать.
Мне как верификатору больше интересны несинтезируемые конструкции. Чего мне прям ощутимо не хватает в SV:
1) динамическое изменение слайсов.
2) перегрузка функций (под синтез так же полезная опция. И это было в VHDL как минимум с 98 версии).
3) дальнейшее улучшение векторов и итераторов по векторам.
4) улучшение рандомайзера. Например мне сильно не хватает возможности в констрейн вернуть из функции вектор. Да в рандомизации можно очень много чего допилить.
5) опять про рандомизацию - явная связь между каверпоинтами и констрейнами/рандомайзером.
С точки зрения синтеза:
1) таки сделать logic как его обещали - полной заменой reg-wire. Чтобы не приходилось писать wire logic!
2) уже упомянутые интерфейсы. Сделать нормальные вектора интерфейсов. И опять по верификации - доработать клокинг блоки.
3) сделать enum нормальным enum'ом, а не оберткой над чем-то.
еще много чего можно вспомнить как по мелочи, так и прям больного.
Да банально пункт номер НОЛЬ во всех списках: привести синтаксис в синтезе, констрейнах, карпоинтах и ассертах к одному!
С точки зрения синтеза:
таки сделать logic как его обещали - полной заменой reg-wire. Чтобы не приходилось писать wire logic!
уже упомянутые интерфейсы. Сделать нормальные вектора интерфейсов.
Работаю только с xilinx vivado, но конкретно в нем:
сто лет так использую. wire пишу только во входных пинах модуля, т.к. предпочитаю `default_nettype none И вот ему зачем-то хочется там input wire logic...blabla
vivado уже лет 8 поддерживает синтезируемые массивы интерфейсов, хотя задокументировано это было на несколько лет позже. Из корявости - их подключение с модпортами или невозможно, или разный синтаксис с моделсим, поэтому просто подключал без модпорта, "благо" vivado их все равно при синтезе игнорирует(до 2019.2 точно, может и до сих пор, не уверен). Скорее всего не даст подключение части массива и, возможно, многомерных массивов, но врядли эти ситуации сильно нужны в синтезируемом коде.
Так что эти пункты - это не проблемы языка, максимум конкретной среды.
Насколько трудно это будет портировать при смене поставщика FPGA?
Про reg/wire точно не скажу, но
xilinx vivado(я с ним с 2015) никогда их не требовал в явном виде.
с другими производителями не работал, но врядли там настолько хуже
synplify(а он вроде мультиплатформенный) тоже спокойно синтезил все из logic
на крайняк можно попробовать каким-нить внешним (самописным?) парсером позаменять обьявление сигналов - reg, если поисваивается под always_ff, иначе wire.
Массивы интерфейсов можно постфактум относительно легко заменить на массив структур/двумерных векторов/одномерных векторов, даже не потеряв параметрезируемость по размерам. Просто код станет более громоздким и хуже читаемым.
Думаю скорее вопрос был что делать если софт экзотического семейства не поддерживает ни sv, ни возможность подключить внешний синтезатор? Страдать:]
Лично мне было бы проще/быстрее написать и отладить все на sv, а потом переписать синтезируемую часть(сверяясь с эталонным sv в sv тестбенче)на vhdl или старорежимный verilog, чем страдать сразу на них. Но, к счастью для начальников и снабженцев и горю разработчиков, ничего принципиально непереносимого в синтезируемом подмножестве sv нет. Настощим софтверным программистам в это трудно поверить, но по факту (оптимизация и отладка) синтезируемый код в плис это что-то на уровне смеси самого начального и низкоуровнего си и ассемблера. По крайней мере для моих задач и навыков /o\
Как обычно и бывает с такими прорывами -- простые вещи *может быть* оказывается писать чуть проще, а сложные -- *пока не поддержано* или как тут -- рассыпается вдребезги. Но зато на ржасте.
На первый взгляд выглядит как синтаксис Verilog-а с косметическими изменениями. Не совсем понятна идея. Ну ок, есть линтер и автодокументация, но это как-то не перевешивает...
Если хочется чего-то альтернативного, то чем плох тот же Chisel, где все плюшки Scala можно применить чтобы получить RTL с высокой степенью параметризуемости?
В случае с Chisel авторы уже 2 раза ломали совместимость кодовой базы. Первый раз — когда перешли от Chisel 2 к Chisel 3, второй — когда заменили компилятор FIRTTL на CIRCT. Работа с несколькими таковыми доменами по-прежнему выглядит криво после удобств SpinalConfig. Поэтому SpinalHDL выглядит куда краше, если брать Scala based HCL.
Смотрим на современный инструмент для FPGA