tempistica del processo su FPGA

Sono nuovo di fpgas, e ci sono alcune sottigliezze temporali che non sono sicuro di capire: se tutti i miei processi sincroni vengono attivati ​​sullo stesso fronte, significa che i miei input vengono "catturati" su un fronte di salita, e il mio le uscite cambiano sullo stesso bordo? il prossimo fronte di salita?

se ho due moduli, in cui l'uscita di uno scorre negli ingressi del successivo, potrebbe sorgere la situazione in cui gli ingressi al mio modulo (gli output di un modulo precedente) cambiano contemporaneamente alla loro acquisizione.

Il marcatore a 205ns mostra di cosa sto parlando, op e data_write sono i miei input. Tutto sembra "funzionare" in questo caso di test, ma nella simulazione non è chiaro esattamente cosa viene catturato quando. Data_write = "0001 ..." è stato catturato a 205ns o (205ns + 1 ciclo di clock)? Esiste un modo per ottenere forme d'onda più dettagliate in ISim che mostrano i tempi di configurazione e di attesa?

Grazie.

C'è sempre qualche ritardo di propagazione attraverso il flip-flop. Viene spesso chiamato ritardo "clock-to-Q".

Ciò significa che i tuoi input vengono catturati sul bordo e le uscite cambiano sullo stesso bordo, ma solo pochi nanosecondi più tardi. Questo ritardo di pochi nanosecondi è sufficiente (se i tuoi flip-flop sono progettati con "zero hold time" come nella maggior parte degli FPGA) che le modifiche non influiscono su eventuali flip-flop a valle fino al successivo limite di clock.

Nella simulazione funzionale o RTL (che è probabilmente ciò che stai facendo per generare il tuo risultato) il ritardo non verrà simulato come nanosecondi duraturi. In VHDL, sarà un singolo ciclo delta dell'orologio del simulatore, che tecnicamente non è affatto tempo. Ciò rende impossibile vedere il ritardo nell'uscita del simulatore. Tuttavia per i flip-flop simulati come ideali, è sufficiente che i cambiamenti di output non influenzino i flip-flop a valle.

Se si esegue la simulazione post-place-and-route, dovrebbe essere in grado di includere ritardi appropriati in modo da vedere chiaramente questi effetti, a costo di un maggiore sforzo di simulazione.

Sul fronte di clock desiderato (crescente o decrescente), l'ingresso su D appare sull'uscita Q. Ciò richiede un tempo finito (ritardo da Clock a Q) e supponendo che non vi siano violazioni di temporizzazione, D passerà attraverso un solo FF alla volta (cioè se c'è un altro ingresso FF collegato a Q, il secondo FF passerà il valore FF1 Q prima che cambi.

Per includere i tempi nella simulazione, è necessario sintetizzare e posizionare e instradare il progetto, quindi eseguire un posto post e simulare l'itinerario. Ciò includerà tutti i ritardi combinativi, da clock a Q, ecc. Inclusi. La simulazione HDL non ha nessuno di questi tempi, quindi è utile solo per testare le operazioni di base, non i limiti di tempo. Riceverai anche un rapporto di temporizzazione, che ti dirà i limiti di velocità di un particolare dominio di clock, ti ​​farà sapere se ci sono violazioni di temporizzazione e ti mostrerà il rallentamento del tempo per vari percorsi. Puoi usare queste informazioni per capire dove potrebbe essere necessario creare chnages o aggiungere regole per dire al software che la violazione non è un problema (ad es. Per cose come percorsi multi-ciclo o percorsi cross clock)

Questo è inteso come un'aggiunta alle risposte precedenti, da cui credo che tu abbia avuto l'idea.

Queste questioni possono in effetti essere un po 'complicate all'inizio quando si progetta la simulazione RTL poiché si può trovare difficile vedere qual è la causa e qual è l'effetto nelle simulazioni ideali / funzionali / RTL (= nessun ritardo di propagazione).

Con il simulatore giusto, i ritardi delta possono essere effettivamente visualizzati. ISim non lo fa, ma in ei ModelSim è possibile abilitare l' espansione delta attorno ai bordi dell'orologio. Di seguito è riportato uno screenshot di esempio da un IP di terze parti difettoso che ho individuato nei problemi.

cè il segnale di clock, e +1ecc. sono i cicli delta, visualizzati come tempo.

Se un progetto viene simulato in cui sia la simulazione che il progetto sono veramente ideali e sincroni , senza simulazioni di ritardi, è possibile, in linea di principio, visualizzare tutte le variazioni del segnale su un determinato fronte di orologio che si verificano leggermente dopo quel fianco di clock. Nel tuo esempio, quindi, a 205 ns, data_write= 0000...è ciò che viene catturato. Alcuni altra logica nella prima unità sta cambiando il segnale data_writedi 0001...sullo stesso fianco, e sembra che segnale data_writeleggermente dopo fianco orologio. Questo "leggermente dopo" sarebbe uno o più delta di simulazione in una simulazione ideale (il tuo esempio) (non visibile in ISim, ma in esempio ModelSim con espansione delta), o alcuni ps / n più tardi nel mondo reale.

Una nota a margine: Una cosa importante con il design RTL è assicurarsi che gli ingressi siano sempre campionati sul fianco del clock - anche un ciclo delta più tardi è troppo tardi. L'input potrebbe non essere valido un delta dopo. O in altre parole: "non scherzare con il percorso dell'orologio".