Начало работы с использованием инструментов FPGA с открытым исходным кодом

Начало работы с использованием инструментов FPGA с открытым исходным кодом

11 апреля 2022 г.

В этом посте мы рассмотрим некоторые из самых популярных инструментов с открытым исходным кодом для [проектирования ПЛИС] (https://fpgatutorial.com/fpga-design-introduction/) и проверки.


Традиционно, когда мы создаем дизайн FPGA, мы должны использовать проприетарные программные инструменты для моделирования и построения нашего проекта.


Например, когда мы создаем проект, предназначенный для Xilinix FPGA, мы обычно используем программное обеспечение Vivado.


Это означает, что когда мы ориентируемся на другого поставщика FPGA, нам также нужно научиться использовать другой инструмент.


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


Однако за последние несколько лет было разработано несколько инструментов с открытым исходным кодом, предназначенных для моделирования и создания проектов ПЛИС.


Хотя этим инструментам еще предстоит пройти долгий путь, прежде чем они будут поддерживать все FPGA на рынке, они уже предлагают поддержку ряда FPGA от [Lattice] (https://www.latticesemi.com/Products) и Xilinx.


В результате мы часто можем использовать одну и ту же цепочку инструментов с открытым исходным кодом для многих разных проектов FPGA.


В дополнение к этому прилагаются большие усилия для поддержки большего количества устройств и внедрения дополнительных функций.


Все это означает, что инструменты FPGA с открытым исходным кодом быстро развиваются до уровня, когда они могут конкурировать с коммерчески разработанным программным обеспечением.


В оставшейся части этого поста мы рассмотрим некоторые из наиболее часто используемых программных инструментов с открытым исходным кодом, которые мы можем использовать при разработке ПЛИС.


Инструменты моделирования


Существует несколько инструментов FPGA с открытым исходным кодом, которые были разработаны в качестве альтернативы дорогому программному обеспечению, такому как [QuestaSim] (https://eda.sw.siemens.com/en-US/ic/questa/simulation/advanced-simulator/ ) и Synopsys VCS.


Одним из главных преимуществ использования симуляторов с открытым исходным кодом, несомненно, является цена.


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


Например, мы часто находим лучшую поддержку библиотек моделирования, таких как UVM, с инструментами с открытым исходным кодом.


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


Несмотря на эти преимущества, мы также должны учитывать некоторые недостатки симуляторов с открытым исходным кодом.


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


Исключением из этого правила является Verilator, предлагающий производительность, сравнимую со многими коммерческими симуляторами.


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


Еще одна проблема, с которой мы сталкиваемся при использовании симуляторов с открытым исходным кодом, заключается в том, что они не поддерживают зашифрованные блоки IP.


Это проблема, если мы хотим использовать IP от таких поставщиков, как Xilinx, поскольку все модели моделирования, которые они предоставляют, зашифрованы.


Наконец, в настоящее время нет симуляторов с открытым исходным кодом, предлагающих многоязычную поддержку.


В результате мы не сможем использовать симулятор с открытым исходным кодом при создании проекта, использующего как VHDL, так и Verilog.


Хотя обычно это не проблема, у нас могут быть случаи, когда мы хотим спроектировать нашу ПЛИС с использованием VHDL и создать испытательный стенд с помощью SystemVerilog.


Мы не можем использовать этот подход с доступными в настоящее время симуляторами с открытым исходным кодом.


Давайте взглянем на некоторые из самых популярных симуляторов с открытым исходным кодом.


Икар Verilog


Программный инструмент [Icarus Verilog] (http://iverilog.icarus.com/) представляет собой компилятор Verilog с открытым исходным кодом, который включает в себя синтезатор и симулятор.


Мы можем использовать Icarus Verilog в операционных системах Linux, macOS и Windows.


Icarus Verilog поддерживает все функции [стандарта Verilog 2005] (https://standards.ieee.org/standard/1364-2005.html), а также ограниченное количество SystemVerilog.


По умолчанию мы не можем просматривать сигналы из нашей симуляции, когда используем Icarus Verilog.


Однако мы можем экспортировать результаты нашего моделирования в [программу GTKWave] с открытым исходным кодом (http://gtkwave.sourceforge.net/), когда нам нужно просмотреть формы волны.


Icarus Verilog — один из самых популярных симуляторов Verilog с открытым исходным кодом. На самом деле, он настолько популярен, что даже является одним из рекомендуемых симуляторов на [игровой площадке EDA] (https://www.edaplayground.com/home).


Одна из причин этого заключается в том, что он предлагает очень хорошую поддержку всех функций стандарта verilog 2005.


В дополнение к этому сообщество разработчиков активно поддерживает Icarus Verilog и регулярно обновляет его новыми функциями.


Моделирование проектов с помощью Icarus Verilog


Когда мы используем Icarus Verilog для моделирования наших проектов, мы должны сделать два шага.


Во-первых, мы должны скомпилировать наш дизайн в объект, который может использовать внутренний симулятор.


Мы можем сделать это с помощью программы командной строки iverilog. Фрагмент кода ниже показывает общий синтаксис, который мы используем для этого.


``` ударить


iverilog -o <имя_выхода> <имя_входа>


В приведенном выше примере мы используем поле , чтобы дать имя скомпилированному выводу.


Мы используем поле в приведенном выше примере, чтобы указать файл Verilog, который мы хотим скомпилировать.


После того, как мы скомпилировали наш код Verilog, нам нужно вызвать симулятор с помощью программы командной строки vvp. Фрагмент кода ниже показывает общий синтаксис, который мы используем для этого.


``` ударить


vvp <имя файла>


Верилятор


Инструмент Verilator — это компилятор Verilog с открытым исходным кодом, который принимает только синтезируемый код Verilog или SystemVerilog.


В отличие от Icarus Verilog, мы используем Verilator для компиляции нашего кода Verilog в другой язык программирования — либо [C++] (https://www.cplusplus.com/), либо [SystemC] (https://fpgatutorial.com/systemc/).


В результате мы не можем напрямую имитировать скомпилированные объекты, которые создает Verilator.


Вместо этого нам нужно написать некоторый код на SystemC или C++, который затем можно использовать для имитации нашего проекта.


Затем мы можем использовать стандартный компилятор C, такой как GCC, для компиляции нашего проекта SystemC/C++ в исполняемый файл, который мы можем запустить.


Как мы видим из этого, когда мы ищем базовый симулятор Verilog, обычно проще использовать Icarus Verilog.


Однако Verilator предлагает ряд преимуществ по сравнению с другими открытыми и коммерческими компиляторами.


Возможно, самым большим преимуществом использования Verilator для моделирования наших проектов является скорость.


По сравнению с Icarus Verilog или GHDL наши симуляции будут работать намного быстрее, когда мы используем Verilator.


На самом деле, Verilator также работает лучше, чем большинство бесплатных инструментов, предоставляемых на коммерческой основе такими компаниями, как Xilinx и Intel.


Однако обычно мы обнаруживаем, что дорогие платные симуляторы, такие как QuestaSim, предлагают лучшую производительность, чем Verilator.


Еще одно преимущество Verilator заключается в том, что он применяет строгие правила linting. Когда мы пишем код, который нельзя синтезировать, Verilator выдает ошибки и сообщает нам, что не так с нашим кодом.


В результате мы сможем найти ошибки в нашем дизайне намного раньше в процессе проектирования.


ГДЛ


Программное обеспечение [GHDL] (https://ghdl.readthedocs.io/en/latest/index.html) представляет собой компилятор и симулятор VHDL с открытым исходным кодом, который существует уже почти 20 лет.


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


Во многих смыслах мы можем рассматривать GHDL как VHDL-эквивалент инструмента Icarus Verilog.


Мы можем использовать GHDL практически в любой операционной системе, включая Linux, Windows и macOS.


В настоящее время GHDL предлагает полную поддержку стандартов VHDL-87, 93 и 2002. Кроме того, имеется также частичная поддержка стандарта VHDL-2008.


Как и в случае с Icarus Verilog, при использовании GHDL мы не можем просматривать формы сигналов из нашей симуляции.


Однако мы можем экспортировать результат моделирования в программу GTKWave с открытым исходным кодом, когда хотим просмотреть формы волны.


GHDL — самый популярный инструмент моделирования VHDL с открытым исходным кодом. На самом деле, он настолько популярен, что даже является одним из рекомендуемых симуляторов на [игровой площадке EDA] (https://www.edaplayground.com/home).


Одной из основных причин его популярности является тот факт, что он предлагает надежную поддержку многих полезных функций VHDL-2008.


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


В дополнение к этому существует сообщество разработчиков, которое поддерживает код на [github] (https://github.com/ghdl/ghdl). В результате мы регулярно получаем новые функции и исправления ошибок для программного обеспечения.


Наконец, мы также можем использовать популярные библиотеки моделирования, такие как [UVVM] (https://github.com/UVVM/UVVM) или [OSVVM] (https://osvvm.org/) в GHDL.


Моделирование проектов с помощью GHDL


Когда мы хотим смоделировать проект с помощью GHDL, мы должны сделать три отдельных шага.


Во-первых, мы должны запустить этап анализа. Мы используем этот шаг для преобразования нашего исходного кода VHDL в формат, который используется внутри GHDL.


Фрагмент кода ниже показывает команду, которую мы используем для запуска шага анализа.


``` ударить


ghdl -a <входное_имя>


В этом примере мы используем поле , чтобы указать, какой файл VHDL мы хотим запустить анализ.


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


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


``` ударить


ghdl -e <входное_имя>


В этом примере мы используем поле , чтобы указать, какой дизайн мы хотим разработать.


Как только мы скомпилировали наш исходный код VHDL в машинный код, мы можем запустить нашу симуляцию.


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


``` ударить


ghdl -r <имя_теста>


В этом примере мы используем поле , чтобы указать, какую симуляцию мы хотим запустить.


Мы также можем пропустить сложный шаг, поскольку он также выполняется как часть команды запуска.


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


Инструменты для создания проектов FPGA


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


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


Однако большинство этих инструментов являются достаточно новыми разработками, появившимися за последние десять лет.


Несмотря на это, мы уже начали видеть, как инструменты с открытым исходным кодом находят применение у промышленных клиентов. В частности, набор инструментов для создания нескольких [Lattice FPGA] (https://hackaday.com/2015/05/29/an-open-source-toolchain-for-ice40-fpgas/) теперь полностью открыт.


В дополнение к этому крупные скоординированные проекты, такие как [symbiflow] (https://symbiflow.github.io/), помогают ускорить разработку этих инструментов.


Давайте рассмотрим некоторые из самых популярных инструментов с открытым исходным кодом, которые мы можем использовать для создания битовых потоков FPGA.


Инструмент синтеза Yosys


[Yosys] (http://www.clifford.at/yosys/about.html) — это инструмент для [синтеза] verilog с открытым исходным кодом, который поддерживает почти все функции. стандарта Verilog 2005.


Благодаря широким возможностям настройки и [расширяемости] (https://www.techopedia.com/definition/7107/extensible), Yosys является самым популярным инструментом синтеза ПЛИС с открытым исходным кодом.


Yosys на самом деле представляет собой набор связанных программных инструментов, которые можно использовать для создания полного инструмента синтеза.


В результате этого мы можем легко настроить процесс синтеза в зависимости от наших потребностей.


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


Мы используем сценарии на основе tcl для настройки потока синтеза для различных ПЛИС. Такой подход означает, что на самом деле относительно просто настроить Yosys для различных требований.


Однако мы также можем просто использовать общие потоки синтеза, когда нам требуется базовый поток синтеза.


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


После синтеза нашего дизайна с помощью Yosys мы также можем экспортировать список соединений в несколько различных форматов файлов, таких как blif, JSON или edif.


Это полезно, так как это означает, что мы можем экспортировать наш список соединений в разные инструменты места и маршрута, в зависимости от нашей конкретной цепочки инструментов.


Кроме того, мы также можем сгенерировать наш список соединений в Verilog. Это позволяет нам выполнять моделирование постсинтеза нашего дизайна.


На данный момент мы можем использовать Yosys только для синтеза ПЛИС из Lattice iCE40 или серии Xilinix 7 семейств. Однако разработчики прилагают усилия для поддержки большего количества семейств ПЛИС.


Одним из недостатков программного обеспечения для синтеза Yosys является то, что в настоящее время оно не поддерживает проекты на основе VHDL.


Однако мы можем использовать инструмент [GHDL] с открытым исходным кодом (https://ghdl.readthedocs.io/en/latest/using/Synthesis.html) в качестве интерфейса для Yosys при работе с VHDL. Этот подход означает, что мы генерируем простой список соединений с помощью GHDL, а затем используем Yosys для его оптимизации.


Единственным недостатком этого подхода является то, что поддержка синтеза в GHDL все еще является экспериментальной.


Инструмент размещения и маршрутизации VPR


Инструмент [Versatile Place and Route] (https://docs.verilogtorouting.org/en/latest/vpr/) (VPR) — это инструмент с открытым исходным кодом, который был впервые разработан в Университете Торонто более 20 лет назад. тому назад.


Мы можем использовать инструмент VPR для выполнения операций по размещению, маршрутизации и анализу нашего списка соединений.


Мы можем использовать инструменты синтеза, такие как Yosys, для создания нашего списка соединений, а затем экспортировать его в проект VPR.


В качестве альтернативы мы также можем использовать пакет [Verilog-to-Routing] (https://docs.verilogtorouting.org/en/latest/), который включает как VPR, так и отдельный инструмент синтеза.


Мы можем использовать VPR в операционных системах на базе Linux и macOS. Кроме того, мы также можем использовать cygwin для запуска VPR в Windows.


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


Это означает, что его может быть сложно использовать, когда нам нужен простой способ создания нашего кода для легкодоступных ПЛИС.


Эта функция означает, что она не совсем подходит для использования в простой цепочке инструментов VHDL/verilog-to-bitstream.


Arachne Place and Route Tool


[Инструмент Arachne PNR] (https://github.com/YosysHQ/arachne-pnr) — это инструмент с открытым исходным кодом для мест и маршрутов, впервые выпущенный в 2015 году.


Мы можем использовать Arachne для выполнения операций размещения и маршрутизации для семейства ПЛИС Lattice ice40. В настоящее время это программное обеспечение не поддерживает никакие другие семейства ПЛИС.


Arachne был первым инструментом размещения и маршрутизации с открытым исходным кодом, который использовался в цепочке инструментов verilog to bitstream для промышленных пользователей.


Хотя это стало важной вехой для инструментов FPGA с открытым исходным кодом, у этого программного обеспечения есть несколько ограничений.


Как мы уже упоминали, мы можем использовать Arachne только с семейством ПЛИС Lattice ice40.


Это означает, что мы можем использовать Arachne только с очень небольшим подмножеством устройств FPGA.


В дополнение к этому, Arachne использует алгоритм маршрутизации, не зависящий от времени. Это означает, что инструмент не отдает приоритет достижению максимальной максимальной тактовой частоты при выполнении операций размещения и маршрутизации.


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


Хотя мы все еще можем использовать Arachne, кодовая база больше не поддерживается активно. В результате мы должны использовать инструмент nextpnr, а не Arachne для новых проектов.


Nextpnr Place and Route Tool


Инструмент nextpnr — это инструмент определения местоположения и маршрута с открытым исходным кодом, который был впервые выпущен в 2018 году. Первоначально он был разработан как замена инструменту размещения и маршрута Arachne.


С момента своего выпуска он стал самым популярным инструментом для поиска мест и маршрутов с открытым исходным кодом.


Мы можем использовать nextpnr в системах на базе Windows, macOS и Linux.


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


Это может быть полезной функцией, поскольку позволяет нам легче отлаживать наш проект, визуализируя схему в FPGA.


В настоящее время nextpnr в первую очередь нацелен на ПЛИС Lattice с полной поддержкой семейств ice40, ECP5 и Nexus.


Однако в настоящее время ведется работа по поддержке большего количества FPGA в будущем, в частности семейства FPGA Xilinx 7 Series.


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


В результате мы можем достичь более высокой частоты при использовании nextpnr.


Однако недостатком этого является то, что обычно требуется больше времени для размещения и маршрутизации проекта.


Как мы уже обсуждали с Yosys, мы также можем легко расширить функциональность инструмента nextpnr, поскольку он имеет открытый исходный код.


На самом деле, это еще проще сделать с помощью nextpnr, так как он также имеет интерфейс Python.


Nextpnr в настоящее время является самым популярным инструментом для размещения и маршрутизации с открытым исходным кодом с некоторым отрывом. В результате он также используется в популярных проектах Verilog to Bitstream, таких как [symbiflow] (https://symbiflow.github.io/) и [apio] (https://github.com/FPGAwars/apio). .


Генерация битового потока


Последним этапом создания файла программирования FPGA является создание самого битового потока.


Поскольку большинство поставщиков ПЛИС держат содержимое своих битовых потоков в секрете, для создания битовых потоков доступно меньше инструментов с открытым исходным кодом.


Однако в настоящее время существует несколько проектов, целью которых является документирование формата этих битовых потоков.


На данный момент доступна полная документация для Lattice ice40 (проект icestorm) и ECP5 (проект trellis. /prjtrellis)) семейств ПЛИС.


Мы также можем использовать инструменты, включенные в эти проекты, для генерации битовых потоков, которые мы можем запрограммировать в нашу целевую ПЛИС.


Существует также некоторая документация для семейства Xilinix 7 (project x-ray), хотя в настоящее время она не завершена.


Также опубликовано здесь



Оригинал
PREVIOUS ARTICLE
NEXT ARTICLE