Calcul des contraintes de temps pour les FPGA en langage simple

Bonjour. Cet article est écrit pour les très, très débutants dans le monde des FPGA, qui ne savent pas encore ce qu'est STA (analyse de synchronisation statique). Dans ce document, j'essaierai d'expliquer aussi simplement et clairement que possible quelles contraintes de timing sont imposées aux projets de FPGA.



L'article a été créé sur la base de ma propre expérience de tentatives d'expliquer ce sujet à moi-même, aux étudiants-stagiaires et aux collègues curieux afin de ne pas plonger dans une jungle académique abstruse, mais aussi simplement et de manière transparente que possible, dans le langage courant. J'ai appris à travailler avec des FPGA sans étude ni formation sur ce sujet, et je sais par ma propre expérience à quel point il est difficile de comprendre quelque chose sans base théorique dans ce sujet et dans les circuits. Pour un éleveur expérimenté, ce qui précède est élémentaire. Mais pour certains étudiants de quatrième année, l'article sera utile et aidera à comprendre tous ces slacks, configurations et prises.



Dans l'article, j'utiliserai des termes avec leur version anglaise dupliquée entre parenthèses. Cela est dû au fait qu’une terminologie unifiée n’a pas été établie et qu’avec la duplication, il est plus facile de comprendre quel concept est discuté et, si nécessaire, de trouver des informations à ce sujet dans des sources en anglais.

introduction

Je donnerai une brève introduction dans le langage des concepts simples.



Pour que quelque chose fonctionne dans le FPGA, vous devez y charger (remplir, coudre) le fichier du micrologiciel à l'aide du programmeur et de l'utilitaire du micrologiciel. Le fichier du micrologiciel est le produit d'une compilation CAO d'un certain projet - des dossiers contenant des fichiers, dont chacun décrit un aspect du projet. Dans les cas simples, l'utilisateur ne décrit lui-même que les fichiers avec le code source, un fichier avec un brochage et un fichier avec des restrictions de temps. Le reste des fichiers est géré discrètement par la CAO. De ce trièdre, seul le fichier de contraintes de temps est formellement facultatif.partie du projet. En fait, si votre projet ne contient pas de fréquences supérieures à 30-50 MHz, il est probable qu'il puisse fonctionner d'une manière ou d'une autre sans ce fichier. Cette option est appropriée pour la facilité de création des tout premiers projets éducatifs. Cependant, si votre projet de formation contient déjà des fréquences d'horloge élevées et n'est pas équipé d'un fichier de contraintes de temps, le traitement des données sera probablement perturbé quelque part à l'intérieur du FPGA et vous ne pourrez pas savoir à quel point du projet. Quant au travail, pas à l'étude, la description du dossier complet des restrictions est strictement requise . Il est de votre responsabilité de vérifier et valider la fonctionnalité de votre projet.



Le compilateur place votre projet sur la puce FPGA, reçoit un fichier de connexions de tous les éléments physiques. L'analyseur de synchronisation utilise le fichier de connexion pour calculer toutes les durées des transferts de données vers le FPGA. Ces durées ne doivent pas être infiniment longues ou trop courtes. Le fichier des contraintes de temps indique à l'analyseur dans quelle trame ces durées doivent être. En utilisant les résultats de l'analyse temporelle, le développeur peut voir dans quelles parties du projet il y a une marge dans le temps, et donc en fréquence, et où il n'y a pas de telle marge.



Les systèmes synchrones synchronisent le travail de traitement des données à l'aide de signaux d'horloge de synchronisation, qui dans le jargon sont brièvement appelés horloges de l' horloge anglaise... Les résultats intermédiaires des opérations sont stockés dans des registres capables de mémoriser l'état en entrée au moment de l'arrivée du front du signal d'horloge et de le maintenir en sortie jusqu'au prochain cycle d'horloge.



Ainsi, les circuits synchrones sont constitués de transferts de données inter- registres ( RTL, logique de transfert de registre, transfert r2r ). Et un aspect clé de l'analyse temporelle consiste à mesurer Slack ( slack ). Ce mot se traduit littéralement par «réserve de temps», «affaissement», mais dans l'environnement russophone, le papier calque de l'anglais est souvent utilisé - «mou». Dans les transferts inter-registres, nous parlons de slacks prédéfinis ( Setup ) et hold slacks ( Hold ).

Transfert inter-registres

