VHDL: denominazione e interpretazione dell'architettura

Nota: sto usando l'ISE di Xilinx e ho una scheda FPGA con cui lavorare (con interruttori, luci e così via), e finora ho hackerato insieme alcuni progetti semplici. Allo stesso tempo sto leggendo diversi tutorial per costruire una base per quello che sto facendo.

Ho visto varie entità e le loro architetture menzionate nei materiali di riferimento che ho passato, ma la denominazione è spesso confusa. Spesso invece di "architecture rtl of .." o "architecture strutturale of ..." vedrò "architecture foo of ..." o anche "architecture arch of ..."

Mi rendo conto (in ritardo) che il nome dell'architettura è arbitrario tanto quanto il nome dell'entità, anche se ci sono guide di stile che suggeriscono che convenzioni di denominazione più coerenti possono essere utilizzate per evitare questo problema. Questo mi porta ad alcune domande:

• Osservando un'entità, come si può determinare il modello architettonico effettivo utilizzato senza suggerimenti dal nome dell'architettura? RTL, comportamentale, strutturale ... sembrano essere abbastanza simili all'occhio del mio discente (supponendo che gli esempi che ho visto siano stati effettivamente nominati correttamente). Un esempio semplice ma ovvio sarebbe utile qui (o un puntatore a uno).

• Se si specificano più architetture per una singola entità (che capisco è possibile), si danno semplicemente alle architetture nomi diversi nello stesso file o ...?

• I nomi di architettura sono limitati a una determinata entità (vale a dire, c'è qualche problema con "namespace" usando lo stesso nome di architettura su più entità)?

Modifica: e ancora uno:

• Sembra che ci sia una distinzione tra RTL e comportamentale, ma come detto sopra non lo vedo davvero negli esempi che ho visto (spesso vedo solo una architettura definita). Un'architettura è più comune delle altre?

Quello che stavo cercando è un progetto multi-componente completo ma semplice (piccoli componenti), scritto usando le migliori pratiche (denominazione corretta, non tutte stipate in un file, ecc.) Ma devo ancora trovarne uno. Trovo molto utili esempi di progetti realizzati in modo adeguato per illuminare i principi di base e le migliori pratiche. Se conosci un simile progetto di esempio, ti sarei grato anche per un suggerimento. (Se non altro, forse una volta capito questo posso condividere uno dei miei ...)

Osservando un'entità, come si può determinare il modello architettonico effettivo utilizzato senza suggerimenti dal nome dell'architettura?

Non è possibile: quando viene istanziato o configurato , è possibile specificare l'architettura (se ce ne sono più di una tra cui scegliere) o verrà scelto un valore predefinito.

Se si specificano più architetture per una singola entità (che capisco è possibile), si danno semplicemente alle architetture nomi diversi nello stesso file o ...?

Dai loro nomi diversi. Non deve essere all'interno dello stesso file (in realtà VHDL si preoccupa molto meno di quanto potresti pensare a cosa c'è in quale file)

I nomi di architettura sono limitati a una determinata entità (vale a dire, c'è qualche problema con "namespace" usando lo stesso nome di architettura su più entità)?

Sono "collegati" a un'entità, quindi possono essere riutilizzati.

Uso spesso a1come architettura per tutto ciò che è sintetizzabile

• rtl implica un livello inferiore (per molti lettori) di quello che scrivo.
• behavioural spesso implica non sintetizzabile (per alcuni lettori)
• synth è usato dal sintetizzatore per il suo modello (altrimenti lo avrei usato)

a1 è stato finora in conflitto e non causa confusione;)

Se in realtà ho più di un'architettura, tendo a nominarli verbalmente (per esempio hard_multiplierse lut_multipliersper un filtro che istanzia - o no - blocchi MUL18).

Molto spesso hai solo un'architettura, quindi non importa. I nomi di entità valide sono molto più importanti.

Sembra che ci sia una distinzione tra RTL e comportamentale, ma come detto sopra non lo vedo davvero negli esempi che ho visto (spesso vedo solo una architettura definita). Un'architettura è più comune delle altre?

