Classification des RTC

De manière à mieux appréhender les contraintes temporelles, nous proposons de les classifier sous la forme d’un arbre taxinomique donné enfigure 2.6.

Figure 2.6 – Arbre de classification des contraintes de temps relatifs.

2.5.2.1 Paramètres de l’arbre

Nous l’avons vu, les outils, les modèles et les méthodes d’analyse existants, bien que dé-veloppés dans un paradigme synchrone, manipulent déjà des contraintes de temps relatifs. Les contraintes classiques de setup, dehold ou de largeur d’impulsion, qui sont associées à tout élément séquentiel, révèlent lesRTC masquées par le niveau d’abstraction apporté par le modèle. Pour les circuits synchrones, la plupart des RTC sont agrégées au niveau des éléments séquentiels à cause du modèle de délais bornés utilisé. Mais des exceptions ont été apportées et de nouvelles sémantiques ont été créées pour capturer des RTC qui ne s’intègrent pas aux éléments séquentiels. Par exemple, la commande SDC set_data_ checkpermet de définir les point de convergence (POC) et le sens deRTCs’appliquant sur la logique combinatoire. Nous proposons donc de classer lesRTC en fonction du type de cellule dePOCqu’elles utilisent : soit un élément séquentiel, soit une cellule combinatoire. Les signaux mis en concurrence par uneRTC ne sont pas tous de même nature. Dans

les circuits à données groupées, un signal peut appartenir soit au chemin de données soit au contrôleur. Nous pouvons aussi distinguer le reset qui est un troisième type de signal par-ticulier. Ainsi, lesRTCpeuvent être classées selon le type d’interaction qu’elles décrivent. Alors que les interactions données-données ne sont pas valides (les circuitsBD utilisent le même modèle à délais bornés dans la partie chemin de données), les interactions donnée-contrôle regroupent l’ensemble des RTC s’appliquant à la frontière entre les deux parties du circuit. Les interactions contrôle-contrôle sont celles requises à l’intérieur du contrôleur pour assurer le bon fonctionnement du protocole. La quatrième famille comprend les inter-actions reset-contrôle. Celles-ci sont souvent oubliées mais peuvent, lorsqu’elles sont mal implémentées, générer de mauvais fonctionnements comme une désynchronisation entre les données et les signaux de contrôle.

Les RTC peuvent ensuite être triées suivant le type de vérification qu’elles décrivent. Les vérifications desetupet dehold s’intéressent à la relation entre deux signaux distincts. Elles se différencient selon l’orientation de l’inégalité (quel signal doit arriver en premier). Elles mettent respectivement en jeu le même cycle de « poignée de mains » ou bien deux cycles consécutifs3. Le troisième type de vérification s’applique au temps séparant deux transitions opposées4 du même signal. Il est nommé « largeur minimum d’impulsion haute » quand il contraint l’espacement entre un front montant et un front descendant et « largeur minimum d’impulsion basse » dans l’autre sens.

Enfin, les RTC peuvent être séparées en deux catégories suivant le type de chemin qu’elles activent : (i) Certaines sont contenues dans un seul étage du bloc de contrôle. Elles sont internes et peuvent être facilement masquées par un modèle d’abstraction temporelle comme le formatLiberty. (ii) Les autres impliquent au moins deux contrôleurs. Les chemins temporels s’étalent sur plusieurs étages du bloc de contrôle pour relier leurs points de divergence et de convergences.

Certains cas ont volontairement été ignorés. Par exemple, une contrainte de « grou-pement interne » n’existe pas par définition. Une contrainte de « capture d’état interne » semble peu probable. Elle impliquerait soit deux éléments séquentiels5. dans le même contrôleur, soit un protocole générant de multiples impulsions au cours du même cycle de communication. Nous avons donné un nom à chacune des feuilles de l’arbre de classi-fication. Certains sont inspirés de la littérature. Pour les autres, un nom explicite a été choisi.

2.5.2.2 Classes de contraintes de temps relatifs

Une équation de temps relatifs générique peut être associée à chaque contrainte de la figure 2.6. Le formalisme suivant est adopté : d-data et d-ctrl représentent respectivement une transition sur l’entrée de données ou d’horloge d’un élément séquentiel dans le chemin de données, c-data et c-ctrl sont leurs équivalents pour un élément séquentiel présent dans le bloc de contrôle. Les transitions cl et cc sont deux POCdans la logique combinatoire, respectivement de lancement et de capture. La transition pod est un point de divergence (POD) du circuit. D’autre part, rst est la source de reset du circuit et d-rst est l’entrée dereset d’un élément séquentiel. L’indice i est utilisé pour indiquer l’appartenance d’une transition au i-ème étage du contrôleur. Nous utilisons aussi la notation7→^[i] pour préciser