Le transfert inter-registres (Fig. 1) est considéré comme un système de deux registres connectés séquentiellement qui fonctionnent sur des horloges synchrones dans le cas général. Dans le cas simple, sur un lambeau. Un registre joue le rôle de la source (source) et l'autre le rôle du récepteur des données (destination). Et lors du prochain transfert inter-registres, ce registre récepteur sera déjà considéré comme la source, etc. Entre les registres sur le chemin de données se trouve une logique combinatoire arbitraire définie par l'utilisateur. Il est asynchrone car il ne possède pas d'éléments de mémoire avec un signal de synchronisation, comme les registres. Cette logique est ce comportement, ces opérations logiques que l'utilisateur décrit avec son code. Les registres sont ces "variables" d'un bit que l'utilisateur donne des noms dans le code et opèrent séparément,ou en combinant des vecteurs et des tableaux.





Figure: 1. Schéma de transfert de données d'un registre à l'autre



Il existe deux concepts associés à la réception de données par le registre récepteur: le temps de configuration et le temps de maintien. Ils décrivent la plage de temps pendant laquelle le signal à l'entrée du récepteur doit être stable et pertinent. Stable - signifie essentiellement que sa tension doit être très proche de l'un des deux états logiques - "0" ou "1", et ne pas se balancer entre eux avec un risque de confusion. Pertinent - signifie que ce bit d'information doit être lié de manière significative à cette horloge de l'horloge qui la capturera, et non à un bit tardif de l'horloge précédente.



Heure de configuration - heure prédéfinie, la durée minimale pendant laquelle, avant l'arrivée du front d'horloge, le signal de données doit déjà être établi dans un état stable.



Temps de maintien - le temps de maintien, le temps minimum après l'arrivée du front d'horloge, le signal de données doit toujours être maintenu dans un état stable.



Autrement dit, les données à l'entrée du récepteur doivent être stables et à jour non seulement au moment de l'arrivée du front d'horloge, mais également pendant un certain intervalle de temps de protection autour de lui (Fig.2), avec une durée d'au moins Setup_time + Hold_time. Si la condition de stabilité des données est remplie pendant cet intervalle, le registre pourra certainement capturer les données entrantes sans erreur, sinon personne ne garantit qu'il n'y aura pas de panne.





Figure: 2.Setup Time et Hold time comme intervalle de garde autour du bord de capture à l'entrée d'horloge du registre



Les valeurs de temps de configuration et de temps de maintien sont strictement définies par le fabricant du FPGA. Ils dépendent de la technologie de production du cristal et sont considérés comme des constantes d'analyse, les mêmes pour chaque registre du cristal. Dans tous les cas, ces valeurs ne dépendent en aucun cas de l'utilisateur; leur comptabilité est une tâche réservée à l'utilitaire d'analyse du temps. Il n'est pas important pour nous de savoir à quoi ils sont égaux, il est important pour nous seulement de savoir qu'ils existent et ne sont pas égaux à zéro.



L'essence de l'analyse temporelle est de calculer les écarts pour chaque paire de registres du projet, entre lesquels il y a un transfert de données, que les données doivent être stables pendant l'intervalle de garde. Il existe de nombreuses paires r2r de ce type dans le projet, des milliers, voire des millions, mais chacune d'elles doit être analysée afin de s'assurer que le projet fonctionne.



Il existe également deux slacks, respectivement - Setup Slack et Hold Slack (Fig. 3).



Setup Slack caractérise la marge de temps dont disposent les données entre le moment de la stabilisation et le début de l'intervalle de temps Setup.



Hold Slack caractérise la marge de temps dont disposent les données à partir de la fin de l'intervalle de temps Hold jusqu'à ce que les données perdent leur stabilité.



Les slacks doivent être positifs. Si la marge est négative, la condition de stabilité des données d'entrée n'est pas remplie et les données battent. Plus il y a de mou - mieux c'est, mais vous devez comprendre que sur chaque destinataire de registre, ses slacks de présélection et de maintien ont un temps commun pour deux. Cela signifie qu'une augmentation d'un relâchement entraîne toujours une diminution de l'autre. Par conséquent, la meilleure option est lorsque les deux slacks sont positifs et approximativement égaux l'un à l'autre, c.-à-d. l'équilibre des slacks est observé.





Figure: 3. Slacks positifs, la condition pour une réception réussie des données est remplie, mais il n'y a pas d'équilibre entre les slacks

Calcul de la marge

