Esistono librerie open source per VHDL come fanno per C ++ o Python?


11

Quando mi sto avvicinando a un problema in C ++ o Python, esistono molte librerie che fanno il pesante sollevamento del mio codice. Sto pensando a GNU GSL , BOOST o FFTW per C ++ e NumPy o SciPy per Python. In molti modi, il fatto che esistano queste risorse rende utile la codifica in queste rispettive lingue, poiché le librerie ti impediscono di dover riscrivere tutte le cose di basso livello da zero.

Le librerie standard IEEE sembrano coprire solo le basi, come i tipi di dati (simili alle librerie C standard).

Sembra che in VHDL, è possibile acquistare / trovare alcuni "core IP" che risolveranno un problema, piuttosto che utilizzare una libreria open source. In Python, se voglio parlare con un dispositivo seriale, lo faccio import seriale ho praticamente finito. In VHDL sarei bloccato a scrivere un protocollo seriale da zero, o dovrei cercare su Google nei vari repository finché non trovassi qualcuno che aveva prodotto qualcosa del genere. Vorrei quindi patchare frammenti di codice nel mio progetto, piuttosto che includere semplicemente qualcosa e chiamarlo. In modo simile, se voglio eseguire una FFT, posso trovare esempi di FFT in VHDL tramite Google, ma non c'è qualcosa di semplice come FFTW che posso trovare.

Sono disponibili librerie open source complete che posso importare nei miei progetti? Perché tutti sembrano avere il proprio codice per tante delle stesse cose?


2
Hai cercato opencores.org?
MarkU,

3
Per le librerie di verifica VHDL, vedere osvvm.org
Jim Lewis,

Opencores, puoi anche acquistare librerie da varie fonti. Passerai un po 'di tempo con la maggior parte dei core degli opencores poiché la maggior parte non è ben documentata.
Voltage Spike,

Risposte:


14

Sono sviluppatore e manutentore di " The PoC Library ". Cerchiamo di fornire tale libreria composta da pacchetti (raccolta di nuovi tipi e funzioni) e moduli. Viene fornito con quindici comuni, aritmetica, componenti cross-clock, componenti I / O a bassa velocità e uno stack Ethernet / IP / UDP (prossima versione).

Come descritto da @crgrace, è abbastanza complicato progettare moduli, che:

  • lavorare su molte piattaforme
  • supporta la maggior parte delle catene di strumenti del fornitore
  • aggiungere nessun / meno sovraccarico

La nostra libreria ha un meccanismo di configurazione interno (PoC.config) per distinguere i fornitori, i dispositivi e persino le sottofamiglie dei dispositivi per scegliere il codice giusto o un'implementazione ottimizzata. Distingue anche in alcuni punti tra sintesi e codice di simulazione.

Ad esempio PoC.fifo_cc_gotè un FIFO con un'interfaccia 'common clock' (cc) e segnali put / got per controllare il fifo. Il fifo è configurabile in larghezze, profondità, bit di stato di riempimento e tipo di implementazione. È possibile scegliere un tipo di implementazione RAM basata su LUT o On-Chip-RAM (ocram). Se questo fifo è sintetizzato con l'opzione ocram per Altera, usa altsyncram; se viene scelto Xilinx, utilizza una descrizione BlockRAM generica e implementa l'aritmetica del puntatore mediante un'istanza di carrychain esplicita (Xilinx XST non trova la soluzione ottimale, quindi viene eseguita manualmente).

Esistono altri 2 tipi di Fifo con interfaccia 'orologio dipendente' (cc) e orologio indipendente (ic). Quindi, se è necessario passare da un FIFO normale a un FIFO cross-clock (PoC.fifo_ic_got), modificare il nome dell'entità e aggiungere un orologio e reimpostare per il secondo dominio di clock, tutto qui.

Penso che ciò provi, è possibile scrivere moduli comuni, che funzionano su più piattaforme e compilano in diversi strumenti (Spartan-> Virtex, Ciclone -> Stratix; ISE, Vivado, Quartus).

Oltre a PoC, ci sono altre librerie open source:


I ( "Discover libero e open source Silicon" Fossi ) progetti su GitHub offre una banca dati consultabile di tutti i progetti GitHub che utilizzano principalmente , , , o qualsiasi altro importante linguaggio di descrizione dell'hardware ( ).

