33 / 37 · Concetto

Setup, hold e bilancio temporale

Separare cammini massimi e minimi e calcolare hold indipendentemente dalla frequenza.

I dati corretti devono arrivare in tempo

Un cammino sincrono comprende flip-flop^{Flip-flop Acquisisce al fronte di clock specificato e mantiene fino al successivo. Gli ingressi devono rispettare setup e hold. Approfondisci} sorgente, logica combinatoria e flip-flop destinatario. Con skew dei clock nullo, il modello semplice impone questo setup^{Setup Tempo minimo prima del fronte di acquisizione in cui i dati devono essere stabili. Una violazione rende non garantito il valore memorizzato.}. uncertainty include prudentemente jitter e margine di progetto.

T_{clk}\ge t_{cq,\mathrm{max}}+t_{pd,\mathrm{max}}+t_{setup}+t_{uncertainty}

$t_{cq}$ è clock-to-Q, $t_{pd}$ il ritardo combinatorio massimo. La logica può usare solo il tempo restante dopo uscita del registro^{Registro Memorizza uno stato di più bit. I registri sincroni del corso acquisiscono gli ingressi specificati al fronte di clock. Approfondisci} e setup del destinatario.

Calcolare numericamente il limite del cammino

Con clock-to-Q 0.12ns, logica 1.80ns, setup 0.15ns e uncertainty 0.08ns, il periodo minimo è 2.15ns.

f_{\mathrm{max}}\le\frac{1}{2.15\ \mathrm{ns}}\approx465.1\ \mathrm{MHz}

500MHz corrispondono a 2ns: il margine setup è −0.15ns. Vale solo per quel cammino e quelle ipotesi. Garantire la frequenza reale richiede tutti i cammini, corner e vincoli pertinenti.

Seguite i ritardi sommati in serie: il totale è 2.15ns. Le frecce indicano l'ordine del bilancio, non dimensioni dei dispositivi o ritardi in scala.

Il percorso usa il budget temporale di setup

FF trasmittente: clock-to-Q: 0.12ns
Percorso combinatorio: Ritardo massimo: 1,80 ns
Vincoli di ricezione: setup: 0.15ns
Margine di progetto: uncertainty: 0.08ns

Hold riguarda il cammino più veloce

Se i nuovi dati cambiano troppo presto allo stesso fronte, invadono il tempo necessario al destinatario per mantenere il valore precedente. Con skew=0 e senza margini aggiuntivi, la condizione hold^{Tempo di hold Tempo minimo dopo il fronte di acquisizione in cui i dati devono restare stabili. Va distinto dal generico mantenimento di un valore.} semplice è:

t_{cq,\mathrm{min}}+t_{cd,\mathrm{min}}\ge t_{hold}

Con clock-to-Q minimo 0.05ns, logica minima 0.03ns e hold 0.10ns, mancano 0.02ns. Allungare il periodo non risolve questo vincolo sullo stesso fronte. Servono interventi come aggiunta di ritardo o modifica del percorso clock.

Uno skew positivo, con clock di cattura più tardo, può aiutare il setup a un ciclo e peggiorare hold. Disegnate arrivi e fronti invece di memorizzare i segni. Eccezioni multicycle o false path non devono nascondere avvisi temporali senza una reale motivazione funzionale.

Prova tu

Quale ritardo combinatorio massimo è ammesso con periodo 4ns, $t_{cq}=0.2$ ns, $t_{setup}=0.3$ ns e uncertainty=0.1ns? Passare a 8ns risolve una violazione hold?

Leggi la spiegazione

$4-0.2-0.3-0.1=3.4$ ns. I normali vincoli hold sullo stesso fronte non si risolvono allungando il periodo. Analizzate separatamente cammini minimi e arrivi del clock.