Существуют ли библиотеки с открытым исходным кодом для VHDL, как для C ++ или python?

11

Когда я подхожу к проблеме в C ++ или python, существует много библиотек, которые выполняют тяжелую работу над моим кодом. Я думаю о GNU GSL , BOOST или FFTW для C ++ и NumPy или SciPy для Python. Во многих отношениях тот факт, что эти ресурсы существуют, делает кодирование на этих соответствующих языках полезным, поскольку библиотеки не позволяют вам переписывать все низкоуровневые вещи с нуля.

Стандартные библиотеки IEEE, кажется, охватывают только самые основы, такие как типы данных (что-то вроде стандартных библиотек C).

Похоже, что в VHDL вы можете купить / найти некоторые «IP-ядра», которые решат проблему, вместо использования библиотеки с открытым исходным кодом. В Python, если я хочу поговорить с последовательным устройством, я просто import serialи я в основном закончил. В VHDL я либо застрял бы в написании последовательного протокола с нуля, либо мне пришлось бы гуглить по различным репозиториям, пока я не нашел кого-то, кто произвел что-то подобное. Я бы тогда вставлял кусочки кода в свой проект, а не просто включал что-то и вызывал это. Аналогичным образом, если я хочу выполнить БПФ, я могу найти примеры БПФ в VHDL через Google, но не существует чего-то простого, такого как FFTW, которое я могу найти.

Существуют ли какие-либо всеобъемлющие библиотеки с открытым исходным кодом, которые я могу импортировать в свои проекты? Почему каждый, кажется, катит свой собственный код для стольких вещей?

Сэм
источник
2
Вы искали opencores.org?
MarkU
3
Для библиотек проверки VHDL, смотрите osvvm.org
Джим Льюис
Opencores, вы также можете купить библиотеки из разных источников. Вы проведете некоторое время с большинством ядер opencore, так как большинство из них не документированы.
напряжения

Ответы:

14

Я разработчик и сопровождающий в библиотеке PoC . Мы стараемся предоставить такую ​​библиотеку, состоящую из пакетов (коллекция новых типов и функций) и модулей. Он поставляется с обычными вычислениями, арифметикой, кросс-тактовыми компонентами, низкоскоростными компонентами ввода-вывода и стеком Ethernet / IP / UDP (следующий выпуск).

Как описано в @crgrace, довольно сложно создавать модули, которые:

  • работать на многих платформах
  • поддержка большинства цепочек инструментов поставщиков
  • добавить нет / меньше накладных

Наша библиотека имеет внутренний механизм настройки (PoC.config), позволяющий различать поставщиков, устройства и даже подсемейства устройств, чтобы выбрать правильный код или оптимизированную реализацию. Он также различает синтез и код моделирования в некоторых точках.

Например, PoC.fifo_cc_gotFIFO с интерфейсом «общие часы» (cc) и положил / получил сигналы для управления fifo. Fifo настраивается по ширине, глубине, битам состояния заполнения и типу реализации. Можно выбрать тип реализации RAM на основе LUT или On-Chip-RAM (ocram). Если этот fifo синтезирован с опцией ocram для Altera, он использует altsyncram; если выбран Xilinx, он использует общее описание BlockRAM и реализует арифметику указателей с помощью явной инстанцирования переноса (Xilinx XST не находит оптимального решения, поэтому это делается вручную).

Есть 2 других типа fifo с интерфейсом «зависимые часы» (dc) и независимые часы (ic). Поэтому, если требуется переключиться с обычного fifo на поперечный fifo (PoC.fifo_ic_got), измените имя объекта, добавьте часы и выполните сброс для второго домена часов, вот и все.

Я думаю, это доказывает, что можно писать общие модули, которые работают на разных платформах и компилируются в разных инструментах (Spartan-> Virtex, Cyclone -> Stratix; ISE, Vivado, Quartus).

Помимо PoC, есть и другие библиотеки с открытым исходным кодом:


