Gibt es Open-Source-Bibliotheken für VHDL wie für C++ oder Python?

Wenn ich mich einem Problem in C++ oder Python nähere, gibt es viele Bibliotheken, die meinen Code schwer heben. Ich denke an GNU GSL , BOOST oder FFTW für C++ und NumPy oder SciPy für Python. In vielerlei Hinsicht macht die Tatsache, dass diese Ressourcen vorhanden sind, das Codieren in diesen jeweiligen Sprachen lohnenswert, da die Bibliotheken verhindern, dass Sie all die Dinge auf niedriger Ebene von Grund auf neu schreiben müssen.

Die IEEE-Standardbibliotheken scheinen nur die Grundlagen abzudecken, wie z. B. Datentypen (ähnlich wie die C-Standardbibliotheken).

Es scheint, als ob Sie in VHDL einige "IP-Kerne" kaufen / finden können, die ein Problem lösen, anstatt eine Open-Source-Bibliothek zu verwenden. Wenn ich in Python mit einem seriellen Gerät sprechen möchte, mache ich das einfach import serialund bin im Grunde fertig. In VHDL würde ich entweder feststecken, um ein serielles Protokoll von Grund auf neu zu schreiben, oder ich müsste in den verschiedenen Repositories herumgoogeln, bis ich jemanden gefunden habe, der so etwas produziert hat, das funktioniert. Ich würde dann Code-Bits in mein Projekt patchen, anstatt nur etwas einzufügen und das aufzurufen. Auf ähnliche Weise kann ich, wenn ich eine FFT durchführen möchte, Beispiele für FFTs in VHDL über Google finden, aber es gibt nichts Einfaches wie FFTW, das ich finden kann.

Gibt es umfassende Open-Source-Bibliotheken, die ich in meine Projekte importieren kann? Warum scheint jeder seinen eigenen Code für so viele der gleichen Dinge zu rollen?

Haben Sie opencores.org durchsucht?
Informationen zu VHDL-Überprüfungsbibliotheken finden Sie unter osvvm.org
Opencores können Sie auch Bibliotheken aus verschiedenen Quellen kaufen. Sie werden einige Zeit mit den meisten Kernen von Opencores verbringen, da die meisten nicht gut dokumentiert sind.

Antworten (5)

Ich bin Entwickler und Betreuer bei ' The PoC Library '. Wir versuchen, eine solche Bibliothek bereitzustellen, die aus Paketen (Sammlung neuer Typen und Funktionen) und Modulen besteht. Es kommt mit gemeinsamen Fifos, Arithmetik, Cross-Clock-Komponenten, Low-Speed-I/O-Komponenten und einem Ethernet/IP/UDP-Stack (nächste Version).

Wie @crgrace beschrieben hat, ist es ziemlich kompliziert, Module zu entwerfen, die:

  • arbeiten auf vielen Plattformen
  • unterstützen die meisten Anbieter-Toolketten
  • Fügen Sie keinen/weniger Overhead hinzu

Unsere Bibliothek verfügt über einen internen Konfigurationsmechanismus (PoC.config), um Anbieter, Geräte und sogar Geräteunterfamilien zu unterscheiden, um den richtigen Code oder eine optimierte Implementierung auszuwählen. An einigen Stellen wird auch zwischen Synthese- und Simulationscode unterschieden.

Zum Beispiel PoC.fifo_cc_gotist ein FIFO mit einer "gemeinsamen Uhr" (cc)-Schnittstelle und Put/Go-Signalen zur Steuerung des FIFO. Das Fifo ist in Breiten, Tiefen, Füllzustandsbits und Implementierungstyp konfigurierbar. Es ist möglich, einen LUT-basierten RAM- oder On-Chip-RAM (ocram)-Implementierungstyp zu wählen. Wenn dieses Fifo mit der ocram-Option für Altera synthetisiert wird, verwendet es altsyncram; Wenn Xilinx ausgewählt wird, verwendet es eine generische BlockRAM-Beschreibung und implementiert die Zeigerarithmetik durch explizite Carrychain-Instanziierung (Xilinx XST findet nicht die optimale Lösung, daher erfolgt dies manuell).

Es gibt 2 andere Fifo-Typen mit 'abhängiger Uhr' (dc) und unabhängiger Uhr (ic) Schnittstelle. Wenn es also erforderlich ist, von einem normalen Fifo zu einem Cross-Clock-Fifo (PoC.fifo_ic_got) zu wechseln, den Entitätsnamen zu ändern und eine Uhr hinzuzufügen und für die zweite Uhrendomäne zurückzusetzen, das ist alles.

Ich denke, dies beweist, dass es möglich ist, gemeinsame Module zu schreiben, die auf mehreren Plattformen funktionieren und in verschiedenen Tools kompiliert werden (Spartan-> Virtex, Cyclone -> Stratix; ISE, Vivado, Quartus).

Neben PoC gibt es noch weitere Open-Source-Bibliotheken:


