Analyse de l'architecture abstraite VALMEM Analyse de l'architecture abstraite de la SP-SMALL (3x2 bits) A. BARA, E. ENCRENAZ LIP6

Analyse de l'architecture (1/5) SP-SMALL avec le model-checking Architecture complète abstraite automatiquement par LIP6 dans le projet VALMEM 3 mots de 2 bits 62 affectations concurrentes + 30 processus séquentiels 8 signaux non connectés Délais de portes (Implémentation): fichiers de timings associés aux portes et aux latchs du circuits (donnés par Dominique, Patricia & Pirouz). extraire les intervalles des délais de propagation des fronts des signaux de sorties des portes et latchs du circuit. réduction des délais par Algo 1 et 2 + les nouveaux délais associés aux signaux b0, b1, b_0 & b_1 (voir [3] et [4]).

Analyse de l'architecture (2/5) SP-SMALL avec le model-checking Environnement de test : ck : thi 36 tlo 74; d_0 : 112 up; wen : 62 up, 172 dn; a_0 : 162 up;

Analyse de l'architecture (3/5) SP-SMALL avec le model-checking Traduction (avec l'outil VHDL2TA [1]): 18051 lignes de code description UPPAAL. 92 automates (portes & latchs) + 24 automates (gardes des process) + 1 automate Env. 93 horloges + (92+24) var + 92x4 délais. pour UPPAAL, les délais sont instanciés aux bornes des intervalles calculés précédemment. temps de traduction VHDL + temps ⇾ TA : 60 sec.

Analyse de l'architecture (4/5) SP-SMALL avec le model-checking Analyse de la description obtenue (avec l'outil UPPAAL [5]) : la propriété tCK->Q est évaluée en < 10 mn. temps de réponse global tCK->Q > taaw = 56. l'intervalle [51,57] du temps de réponse est dû aux délais des signaux : en instanciant les délais des fronts descendants de ces trois derniers signaux : b_0 : [17,19] - , [1,37] + ; v_18_e_i47_out_n_drive_h : [5,5] - , [8,9] + ; v_18_e_i47_out_p_drive_l : [4,9] - , [7,9] + ; tCK->Q = 50 + d0(b_0)-17 + max (d0(..n_drive_h)-5, d0(..p_drive_l)-4). t.q d0(b_0) in [17,19], .........

Analyse de l'architecture (5/5) SP-SMALL avec le model-checking Réduction des temps setup des signaux d_0, a_0 & wen : avec le temps de setup du signal d_0, soit t_setup_d_0 = 108 : on peut réduire t_setup_d_0 de x = 27 u.t sans faire bouger v_18_e_clk_local_l avant les deux signaux v_18_e_data_l_int et v_18_e_data_delay_h_inv. d_0 : v ∈ {108,...,81} a_0 : v ∈ {58,...,33} wen : v ∈ {48,...,32} t_setup_d_0 ne doit pas < 95 v_18_e_clk_local_l bouge à t = 237 indépendamment du temps de t_setup_d_0 v_18_e_data_l_int bouge à t = 208 v_18_e_data_delay_h_inv bouge à t ∈ [208,209] but: Max(x) s.c 209 + x < 237. 108 - x >= 81.

Analyse de l'architecture (1/7) SP-SMALL avec la simulation Quelques pistes d'améliorations ? Modèle de programmes VHDL temporisés. Intégrer les temps (exacts) dans le modèle VHDL initial : délais ponctuels associés à chaque configuration et non plus intervalle. à l'exécution, seules les configurations fonctionnelles réellement utilisées sont prises en compte. modèle concret avec des délais ponctuels mais est très gros (contient tous les délais pour toutes les configurations). Appel aux outils de simulation pour faire les tests (ModelSim [6], . . . , etc).

Analyse de l'architecture (2/7) SP-SMALL avec la simulation Porgramme VHDL temporisé prêt à simuler (généré par l'outil VHDL2TV [2]): à partir les mêmes descriptions d'entrée que celles passés sur l'outil VHDL2TA lors de la génération de la description en Uppaal : le programme VHDL initial. les fichiers de timings fourni par pirouz. l'environnement de test. constitué de : fichiers VHDL (fichier) associés aux portes du circuits (au circuit). fichier Test-bench qui compose: process env + instanciations des composants (portes). taille des fichiers du programme généré < 1 Mega + temps de génération est instantané.

Analyse de l'architecture (3/7) SP-SMALL avec la simulation Simulation du programme généré (en utilisant ModelSim): construction du simulateur en 40 secondes. le temps de simulation est quasiment instantané. le comportement de la sortie q_0 est stable ! causes: manque de configurations fonctionnelles dans les fichiers de timings b0, b1, b_0 et b_1. (exemple : {<row_2=0, c_pass_l=0, row_1=0, a_pass_l=0,row_0=0, 8_pass_l=0, e_data_delay_h_inv=1, e_net_27=0, b_0={0,1}, e_clock_local_h={0,1}, weh=U(D), b0=D(U)>: X in {0,1}}) non prise en compte de la fonctionnalité de la porte associé au signal b0, b1, b_0 et b_1. (en cas d'absence de configuration).

