VHDL: numeri interi per sintesi?

Sono un po 'confuso se dovrei usare numeri interi in VHDL per segnali e porte di sintesi, ecc.

Io uso std_logic nei porti di alto livello, ma internamente io stavo usando numeri interi a distanza in tutto il luogo. Tuttavia, mi sono imbattuto in alcuni riferimenti a persone che dicevano che dovresti usare solo firmato / non firmato per il codice di sintesi.

Sono andato e rielaborato il mio progetto attuale per usare unsigned ... e, beh, è notevolmente più brutto.

È una cattiva pratica usare numeri interi? Qual è il problema? C'è qualche incertezza su quale larghezza lo strumento mapperà gli interi?

vhdl synthesis

— Darron
fonte

Buona domanda. Me lo stavo chiedendo da solo. Ho iniziato con l'utilizzo di interi, positivi e di altri tipi in tutto il luogo, ma si è rivelato molto peloso per essere sintetizzato correttamente. Spero che qualcuno possa spiegare perché tutti finiscono per usare std_logic in un linguaggio fortemente tipizzato.

— Trygve Laugstøl,

Si. Non è pazzo? Altamente tipizzato nella pratica corrente tende a provocare molti DATA_I <= TO_UNSIGNED (32010, DATA_I'LENGTH); tipo di roba ... che non disturba nessuno? :) Sembra sicuramente un sacco di bagagli inutili. (Soprattutto quando ho aggiunto STD_LOGIC_VECTOR () a questo) ho dichiarato il mio tipo e le mie dimensioni, questo dovrebbe essere DATA_I <= 32010; Questo dovrebbe essere implicito. Andare tra firmati / non firmati, ecc. Può e dovrebbe essere esplicito ... ma un'assegnazione o un'operazione diretta e inequivocabile su numeri interi dovrebbe essere implicita.

— darron,

Risposte:

I numeri interi vanno bene in sintesi, li uso sempre.

Uso std_logic alle porte di livello superiore, ma internamente stavo usando interi a distanza dappertutto

Va bene!

Attenzione:

Per prima cosa stai simulando, vero :) - I tipi interi non si "roll-over" automaticamente nella simulazione - è un errore uscire dall'intervallo specificato per loro. Se si desidera un comportamento di roll-over, è necessario codificarlo esplicitamente.
Si ipotizza che vadano da a (ovvero non l'intera gamma di un numero intero a 32 bit, non è possibile utilizzare e rimangono portatili), che è un un po 'di dolore a volte. Se devi usare numeri "grandi", dovrai usare e . $-(2^{31}-1)$ $+2^{31}-1$ $-2^{31}$ unsignedsigned
Se non li vincoli, a volte puoi finire con contatori a 32 bit dove meno farebbe (se il synth e gli strumenti successivi non possono "vedere" che potrebbero ottimizzare i bit di distanza).

Il lato positivo:

Sono molto più veloci da simulare rispetto ai vettori non firmati / firmati
Non eseguono il roll-over automatico nella simulazione (sì, è presente in entrambe le liste :). Questo è utile: ad esempio ricevi un avviso in anticipo che il tuo contatore è troppo piccolo.

Quando usi tipi di vettori, stai usando ieee.numeric_std, noieee.std_logic_arith ?

Uso integers dove posso, ma se voglio esplicitamente "contatori roll-over n-bit", tendo ad usare unsigned.

— Martin Thompson
fonte

Sì, utilizzo numeric_std. Immagino di essere principalmente preoccupato per gli strumenti Xilinx ... generano ancora std_logic_vector per tutto e "UNSIGNED" non è nemmeno nell'evidenziazione della sintassi.

— darron,

@darron Non preoccuparti dell'evidenziazione della sintassi. L'editor e il suo evidenziatore della sintassi sono un software completamente diverso dallo strumento di sintesi. Inoltre, unsigned è "solo" un tipo di dati. Fa parte di una libreria standard, non del linguaggio stesso.

— Philippe

Non è invece il limite inferiore -2 ^ 32 + 1? Se fosse -2 ^ 31 - 1 avresti bisogno di un altro bit per rappresentare un solo numero - molto strano.

— Bregalad,

@Bregalad - buona cattura - è sbagliato da un bel po '!

— Martin Thompson,

@MartinThompson O forse puoi scriverlo come - (2 ^ 32-1) se preferisci mantenere il segno meno.

— Bregalad,

Jan Decaluwe ha scritto un intero white paper sui problemi degli interi rispetto ai vettori di bit. Mi aspetto che le sue risposte sarebbero usare numeri interi ogni volta che è possibile . http://www.jandecaluwe.com/hdldesign/counting.html

— Philippe
fonte

Non c'è niente di sbagliato nell'usare numeri interi per RTL in sé , ma ci sono ragioni che alcuni lo evitano. Questa è davvero una domanda sulle "migliori pratiche" soggettive e alla fine dovrai scoprire tu stesso cosa preferisci. Come aiuto a questo, condividerò la mia esperienza e pensieri su questo.

Principalmente , sono a favore dell'uso di numeri interi (vincolati), anche quando scrivo per la sintesi. A volte lo faccio, ma in pratica , di solito mi attengo a signede unsigned. Elaborerò il perché.

Sarai costretto a utilizzare un tipo di dati vettoriali in parte del tuo progetto comunque:

Quasi nessun IP fornitore o IP di terze parti utilizzerà il integertipo per le porte
Ad esempio, quando si inviano dati tramite BlockRam, anche se lo si deduce e quindi non è mai necessario interfacciarsi con alcun IP / macro / primitiva, è molto probabile che si debba convertire comunque in tipo vettoriale
Anche se nessuna delle precedenti condizioni si applica, sarà necessario per lo più interfacciarsi con qualcos'altro ad un certo punto (una porta di livello superiore, se non altro)

Dal momento che non puoi utilizzarlo integerper il design completo, potresti voler saltare tutto insieme, perché:

In alcuni punti, dovrai comunque fare le conversioni e questo toglie parte del punto di utilizzo integerin primo luogo
Inoltre, per la simulazione, queste conversioni in genere essere chiamati con vettori di 'U'o 'X', sia prima del reset, o in altri momenti, e ogni singolo come chiamata di funzione genera un messaggio di avviso dalla funzione pacchetto, ingombrano i vostri avvisi di simulazione / pronta

Svantaggi dell'utilizzointeger :

Contrariamente ai tipi vettorializzati, i numeri interi non hanno 'U'e 'X'; Trovo che siano molto utili nelle simulazioni. Vedi come i segnali non inizializzati si propagano attraverso il design e probabilmente reagirai se vedi molti segnali non inizializzati dopo il reset. Questo non sarà il caso se si utilizzano numeri interi.
Con gli interi, esiste un rischio maggiore di errata corrispondenza di simulazione / sintesi durante l'aggiunta o la sottrazione con conseguente under / overflow. (Come già sottolineato da qualcun altro.)

Casi tipici in cui trovo integerdavvero una buona opzione:

Per segnali / contatori di debug monitorati tramite chipScope / signalTap ecc.
Rappresentazione totalmente interna di contatori, che non entrano o escono mai dal proprio codice. Sì, ci sono questi casi, ad esempio se si sta scrivendo una FIFO e si sono scrive dead-reckoning / legge per formare i segnali full, empty, almostFullecc (però aritmetica sui puntatori è un modo migliore di dead-reckoning in questo caso. ..)

Le mie conclusioni: uso numeri interi a volte, ma con parsimonia, e soprattutto nei casi sopra descritti. Non vedo molte spese generali nell'uso unsignede signedinvece dell'intero, e quindi, di solito, mi attengo a loro.

— Carl
fonte