Die Projekte „Discover Free and Open Source Silicon“ ( FOSSi ) auf GitHub bieten eine durchsuchbare Datenbank aller GitHub-Projekte, die hauptsächlich , , oder andere wichtige Hardwarebeschreibungssprachen ( ) verwenden.

Siehe auch:

Open-Source-Bibliotheken, wie Sie sie beschreiben, wären für VHDL oder Verilog nicht annähernd so nützlich wie für eine Programmiersprache für allgemeine Zwecke. Dies liegt daran, dass WIE Sie eine bestimmte Funktion implementieren, sehr stark davon abhängen kann, was Sie zu tun versuchen. Code, der gut für und FPGA ist, ist wahrscheinlich nicht so gut für einen ASIC und umgekehrt.

Da wir Hardware beschreiben, würde eine Funktion, die eine FFT durchführt, außerdem solche Besonderheiten wie Wortbreite und Takt- und Rücksetzstrategie erfordern, die Ihnen die Hände binden und Ihr gesamtes Design einschränken würden. Wenn Sie die Funktion sehr flexibel gestalten würden, hätte dies einen enormen Overhead.

Betrachten Sie zuletzt die Größe Ihrer ausführbaren Datei, wenn Sie beispielsweise viele Bibliotheken in C einbinden. Da gibt es eine Menge Blähungen. Das spielt für die Softwareentwicklung (meistens) keine Rolle, ist aber für die FPGA- und insbesondere die ASIC-Entwicklung sehr wichtig. Es macht keinen Sinn, einen Haufen Overhead zu synthetisieren, den Sie nicht brauchen.

Unter dem Strich gibt es also keine solchen Bibliotheken, und Ihr derzeitiger Ansatz ist solide.

Die alternativen (IP) Core-Generatoren bergen auch die Scylla- und Chabydris-Risiken einer Herstellerbindung und daraus resultierender Aufblähung. FPGA- und ASIC-Kapazitäten sind groß genug geworden, um Aufblähen zu unterstützen, das Problem waren dann Kosten und Tests, unterstützt durch Aufblähungsstandardisierung (z. B. AMBA AXI4). Der Kompromiss zwischen Markteinführungszeit und „Overhead, den Sie nicht benötigen“ wurde bereits von ganzen Branchen eingegangen. Systemdesign unter Verwendung von Bausteinen anstelle von Hardwaredesign, letzteres die Vogtei von VHDL.
Ihr dritter Absatz ist ziemlich unwissend darüber, wie Compiler und Synthesewerkzeuge funktionieren - Werkzeuge sollten die nicht benötigten Dinge und die nicht verwendeten Ergebnisse verwerfen, wahrscheinlich noch mehr in einer digitalen Logikumgebung als in einer Hochsprachenbibliothek, in der es möglicherweise einige lokale gibt Variablen und Speicherzuweisungen, die Overhead der Bibliotheksabstraktion sind, insbesondere wenn sie dynamisch verknüpft ist.

VHDL und Verilog sind beschreibende Sprachen und beschreiben Hardwareblöcke. Ein serieller Treiber in C++ kann in VHDL/Verilog in eine serielle IP übersetzt werden.

opencores.org ist die bisher größte Open-Source-Datenbank.

Um den Such-, Download- und Code-Browsing-Prozess (über Github) zu erleichtern, können Sie diese moderne Schnittstelle verwenden:

http://freerangefactory.org/cores.html

Wenn Sie beispielsweise nach Serien suchen, können Sie hier landen:

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

und direkt zum Code in GitHub springen. Dort sehen Sie, dass Sie das serielle Modul ganz einfach instanziieren und Ihre eigene Schaltung daran anschließen und mit dem Senden und Empfangen von Daten beginnen können. Das ist so einfach wie serielle Bibliotheken in C++.

Ich hoffe das hilft.

Die erste Seite, auf die ich für so etwas gehe (wie @MarkU erwähnte), ist opencores.org.

Beispielsweise gibt es eine parametrisierte FFT-Engine , die in VHDL geschrieben und unter der BSD-Lizenz veröffentlicht wurde. Der Status ist „Beta“.

das ist nicht, was der OP fragt. Er oder sie weiß, wie man sich opencores.org ansieht. Eine parametrisierte FFT-Engine ist weit davon entfernt, eine Standard-Mathematikbibliothek in Python zu importieren und zu verwenden. Aufgrund des Overheads gibt es in der Hardware keine "Middleware".

Für die Verifizierung gibt es die Open Source VHDL Verification Methodology (OSVVM).
OSVVM ist eine umfassende, fortschrittliche VHDL-Verifizierungsmethodik, die die Implementierung von funktionaler Abdeckung, eingeschränktem Zufall und intelligenter Abdeckungs-Randomisierung (einer intelligenten Testbench-Methodik) vereinfacht. Es erleichtert auch die Implementierung gemeinsam genutzter Transkriptdateien, Fehlerberichte, Protokolle (bedingtes Drucken) und Speichermodellierung.

Die Website und der Blog von OSVVM befinden sich unter http://osvvm.org . Die Pakete sind auch auf Github verfügbar unter: https://github.com/JimLewis/OSVVM