Passons maintenant à la façon dont ces écarts sont calculés. Commençons par Setup Slack.

Considérez le schéma de transfert de données de la Fig. 4.





Fig. 4. Schéma de transfert de données



Ici, nous introduisons des concepts tels que le front de déclenchement, le front de capture, l'heure d'arrivée des données, le temps d'attente des données et l'heure d'arrivée de l'horloge.



Le Launch Edge est l'avant de l'horloge qui est venu à l'entrée du registre source et a commencé le processus de transfert de données.



Le bord de verrouillage est le front d'horloge qui arrive au registre de réception et le force à saisir des données en entrée.



Le moment d'arrivée des données ( Data Arrival Time ) est défini comme l'arrivée effective des données au registre de réception.



Le temps requis pour les données est défini comme le temps nécessaire pour que les données atteignent la destination avant l'heure prédéfinie sur le registre de destination.



L'heure d'arrivée d'une horloge ( Clock Arrival Time ) est définie comme l'heure de passage du front de la capture de l'entrée d'horloge de l'ensemble du circuit à l'entrée d'horloge du récepteur. De plus, le front de capture signifie le front suivant après le front de lancement. Le front de lancement envoie les données de la source au destinataire, et après une période d'horloge, le front de capture capture ces données du côté du destinataire.

L'entrée d'horloge de l'ensemble du circuit est comprise comme un point unique à partir duquel l'horloge diverge vers tous les registres qui y fonctionnent. Il s'agit généralement de la sortie du tampon d'horloge global ou de la sortie de la PLL. Dans le cas le plus primitif, il s'agit de la branche FPGA, à laquelle le générateur d'horloge est connecté.



Les termes impliqués dans l'analyse temporelle peuvent ne pas avoir une valeur ponctuelle, mais une certaine plage de valeurs possibles, en fonction de la trace de conception et de la température du cristal. Par conséquent, la plus mauvaise marge est analysée. L'échange de données est considéré comme réussi si, même dans les pires conditions de mou, il reste positif.



Quel est le lien entre le moment de l'arrivée des données et le front de déclenchement?



Nous considérons l'arrivée de données comme passant par une chaîne avec un registre d'un événement, initié par un front de déclenchement.



Le front de déclenchement apparaît à l'entrée d'horloge du système, puis il atteint l'entrée du registre source pendant un certain temps, puis pendant un certain temps ce registre est déclenché et envoie de nouvelles données à la sortie, puis ces données passent par les circuits logiques de combinaison vers le registre de réception. La variante la plus mauvaise et la plus lente du passage des données est considérée, donc les termes sont accompagnés du préfixe "max".

$$

$$\max Data Arrival Time = Launch Edge + \max t_{CLK} + t_{CO} + \max t_D$$

Dans cette formule, le terme pour le front de déclenchement porte la signification du point de référence par rapport auquel les événements se développent, et non une valeur mesurée en nanosecondes.



Terme$$$\max t_{CLK}$Est le temps maximum nécessaire pour que le front de déclenchement passe de l'entrée d'horloge de l'ensemble du circuit à l'entrée d'horloge de la source. En règle générale, l'analyseur prend simplement la plage de temps allant de «exactement pas moins que» à «exactement pas plus que» et remplace la borne supérieure «certainement pas plus que» dans cette formule. Cette valeur est indépendante de l'utilisateur. Le compilateur décide par lui-même où placer le registre sur le cristal et prend en compte le temps nécessaire à l'horloge pour s'y rendre. Le réseau de connexions à travers lequel le signal d'horloge diverge de la mémoire tampon d'horloge globale vers les registres est conçu de sorte que le signal d'horloge atteigne n'importe quel registre dans presque le même laps de temps. Par conséquent, en fait, la différence entre$$$\max t_{CLK}$ et $$$\min t_{CLK}$extrêmement petit, mais toujours pris en compte.



Terme$$$t_{CO}$- c'est le temps d' horloge à sortie , que le registre passe à voir le front à l'entrée d'horloge changer les données à sa sortie. L'analyseur considère que cette valeur est égale pour tous les registres de la puce. Cette valeur est indépendante de l'utilisateur.



Le dernier terme$$$\max t_D$Est le temps maximum pour qu'un événement (données) passe par la logique de combinaison entre les registres, qui est défini par l'utilisateur. Cette valeur dépend fortement de l'utilisateur. Il exprime la quantité de logique combinatoire entre les registres. À leur tour, les longues chaînes de logique combinatoire sont souvent le résultat d'un codage imprécis par l'utilisateur.



