Комментарии 65
Монументально! Буду на следующей неделе читать, извлекать что не знаю
Вот это талмуд, мое почтение. Программировал когда-то давно на 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.
Хорошо если так, но проект пока ИМХО слишком молод и ментейнеров/контрибьюторов не так много.
Дык подключайтесь. Я, пока писал статью, наткнулся на пару багов и написла об этом Шарлю Папону, он тут же поправил. Баги не существенные, связанные с переходами между версиями.
Все просто великолепно. А как можно у вас купить эту плату?
Спасибо за статью. Подскажите, пожалуйста, У меня есть вот такая плата iCESugar-Pro v1.3 lattice LFE5U 6BG265C MuseLab модуль ECP5 FPGA RISC-V Linux SODIMM LFE5U-25F-6BG256C. Как узнать поддерживается ли эта плата в yosys? И как с ней работать в yosys? Тот же вопрос по плате Colorlight i9 модуль LFE5U 45F 6BG381C 44K LUT Open Source Toolchain v7.2. Какие модули yosys надо использовать? и как?
Микросхема ПЛИС FE5U-25F-6BG256C в Yosys тулчейне поддерживается (это та же самая микросхема что и на нашей плате "Карно"). Все инструкции есть в тексте статьи. Основная заморочка у Вас будет с программатором. Имеется ли на Вашей плате встроенный JTAG на базе какой нибудь FTDI ? Если так, то все просто - прошивать через openFPGALoader. Иначе придется купить программатор и спаять кабель и шить либо через openFGPALoader, либо через ecpprog.
Спасибо. На плате есть JTAG. С платой LFE5U-25F-6BG256C понятно. А что насчет LFE5U 45F 6BG381C 44K LUT? Я так понимаю для неё только LPF файл нужен правильный. Где его можно взять? Или где взять данные для этого файла?
И еще вопрос. Есть плата вот с таким чипом GW5A LV25 UG324C2 на док плате GW ACG525. Как с ней работать? Вот ссылка на алиекспресс https://aliexpress.ru/item/1005006282814249.html?spm=a2g2w.orderdetail.0.0.1e684aa67OGusL&sku_id=12000036600111305
Не могу найти на неё практически ничего. Вроде как GW5A в yosys не поддерживается. Работать можно и в GoWin. Но я не могу найти документацию на неё: datasheet, распиновку.
И огромное спасибо за наводку по Makefile.
Где его можно взять? Или где взять данные для этого файла?
Создать самому. Формат LPF файла очень прост. Вам нужно найти схему распайки периферии на вашей плате и создать соответствующий LPF. Начать можно с одного единственного светодиода, убедится что он работае и дальше продвигаться (наращивать LPF) по мере надобности. Еще нужно подправить Makefile и указать в нём тип и корпус микросхемы.
Есть плата вот с таким чипом GW5A LV25 UG324C2 на док плате GW ACG525. Как с ней работать?
GW5A (Arora V) в Yosys на данный момент не поддерживается. Поэтому Вам придется использовать проприетарный тул GOWIN EDA. На сайте производителя есть вся необходимая документация, в том числе даташит на GW5A.
Вот пытаюсь повторить работу.
Шаг настройки
/school/prj/J1Hub/basics-graphics-music$ bash check_setup_and_choose_fpga_board.bash
...
emooc_cc 55) tang_primer_25k_dock
ice40hx8k_evb_yosys 56) trion_t20
karnix_ecp5_yosys 57) zeowaa
nexys4 58) zeowaa_wo_dig_0
nexys4_ddr 59) zybo_z7
nexys_a7 60) exit Your choice (a number): 27
check_setup_and_choose_fpga_board.bash: FPGA board selected: karnix_ecp5_yosys
check_setup_and_choose_fpga_board.bash: Created an FPGA board selection file: "/home/serge/school/prj/J1Hub/basics-graphics-music/fpga_board_selection"
Would you like to create the new run directories for the synthesis of all labs in the package, based on your FPGA board selection? We recommend to do this if you plan to work with Quartus GUI rather than with the synthesis scripts. [y/n] n
Configuring for Lattice ECP5...
OK
Теперь Запуск всего конвейера для получения битстрима осуществляется одной командой:
/school/prj/J1Hub/basics-graphics-music/labs/01_and_or_not_xor_de_morgan$ bash 03_synthesize_for_fpga.bash
Configuring for Lattice ECP5...
OK
/home/serge/school/prj/J1Hub/basics-graphics-music/scripts/steps/00_setup_yosys.source_bash: line 104: //: Is a directory
На этом всё останавливается. Почему?. У меня Ubuntu 22.04. Весь пакет yosys я установил. Проверил как в этом руководстве наличие каждой программы. ??? Одни вопросы ???
Потому что на вопрос "надо ли создавать рабочие директории" Вы ответили "нет" (n). Еще раз запустите конфигурационный скрипт.
OK! Запустил clean_all на вссякий случай. Потом
$ bash check_setup_and_choose_fpga_board.bash
...
karnix_ecp5_yosys 57) zeowaa
nexys4 58) zeowaa_wo_dig_0
nexys4_ddr 59) zybo_z7
nexys_a7 60) exit Your choice (a number): 27
check_setup_and_choose_fpga_board.bash: FPGA board selected: karnix_ecp5_yosys
check_setup_and_choose_fpga_board.bash: Created an FPGA board selection file: "/home/serge/school/prj/J1Hub/basics-graphics-music/fpga_board_selection"
Would you like to create the new run directories for the synthesis of all labs in the package, based on your FPGA board selection? We recommend to do this if you plan to work with Quartus GUI rather than with the synthesis scripts. [y/n] y
check_setup_and_choose_fpga_board.bash: Setting up: "/home/serge/school/prj/J1Hub/basics-graphics-music/labs/18_pow5_single_cycle/run"
/home/serge/school/prj/J1Hub/basics-graphics-music/scripts/steps/00_setup_yosys.source_bash: line 104: //: Is a directory
Завершается вот так???
Что бы это значило? И как с этим быть?
Кто-то что-то сломал в репе. Я посмотрю.
Так и есть, при добавлении поддержки Gowin EDA сломали поддержку Yosys. :)
Я внес исправления и отправил PR в апстрим. Пока его рассматривают можете воспользоваться моим патчем.
Патч исправления ошибки /00_setup_yosys.source_bash: line 104: //: Is a directory
diff --git a/scripts/steps/00_setup_yosys.source_bash b/scripts/steps/00_setup_yosys.source_bash
index e082116..3a822e1 100644
--- a/scripts/steps/00_setup_yosys.source_bash
+++ b/scripts/steps/00_setup_yosys.source_bash
@@ -101,10 +101,9 @@ setup_run_directory_for_fpga_synthesis_yosys ()
"$board_dir/$fpga_board" \
"$lab_dir/common"
do
- // TODO: Check if we really need adjust_path_for_gowin_win here
$find_to_run \
- "$(adjust_path_for_gowin_win "$verilog_src_dir")" \
+ "${verilog_src_dir/\/[[:alpha:]]\//${verilog_src_dir:1:1}:\/}" \
-type f -name '*.sv' -not -name tb.sv \
-printf "READ_VERILOG += -p \"read_verilog -sv %p\"\n" \
-printf "DEPS += %p\n" \
Спасибо за ответы. Попробую найти данные и сделать LPF. Кстати, у меня есть GoWin v1.9.9. Она поддерживает GW5A. Я уже проверил. Нельзя ли как-то из неё вытащить полный LPF файл?
Кажется я нашел. Нашел примеры. В них есть LPF. Но есть вопрос. Что ещё нужно для того, чтобы эта плата заработала в yosys? Мне кажется там нужно что-то ещё?
Yosys не зависит от LPF, он используется утилитой nextpnr на стадии трассировки сигнальных линий. Еще раз, это конфигурационный файл который Вы должны подготовить самостоятельно, в зависимости от Вашего проекта и расположения перифериии на пинах ПЛИС.
Что именно Вы собрались синтезировать ? Если речь идет о basic-graphics-music то Вы можете взять в качестве примера boards/karnix_ecp5_yosys/board_specific.lpf от платы "Карно" и переписать его под свою плату. Скопируйте каталог boards/karnix_ecp5_yosys во что-нибудь типа boards/icesugar_pro_ecp5_yosys, после чего у Вас появится еще одна плата в меню. Исправьте содержимое board_specific.lpf согласно расположению пинов на этой плате, после чего синтузируйте первые лабы и проверяйте как оно работает. Как полностью заработают все лабы (ну или хотя бы большая их часть) - отсылайте коммит в апстрим. :-)
Вот попробовал сделать как здесь указано. Получил вот что:
icesugar_pro_ecp5_yosys 58) zeowaa
karnix_ecp5_yosys 59) zeowaa_wo_dig_0
nexys4 60) zybo_z7
nexys4_ddr 61) exit
nexys_a7 Your choice (a number): 27
check_setup_and_choose_fpga_board.bash: FPGA board selected: icesugar_pro_ecp5_yosys
check_setup_and_choose_fpga_board.bash: Created an FPGA board selection file: "/home/serge/school/prj/J1Hub/basics-graphics-music/fpga_board_selection"
Would you like to create the new run directories for the synthesis of all labs in the package, based on your FPGA board selection? We recommend to do this if you plan to work with Quartus GUI rather than with the synthesis scripts. [y/n] y
check_setup_and_choose_fpga_board.bash: Setting up: "/home/serge/school/prj/J1Hub/basics-graphics-music/labs/18_pow5_single_cycle/run"
check_setup_and_choose_fpga_board.bash: error: Unsupported FPGA synthesis toolchain: none. Currently supported: quartus, xilinx, gowin, yosys.
Вот такая ошибка. Как это лечить? Жаль, что нет подробной инструкции типа "как добавить новый девайс"
Нужно еще добавить имя нового каталога в скрипт ./scripts/steps/00_setup.source_bash.
Вообщем, для таких работ требуется знание bash скриптинга.
Таки сделал я. Заработало! Но есть вопрос. Для прожига icesugar-pro я использую скрипт dapprog. Он в свою очередь использует openocd. Скрипт оболочки dapprog написан для удобства. Также для удобства можно экспортировать путь к dapprog, чтобы использовать его везде. openocd может поддерживать только svf-файл, поэтому бит-файл будет преобразован в svf-файл с немного измененным urjtag . кроме того, svf-файл является программой для sram, а битовый файл - программой для flash. dapprog это оболочка bash команды openocd.
В ручную я просто выполняю команду dapprog file.svf для программирования в RAM. Вот и вопрос. Как сделать это при помощи scripts/??? После синтеза в run у меня есть только .bin. Его надо ещё как-то преобразовать в .svf??? В какие скрипты чего надо написать?
И как сделать симуляцию? Какой скрипт надо запустить и, возможно в нём что-то надо изменить для icesugar-pro?
Всё, в апстриме исправлено. Сделайте git pull origin main .
В Gowin используется не LPF, а CST - этот конфигурационный файл зависит не от среды разработки, а от производителя Вашей платы, так как в нём расписано что и на каких пинах припаяно конкретно на вашей плате. Вы должны сделать его самостоятельно. Задействуйте сначала один из светодиодов или линю GPIO, добейтесь работоспособности и потом по мере надобности добавляйте периферию которую Вы собираетесь использовать. Нет необходимости запихивать сразу всю распиновку ПЛИС.
В качестве примера можете воспользоваться CST файлом от TangNano-9K из basics-graphics-music: boards/tang_nano_9k_gowin_yosys/board_specific.cst - просто переделайте его под свою плату. Но Вы должны знать на каких пинах подключена интересующая Вас периферия, для этого нужно иметь либо схему платы, либо какой-то демо проект с этой платой от её производителя.
Спасибо, патч сработал и всё завелось. Отлично. Но вылезла другая проблема. Я не могу программировать плату.. Вот пример:
$ iceprog -r j1
init..
Can't find iCE FTDI USB device (vendor_id 0x0403, device_id 0x6010 or 0x6014).
ABORT.
Хотя сама плата включена
$ lsusb
0bda:b008 (bus 1, device 4) path: 1.4
1ea7:0066 (bus 1, device 3) path: 1.1
0438:7900 (bus 1, device 2) path: 1
1d6b:0002 (bus 1, device 1)
2109:0817 (bus 3, device 11) path: 3
1d6b:0003 (bus 3, device 1)
0781:5571 (bus 2, device 10) path: 4
0d28:0204 (bus 2, device 25) path: 3.1
2109:2817 (bus 2, device 24) path: 3
0bda:58ed (bus 2, device 2) path: 1
1d6b:0002 (bus 2, device 1)
3.1 это как раз моя плата на порту USB. Может что надо прописать в /etc/udev/rules.d? Но я не могу найти что туда прописать. Обычно это помогает. Например с GW 20К и 25К так и было. Подскажите, плиз, что в rules надо прописать? Или может быть это ещё какая-то проблема другая? Вот часть сообщений из dmesg
[235887.130671] usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[235887.130673] usb 2-3: Product: USB2.0 Hub
[235887.130675] usb 2-3: Manufacturer: VIA Labs, Inc.
[235887.132728] hub 2-3:1.0: USB hub found
[235887.133037] hub 2-3:1.0: 4 ports detected
[235888.079002] usb 2-3.1: new full-speed USB device number 25 using xhci_hcd
[235888.241047] usb 2-3.1: New USB device found, idVendor=0d28, idProduct=0204, bcdDevice= 1.00
[235888.241062] usb 2-3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[235888.241069] usb 2-3.1: Product: DAPLink CMSIS-DAP
[235888.241074] usb 2-3.1: Manufacturer: ARM
[235888.241078] usb 2-3.1: SerialNumber: 0700000100170034340000124e543352a5a5a5a59796
Вcтроенный программатор на вашей плате построен не на базе FTDI. Это значить что Вам придется самостоятельно разобраться каким программатором её прошивать. Начните с того, что бы выяснить какая микросхема использована, с каким софтом она может управляться (openFTPGLoader поддерживает много разных USB-to-Serial преобразователей).
Вот здесь упоминается какая-то утилита icesugar-iceprog. Там же есть схема в формате PDF.
UPD: Похоже там что-то нестандартное, какой-то ICELink на базе STM32. Но, на плате есть вывод JTAG, так что в крайнем случае Вы сможете прошить её обычным USB Blaster-ом.
Ура! Заработало! Я нашел как правильно программировать плату. Надо было внимательно прочитать README. Я сделал это несколько раз и увидел то, что не видел. Сделал как написано и всё получилось.
Мои успешные действия:
Видеть цель и проявляя настойчивость двигаться к цели.
Внимательно читать инструкцию, проясняя при этом непонятые слова до тех пор пока станет понятно.
Строго выполнять то, что написано.
Смотреть на результат сравнивать его с тем, что должно быть, добиваясь того, что должно получиться.
Теперь можно заняться сами basic-graphics-music и выполнить уроки на моей плате. Попробую достичь эту цель.
Отлично! Так поделитесь же с нами результатом достижений, а именно - как прошить ICESugar ?
Да! Если очень коротко, то это так. Подчеркиваю, я работаю с платой iceshugar-pro. Эта плата не тоже самое, что плата iceshugar. Второе, оказалось имело место быть два ключевых момента.
Подсоединять надо было USB не к материнской плате а к самой плате iceshugar-pro
Использовать для прожига программу dapprog, которая идёт в комплекте вот отсюла https://github.com/wuxx/icesugar-pro.git
Для прожига платы iceshugar надо использовать программу icesprog именно с буквой s. Эта прога в комплекте вот от сюда https://github.com/wuxx/icesugar.git
Кроме того есть еще программа iceprog. Я не помню сейчас откуда она прицепилась, но она не работает ни с iceshugar, ни с iceshugar-pro.
В этом была некоторая путаница. К тому же была ещё плата GW Tang 25K. Но это уже другая история. Хотя в данном случае она добавляла хаотичности. Но в итоге я расставил всё по своим местам. и каждая из плат заработала.
И хочу отметить ещё одно успешное обстоятельство - это общение. Спасибо за поддержку.
PS. Я, всё-таки напишу статью об этом приключении. )))
Разработка цифровой аппаратуры нетрадиционным методом: Yosys, SpinalHDL, VexRiscv (ч.1)