È storico - non si era in grado di sintetizzare il codice "comportamentale" (che a un certo punto includeva cose come l'aggiunta!) - quindi si è creata una versione RTL che ha istanziato additivi e simili. (Questo è quello che ho capito - ho scritto codice comportamentale (eppure ancora sintetizzabile) da quando ho iniziato VHDLing nel 1999 circa!)

Ecco i tipi di architettura:

Comportamentale:

Note generali:

• Tradizionalmente nessuna erirarchia (solo un file, nessun componente istanziato) anche se questo varia tra gli strumenti.
• Molto veloce da simulare.
• I comportamenti dei segnali sono definiti.
• Quando il comportamento è usato solo per la simulazione, può contenere codice non sintetizzabile. Il comportamento comportamentale per la sintesi deve essere naturalmente sintetizzabile.

Note specifiche per Xilinx

• Generalmente i modelli di generatori core sono file .vhd pre-sintesi

Strutturale:

Definizione generale

• Crea un'istanza dei componenti e li collega solo (gerarchici).
• Più lento da simulare che comportamentale.
• Nessuna definizione del comportamento del segnale reale al massimo livello.
• Solo codice sintetizzabile.

Xilinx note specifiche

• I modelli di generatori di base non tengono conto dei tempi.
• Generalmente i modelli di generatori core istanziano netlist post-sintesi

Quanto sopra sono fondamentalmente i due principali animali dell'architettura tradizionale. Molto comunemente viene utilizzata una definizione "mista", che contiene proprietà di entrambi.

RTL:

RTL ciò che viene effettivamente inserito nell'FPGA alla fine della giornata. Quindi questo è un codice sintetizzabile che definisce il comportamento del sistema ed è costituito da una gerarchia di codici:
gli strati inferiori saranno comportamentali sintetizzabili, in cui è definito il grintoso contenuto del comportamento del segnale e i livelli superiori saranno strutturali, in cui il componenti comportamentali sono legati insieme per creare un grande "diagramma a blocchi" di alto livello, se vuoi.

A più architetture:

Le architetture possono essere tutte in un file o in più file. L'unica cosa importante è che l'entità viene compilata per prima e che viene specificata l'architettura da utilizzare.

Questo libro è molto utile e descrive abbastanza bene questo genere di cose.

Non esiste una regola rigida e veloce su come le cose dovrebbero essere fatte in termini di modelli comportamentali e strutturali distinti o semplicemente di mescolarli. Di solito in enormi progetti di firmware (o in grandi aziende in cui il codice viene condiviso e riutilizzato) è utile distinguere tra i due per semplificare le cose, tuttavia alla fine si riduce a tutto ciò che funziona per te.

Prima di tutto, i progetti di architettura del mondo reale non possono essere rigorosamente classificati in questo modo. Perché limitarti? Potresti voler creare un'istanza di altre entità e collegarle "strutturalmente", ma aggiungi un processo o un'assegnazione concorrente qua e là per aggiungere un po 'di logica "rtl" e forse usare alcuni schemi di codifica "comportamentale" in modo che il sintetizzatore capisca alcuni dei dettagli che non ti interessano (come l'aggiunta senza l'istanza specifica di un sommatore con parametri area / pipelining / performance), tutti nella stessa architettura.

Ancora più importante, è necessario capire cosa è sintetizzabile nelle attuali tecnologie asic / fpga e cosa non lo è, e questo è indipendentemente dal modello di architettura.

Un'entità può essere implementata in più modi, anche consentendo comportamenti leggermente diversi, quindi è possibile avere più architetture per la stessa entità. Inoltre, potresti avere un'architettura solo per la simulazione (di solito non sintetizzabile) che può simulare più velocemente della versione "reale", che può rivelarsi utile quando esegui il test di grandi progetti nel loro insieme. Assegneresti a queste architetture nomi che ti aiutino a ricordare cosa li rende diversi dagli altri, e semplicemente bhv / str / rtl di solito non è abbastanza o preciso, data la natura ibrida dei progetti del mondo reale.

Per quanto riguarda le vostre domande specifiche, la dichiarazione di architettura è legata al nome di un'entità, quindi non ci sono problemi di spazio dei nomi con architetture con lo stesso nome per entità diverse. Usa solo nomi diversi per architetture per la stessa entità.

Le architetture possono risiedere in file diversi, è sufficiente assicurarsi che la dichiarazione dell'entità sia compilata per prima.

È possibile selezionare quale architettura utilizzare quando si crea un'istanza dell'entità o si utilizzano le istruzioni di configurazione. In caso contrario, l'impostazione predefinita è "di solito" l'ultima architettura visualizzata dal compilatore per una determinata dichiarazione di entità.