Guarda anche:


+1 per mostrare ciò che hai fatto e anche quello che hanno fatto gli altri. Buona lista lunga.
Mister Mystère,

3

Le librerie open source come la descrivi non sarebbero altrettanto utili per VHDL o Verilog come lo sono per un linguaggio di programmazione generico. Questo perché il modo in cui implementate una determinata funzione può molto a seconda di cosa state cercando di fare. Il codice che è buono per e FPGA probabilmente non è così buono per un ASIC e viceversa.

Inoltre, poiché stiamo descrivendo l'hardware, una funzione che esegue una FFT richiederebbe specifiche come larghezza delle parole e clock e strategia di ripristino che legherebbe le mani e vincolerebbe l'intero progetto. Se rendessi la funzione molto flessibile, avrebbe un enorme sovraccarico.

Infine, guarda la dimensione del tuo eseguibile quando includi molte librerie in C, per esempio. C'è un sacco di gonfiore lì. Questo non ha importanza per lo sviluppo del software (la maggior parte delle volte) ma conta molto per lo sviluppo di FPGA e in particolare di ASIC. Non ha senso sintetizzare un mucchio di spese generali non necessarie.

Quindi la linea di fondo è che non ci sono tali librerie e il tuo approccio attuale è valido.


I generatori di core alternativi (IP) forniscono anche i rischi di Scilla e Chabydris di blocco del fornitore e conseguente gonfia. Le capacità di FPGA e ASIC sono cresciute abbastanza grande da supportare il gonfiamento, il problema quindi i costi e i test, aiutati dalla standardizzazione del gonfiamento (ad esempio AMBA AXI4). Il trade off Time To Market rispetto a "overhead you not need" è già stato realizzato da interi settori. Progettazione del sistema utilizzando blocchi di costruzione anziché progettazione hardware, quest'ultimo il baliato di VHDL.
user8352,

Il tuo terzo paragrafo è abbastanza ignorante su come funzionano i compilatori e gli strumenti di sintesi: gli strumenti dovrebbero scartare le cose non necessarie e i risultati non utilizzati, probabilmente anche più in un'impostazione di logica digitale che in una biblioteca di lingue di alto livello, dove potrebbero esserci alcuni locali variabili e allocazioni di memoria che sono sovraccarico dell'astrazione della libreria, specialmente se è collegata dinamicamente.
Chris Stratton,

2

VHDL e Verilog sono linguaggi descrittivi e descrivono blocchi hardware. Un driver seriale in C ++ potrebbe tradursi in un IP seriale in VHDL / Verilog.

opencores.org è il più grande database open source fino ad oggi.

Per facilitare il processo di ricerca, download e navigazione del codice (tramite Github) puoi utilizzare questa moderna interfaccia:

http://freerangefactory.org/cores.html

Se, ad esempio, cerchi un seriale, puoi finire qui:

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

e passa direttamente al codice in GitHub. Lì vedrai che puoi istanziare abbastanza facilmente il modulo seriale e collegare il tuo circuito ad esso e iniziare a inviare e ricevere dati. Questo è semplice come le librerie seriali in C ++.

Spero che possa aiutare.


0

Il primo sito a cui vado per questo genere di cose (come menzionato @MarkU) è opencores.org.

Ad esempio, esiste un motore FFT con parametri , scritto in VHDL, rilasciato sotto licenza BSD. Lo stato è "beta".


non è quello che chiede l'OP. Conosce opencores.org. Un motore FFT con parametri è molto lontano dall'importazione e dall'utilizzo di una libreria matematica standard in Python. Non esiste un "middleware" nell'hardware a causa del sovraccarico.
crgrace

0

Per la verifica, esiste una metodologia di verifica VHDL open source (OSVVM).
OSVVM è una metodologia di verifica VHDL completa e avanzata che semplifica l'implementazione di copertura funzionale, random random vincolato e randomizzazione della copertura intelligente (una metodologia di testbench intelligente). Facilita inoltre l'implementazione di file di trascrizione condivisi, la segnalazione degli errori, i registri (stampa condizionale) e la modellazione della memoria.

Il sito Web e il blog di OSVVM sono disponibili all'indirizzo http://osvvm.org . I pacchetti sono disponibili anche su github all'indirizzo: https://github.com/JimLewis/OSVVM

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.