В «Discover Free и Open Source Кремний» ( Fossi проекты) на GitHub предлагает просматриваемую базу данных всех проектов GitHub , которые в основном используют , , или любой другой важный язык описания аппаратных средств ( ).

Смотрите также:

Paebbels
источник
+1 за показ того, что вы сделали, а также то, что сделали другие. Хороший длинный список.
Мистер Мистер
3

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

Кроме того, поскольку мы описываем аппаратное обеспечение, функция, которая выполняет БПФ, потребует такой специфики, как ширина слова и тактовая частота и стратегия сброса, чтобы связать вам руки и ограничить весь ваш дизайн. Если бы вы сделали функцию очень гибкой, это привело бы к огромным накладным расходам.

Наконец, посмотрите на размер вашего исполняемого файла, например, когда вы включаете много библиотек в C. Там есть куча раздувания. Это не имеет значения для разработки программного обеспечения (большую часть времени), но очень важно для FPGA и особенно для разработки ASIC. Нет смысла синтезировать кучу накладных расходов, которые вам не нужны.

Итак, суть в том, что таких библиотек нет, и ваш нынешний подход обоснован.

crgrace
источник
Альтернативные (IP) генераторы ядра также обеспечивают риски Scylla и Chabydris, связанные с блокировкой поставщика и последующим вздутием. Емкости FPGA и ASIC выросли достаточно, чтобы поддерживать раздувание, затем проблему и стоимость тестирования, чему помогает стандартизация раздувания (например, AMBA AXI4). Компромисс Time To Market и «накладные расходы не нужны» уже достигнут целыми отраслями. Проектирование системы с использованием строительных блоков вместо аппаратного дизайна, последнее из которых Vails Vail.
user8352
Ваш третий абзац совершенно не осведомлен о том, как работают компиляторы и инструменты синтеза - инструменты должны отбрасывать ненужные вещи и неиспользуемые результаты, вероятно, даже в большей степени в условиях цифровой логики, чем в высокоуровневой языковой библиотеке, где могут быть некоторые локальные Переменные и выделения памяти, которые являются накладными расходами на абстракцию библиотеки, особенно если она динамически связана.
Крис Страттон
2

VHDL и Verilog являются описательными языками и описывают аппаратные блоки. Последовательный драйвер в C ++ может переводиться в Serial IP в VHDL / Verilog.

opencores.org - самая большая на сегодняшний день база данных с открытым исходным кодом.

Для облегчения процесса поиска, загрузки и просмотра кода (через Github) вы можете использовать этот современный интерфейс:

http://freerangefactory.org/cores.html

Если, например, вы ищете серийный номер, вы можете оказаться здесь:

http://freerangefactory.org/cores/communication_controller/serial_uart_2/index.html

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

Надеюсь, это поможет.

Фабрицио
источник
0

Первый сайт, на который я захожу для такого рода вещей (как упомянул @MarkU) - opencores.org.

Например, существует параметризованный механизм FFT , написанный на VHDL, выпущенный по лицензии BSD. Статус «бета».

Спехро Пефхани
источник
это не то, что спрашивают ОП. Он или она знает о взгляде на opencores.org. Параметризованный FFT-движок далек от импорта стандартной математической библиотеки в Python и ее использования. В оборудовании нет такого понятия, как «промежуточное ПО» из-за накладных расходов.
crgrace
0

Для проверки существует методология проверки VHDL с открытым исходным кодом (OSVVM).
OSVVM - это комплексная, продвинутая методология проверки VHDL, которая упрощает реализацию функционального покрытия, случайного ограничения и интеллектуальной рандомизации покрытия (интеллектуальная методология испытательного стенда). Это также облегчает реализацию общих файлов стенограммы, отчетов об ошибках, журналов (условной печати) и моделирования памяти.

Сайт и блог OSVVM находятся по адресу http://osvvm.org . Пакеты также доступны на github по адресу: https://github.com/JimLewis/OSVVM

Джим Льюис
источник