LE MODE FONCTIONNEL DE L’ARCHITECTURE V6_6
Circuit logique programmable de type FPGA
Un circuit logique programmable est un circuit intégré principalement constitué de cellules logiques élémentaires (Configurable Logic Bloc, CLB), de cellules d’entrée/sortie (Input Output Block, IOB) et de réseaux d’interconnexions pouvant être contrôlés afin de réaliser des fonctions logiques au préalable définies par l’usager. Les ressources et leur disposition varient d’un type de circuit à logique programmable à un autre. Le dispositif utilisé dans ce projet fait partie de la famille Spartan-3E de la compagnie Xilinx. L’architecture globale de cette famille comprend cinq catégories d’éléments fondamentaux : CLB : Comprend quatre tranches (slice) qui contiennent chacune deux bascules, deux tables de conversion (look-up table, LUT) et quelques portes logiques. Les LUT contenues dans les slices de la partie de droite (SLICEM) peuvent être configurées comme étant des blocs RAM ou des registres à décalage; IOB : Sert à contrôler le flux des données entre la logique interne du FPGA et ses broches d’entrée/sortie.
Les IOB peuvent être unidirectionnels ou bidirectionnels. Ils sont regroupés en blocs, chacun ayant son alimentation et ses caractéristiques propres; Bloc RAM : Fournit un stockage sous forme de blocs de mémoire statique; Bloc multiplicatif : Permet la fonction de multiplication pour des larges valeurs. Chaque bloc multiplicatif est associé à un bloc RAM; DCM : Permet la génération d’une horloge selon un facteur et un déphasage tout en assurant la synchronisation entre l’horloge de référence en entrée et l’horloge générée en sortie. L’architecture d’un FPGA de la famille Spartan-3E est présentée à la Figure 1.1. Figure 1.1 Architecture d’un FPGA de la famille Spartan-3E Tirée de Xilinx (2012) Les éléments précédemment énumérés sont organisés tel que décrit sur la figure ci-dessus. Des blocs d’entrée/sortie englobent une matrice de CLB au pourtour du dispositif. Le FPGA possède deux colonnes de RAM englobant plusieurs blocs RAM de 18Kbits chacun. Chaque bloc RAM est associé à un bloc multiplicatif. Deux DCM se trouvent au centre supérieur et deux autres au centre inférieur du dispositif. Les cinq éléments principaux communiquent entre eux à l’aide d’interconnexions disposées un peu partout. Dans ce qui suit, nous décrivons de manière plus détaillée le DCM.
Mode test Le but de ce projet étant de comparer une puce de type FPGA dans les modes test et fonctionnel et non de tester la puce à proprement parler, nous ne ferons que survoler la notion de test, afin d’avoir une meilleure idée de ce concept. Tel que mentionné dans l’introduction, afin de s’assurer de la structure et du fonctionnement d’une puce électronique, il est important de tester la puce afin de détecter les différentes défectuosités qui pourraient l’affecter. Pour ce faire, deux principaux types de tests ont été développés : les tests fonctionnels et les tests structurels. Dans le cas du test fonctionnel, on prend la puce comme une boîte noire. On soumet cette dernière à des séquences de bits (vecteurs de test qui sont souvent dérivés des vecteurs de simulation) aux entrées et on compare la réponse prévue aux sorties de la puce. Si les sorties n’ont pas les valeurs escomptées, la puce est déclarée défectueuse. Le but de ce test est de vérifier la fonctionnalité d’une puce. Ce type de test peut également être utilisé pour voir si une puce peut rouler à la fréquence nominale. Si des PIMs affectent le mode fonctionnel, ils peuvent être également présents et avoir un impact similaire durant le test fonctionnel si tous les domaines d’horloges sont actifs et si leur niveau d’activité se rapproche de celui en mode fonctionnel.
Or, ce n’est pas toujours le cas. Le test structurel vise plutôt à s’assurer que la structure du circuit est intacte. Plusieurs défectuosités dues au procédé de fabrication peuvent en effet altérer la structure d’une puce. Pour faciliter l’application de ce type de test, diverses stratégies de conception ont été développées. La plupart de ces stratégies s’appuient sur l’insertion de chaînes de balayage, qui consiste à relier les registres internes et à ajouter des broches d’entrée/sortie supplémentaires donnant accès à ces registres. Cette insertion permet entre autres de rendre les registres plus facilement contrôlables et observables et facilite la génération automatisée des vecteurs de test. Ces vecteurs de test sont conçus de telle sorte à tester des modèles de pannes bien spécifiques. Dans la catégorie des tests structurels, selon (Bushnell, 2000), il y a trois principaux modèles de pannes : collé-à (stuck-at); court-circuit; et retard. Le modèle de pannes collé-à est défini au niveau porte et affecte les noeuds (signaux) reliant les portes logiques, en supposant qu’ils sont de manière permanente collés à « 0 » ou à « 1 ». En d’autres termes, on utilise ce modèle pour tester la possibilité que l’entrée ou la sortie des portes logiques soient collées à l’alimentation VDD ou à la masse. Il s’agit du modèle de pannes le plus utilisé.
Le modèle de panne de court-circuit sert à représenter les défectuosités causant une connexion indésirable entre la sortie de deux portes logiques. Les modèles de pannes de retard servent à représenter les défectuosités qui causent des délais. Ces délais affectent les transitions qui se propagent dans la logique et ils peuvent causer des erreurs de synchronisation lorsque les données sont trop retardées et ne sont pas encore valides lorsqu’elles sont échantillonnées par le signal d’horloge. Ces modèles de pannes sont utilisées dans les tests visant à s’assurer que le CUT respecte les spécifications de fréquence d’horloge(s) minimale de fonctionnement (« at-speed delay testing »). Les modèles existants considèrent deux types de retard : ceux où la transition est lente à descendre et ceux où la transition est lente à monter. Tel que spécifié par (Bushnell, 2000), orthogonalement à ces deux types, deux modèles de pannes sont définis: les pannes de transition et les pannes de retard de chemin.
Expliqué selon (Mourad, 2000), le modèle de pannes de transition suppose que le retard de transition affecte un point précis du circuit et qu’il est suffisamment important pour causer une erreur de synchronisation, alors que le modèle de panne de retard de chemin suppose que le retard est distribué sur tout le chemin. Dans le cas du projet présenté dans ce document, on s’intéresse plus particulièrement au test de type « at-speed delay testing », par conséquent aux pannes de retard. C’est ce type de test qui sera émulé lors de nos expérimentations. Ceci étant dit, aucun vecteur de test ne sera véritablement généré à partir des modèles de pannes, ni appliqué. Le focus de ce projet est l’impact de l’application de ce type de test sur l’alimentation du circuit et sur les différents délais en jeu. Sauf exception, les PIMs n’apparaissent pas avec ce type de test car une seule horloge est habituellement utilisée. L’exception provient du fait que dans certains cas, les puces vont contenir des circuits internes de génération d’horloges. La section suivante vise à étudier les contributions des recherches précédentes dans le but de positionner notre projet.
Revue de littérature
Les recherches effectuées par nos prédécesseurs ont démontré que les tests à vitesse nominale pouvaient ne pas refléter adéquatement le mode fonctionnel d’une puce. Pour ces travaux, l’attention a essentiellement été portée sur les fluctuations observées dans le mode test. Dans notre cas, l’emphase est davantage portée sur le mode fonctionnel, démontrant que ce dernier peut également subir des variations importantes au niveau de la tension d’alimentation. Pour commencer cette revue de littérature, citons (Nadeau-Dostie, Takeshita et al. 2008) qui présentent une nouvelle méthodologie de test dont le but est de contrôler les variations de la tension d’alimentation et l’activité dans un circuit pendant un test de balayage à vitesse nominale. Ils partent du principe que l’activité du circuit a une influence directe sur le courant moyen, la température locale et la réduction du niveau de la tension d’alimentation (IR drop), le tout influençant directement la propagation des délais dans la puce. Ils proposent un contrôleur d’horloge placé dans la puce afin de sélectionner un grand nombre de stimuli d’horloges pour tester les chemins inter-domaines synchrones à vitesse nominale et pour contrôler les variations de la tension d’alimentation
. Ils utilisent des boucles à verrouillage de phase (PLL) et des contraintes de temps pour contrôler les groupes d’horloges synchrones et multiplier la fréquence des horloges externes. Selon leurs expérimentations, les auteurs concluent que la fréquence de balayage (phase « shift ») de l’horloge de test a un impact sur la baisse de la tension d’alimentation. Ils affirment que la méthodologie BurstMode permet au contrôle de l’activité d’un circuit numérique de refléter le mode d’opération fonctionnel pendant l’application de tests structurels à vitesse nominale. Cela est utile pour le diagnostic et la caractérisation de baisses de tension inattendues. Selon les auteurs, le mode test est davantage représentatif du mode fonctionnel en appliquant leur méthodologie au testeur. Par soucis d’analyser l’impact des baisses de VDD sur les délais de propagation, différentes formes d’horloges test seront étudiées dans le cas de notre système. Dans le cas des tests effectués par (Nadeau-Dostie, Takeshita et al. 2008), les auteurs ne tiennent pas compte que la baisse de la tension d’alimentation pourrait également être affectée par des PIMs dans les modes test (dans le cas de génération interne de signaux) et fonctionnel, ce qui peut influencer la représentativité du mode test versus le mode fonctionnel.
|
Table des matières
INTRODUCTION
CHAPITRE 1 NOTIONS DE BASE ET REVUE DE LITTÉRATURE
1.1 Introduction
1.2 Circuit logique programmable de type FPGA
1.3 DCM
1.4 Distribution d’horloges
1.5 Produits d’intermodulation
1.6 Mode test
1.7 Revue de littérature
1.8 Conclusion
CHAPITRE 2 SÉRIES D’EXPÉRIMENTATIONS PRÉLIMINAIRES
2.1 Introduction
2.2 Plateforme utilisée
2.2.1 Plaquette de développement
2.2.2 Environnement de développement
2.3 Première série d’expérimentations préliminaires
2.3.1 Caractéristiques
2.3.2 Analyse des résultats
2.4 Deuxième série d’expérimentations
2.4.1 Caractéristiques
2.4.2 Analyse des résultats
2.5 Conclusion
CHAPITRE 3 ARCHITECTURES PROPOSÉES
3.1 Introduction
3.2 Première architecture à un FPGA
3.2.1 Diagramme bloc commun Testeur CUT
3.2.2 Spécificités de l’architecture à un FPGA (V6_6)
3.3 Deuxième architecture à deux FPGA
3.3.1 Spécificités de l’architecture à deux FPGA (V6_7)
3.3.2 Communication entre les deux cartes
3.4 Conclusion
CHAPITRE 4 RÉSULTATS ET ANALYSE
4.1 Méthodologie d’analyse
4.1.1 Approximation de la marge de synchronisation par la mesure de la
largeur de l’impulsion sur X_o
4.1.2 Objectifs
4.1.3 Analyse des résultats : mesures et calculs
4.2 Testeur et CUT ensemble (architecture à un seul FPGA)
4.3 Testeur et CUT séparés (architecture à 2 FPGA)
4.3.1 Mode fonctionnel
4.3.2 Mode test
4.3.3 Comparaison des modes test et fonctionnel
Fréquences solos
Trios de fréquences
4.4 Comparaison des deux architectures V6_6 et V6_7
4.5 Conclusion de l’analyse
CONCLUSION ET RECOMMANDATIONS
ANNEXE I PLATEFORME UTILISÉE
ANNEXE II DÉTAILS D’IMPLÉMENTATION
ANNEXE III APPROXIMATION DÉTAILLÉE DE LA MARGE DE
SYNCHRONISATION
ANNEXE IV PROCÉDURE DE TEST POUR L’ARCHITECTURE V6_7 DANS LE
MODE FONCTIONNEL POUR DES FRÉQUENCES SOLOS
ANNEXE V RAPPORTS RELATIFS POUR L’ARCHITECTURE V6_7 DANS LE
MODE FONCTIONNEL POUR LES FRÉQUENCES SOLOS
ANNEXE VI GRAPHIQUES DE LA LARGEUR DE L’IMPULSION SUR X DANS
LE MODE FONCTIONNEL DE L’ARCHITECTURE V6_6
ANNEXE VII GRAPHIQUES DE LA LARGEUR DE L’IMPULSION SUR X DANS
LE MODE FONCTIONNEL POUR LES TRIOS DE FRÉQUENCES
DE L’ARCHITECTURE V6_7
ANNEXE VIII GRAPHIQUES DE LA LARGEUR DE L’IMPULSION SUR X DANS
LE MODE TEST POUR UNE FRÉQUENCE DE RÉFÉRENCE
FCLK_REF DE 95MHz
ANNEXE IX GRAPHIQUES DE LA LARGEUR DE L’IMPULSION SUR X DANS
LE MODE TEST DE L’ARCHITECTURE V6_7
ANNEXE X GRAPHIQUES DE LA LARGEUR DE L’IMPULSION SUR X DANS
LES MODES TEST ET FONCTIONNEL DE
L’ARCHITECTURE V6_7
ANNEXE XI RTL DÉTAILLÉ DES ARCHITECTURES V6_6 ET V6_7
BIBLIOGRAPHIE
Télécharger le rapport complet