Le moment où le lambeau arrive chez le destinataire est plus facile à calculer:

$$

$$\min Clock Arrival Time = Latch Edge + \min t_{CLK}'$$

Il s'agit du premier moment auquel le front de capture atteint l'entrée d'horloge du registre de réception.

Terme$$$\min t_{CLK}'$- c'est le temps minimum pendant lequel le front de capture atteindra l'entrée d'horloge du destinataire, c'est-à-dire que, par analogie avec la formule précédente, ce temps n'est "certainement pas inférieur à". Le tiret dans ce cas signifie que nous parlons de l'entrée d'horloge du destinataire, pas de la source.



Le temps d'attente des données est défini comme le temps nécessaire aux données pour atteindre le récepteur avant l'heure prédéfinie sur le registre du récepteur:

$$

$$\min Data Required Time = \min Clock Arrival Time – t_{SU} – CSU$$

Terme $$$t_{SU}$- nous connaissons déjà l'heure de configuration, qui est considérée comme la même pour chaque registre sur le cristal. Cette heure est indépendante de l'utilisateur.



Terme$$$CSU$Est l' incertitude de configuration de l'horloge , incertitude de temps prédéfinie. Comme toute autre incertitude dans l'analyse temporelle d'une CSU, ce n'est pas un processus physique, mais un moyen de refléter l'influence de la gigue dans l'analyse, ou simplement un moyen d'introduire un temps de garde dans l'analyse au cas où. En termes simples, c'est une marge de temps pour prendre en compte des processus difficiles.



Maintenant que ces termes sont définis, nous pouvons définir une marge prédéfinie comme la plus petite différence entre le temps qui est autorisé pour se rendre à la destination et le temps que cela prend réellement.

$$

$$\min Setup Slack = \min Data Required Time – \max Data Arrival Time$$

Maintenant, développons ces termes et réorganisons-les un peu:

$$

$$\min Setup Slack = Latch Edge + \min t_{CLK}' – t_{SU} – CSU -$$

$$

$$– (Launch Edge + \max t_{CLK} + t_{CO} + \max t_D)$$

$$

$$\min Setup Slack = Latch Edge-Launch Edge-\max t_D –$$

$$