3. En cela les circuitsBDse différencient des circuits synchrones pour lesquels les vérifications desetup

sont faites entre deux cycles d’horloge successifs et celles deholdsur le même cycle.

4. Des vérifications de période minimum sont possibles (temps séparant deux transitions identiques du même signal), mais celles-ci sont en général réservées aux blocs hiérarchiques de grosse taille intégrant eux-mêmes un chemin de données (mémoire, sous-circuit). Dans ce cas, le respect des contraintes de largeur d’impulsion n’est pas suffisant à garantir le bon fonctionnement du bloc.

2.5. Contraintes de temps relatifs et circuits à données groupées l’étage du contrôleur auquel les chemins sont restreints. Le sens des transitions est défini à l’aide de + ou −. Dans un souci de simplicité, ceux-ci sont omis lorsque les deux sens sont valables. Finalement, chaque équation utilise un paramètre générique, δ, qui représente l’ensemble des marges prises par les concepteurs, les outils ou les modèles.

(1) Regroupement : Elle est la principale contrainte entre deux contrôleurs d’un cir-cuit à données groupées. Elle garantît que les données et les signaux de contrôle se propagent de manière synchronisée. Elle fait intervenir le délai matché sur les fils de poignée-de-main ainsi que le pire chemin de propagation des données. Cette contrainte vérifie que les marges de setup de l’élément séquentiel ne sont pas mises en défaut par les temps d’arrivée des données et des signaux de contrôle.

pod 7→ d-datai ≺ d-ctrli− δ (2.4) (2) ´Ecrasement de donn´ees : Cette contrainte permet de s’assurer que l’arrivée rapide d’une nouvelle donnée au niveau d’un élément séquentiel ne vienne pas perturber la mémorisation de la donnée précédente. Elle garantit que les données soient mainte-nues suffisamment longtemps pour respecter les temps de hold des éléments séquen-tiels.

pod 7→ d-ctrli ≺ d-datai− δ (2.5) (3-4) T emps de phase minimum : Elle s’applique à tout élément séquentiel et garantit une capture cohérente des données. En fonction du type d’élément séquentiel uti-lisé, elle vérifie la durée de l’état haut ou de l’état bas du signal de capture. Cette contrainte s’applique à une impulsion générée par le protocole et dont la largeur dépend de la réponse de l’environnement. Elle implique au moins une phase du cycle de communication. (haut) pod 7→ d-ctrl+ i ≺ d-ctrl− i − δ (2.6) (bas) pod 7→ d-ctrl− i ≺ d-ctrl+ i − δ (2.7)

(5-6) Largeur d’impulsion locale : Comme la contrainte de temps de phase minimum, elle s’applique à tout élément séquentiel. Mais dans ce cas, la largeur d’impulsion dépend de chemins internes au contrôleur. Cette contrainte est typiquement présente dans les protocoles utilisant de la conversion de phase (protocole 2 phases).

(haut) podi [i] 7−→ d-ctrl+ i ≺ d-ctrl− i − δ (2.8) (bas) podi [i] 7−→ d-ctrl− i ≺ d-ctrl+ i − δ (2.9)

(7) Capture d’´etat : Cette contrainte s’applique aux protocoles utilisant un élément sé-quentiel dans leur contrôleur. Ces éléments mémorisent un état interne du contrôleur. La nouvelle valeur de cet état doit être stable pour pouvoir être mémorisée lorsque la phase suivante du protocole commencera.

pod 7→ c-datai ≺ c-ctrli− δ (2.10) (8) ´Ecrasement de contrˆole : Cette contrainte s’applique aussi aux contrôleurs incluant un élément séquentiel. La variable d’état ne doit pas être écrasée tant qu’elle n’a été correctement mémorisée.

(9) Maintien d’´etat local : Tout comme la contrainte d’´ecrasement de contrˆole, celle-ci s’attend à ce que la variable d’état local soit stable lors de sa mémorisation. Chaque fois que cette variable est modifiée localement (c’est-à-dire, sa prochaine valeur dépend directement de sa valeur actuelle), une contrainte de maintien d’état local s’applique.

