33 / 37 · Concept

Setup, hold et budget temporel

Séparer chemins maximaux et minimaux et calculer hold indépendamment de la fréquence.

Une fonction correcte doit aussi arriver à temps

Un chemin synchrone relie bascule émettrice^{Bascule Élément capturant l'entrée au front d'horloge spécifié et la conservant jusqu'au suivant. L'entrée doit respecter setup et hold. En savoir plus} → logique combinatoire → bascule réceptrice. Avec un skew nul entre horloges, la condition setup^{Setup Durée minimale de stabilité de la donnée avant le front de capture. En cas de violation, le résultat mémorisé n'est pas garanti.} simplifiée est la suivante. uncertainty représente de manière prudente la gigue et les marges de conception.

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

$t_{cq}$ est clock-to-Q et $t_{pd}$ le retard combinatoire maximal. Seule la période restante après sortie du registre^{Registre Circuit stockant plusieurs bits d'état. Les registres synchrones du cours capturent leur entrée définie sur un front d'horloge. En savoir plus} et réserve setup est disponible pour la logique.

Calcul numérique d'une limite de chemin

Avec clock-to-Q=0.12ns, logique=1.80ns, setup=0.15ns et uncertainty=0.08ns, la période minimale vaut 2.15ns.

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

500MHz correspond à 2ns, donc une marge setup de −0.15ns. Ce calcul porte sur un chemin et des hypothèses donnés ; garantir la fréquence réelle exige l'analyse de tous les chemins, coins et contraintes pertinents.

Suivez les termes additionnés en série : leur somme est 2.15ns. Les flèches indiquent l'ordre du budget, pas la taille des composants ni leurs retards relatifs.

Chemin consommant le budget de setup

FF émettrice: clock-to-Q : 0.12ns
Chemin combinatoire: Retard maximal : 1.80ns
Conditions de réception: setup : 0.15ns
Marge de conception: Incertitude : 0.08ns

Hold concerne le chemin le plus rapide

Si la donnée émise change trop vite sur le même front, elle empiète sur le temps nécessaire au récepteur pour capturer l'ancienne valeur. Avec skew=0 et sans autre marge, la condition hold^{Temps hold Durée minimale de stabilité des données après le front de capture. À distinguer du maintien ordinaire d'une valeur selon le contexte.} est :

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

Avec clock-to-Q minimal=0.05ns, logique minimale=0.03ns et hold=0.10ns, il manque 0.02ns. Allonger la période ne résout pas cette contrainte liée au même front. Il faut une correction d'implémentation, telle qu'ajouter du retard ou ajuster le chemin d'horloge.

Un skew positif, où l'horloge de capture arrive après celle de lancement, peut aider setup sur un cycle et nuire à hold. Tracez arrivées et fronts plutôt que de mémoriser les signes. N'utilisez pas multicycle ou false path pour supprimer un avertissement sans justification fonctionnelle réelle.

Essayez vous-même

Avec période=4ns, $t_{cq}=0.2$ ns, $t_{setup}=0.3$ ns et uncertainty=0.1ns, quel retard combinatoire maximal est permis ? Passer à 8ns corrige-t-il hold ?

Lire l’explication

Le retard maximal autorisé vaut $4-0.2-0.3-0.1=3.4$ ns. Une violation hold classique sur le même front n'est pas corrigée par une période plus longue ; analysez le chemin de données minimal et les arrivées d'horloge séparément.