$$-CSU+( \min t_{CLK}'-\max t_{CLK}) – t_{SU} – t_{CO}$$

$$

$$=Period-\max t_D – CSU+ \min t_{CS} – t_{SU} – t_{CO}$$

De nouveaux termes sont apparus ici.

Il est clair sur la période, c'est la période de la fréquence d'horloge, c'est-à-dire temps entre Launch Edge et Latch Edge.

Terme$$$\min t_{CS}$- c'est le biais d'horloge - la valeur minimale de l'étalement de l'heure d'arrivée d'un front d'horloge depuis l'entrée d'horloge du système vers différents registres synchrones. L'étalement d'horloge minimum est défini comme la différence entre le plus petit retard d'horloge vers le destinataire et le plus grand retard d'horloge vers la source.$$$\min t_{CS} = \min t_{CLK}' - \max t_{CLK}$... L'analyseur ne fait aucune différence dans l'estimation de ce temps pour différents registres sur la puce.



C'est ainsi que nous avons calculé la marge prédéfinie. Une marge positive est bonne, une marge négative est mauvaise. Slack se traduit littéralement par un affaissement. Donc, s'il y a un mou, alors le transfert interregister n'est pas configuré "vnatyag", le "thread" conditionnel s'affaisse librement. Le jeu est négatif - cela signifie que le fil de transmission a été tiré et cassé.



La figure 5 montre comment la formule d'écart peut être représentée graphiquement:





Fig. 5. Représentation graphique de l'expression Setup Slack



Ceci montre la relation en arrière-plan du signal d'horloge, et il s'agit du signal d'horloge à l'entrée d'horloge du système, et non à l'entrée d'un registre.



Calculons maintenant la marge de rétention de la même manière .



Il peut également être représenté par une expression dans laquelle les termes ont changé de signe:

$$

$$\min Hold Slack = \min Data Arrival Time – \max Data Required Time$$

Ces termes sont maintenant considérés de l'autre côté.

$$

$$\min Data Arrival Time = Launch Edge + \min t_{CLK} + t_{CO} + \min t_D$$

Maintenant, la variante la plus rapide du passage des données est considérée ici et où «max» était «min».



Le moment de l'arrivée du front de clok est également envisagé dans une autre veine, comme le plus récent possible:

$$

$$\max Clock Arrival Time = Latch Edge + \max t_{CLK}'$$

Il est important de noter que dans le cas de Hold Slack, les fronts Launch Edge et Latch Edge sont maintenant le même front, plutôt que deux fronts différents séparés par la période d'horloge. Le registre destinataire dans cette situation a besoin d'avoir le temps de conserver les données à l'entrée pendant le temps de maintien à partir de l'arrivée du front d'horloge. Mais les données sont modifiées à leur entrée par le même front, qui est venu ailleurs dans le registre source. Par conséquent, dans l'analyse du jeu de rétention, la différence$$$Latch Edge - Launch Edge$égal à zéro, pas la période.



Le temps requis dans ce cas est défini comme le temps pendant lequel les données ne doivent pas changer à l'entrée des données du destinataire, afin de ne pas rattraper le temps de maintien:

$$

$$\max Data Required Time = \max Clock Arrival Time + t_H + CHU$$

Terme $$$t_H$- cela nous est déjà connu Tenez le temps, tenez le temps. Il est considéré comme le même pour chaque registre sur la puce et ne dépend pas de l'utilisateur.

Terme$$$CHU$Est-ce que l' horloge est incertaine , l'incertitude du temps de maintien. Il a en général la même signification que CSU, et en règle générale, il est pris comme égal.



Si, comme dans le cas de la marge prédéfinie, vous développez les termes et les échangez, alors l'expression de la marge de rétention peut être transformée sous la forme suivante:

$$

$$\min Hold Slack = \min t_D-\max t_{CS} + t_{CO} -t_H - CHU$$

$$

$$\max t_{CS} = \max t_{CLK}'-\min t_{CLK}$$

Un autre regard sur cette formule

Ci-dessus, une méthode de calcul des relances a été présentée, caractéristique de la compréhension humaine des processus en cours. Ici "le front arrive ...", "les données arrivent ...". Si cela vous intéresse, en complément, je vous dirai comment l'analyseur de contraintes de temps imagine ces calculs.



L'analyseur regroupe les termes différemment, en fonction de ses raisons machine. Mais au final, cela aboutit au même résultat.

Il utilise les termes relation de configuration de l'horloge ( SR ) et relation de maintien de l' horloge ( HR ) - qui peuvent être traduits comme le rapport du temps entre les fronts de déclenchement pour le préréglage et le maintien, respectivement.

$$

$$SR = Setup Latch Edge - Setup Launch Edge-CSU$$

$$

$$HR = Hold Latch Edge - Hold Launch Edge+CHU$$

La figure 6 montre comment ces fronts sont liés:





Fig. 6. Fronts utilisés dans les calculs de mou.



Vous pouvez immédiatement convertir les expressions résultantes en une forme plus compréhensible:

$$

$$SR = Period-CSU$$

$$

$$HR = CHU$$

Le temps inter-registres le plus long (le plus grand r2r requis) est le temps maximum disponible pour que les données atteignent la destination avant le début de l'intervalle prédéfini:

$$

$$Largest\ r2r\ Required = SR + \min t_{CS} – t_{CO} – t_{SU}$$

Le plus long délai inter-registres (délai r2r le plus long) est le temps nécessaire pour transférer les données du registre source vers le registre de destination le long du chemin le plus long:

$$

$$Longest\ r2r\ Delay = \max t_D$$

Nous pouvons maintenant définir le jeu prédéfini comme la différence entre le temps disponible pour atteindre le registre de destination et le temps réel pour y arriver:

$$

$$\min SetupSlack = Largest\ r2r\ Required –Longest\ r2r\ Delay$$

L'élargissement des termes de cette formule nous donnera la représentation familière du jeu prédéfini:

$$

$$\min Setup Slack=Period-\max t_D – CSU+ \min t_{CS} – t_{SU} – t_{CO}$$

Maintenant sur le relâchement de la rétention. La plus petite exigence r2r est le temps nécessaire pour conserver les données à l'entrée du registre de destination:

$$

$$Smallest\ r2r\ Required = HR + \max t_{CS} – \min t_{CO} + t_H$$

Délai inter-registres le plus court:

$$

$$Shortest\ r2r\ Delay = t_D$$

Maintenant, nous définissons la marge du préréglage comme la différence entre le temps le plus rapide pour que les données quittent l'entrée du récepteur et le temps qu'il faut pour les y conserver:

$$

$$\min HoldSlack = Shortest\ r2r\ Delay – Smallest\ r2r\ Required$$

En développant les termes, l'expression prend également la forme déjà familière:

$$

$$\min Hold Slack = \min t_D -\max t_{CS} + t_{CO} -t_H - CHU$$

Quelles conclusions peut-on tirer de formules ennuyeuses?

Nous avons vu comment les relances sont calculées. Comment utiliser ces connaissances?

Regardons à nouveau les expressions lâches:

$$

$$\min Setup Slack=Period-\max t_D – CSU+ \min t_{CS} – t_{SU} – t_{CO}$$

$$

$$\min Hold Slack = \min t_D -\max t_{CS} + t_{CO} -t_H - CHU$$

Si certains slacks du projet devenaient négatifs, alors nous pouvons les changer en changeant leurs termes. Autrement dit, nous voyons comment nous pouvons réparer les mauvais pantalons.



Nous voyons des termes qui ne dépendent pas de l'utilisateur, mais dépendent uniquement de la technologie du cristal. il$$$t_{SU}, t_H, t_{CS}, t_{CO}$... Il n'y a aucun moyen d'interférer.

Nous voyons les termes CSU et CHU, que l'analyseur prend généralement égal au paramètre CU - Incertitude d'horloge, l'instabilité de la fréquence d'horloge. D'une manière générale, ce paramètre est petit, des dizaines de picosecondes. Il est spécifié par l'utilisateur dans le fichier de restrictions. Et l'utilisateur, à son tour, le prend à partir de la spécification du générateur d'horloge. On considère qu'un tampon d'horloge ou FPGA PLL interne, qui reçoit une horloge externe de l'oscillateur et la convertit en une horloge interne à l'entrée de l'horloge système, conserve la valeur CU identique à celle reçue de l'oscillateur. Si CU n'est pas spécifié, l'analyseur le définira sur une valeur par défaut, par exemple, Quartus le définit sur 20 ps. Dans le cas général, ce terme nous indique qu'il est préférable d'utiliser des oscillateurs très stables avec une petite instabilité pour la synchronisation. Les bons oscillateurs sont de l'ordre de 20 à 60 ps.



Le terme de période montre que la manière évidente de lutter contre les erreurs de transmission de données est de réduire la fréquence d'horloge. C'est raisonnable, mais pas toujours acceptable, car les termes de référence exigent généralement des performances du système au-dessous desquelles vous ne pouvez pas aller. Et les performances dépendent directement de la vitesse d'horloge. Nous pouvons également voir la différence entre les slacks préréglés et hold - le hold slack est indépendant de la fréquence.



Et enfin, le terme$$$t_D$caractérise essentiellement l'efficacité du code écrit. Par conséquent, le principal moyen de résoudre les problèmes de relâchement est de le réécrire correctement. Temps fort$$$t_D$apparaît dans des conceptions matérielles trop complexes qui nécessitent trop de logique combinatoire. Si vous avez des constructions aussi complexes dans votre projet, la manière classique de résoudre le problème consiste à diviser un transfert r2r complexe en plusieurs transferts simples en insérant 1 à 2 autres registres dans la séquence d'opérations. Dans ce cas, le retard des cycles pour l'opération augmentera, mais la vitesse de fonctionnement augmentera. Par exemple, l'ajout de plusieurs vecteurs dans un cycle d'horloge n'est pas une bonne idée. Il est préférable d'ajouter plusieurs vecteurs à tour de rôle, avec des sommes intermédiaires. Il peut être impossible de diviser certaines constructions complexes en un pipeline de plusieurs constructions simples - alors une telle logique doit être réécrite d'une manière fondamentalement différente.

Conclusion

Le but de cet article est d'apprendre l'existence du concept de mou et de quoi dépend physiquement ce mou. Sachant cela, vous pouvez étudier indépendamment les rapports de l'analyseur de contraintes de temps, tirer des conclusions et déboguer les performances de votre projet. Ce sont des formules par lesquelles vous n'aurez presque jamais à faire un vrai calcul. Vous n'avez même pas besoin de vous en souvenir par cœur. Il est seulement important de saisir la logique de ce qui se passe dans le transfert inter-registres et de comprendre quels facteurs déterminent la vitesse du projet.