pod_i7−→ c^[i] -ctrli≺ c-datai− δ (2.12) (10) Blocage d’´ev`enement : Cette contrainte est nécessaire à chaque fois qu’il existe une interaction directe dans la logique combinatoire (et non au niveau d’un élément séquentiel) entre un signal de contrôle et un signal de données. Cette relation tem-porelle est habituellement appelée clock-gating dans le contexte synchrone. Suivant le sens de l’inégalité, une contrainte de setup ou de hold de blocage d’évènement doit être vérifiée.

pod 7→ cl_i ≺ cc_i− δ (2.13) (11) Course de chemins d’environnement : Une contrainte interne peut être nécessaire pour s’assurer du bon séquencement des évènements dans un contrôleur. Si le chemin relatif s’étend à plusieurs contrôleurs, il décrit un course d’environnement entre deux signaux de contrôle.

pod 7→ cli ≺ cc_i− δ (2.14) (12) Course de chemins locaux : Cette contrainte est similaire à une course d’environ-nement, mais le séquencement des évènements dépend uniquement de transitions internes à un seul contrôleur.

pod_i 7−→ cl^[i] _i ≺ cc_i− δ (2.15)

(13) Relaxe du reset : Le relâchement du signal de réinitialisation est une phase sen-sible pour un circuit à données groupées. Un léger décalage entre le redémarrage du contrôleur et celui du chemin de données peut générer un désalignement entre les événements de contrôle et les données. Cela peut conduire à un comportement in-correct ou à un blocage du système. Habituellement, un délai est inséré pour séparer les signaux de réinitialisation du chemin de données et du contrôleur. Il permet de retarder la réinitialisation du contrôleur jusqu’à ce que le chemin de données soit prêt.

rst 7→ d-rsti ≺ d-ctrli− δ (2.16)

2.5.2.3 Exemple du contrôleur Mousetrap

Nous proposons d’utiliser cette classification pour identifier les contraintes temporelles associées au contrôleur de protocole Mousetrap. Lafigure 2.7 donne l’implémentation ty-pique de cette primitive. En examinant cette implémentation et en identifiant les éléments séquentiels, nous pouvons facilement déduire un premier ensemble deRTC s’appliquant à ce contrôleur. Deux verrous doivent être pris en compte : un dans le contrôleur et l’autre dans le chemin de données. Leséquations (2.4)à (2.12)et(2.16)s’appliquent donc néces-sairement. Mais, en considérant que les verrous sont transparents à l’état haut, seule la contrainte de largeur d’impulsion minimum haute doit être vérifiée (les impulsions basses ne génèrent pas de métastabilité dans ce type de verrous). Les équations (2.7) et (2.9) peuvent être ignorées.

2.5. Contraintes de temps relatifs et circuits à données groupées

Figure 2.7 – Contraintes temporelles relatives du contrôleur Mousetrap.

En regardant le fonctionnement de ce contrôleur, cette liste peut être encore légère-ment simplifiée. Le front descendant du signal de contrôle des verrous est généré dans le contrôleur, alors que le front montant est déclenché par le retour d’acquittement de l’étage suivant. Nous pouvons en déduire que la largeur de l’impulsion haute dépend uniquement de chemins temporels internes. La contrainte de temps de phase minimum ne s’applique donc pas et l’équation (2.6) peut être ignorée. L’analyse inverse peut être faite pour la contrainte de maintien d’´etat local. La variable d’état dépend seulement du signal de requête du canal d’entrée. L’équation (2.12) n’a pas de sens dans ce cas.

En parcourant les branches de l’arbre taxinomique, nous avons pu construire une pre-mière série de 8RTC génériques (les contraintes relaxe du reset et largeur d’impulsion locale doivent être comptées pour chaque verrou). Les autres RTC, s’appliquant sur la logique combinatoire, ne peuvent pas être extraites de la même manière mais peuvent être retrouvées en utilisant des approches formelles. Des outils de synthèse de modèle formel comme Petrify permettent de générer une implémentation d’un protocole donné et de fournir une liste desRTC associées. De telles contraintes n’existent pas dans l’implémen-tation originale du protocole Mousetrap. Seuls lesPOC ont été localisés jusqu’à présent. Pour compléter les RTC, chaque POD doit être identifié. Cela peut être fait de manière très intuitive : en parcourant le schéma du bloc de contrôle un point commun connectant les deux POC peut être trouvé. La figure 2.7 trace toutes les RTC identifiées et place leur POD respectif (losange grisé). Il est intéressant de remarquer que trois points sont suffisants pour décrire lesPOD des 8 RTC.