Rapport - Polytechnique Montréal

Mécanisme d’Accès aux Tests des Systèmes On Chip
« SOC »
Fatma Tiza , Youssef Bennis
École Polytechnique de Montréal
RÉSUMÉ : Dans ce projet, on va exposer les causes de la création de la norme P1500 (fournisseurs et concepteurs
systèmes) En deuxième lieu, on va décrire brièvement les études entamées par le groupe P1500. Ensuite on parlera des
techniques de calcul d'une architecture optimale de Mécanisme d’accès aux Tests (TAM), après de brèves définitions de
mots clés. Une étude physique et mathématique sera exposée afin de donner certains éclaircissements, et espérer aboutir à
cette architecture optimale et on va terminer par une conclusion.
1-INTRODUCTION
Micro-ordinateur, minichaîne, compact disque, industrie
spatiale, téléphones cellulaires etc…, l'espace est decidément bien précieux, et l'on cherche sans arrêt à réduire les
e
dimensions des objets quotidiens. Le XX siècle est incontestablement celui de la miniaturisation, rendue possible
grâce aux progrès effectués sur les composants, à la
découverte des semi-conducteurs ainsi qu'à l'avènement de
la microélectronique. Des premiers postes de TSF aux
micro-ordinateurs portables, du premier tube électronique
(Geissler, 1857) aux puces d'aujourd'hui, en passant par le
transistor (1947), la course au plus petit est impressionnante.
Très vite l'informatique s'intéresse à ces nouveaux
matériaux et devient le secteur qui sait le mieux profiter de la
miniaturisation des composants électroniques.
Désormais grâce à cette évolution il est possible d'intégrer
un système complet sur une seule puce, système qui jusque
là tenait sur une carte ou sur un MCM (Multi Chip Module.
Ces systèmes intégrés sur une puce, appelés SOC (System
on a Chip), se développent inévitablement et se retrouvent
dans des domaines comme les télécommunications, l'avionique, la construction automobile...
2 – SYSTEME ON CHIP
La mutation des systèmes électroniques a rapidement
muté des systèmes sur cartes aux Systèmes sur puce,
appelé Systèmes On Chip « SOC », impliquant un grand
niveau de Complexité. La fabrication des systèmes sur puce
compte énormément sur la réutilisation des blocs préconçus
appelés « design reuse ».
figure 1 : Architecture d’un system on chip
L’utilisation de ces blocs dits Cœurs provient de plusieurs
fournisseurs, ce qui a provoqué des difficultés :
•
Accessibilité aux cœurs
•
Temps de test du système
•
Puissance dissipée au cours du test
•
Partage des ressources de test
Avant d’étudier l’architecture de P1500, on va s’intéresser
comme pour le JTAG de la standardisation des années 80
du test sur carte (isolation par les cellules BOUNDARY
SCAN des cœurs ) et faire les différences de test entre les
cartes et les puces.
On constate par ces différences, que les stratégies de test
des systèmes sur cartes ne peuvent pas être appliquées aux
tests des SOCS
Pour les cartes qui intègrent des composants physiques
testés individuellement (donc considérés comme bon), et qui
sont ensuite testées au niveau système.
1
Pour les SOCs, les composants étant virtuels, les différents
cœurs ne pourront être testés que lorsque le circuit aura été
fondu sur silicium, en même temps que le système.
Cela implique que la testabilité du SOC doit être prise en
compte très tôt, des la phase de conception [13]
Le schéma ci-dessous illustre les processus de fabrication
des cartes et des puces.
2-3-a : Les «softs cores» sont décrits dans un langage de
description matériel (HDL Hardware Description Language),
synthétisables. Ils sont indépendants de toute technologie et
sont très souples d’utilisation
2-3-b- Les «hard cores» sont optimisés, placés et routés.
Donc le concepteur le voit comme une boite noire, moins
portable que les softs et les firms.
2-3-c- Les «Firm cores» sont des blocs ayant subis une
optimisation en surface et vitesse par des techniques de
placement relatif. Décrit en HDL, structurel, ils font appel à
des composants élémentaires d’une librairie générique. Un
tableau récapitule les différences entre ces IP :
Caractéristiques
IPS
Figure 2 : Représentation du Flot d’intégration
2-1 Niveau des IP core
Du coté des fournisseurs, les techniques de test sont
celles classiquement utilisés
•
•
•
Insertion des points de test
Scan
Bist
Les cœurs étant testables, le fournisseur doit fournir
•
•
•
Les vecteurs de test
Les réponses
Le plan de test complet
2-2 Niveau des SOCS
L’intégrateur système doit prendre en compte les éléments
suivants afin d’assurer la testabilité du SOC :
¾
Intégration et coordination des éléments de test dans
le circuit
¾
Comment transférer les vecteurs de test aux cœurs ?
¾
Traduction des vecteurs fournis avec les cœurs, pour
pouvoir les intégrer dans la session de test au niveau
SOC.
2-3 Différents cœurs
Il existe trois grandes catégories de cœurs IP (Intellectuel
Property) :
\
Soft cores
Hard cores
Firm cores
Représentation
Comportemental
Masque
Structurelle
Technologie
Indépendant
Fixe
Générique
Flexibilité
très grande
très faible
Grande
Portabilité
Illimitée
Process
Librairie
Optimisation
Performance
Haut Niveau
Optimum
Limité
Protection
Très faible
Grande
Faible
Tableau 1 : Représentation des différences entre les IPs
En se basant sur ces différences, on peut expliquer
aisément la création du groupe P1500.
3-Norme P1500 :
3-1- Histoire
Comme pour le JTAG (Joint Test Action Group) dans les
années 80, le groupe IEEEE P1500 s’est formé pour
essayer de proposer des solutions aux problèmes de test
rencontrés dans l’industrie.
En septembre 1995, un comité de recherche sur les
techniques de test des systèmes a base des cœurs a vu le
jour sous le nom de TAC (Comité d’Activités Techniques) Ce
comité, issu du IEEE TTTC (Test Technology Technical
Council), s’est transformé en groupe de travail en juin 1997
sous le nom de P1500.
Ce groupe avait pour but de créer des standards pour
faciliter l’utilisation et la réutilisation des techniques et
méthodes de test des systèmes a base de cœurs.
Trois projets sont en cours de standardisation
- Test des cœurs fusionnables (mergeables cores)
-Développement d’un langage de description des informati ons de test d’un core
2
-Définition d’une interface de test autour des cœurs non fusionables appelés «Wrapper»
3- ARCHITECTURE P1500 :
3-1 Description
3-2 Objectifs :
L’objectif principal du groupe est de faciliter la
communication des fournisseurs et des concepteurs
Systèmes.
Lors des conférences, ils se fixent des thèmes de
recherches du Standard P1500, on le dénombre à huit
taches importantes
a)
Langage de test des cœurs (CTL - CTDL)
Définition d’un langage décrivant les caractéristiques de test
des cœurs
¾
Méthodes de test utilisées
¾
Les modes de test et les protocoles correspondants
¾
Les données de test à appliquer
¾
Les informations sur les modèles de fautes et les
taux de couverture
¾
Le nombre, l’ordre et la longueur des chaînes de
scan i internes
¾
b)
Les informations sur le diagnostic et le debug de
l’IP
Architecture
Définition d’un anneau d’isolation et d’une interface pour
les connexions des cœurs au mécanisme d’accès (TAM)
entre les entrées sorties du système et les entrées sorties
des cœurs.
c)
Définition des compatibilités
Définition des niveaux de normalisations P1500, avec anneau ou sans anneau d’isolation.
d)
Terminologie
Définition d’une terminologie pour la norme P1500
e)
Test des coeurs
Étude de ce que peut être fait par les fournisseurs de cœurs, pour aider les utilisateurs systèmes et leurs donner des
conseils.
f)
Benchmarks
Collecter et distribuer des bans d’essai (circuits
d’étude)Cette activité est en étroite coopération avec
l’initiative ITC99 Benchmarks
g)
Industries et Relations avec les médias
h)
Documentation
Figure 3 : Conception Architecturale pour le test des
SOCS
La conception
phases :
de
cette
architecture
comprend
trois
Phase 1 : Construction d’un anneau d’isolation autour de
chaque cœur. Cet anneau comme on l’a déjà vu s’appelle
«Wrapper »
Phase 2 : Consiste à la conception d’un Mécanisme
d’Accès aux Tests «TAM»
Phase 3 : ‘ Source et Sink ‘
Mot Source désigne le matériel fournissant les vecteurs de
test. Il peur être :
9
Un testeur industriel dans le cas où il serait externe au
circuit
9
Un générateur de type Bist quand celui–ci est interne
Mot Sink correspond à l’analyseur de réponses aux stimuli
appliqués, de la même façon que la Source, il peut être
interne ou externe au SOC, sous la forme d’un analyseur de
signature ou d’un testeur.
3-2 Définition de Wrapper et du TAM
Qu’est ce qu’un Wrapper ?
C’est une interface entre le cœur (Entrées / Sorties) et le
TAM.
La norme P1500 exige deux niveaux de conformité, le
Wrapper peut faire partie du pack livré avec le cœur (IEEE
1500 compliant core) ou être conçu par le concepteur
système (IEEE1500 Ready core)
L’acheminement des données de test aux entrées /sorties
du cœur par l’intermédiaire des données du Wrapper se fait
soit :
- En série par l’interface série SIL (Serial Interface Layer)
Préparation de la documentation de la norme P1500
3
- En parallèle par l’interface parallèle PIL (Parallel Interface
Layer)
4- MECANISMES D’ACCES AUX TESTS – LIMITATION :
Les TAM peuvent se classer en deux catégories
Remarque :
•
TAM correspondants à la réutilisation des
ressources fonctionnelles, pour transporter les
vecteurs de test.
•
TAM correspondant
à un rajout du matériel
supplémentaire dédié au test
L'interface série est bien définie en comparaison à la PIL
Lorsque les TAM utilisent les ressources fonctionnelles, ils
sont peu flexibles.
Figure 4 : Architecture du Wrapper P1500
Qu’est ce qu’un TAM ?
Permet de transférer les données de Test au niveau
système.
Le TAM est choisi selon le Sink/Source des types de cœurs
intégrés et des contraintes physiques imposées
a
l’intégrateur système, c’est à dire le systèmier a la charge de
concevoir lui-même le TAM, Sink, et Source, car ces
éléments ne sont pas standardisés. Pour cette raison, on a
décidé de s’intéresser spécialement au TAM.
En général ces ressources sont le bus système, sa largeur
est fixe, l’intégrateur système (concepteur Système) ne peut
pas faire de compromis entre la surface rajoutée et le test.
Avec ce type de TAM, la méthodologie de test est dominée
par le test fonctionnel et l’ajout de structure de scan est
difficile à intégrer.
Remarque
Actuellement d’après la littérature de TAM, le bus utilisé
comme TAM est le bus ARM, de ce fait il devient standard.
5-ETAT DE L’ART DES ARCHITECTURES DES
TAMs
Comme la norme P1500 n’est pas restrictive, quant au
choix et a la conception du TAM.
Plusieurs méthodes ont été proposées dans la littérature
qui traite de l’optimisation dans les articles de reference,
visant à être un accord avec les concepts que définit la
norme P1500 et qui respectent les facteurs suivants :
Figure 5 : Architecture P1500 pour le TAM
On retrouve le TAM qui permet d’accéder aux différents
Wrapper de chaque cœur par les signaux TAM-in, TAM-out,
TAM-source et TAM-sink, permettant le transfert d’inform ations entre les entrées /sorties des cœurs et les éléments
chargées de fournir les vecteurs de test ou d’analyser les
réponses (testeurs, modules de BIST).
Le module WIP (Wrapper Interface Port) permet de
configurer les Wrappers des différents cœurs dans le monde
voulu et imposé par l’ordonnancement du test.
•
Surface additionnelle
•
Temps de test
•
Contrôle complexe du TAM
•
coût du bus additionnel
Certaines architectures réutilisent
ressources implantées sur le système.
au
maximum
les
D’autres utilisent directement les propriétés des cœurs.
Dans [7] [9] [10] , des algorithmes sont présentés pour
optimiser les largeurs des TAMs en fonction du temps de
test. , et aussi prendre en compte les contraintes de
placement –routage et de puissance dissipée. Mais les
approches les plus standardisées (et les plus utilisées)
reposent sur l’utilisation de bus spécifiques de test sur un
système.
Il contrôle les modes prévus par la norme P1500 lors des
différentes phases ou de fonctionnement normal du circuit.
4
6-APPROCHE UTILISANT DES BUS DE TEST
L’accès au cœur peut se faire de plusieurs manières par
les concepteurs système, en utilisant les différentes
architectures existantes, elles se présentent en trois ca tégories :
•
Architecture multiplexée
•
Architecture daisy-chained
•
Architecture distribuée
6-1 Architecture multiplexée
-Un seul cœur peut être testé à la fois
-Temps de test =∑ temps de test de chaque cœur
-Très difficile de tester la connectique externe au cœur, car
ceci nécessite l’accès au moins deux cœurs en même
temps.
Architecture distribuée
Figure 6 : types d’architectures
6-2 Architecture daisy-chained
6-4 Test Bus
Tous les coeurs sont accédés en même temps ⇒ facilite
des tests des cœurs.
Le test bus [14] est une architecture mixte basée sur les
approches«distribuée et Multiplixée»
Ces deux architectures ont des cœurs, qui ont accès à tous
les bits du TAM.
Le bus de test est partagé en plusieurs « Sous Bus », qui
peuvent être de largeur différente, plusieurs cœurs sont
ensuite connectés à chaque bus comme dans l’architecture
multiplexée
Le schéma ci-dessous représente
architectures et leurs chaînages au bus
les
différentes
6-3 Architecture distribuée
•
Largeur totale du bus est partagée entre les
différents cœurs
•
Le Test est fait en parallèle
•
Test = max (Tps de test des coeurs)
Figure 7: Architecture Test Bus
6-5 Test Rail
Le test Rail est une architecture mixte basée sur les deux
approches « distribuée et daisy-chained»
Plusieurs cœurs sont chaînés comme sur la figure cidessous
Architecture multiplexée
Architecture daisy-chained
5
Remarque
Largeur du Test Rail n’est pas forcement égal au nombre
d’entrées-sorties des cœurs.
L’architecture Test Shell est compatible a la norme P1500,
car elle respecte les modes de fonctionnement
-
Mode Test
-
Test des interconnexions
Pour avoir une architecture optimale [14] propose
d’optimiser les bits qui ne sont pas utilisés pendant le test,
ainsi le temps de test sera minimiser.
Figure 8: Architecture Test Rail
comporte deux bus de largeur m et n connectant deux
coeurs et trois cœurs
6-6 Test Shell (pour les wrappers)
Le wrapper est un Test Shell est, qui comporte des cellules
le constituant (bascules sur les entrées /sorties fonctionne lles du cœur), les multiplexeurs, le registre de bypass et les
connections permettant de connecter le test Rail a cet ense mble, qui relie les entrées /sorties du TAM.
Un exemple illustre le Test Rail et le Test Shell pour trois
cœurs avec respectivement 3,2 et 2 chaînes de scan.
Des solutions sont trouvées avec des algorithmes
d’optimisations, qui permettent une co-optimisation de
l’architecture et du temps de test
1-
ILP et énumération
2-
Heuristiques pour l’optimisation de largeur des TAM
7- OPTIMISATION-MODELES MATHEMATIQUES
DES TAMs – EXEMPLES –INTERPRETATIONS
Comme on l’a signalé ,l’accès aux cœurs ne se fait pas
directement, car ils sont enfouis. Le temps de test est
important et se trouve le majeur problème quand il y a
plusieurs cœurs sur la puce ou SOC, notre étude se portera
aux points suivants :
•
Assignement des cœurs aux bus de test
•
Minimisation de la largeur du bus.
•
La subdivision du bus
Les solutions qui résolvent le problème majeur «temps du
système » sont des NP-Complet qui sont non déterministes
on utilise l’approche ILP(Programmation linéaire entière) On
va passer en brefs les différentes solutions proposées par la
littérature
Figure 9 : Architecture Test Rail et Test shell
D’après l’exemple le test Rail a :
-
Une largeur de trois bits.
-
Permet l’acheminement des données de test pour
les entrées sorties fonctionnelles, ainsi que pour les
entrées sorties des chaînes de scan internes aux
cœurs.
-
Adaptation de la connexion Test Rail, Test Shell
par rapport aux nombres d’entrées sorties.
•
Cœurs transparents
•
Architecture de bus basé sur le concept Test Rail
•
Architecture à accès multiple.
•
Macro tests
Remarque
Seul Philips propose pour ses propres produits, une
méthodologie et des outils pour pallier ce problème avec son
approche Macro Test [13] [14]
Avant de décrire les différentes optimisations,on donne
une définition d’un ILP :est une résolution mathématique , et
a pour but de minimiser une fonction linéaire de variables
entières , en considérant un jeu de contraintes elles aussi
6
linéaires .Il est généralement représenté par AX (fonction a
minimiser ),sujet aux contraintes BX<= C
Soit :
A est un vecteur , B est une matrice ,C est un vecteur
colonne , X vecteur de variable entière.
7-1 Optimisation Assignement des cœurs aux tests Bus
Et le temps de test du système est égal a :
On définit le problème suivant sous forme de NP-Complet
Le problème P1 : soit NC le nombre de cœurs
Soit NB le nombre de bus (test bus), de largeur w1, w2, w3,
……wNB
L’objectif principal de chaque ILP est la minimisation de la
fonction coût objective, qui correspond à :
On définit l’assignement des cœurs aux tests bus tel que
∑ temps de test est minimal ?
On définit
Avec Фi = max (Ne , No)
Ne et No sont respectivement les entrées et les sorties
du cœur i
On assume que le test se fait en parallèle dans le cas ou
Dans le cas contraire, la largeur du test bus est insuffisan te, on s’oriente au test série, pour les entrées / sorties du
cœur i,
avec
Par la suite, on verra avec l’utilisation des ILP, comment
le temps a été optimisé, avec un SOC ayant des circuits
combinatoires et séquentiels.
7-2 Optimisation de la largeur du Bus Test
Soit le problème P2 : Détermination de la largeur optimale
de test bus et l’assignement des cœurs a ces tests bus?
Le problème de l’optimisation de la largeur du bus test est
plus complexe que le problème vu précédemment.
Objectif :Minimisation de W
sujets aux contraintes suivantes
Avec T fixé par calcul [10]
7-3 Optimisation par Subdivision du Bus Test
Dans cette approche, les auteurs proposent de trouver un
meilleur partitionnement du bus en sous bus, un assignem ent optimal des cœurs aux bus tests pour avoir un temps de
test minimal, la largeur totale du bus étant fixe.
Figure 10 Représentation du modèle série
On définit :
Objective : minimiser le temps de test total sujet aux
contraintes [7]
8-EXEMPLES DES CAS ETUDIÈS
Soit le Système On Chip suivant
7
Figure 11 : Représentation d’un Système On Chip
Ce Système On Chip est constitue de sept circuits
combinatoires et trois circuits séquentiels avec scan interne
et deux bus.
Les résultats par ILP sont représentés ci-dessous
Tableau3: Optimisation du temps de Test
Test Total
T
optimale
largeur
W
Distribution
optimal
Assignement
aux bus tests
(w1,w2)
Tableau4: Optimisation de la largeur du Bus
Remarque
Tableau 2 : Temps de test, nombre d’entrées –sorties
pour chaque circuit et vecteurs de test
Qui correspond à une description du SOC(ISCAS89 benchmark circuits)
8-1-Exemple d’assignement optimal des cœurs au Bus
test et la largeur du bus de test
Test Total
W
Distribution optimisation
optimal
Temps de
w1,w2
Test
Assignement
Si on prend les 3 cas d’assignements suivants pour un bus
de largeur total égal a 48 bits, on aura :
•
W1=32 w2=16 assignement (1,1,1,1,1,1,1,2,2,1)
temps de test=410000 cycles
•
W1=27 w2=21 assignement (2,2,2,2,2,2,2,2,2,1)
temps de test=411884 cycles
•
W1=28 w2=20 assignement (1,1,2,1,2,1,2,2,2,1)
temps de test=408077 cycles
aux bus tests
8
Figure 12 : Représentation de l’assignement par le
vecteur (1,1,1,1,1,1,1,2,2,1) du SOC
On constate que les différentes combinaisons d’assignements ainsi que la distribution de la largeur des bus
optimaux permet d’avoir un temps de test minimal ou
maximal.
(b)
Figure 13: optimisation du temps de test(a) et de
la largeur du bus (b)
Ces deux schémas illustrent la comparaison entre
l’optimisation du temps de test du système et l’optimisation
de la largeur du bus pour notre SOC, ayant deux bus et trois
bus.
8-2-Exemple de la subdivision du bus Test
On va dans cet exemple comment le temps de test a été
diminué.
Test
Distribution
total
de W
w1,w2
/ W1
Temps
Test
Assignement
aux sous bus tests
(a ,b )
(a)
Tableau 5: Optimisation par subdivision du bus
9
Test total
Temps de test
avec subdivision
Temps de test
sans subdivision
20
441404
470380
24
426564
461277
28
412427
452781
32
441404
443620
36
394012
435042
44
394012
417057
52
397748
399290
Le temps de test a diminue, en rajoutant la meilleure
subdivision qui doit être optimal
Si on arrive à trouver des solutions standards, compatibles
a la norme P1500, on pourrait éventuellement espérer
trouver une manière de rendre le test des SOCS comme une
option logicielle dans les outils de conception, comme c’est
le cas pour la génération de test, scan complet, scan partiel..
Références
[1] Erik jan Marinissen & al, ″Towards a Standard for Embeded Core
Test : A examples″, 616-623, International Test Conference 1999
[2] Erik jan Marinissen & al, ″A Structurel and Scallable Mechanism
for Test access to Embeded Reusable Cores″, International Test
Conference 284-293,1998
[3] Yervant Aorin & al , ″Testing Embeded Core based System
Chips ″, 130-143 , International Test Conference 1998
[4] Rajesh K,Gup & al, ″Introducing Core-Based System ″,IEEE
design & test of computers,14(4),15-25,Dec 1997
[5] Robit Kapur & al , ″CTL Language for describing Core-based
Test ″, 131-139 , International Test Conference 2001
[6] Erik jan Marinissen & al ,″On IEEEP1500 Standard ″Journal of
electronic Testing :Theory and Application 18,365-383,2002
[7] Krishnendu Chakrabraty, ″ Optimal Test Access Architecture for
System On Chip ″,ACM Transactions on Design Automation of
Electronic Systems,26-49,Vol.6 No 1,Jan 2001
[8] Vikram Iyengar & al, ″Test Bus Sizing for System On
Chip″,Transactions On Computers,vol.51,No.5,May 2002
[9] Vikram Iyengar, Krishnendu Chakrabraty, ″Test Wrapper and
Test Access Mechanism Co-Optimisation for System On Chip″,
Transactions On Computers,vol.51,No.5,May 2002
[10] Krishnendu Chakrabraty, ″Design of System On Chip Test
Access Architecture Using Integer Linear Programming ,Proc.VLSI
Test symp,pp.127-134,2000
CONCLUSION
On a passé en aperçu les différents problèmes que
rencontrent les systèmiers ou concepteurs systèmes pour
faire des tests sur les SOCs.
[11] Vikram Iyengar & al, ″Design ad Optimisation of Multi-level
TAM Archtectures for Hierarchical SOCs
[12] Subbayu Basu & al, ″An Integrated Approach To testing
Embeded Cores and Interconnects Using Test Access Mechanism
(TAM) Switch ,Journal of Electronic Testing: Theory and Application
18,475-485,2002
Sachant que chaque solution apportée, fait un compromis
entre le temps de test, surface additionnelle sans oublie
qu’un test d’un cœur (ou des cœurs ) causent des
dissipations de puissance qu’on ne ne doit pas omettre
dans les solutions a apporter.
[13] Erik jan Marinissen & al, ″ Wrapper Design for Embeded Core
Test ″, 911-920, International Test Conference 2000
On cherche toujours des solutions qui doivent être
flexibles(portabilité, rajout d’extensions)
[13] Mounir Benbdenbi, ″Conception en vue du test pour les
Systèmes intégrés sur silicium SOC″, thèse de doctorat
septembre 2002
La solution matérielle ou logicielle doit être compatible a la
norme P1500.
Documentation Supplémentaire :
[14] Julien Pouget, ″ Test Intégré des Systèmes sur puces
SOCs″, thèse de doctorat 2002
Pour diminuer le temps de test, on peut solutionner les
problèmes par une implantation de plusieurs types de bus et
de plusieurs types d’accès aux cœurs.
10