Analyse de l'architecture (4/7) SP-SMALL avec la simulation Simulation du programme généré (en utilisant ModelSim): le comportement de la sortie q_0 est stable ! remédier ce problème. resimuler à nouveau le programme. attribuer des délais ponctuels entiers d0(s) in [d0_l(s)-, d0_u(s)-], d1(s) in [d1_l(s),d1_u(s)+], s in {b0, b1, b2 & b_1}. explicitement, on remplace manuellement les anciens fichiers VHDL associés à ces signaux, par ceux qu'on peut générer directement à partir des fichiers d'intervalles des délais cité ci-dessous. Idem pour les fichiers de timing qui n'ont pas la correspondance avec la fonctionalité des portes associées. v_18_e_i47_out_n_drive_h après un délais d0 = d0_u = 5.

Analyse de l'architecture (5/7) SP-SMALL avec la simulation L'architecture SPSMALL s'analyse-t-il bien avec ce modèle ? Fichiers de timings : Rappel sur quelques difficultés rencontrés dans les fichiers de timings : Génération des fichiers de timings : existence, dans quelques fichiers, d'incompatibilité avec la fonctionnalité des portes décrits dans le fichier VHDL initial. manque de configurations fonctionnelles. à partir des intervalles de délais associés aux portes. pour chaque fichier de timing associé à une porte, associer à chaque configuration fonctionnelle un délai ponctuel appartient dans ces intervalle. ces délais ponctuels sont sélectionnés: min, max, aléatoire

Analyse de l'architecture (6/7) SP-SMALL avec la simulation L'architecture SPSMALL s 'analyse-t-il bien avec ce modèle ? Régénération du programme VHDL + simulation : Description du programme VHDL prêt à simuler: Resimulation de ce nouveau programme : à partir de ces nouveau fichiers de timings générés automatiquement (+ le fichier VHDL initial + env de test). taille des fichiers du programme généré < 4 Mega + temps de génération est instantané. les annotations temporelles des fichiers de timings sont toutes intégrés dans le programme VHDL. le simulateur se régénère en 40 secondes. le temps de simulation est quasiment instantané.

Analyse de l'architecture (7/7) SP-SMALL avec la simulation L'architecture SPSMALL s 'analyse-t-il bien avec ce modèle ? Régénération du programme VHDL + simulation : Resimulation de ce nouveau programme : La SPSMALL s'analyse bien avec les programmes VHDL temporisés générés à partir les fichiers de timings conformes à la fonctionnalité de leur porte. le comportement de la sortie q_0: quelques expériences: le temps de réponse global tCK->Q ∈ [51,57]. délais min : tCK->Q = 51. délais max : tCK->Q = 57. délais aléatoires : tCK->Q ∈ [51,58].

Autres approximations (1/3) de délais Approximation de délais (fichier d'intervalles de délais) première approximation : l'unité de temps = E-11 sec (celle qui est employée dans l'analyse de la mémoire SPSMALL-3x2 qu'on vient présenter dans ce document). deuxième approximation : l'unité de temps = E-12 sec = ns (plus précise la précédente). troisième approximation : l'unité de temps = E-15 sec = fs (plus précise que les deux premières approximations). Temps de réponse avec ses approximations (avec l'analyse en UPPAAL) approximation (E-11 sec) : (déjà cité dans partie 1: analyse avec model-checking) Le temps de réponse global tCK->Q(W) ∈ [51,57] (> taaw = 56).

Autres approximations (2/3) de délais Temps de réponse avec ses approximations (avec l'analyse en UPPAAL) la deuxième approximation : l'unité de temps = E-12 sec = ns. La troisième approximation : l'unité de temps = E-15 sec = fs. Conclusion : tCK->Q(W) ∈ [499.659ps,566.139ps] ∈ ]499ps,567ps[ (> taaw = 560ps). Le temps de réponse global tCK->Q(W) ∈ [500,566] (> taaw = 560). Le temps de réponse global tCK->Q(W) ∈ [499659,566139] (> taaw = 560000).

Autres approximations (3/3) de délais Temps de réponse avec ses approximations (avec l'analyse en UPPAAL) Remarques : L'approximation de (E-15 sec) donne des bornes très précises sur le temps de réponse de l'écriture tCK->Q(W) ∈ ]499ps,567ps[ contrairement à la première approximation (E-11 sec) qui montre que tCK->Q(W) ∈ [510ps,570ps]. En revanche, la deuxième approximation (E-12sec) donne des bornes plus proches à celles de la dernière approximation tCK->Q(W) ∈ [500ps,566ps].

Bibliographie [1]. A. Bara, E. Encrenaz & P. Bazargan-Sabet. VHDL2TA : outil de traduction des circuits numériques décrits en VHDL en réseaux d'automates temporisés. [2]. A. Bara, all. VHDL2TV : outil de génération des programmes VHDL temporisés prêts à simuler. [3]. A. Bara. Vérification avec Uppaal de circuits décrits en VHDL avec délais, présentation VALMEM, Mai 2010. [4]. A. Bara. Vérification avec Uppaal de l'architecture abstraite de la mémoire SP- SMALL (3x2 bits), présentation VALMEM, Juin 2010.

Bibliographie [5]. K. Larsen, P. Pettersson, and W. Yi. UPPAAL in a Nutshell. International Journal on Software Tools for Technology Transfer, 1:134–152, 1997. [6] Site web de l'outil de simulation ModelSim : http://model.com/

Merci pour votre attention