Conception de FPGA et communications inter-FGPA dans le

Transcription

Université Bordeaux 1
MASTER 2 GSAT option ISEE
Année universitaire 2009/2010
Conception de FPGA
et communications inter-FGPA dans le cadre
du projet de recherche DreamWafer™
Rapport de Stage
Romain Clochard
Stage réalisé du 15 mars au 31 août 2010 :
Université du Québec à Montréal
Département Informatique – Laboratoire de Génie Microélectronique
CP8888 Montréal, H3C3P8, Québec, Canada
Responsable : Yves Blaquière
REMERCIEMENTS
Je tiens à remercier dans un premier temps M.Yves Blaquière, mon responsable de stage,
directeur des programmes en microélectronique de l'UQAM et directeur de recherche
DreamWafer™ pour sa disponibilité, son écoute et son aide précieuse.
Je remercie les différents partenaires et collègues de ce projet, au sein de l'UQAM et des
autres universités participant à ce projet.
Enfin je remercie Gestion Technocap Inc., le partenaire industriel principal du projet
DreamWafer™ pour la confiance témoignée à mon égard ainsi que pour les conseils de
Richard Prytula et Richard Norman.
Table des matières
RÉSUMÉ............................................................................................................................... 1
ABSTRACT.......................................................................................................................... 2
MOTS-CLEFS......................................................................................................................3
INTRODUCTION................................................................................................................4
CHAPITRE 1 : PROJET DREAMWAFER™...................................................................5
1.1 Présentation des Laboratoires.......................................................................................5
1.2 Organisation du Projet..................................................................................................5
1.3 Objectifs de DreamWafer™.........................................................................................6
CHAPITRE 2 : COMMUNICATIONS DANS LE WAFERBOARD™ ........................8
2.1 Le WaferBoard™ de l'intérieur....................................................................................8
2.1.1 WaferIC™ : description structurelle......................................................................9
2.1.1 WaferIC™ : description fonctionnelle.................................................................10
2.1.2 Réticules et Power Blocks...................................................................................10
2.2 Protocoles de communications...................................................................................11
2.2.1 Architecture.........................................................................................................12
2.2.2 Décisions sur le type de protocole.......................................................................13
2.2.3 Définition des Trames.........................................................................................14
2.2.4 Communications entre le Bottom PCB et les Power Blocks...............................15
a) Trame BOT-PB (Frame BOT-PB)...................................................................15
b) Trame PB-BOT (Frame PB-BOT)...................................................................17
c) Trame Erreur PB (Frame Error PB).................................................................18
CHAPITRE 3 : CONCEPTION DU FPGA DU POWER-BLOCK................................19
3.1 Choix technologiques.................................................................................................19
3.1.1 FPGA Actel Igloo AGL060.................................................................................19
3.1.1 Régulateur iP1202...............................................................................................20
3.2 Conception du bloc-diagramme..................................................................................20
3.2.1 « Top-Level »......................................................................................................20
3.2.2 Bloc de réception frame_rx.................................................................................23
a) Horloge et données entrantes...........................................................................23
b) Dispatcher.......................................................................................................24
3.2.3 FIFOs.................................................................................................................. 24
3.2.4 Registres.............................................................................................................. 25
3.2.5 Génération des signaux JTAG.............................................................................25
a) Fonctionnement de reticule_fsm.....................................................................25
b) Fonctionnement de jtag_fsm...........................................................................27
3.2.6 Bloc de transmission frame_tx............................................................................29
3.3 Précisions sur la programmation VHDL des blocs.....................................................29
3.3.1 Librairies et Packages.........................................................................................29
3.3.2 Registres et Machines à états..............................................................................29
3.3.3 Blocs FIFO..........................................................................................................30
3.3.4 Génération de TCK.............................................................................................30
3.3.5 Débogage............................................................................................................30
3.4 Environnement de Travail..........................................................................................30
3.4.1 Outils logiciels....................................................................................................30
3.4.2 Scripts et Simulation...........................................................................................31
3.5 Environnement de Test...............................................................................................31
3.5.1 Objectifs.............................................................................................................. 32
3.5.2 Réalisation..........................................................................................................32
3.5.3 Utilisation............................................................................................................ 32
3.5.4 Vecteurs de tests pour le débogage......................................................................35
3.6 Synthèse et tests sur carte d'évaluation.......................................................................36
CHAPITRE 4 : BILAN PERSONNEL.............................................................................37
4.1 Planification du travail personnel...............................................................................37
4.2 Organisation du projet................................................................................................37
4.3 Expérience vécue........................................................................................................38
CONCLUSION...................................................................................................................39
Glossaire.............................................................................................................................. 40
Références Bibliographiques.............................................................................................41
ANNEXES........................................................................................................................... 42
ANNEXE 1......................................................................................................................43
Spécifications Protocoles.....................................................................................43
ANNEXE 2......................................................................................................................59
Protocole JTAG...................................................................................................59
ANNEXE 3......................................................................................................................62
Cas de simulation................................................................................................62
ANNEXE 4......................................................................................................................65
Rapports Phase 11...............................................................................................65
ANNEXE 5......................................................................................................................68
Présentation CD / Contenu SVN.........................................................................68
RÉSUMÉ............................................................................................................................. 70
Index des Figures
Figure 1-1: Organisation du Projet.........................................................................................5
Figure 1-2: Fonctionnement du WaferBoard™.......................................................................6
Figure 2-1: Structure Physique du WaferBoard™..................................................................8
Figure 2-2: Structure du WaferIC™.......................................................................................9
Figure 2-3: Structure Interne d'un Réticule...........................................................................11
Figure 2-4: Architecture des communications dans le WaferBoard™..................................12
Figure 2-5: Protocoles dans le WaferBoard..........................................................................14
Figure 2-6: Trame BOT-PB..................................................................................................15
Figure 2-7: Trame PB-BOT..................................................................................................17
Figure 2-8: Trame Erreur PB................................................................................................18
Figure 3-1: Communications du FPGA................................................................................19
Figure 3-2: Bloc-Diagramme "Top-Level"...........................................................................21
Figure 3-3: Bloc-Diagramme frame_rx................................................................................24
Figure 3-4: Machine à états du bloc reticule_fsm.................................................................26
Figure 3-5: Exemple de référence pour l'envoi de signaux vers les réticules........................27
Figure 3-6: Machine à états du bloc jtag_fsm.......................................................................28
Figure 3-7: Arborescence des fichiers VHDL.......................................................................29
Figure 3-8: Scripts de simulation..........................................................................................31
Figure 3-9: Interface de l'environnement de test...................................................................33
Figure 3-10: Méthode de test employée................................................................................33
Figure 3-11: Fichier LogFileIn (trames pour simulation).....................................................34
Figure 3-12: Fichier LogFileOut (résultats simulation)........................................................35
Figure 4-1: Diagramme de Gantt..........................................................................................37
RÉSUMÉ
RÉSUMÉ
Ce stage s'inscrit dans le projet de recherche DreamWafer™ qui vise à développer
une plateforme de prototypage rapide pour les systèmes électroniques appelée
WaferBoard™. L'ambition du projet est de réaliser pour les systèmes électroniques ce
que les FPGA sont aux microprocesseurs : rendre possible une reprogrammation
complète du circuit.
L'utilisateur du WaferBoard™ place les composants sur la surface du WaferIC™ et
referme un couvercle : les composants sont repérés, identifiés, alimentés. Les
connexions entres les circuits peuvent être configurées : le prototype est prêt à
fonctionner.
Pour son fonctionnement interne, le WaferBoard™ comprend plusieurs PCB équipés
de FPGAs.
Ce document porte sur ma contribution à ce projet sur les points suivants :
• La création des protocoles de communication entre FPGA ainsi que la
rédaction des spécifications.
• La conception ou « design » des FPGA des Power Blocks (circuits imprimés
inclus dans le WaferBoard™ ) en langage VHDL.
• La mise au point d'un environnement de test en langage C++, conforme aux
spécifications établies et permettant un débogage avancé du design.
Ces travaux constituent une première étape importante dans le design des FPGA des
autres PCB ainsi que dans la création du logiciel qui pilotera le WaferBoard™.
DreamWafer™ : Conception de FPGA et communications inter-FGPA
Page 1
ABSTRACT
ABSTRACT
This internship was done within the context of the DreamWafer™ project which aims
at the creation of a new rapid prototyping system for electronic systems. The goal of
this project is to design a reprogrammable electronic system as FPGAs can be for
microprocessors.
The WaferBoard™ user simply places components on the WaferIC™ and closes the
cover : components are sensed, identified and powered. Connexions between
components can be established : the prototype is ready to run.
The Waferboard internal architecture includes PCBs with FPGA.
My contributions to this innovative project were :
• The creation of the WaferBoard™ communications protocols and
specifications writing.
• The Power Block FPGA design with VHDL description (a Power Block is a
small substrate flip-chipped onto the back of the Wafer)
• The creation of an environment test according to the protocols specifications in
order to debug the Power Block Design (developed in C++)
This work is a first step toward the FPGA design of others PCBs and the creation of
the WaferBoard™ software.
Page 2
MOTS-CLEFS
MOTS-CLEFS
PROTOTYPAGE
PCB
PROTOCOLES
FPGA
VHDL
Page 3
INTRODUCTION
INTRODUCTION
Les systèmes électroniques modernes comportent de nombreux composants intégrés dans un
même circuit.
Le coût de développement de ces systèmes est élevé, notamment en raison de la fabrication
de prototypes.
Le projet DreamWafer™ vise à réaliser une plateforme de prototypage rapide de systèmes
électroniques. Il va permettre de réduire considérablement le temps de développement des
systèmes électroniques : de quelques mois à quelques minutes ! Il permettra également de
réduire le coût de fabrication du prototype : le circuit pourra être mis en fonction avant sa
fabrication !
C'est pour ce projet et dans le cadre du Master 2 GSAT (Génie des Systèmes pour
l'Aéronautique et les Transports) option ISEE (Ingénierie des Systèmes Électroniques
Embarqués), que j'ai effectué ce stage du 15 mars au 31 août 2010. Il s'est effectué au sein
du laboratoire de génie microélectronique du département d'informatique de l'Université du
Québec à Montréal (UQÀM) au Canada.
Ce document présente tout d'abord l'organisation du projet, puis mes contributions sur les
protocoles de communication, le design du FPGA du Power Block et son environnement de
test. Enfin un bilan personnel de cette expérience est dressé.
Page 4
CHAPITRE 1 : PROJET DREAMWAFER™
1.1 Présentation des Laboratoires
La faculté des sciences de l'Université du Québec à Montréal possède, au sein de son département
d'informatique un laboratoire de génie microélectronique. Ce stage s'est déroulé en majeur partie au
sein de ce laboratoire qui est équipé d'appareils et de logiciels qui répondent aux normes de
l'industrie. Une dizaine de professeurs sont impliqués dans le programme de génie
microélectronique.
Dans le cadre de ce stage, j'ai aussi pu profiter des installations du groupe de recherche en
microélectronique (GRM) de l'École Polytechnique de Montréal.
1.2 Organisation du Projet
Le projet DreamWafer™ est né d'une série de brevets et de l'investissement de Gestion TechnoCap
Inc., société basée à Montréal. Le brevet principal a été enregistré fin 2006.
Le système de prototypage rapide en cours de réalisation constitue la partie technique du projet
DreamWafer™ qui rassemble plusieurs universités canadiennes comme l'indique la figure 1-1 :
Figure 1-1: Organisation du Projet
•
•
•
•
l'Université du Québec à Montréal (UQÀM)
l'École Polytechnique de Montréal
l'Université du Québec en Outaouais (UQO)
l'Université du Québec à Trois-Rivières (UQTR)
Page 5
Le chef de projet, coté technique, est M. Yves Blaquière (UQÀM). Chaque étudiant et professeur
apporte une contribution au projet dans son domaine de compétences : mécanique,
thermomécanique, design en microélectronique...
Des réunions mensuelles sont organisées au sein des locaux de Gestion TechnoCap afin de discuter
des résultats obtenus, des travaux à effectuer ainsi que des axes de développement.
Ce projet, outre le soutien de Gestion TechnoCap Inc., voit également la participation directe de
plusieurs entreprises dans la conception du système : Allvia, BrioConcept, Tower Semiconductor,
Sound Design Technologies, Brioconcept. Des partenariats existent également avec des instituts et
entreprises telles que CMC Microsystems, Hyperchip Inc., Natural Sciences and Engineering
Research Council of Canada (NSERC), PROMPT, Precarn, Hydro-Québec Research Institute
(IREQ).
1.3 Objectifs de DreamWafer™
Basé sur de nombreux brevets, DreamWafer™ ouvre de nouvelles possibilités pour les entreprises
spécialisées dans l'électronique et le prototypage [1]. Il a pour ambition de réaliser pour les PCB
(Printed Circuit Board) ce que les FPGA sont aux microprocesseurs, c’est à dire la possibilité de
reprogrammation complète du circuit. Le WaferBoard™, produit en cours de conception dans le
cadre de ce projet, est composé d’un PCB classique pouvant être relié à un ordinateur et d'une
surface sur laquelle placer les composants électroniques : le WaferIC™. Les différentes étapes de
l'utilisation de cet appareil sont détaillées sur la figure 1-2.
Figure 1-2: Fonctionnement du WaferBoard™
Page 6
Comme le montre la figure 1-2, le système relié à l'ordinateur détecte les composants installés (sans
restriction de placement). L'utilisateur fournit ensuite, via le logiciel, une netlist au WaferBoard™.
Le rôle du logiciel est :
• de présenter à l’utilisateur les broches des composants détectés
• de réaliser la séquence de démarrage de la carte (détection des pannes internes et
visualisation de celles-ci)
• de traduire et d'envoyer la netlist fournie par l’utilisateur (il est ensuite possible de
programmer un nombre illimité de netlists)
A terme, le WaferBoard™ embarquera un analyseur logique permettant de dériver n’importe quel
signal et d'enregistrer son comportement dans le temps, le tout de façon entièrement
reprogrammable sur plusieurs millions de connexions. A l’heure actuelle, les meilleurs systèmes
capables de proposer de telles solutions atteignent quelques dizaines de milliers de connexions
seulement, à un coût fortement rédhibitoire.
Les avantages de la solution WaferBoard™ sont multiples :
•
•
•
•
il n’est pas nécessaire de refaire une carte lorsque le prototype est défectueux
la phase de déverminage est beaucoup plus rapide
embarquer un analyseur logique coûte très peu cher (prix de la mémoire), ceux présents sur
le marché sont très coûteux, complexes et difficiles à mettre en place sur un PCB classique
le système est entièrement réutilisable pour des circuits différents
La précédente analogie faite entre les FPGA et le WaferBoard™ peut être poussée jusqu’au niveau
de la production : tout comme les ASIC ont un coût de production inférieur aux FPGA pour de
grands volumes, un design fait à l’aide d’un PCB aurait un coût de production inférieur à un
WaferBoard™ pour un design vendu en grande quantité. Par contre, il est connu qu’un système
réalisé à l’aide de FPGA peut rivaliser en termes de coût de production avec les ASIC pour les
produits complexes vendus en volume modéré.
Page 7
CHAPITRE 2 : COMMUNICATIONS DANS LE WAFERBOARD™
CHAPITRE 2 : COMMUNICATIONS DANS
LE WAFERBOARD™
Ma première contribution à ce projet portait sur l'établissement des protocoles de communication
entre le futur logiciel et les différents PCB équipés de FPGA et la rédaction des spécifications
associées. Une présentation plus avancée du WaferBoard™ est nécessaire afin de comprendre
comment ces protocoles ont été créés. Certains points ne peuvent cependant être détaillés pour des
raisons de confidentialité.
2.1 Le WaferBoard™ de l'intérieur
Le WaferBoard™ est un système de prototypage rapide pour les circuits numériques. Il permet de
tester et valider rapidement des circuits au niveau système. Il permet un placement des composants
insensible à l’alignement contrairement aux PCB où les circuits discrets doivent être soigneusement
alignés sur des plots avant d'être soudés.
Il est notamment composé d'un «substrat programmable», le WaferIC™, et de plusieurs PCB (voir
figure 2-1), tous équipés de circuits logiques programmables (FPGA) :
• 1 Top PCB (relié à l'ordinateur)
• 1 Bottom PCB
• 21 Power Blocks
Figure 2-1: Structure Physique du WaferBoard™
Page 8
Une poche (« Pouch » sur la figure 2-1) permet le refroidissement des composants placés sur le
WaferIC™.
2.1.1 WaferIC™ : description structurelle
Le WaferIC™ autrement appelé «substrat programmable» est un circuit électronique de type «
wafer scale integration » (WSI), c'est-à-dire un circuit intégré au niveau de la tranche de silicium.
Cette technologie permet la communication de données entre les réticules composant une tranche.
Ces données sont propagées directement par les couches de métallisation intégrées sur la tranche de
silicium.
Une telle approche d’intégration à l’échelle de la tranche offre principalement deux avantages :
• avoir une grande densité de contacts, capables de supporter l'interconnexion des puces les
plus miniaturisées
• permettre une densité d'interconnexions suffisante pour mettre en place des systèmes
entiers
Comme on peut le voir sur la figure 2-2, chaque réticule composant le WaferIC™ est constitué
d'une «mer» de cellules, toutes identiques au niveau physique.
Figure 2-2: Structure du WaferIC™
Les cellules composant le WaferIC™ ne sont différenciées que par le contenu de leur mémoire
interne une fois le circuit configuré. La mémoire interne sert à configurer un crossbar (l'élément de
base du WaferNet) permettant de définir la topologie du système.
Chacune de ces cellules est couverte à sa surface de NanoPads, qui sont autant de points de contact
Page 9
possibles avec des billes de composants déposés sur le WaferIC™. L'espacement des NanoPads
étant très faible, une bille est en contact avec environ quatre NanoPads, même pour les plus petits
packages. Les NanoPads sont connectés au réseau interne reconfigurable du WaferIC™ appelé
WaferNet [2].
2.1.1 WaferIC™ : description fonctionnelle
Le WaferIC™ remplie principalement les fonctions suivantes :
• il envoie les informations sur le placement des circuits intégrés au logiciel.
• Il reçoit la « netlist » représentant l’interconnexion des broches du système à concevoir, et
effectue les connexions afin de permettre le transfert des signaux.
Cependant, le WaferIC™ ne possède peu ou pas d'intelligence propre afin de minimiser la surface
nécessaire au contrôle logique. En somme, il ne fait que répondre passivement aux commandes
numériques issues du logiciel.
Un système de communication sérielle doit être adopté afin de permettre une communication
bidirectionnelle entre le WaferIC™ et le logiciel installé sur l'ordinateur de l'utilisateur.
Ce système, créé précédemment dans le cadre du projet, est compatible avec le protocole JTAG [3]
décrit en annexe 2 de ce rapport. La logique qui le supporte est répétée de manière uniforme sur
toutes les cellules du WaferIC™ pour respecter la contrainte de design qui exige que chaque cellule
soit autant que possible uniforme.
Il faut également que le système de programmation soit tolérant aux pannes, reconfigurable en
fonction des «zones mortes» du circuit. Ceci a fait l'objet de travaux au sein de l'équipe
DreamWafer™ [4].
Sans entrer très profondément dans le protocole JTAG adapté au WaferIC™ (se référer aux travaux
antérieurs de l'équipe, notamment ceux effectués par Yann Basile-Bellavance), on peut tout de
même préciser que celui-ci supporte 4 modes :
1. Mode diagnostic du WaferIC™ : Il localise les fautes pour en permettre l'évitement.
2. Mode de programmation du WaferNet : accède aux registres “scan” (les registres
accessibles par décalage) d’un ensemble de cellules pour configurer le WaferNet et pour
interconnecter les billes des puces déposées sur le WaferIC™.
3. Mode de contrôle externe : prend en charge les fonctionnalités des cellules voisines. Cette
fonctionnalité est utilisée comme stratégie pour la tolérance aux fautes.
4. Mode de détection de contacts : un contact entre la surface du WaferIC™ et les broches
d’un circuit intégré déposé sur le WaferIC™ est détectable par court-circuit [5] puisque les
broches sont composées de matériaux conducteurs.
2.1.2 Réticules et Power Blocks
Les circuits intégrés sont fabriqués à partir de la répétition d’images essentiellement carrées sur une
tranche de silicium par le principe de la photo-lithographie [6]. La structure ‘imprimée’ de façon
répétitive sur la surface de la tranche est communément appelé un réticule et son empreinte sur la
surface de la tranche n’excède typiquement pas 2,5 cm de coté. Par conséquent, tout design de
circuit intégré à l’échelle de la tranche de silicium (comme le WaferIC™) doit être composé d’un
agencement de cellules régulier à l’échelle de l’image d’un réticule.
Page 10
Un Power Block est un PCB (Printed Circuit Board) miniature « gérant » assurant les fonctions
suivantes :
• alimentation en tension du WaferIC™ par l'intermédiaire d'un régulateur de tension.
• assurer la communication entre le logiciel et le WaferIC™, dans le cadre du protocole JTAG
adapté au WaferIC™. Ceci s'effectue par l'intermédiaire d'un FPGA.
Chaque Power Block étant identique, il est obligatoire d'avoir au moins un lien de communication
par réticule : cette communication se fait selon le protocole JTAG (voir annexe 2). On retrouve
ainsi, par réticule, cinq « ports » correspondant aux signaux JTAG, positionnés de la même manière
sur chaque réticule :
• TCK : signal d'horloge
• TRST : reset
• TMS : signal de contrôle
• TDI : données entrantes
• TDO : données sortantes
L'alimentation en puissance (VDD3.3, VDD1.8 et GND) et les cinq fils JTAG parviennent aux
Power Blocks par des trous gravés dans le silicium, les TSV (Through Silicon Via).
La structure interne d'un réticule est décrite figure 2-3 :
Figure 2-3: Structure Interne d'un Réticule
2.2 Protocoles de communications
Le logiciel installé sur l'ordinateur de l'usager du WaferBoard™ est chargé de l'auto-test, la
configuration, la programmation et le test du système en cours de prototypage. Les données fournies
par l'ordinateur sont des bits de configuration permettant au substrat programmable d'adapter sa
topologie de connexions internes afin d'implémenter une « netlist » représentant les interconnexions
voulues par un ingénieur procédant au design d'un système numérique.
La conception du logiciel n'en est qu'à son tout début, c'est une des tâches « finales » du projet.
À mon arrivée sur ce projet, si « l'architecture matérielle » est connue, les protocoles de
communications entre le logiciel et les PCB équipés de FPGA ne sont pas établis.
Page 11
2.2.1 Architecture
L'architecture des communications a été établie selon la figure 2-4. Les débits y sont indiqués pour
chaque liaison.
Figure 2-4: Architecture des communications dans le WaferBoard™
Le PC envoie des données qui sont relayées, à travers trois PCB, comprenant tous un FPGA :
Le FPGA du Top PCB communique avec le PC, le Bottom PCB ainsi qu'avec les composants placés
sur le WaferIC™, pour la gestion des signaux notamment.
Le FPGA du Bottom PCB est chargé de la redirection des données vers les 21 Power Blocks et de la
gestion de ventilateurs, capteurs et régulateurs.
Les FPGA des Power Blocks, les premiers à être conçus ou « designés » dans ce projet, effectuent
les tâches suivantes :
• la commande d'un régulateur de tension
• l'envoi de signaux JTAG vers les réticules. Ces signaux sont essentiellement des séries de
bits de données TDI (données entrantes dans le protocole JTAG) d'une taille pouvant aller
jusqu'à plusieurs dizaines de kilobits.
• la réception de signaux JTAG provenant des réticules : chaque bit TDI envoyé provoque
automatiquement l'émission d'un bit de données TDO (données sortantes du JTAG).
Page 12
2.2.2 Décisions sur le type de protocole
Partant de l'architecture de la figure 2-4, deux grands types de protocoles ont émergés des
discussions entre différents membres du projet, notamment sur la manière de commander les
réticules :
Solution 1 (ébauche) :
Header
Data R1 Data R2 Data R3 Data •R4 Data R1
Le header contient des champs : adresse destination, longueur des données (nombre de blocs Data).
Les champs DATA R1 à R4 de la trame contiennent les 4 signaux JTAG (TDI, TCK, TMS, TRST) à
transmettre à chacun des quatre réticules.
Avantages :
• Simplicité du design FPGA
• Possibilité de commander les différents réticules d'un power-block simultanément
Inconvénients :
• Fonctionnement plus lent avec notamment une surcharge des communications (goulot
d'étranglement) au niveau de la liaison entre le PC et le Top PCB (voir figure 2-4)
• Transmission, pour chaque bit de donnée entrant (TDI), des signaux TCK, RST, TMS depuis
le logiciel jusqu'au réticule alors que ceux-ci changent très rarement d'état (RST, TMS) ou
peuvent être reproduits localement par le FPGA (TCK)
Solution 2 (ébauche) :
Header
Command
Data
Le header contient des champs : adresse source, destination, identification trame.
Le champ command est une commande « haut niveau » JTAG (shift data register, test logic reset,
shift instruction register..., voir annexe 2) traduite au niveau du FPGA du Power Block afin de
générer les signaux TMS, TCK et TRST.
Le champ data contient une suite de bits pour le TDI (chaines entières ou fragmentées)
Avantages :
• On ne transmet pas les bits TCK, TRST et TMS à travers tout le WaferBoard™
• Fonctionnement plus rapide que la solution 1 (moins de trafic entre PC et Top PCB)
Inconvénients :
• Difficultés pour envoyer des données à plusieurs réticules simultanément : la taille des
données étant différente pour chaque réticule, le découpage du champ Data pose problème
• Complexité du design des FPGA : génération locale de signaux TMS, gestion de FIFO
La solution 2 a finalement été adoptée. Elle présente l'énorme avantage d'alléger les
communications à travers tout le WaferBoard™ : réduction de 40 à 70% des données émises par le
logiciel pour la commande des réticules suivant la quantité de signaux JTAG à transmettre.
Page 13
Cependant, ce choix engendre une plus grande complexité pour le design et la programmation du
FPGA. Il est également difficile avec cette solution et avec un petit FPGA (nous le verrons plus
loin) de pouvoir commander plusieurs réticules à l'aide d'une seule trame.
2.2.3 Définition des Trames
Avant de pouvoir concevoir le FPGA des Power Blocks, il faut établir des spécifications sur les
protocoles de communications dans le WaferBoard™. Celles-ci seront une base de travail pour la
conception du futur logiciel. Elles ont fait l'objet de nombreuses modifications et elles portent
encore le titre de « spécifications préliminaires » car elles ne sont complètes que pour la partie
Power Block. Elles sont disponibles en annexe 1 de ce rapport et ont été rédigées en anglais.
Les communications sont basées sur les protocoles et trames de la figure 2-5.
Figure 2-5: Protocoles dans le WaferBoard
Il s'agit ici d'un système d'encapsulation. Par exemple, les données utiles pour le FPGA du Power
Block sont envoyées depuis le PC et acheminées à travers plusieurs trames : PC-TOP, TOP-BOT,
BOT-PB. Les protocoles créés pour ce système présentent quelques similitudes avec le protocole
Ethernet : adresses source et destination suivies de données et d'un champ de contrôle de type
CRC.
Si les communications sont détaillées en annexe 1 de ce rapport, quelques points sont à souligner :
Page 14
•
•
Chaque trame reçue par un Power Block entraîne systématiquement une réponse de ce
dernier par un trame d'erreur (Error PB) ou de donnée (Frame PB-BOT).
La longueur des trames est obligatoirement un multiple d'un octet afin d'assurer la
compatibilité avec le protocole USB [7] utilisé pour la liaison PC-Top PCB.
2.2.4 Communications entre le Bottom PCB et les Power Blocks
Les communications entre le Bottom PCB et les Power Blocks nous intéressent plus
particulièrement ici. Trois types de trames concernant les Power Blocks ont été créés :
a) Trame BOT-PB (Frame BOT-PB)
Sa taille peut varier de 9 à 1017 octets. Ce maximum est conditionné par la taille maximum
admissible par une paquet de donnée USB [7].
En-tête
12 bits
Sync
2
bits
Source
2
bits
Destination
5
bits
Subdestination
18
bits
Frame
ID
Données CRC
6
bits
PB Destination
6
bits
Command
13 bits
Length
0 à 1008
octets
Data
8
bits
CRC
Figure 2-6: Trame BOT-PB
Sync : Le champ Sync (pour synchronisation) est un préambule à la trame permettant d'assurer la
bonne synchronisation entre l'émetteur et le récepteur de la trame (valeur fixe :1010 1010 1011).
Source : Identifie l'émetteur de la trame dans le système. Le système d'adressage ci-dessous est
utilisé pour l'ensemble des champ « source » et « destination » des différentes trames :
Adresses
00
PC
01
Top PCB
10
Bottom PCB
11
Power Block
Destination : Identifie le destinataire de la trame selon le système d'adressage précédent.
Subdestination : Identifie à quel Power Block la trame est destinée. On peut envoyer la même
trame à tous les Power Blocks. C'est alors le Bottom PCB qui se charge de répéter l'envoi de la
trame. Le FPGA d'un Power Block ne « connaît pas » son adresse.
Adresse Subdestination pour les
Power-Blocks
0 0000
Tous les Power Blocks
0 0001
Power Block 1
0 0010
Power Block 2
0 0011
Power Block 3
...
...
1 0101
Power-Block 21
autres
Non utilisé
Frame ID : Ce champ identifie la trame, il est donc primordial pour le logiciel afin de gérer les
communications. Il doit être unique dans le WaferBoard™ pendant toute la durée de vie de la trame.
Il permet également de différencier une trame de donnée (Frame BOT-PB) d'une trame d'erreur
Page 15
(Error PB) pour le FPGA du Bottom PCB.
Bit 17 Bit 16 Bit 15
Bits 14-10
Bits 9-0
EF
FP
LF
Numéro de Fragment Numéro de Paquet
EF : indique s'il s'agit d'une trame d'erreur (1) ou non (0)
FP : indique si la trame fait partie d'un « paquet fragmenté » (1 : oui; 0 : non). Ce mécanisme de
fragmentation permettra au logiciel de pouvoir envoyer à un élément du système une quantité de
données supérieure à la capacité du champ data. L'ensemble des données est appelé « paquet » et
chaque partie du paquet est appelé « fragment ».
LF : indique si la trame constitue le dernier fragment d'un paquet (1 : oui; 0 : non).
Numéro de Fragment : identifie le fragment (0 pour un paquet non fragmenté).
Numéro de Paquet : Ce numéro doit être identique pour tous les fragments d'un paquet.
PB Destination : Indique à quel élément interne du Power Block s'adresse la trame. On peut
théoriquement adresser la trame à plusieurs réticules, mais cette option n'est pour l'instant pas
implémentée en raison des capacités réduites du FPGA des Power Blocks. Un seul élément doit
donc être sélectionné ici :
Bit 5
Bit 4
Bit 3
Bit 2
Bit 1
Bit 0
Régulateur FPGA Réticule 4 Réticule 3 Réticule 2 Réticule 1
Command : Indique la commande à appliquer à l'élément sélectionné dans « PB Destination » :
Pour un réticule : représente une commande avancée JTAG (protocole JTAG adapté au
WaferIC™).
Commande pour les Réticules (Commande avancée JTAG)
Code Binaire
Nom Commande
Description
00 0000
trst
Effectue un reset par le signal TRST JTAG
00 0001
reset
Effectue un reset logique par la machine à état
« tap controller »
00 0010
start_shift_ir*
Début du décalage des données dans le registre
d'instructions
00 0011
on_shift_ir*
Poursuite du décalage des données dans le
registre d'instructions
00 0100
end_shift_ir*
Fin du décalage des données dans le registre
d'instructions.
00 0101
start_shift_dr*
Début du décalage des données dans le registre
de données
00 0110
on_shift_dr*
Poursuite du décalage des données dans le
registre de données
00 0111
end_shift_dr*
Fin du décalage des données dans le registre de
données
autres
Non utilisé
Non utilisé
* la trame doit inclure des données dans le champ data.
•
Page 16
•
Pour le FPGA : permet l'accès en lecture/écriture suivant le cas, à des registres implantés
dans le FPGA. Les registres principaux sont :
◦ fifo_rst : permet un reset des FIFOs du FPGA.
◦ freq_ctrl_reg : détermine la fréquence du signal d'horloge TCK du JTAG.
◦ counters_reg : comptabilise les trames reçues (statistiques, débogage).
◦ last_id_reg : mémorise l'identifiant de la dernière trame reçue.
•
Pour le régulateur : permet l'accès en lecture/écriture suivant le cas, à des registres
implantés dans le FPGA. Ceux-ci permettent notamment de commander les sorties du
régulateur.
Pour plus de détail sur les registres, se rendre en annexe 1.
Length : Indique la longueur du champ data et le nombre de bits utiles dans le dernier octet. Le
champ Data doit être obligatoirement un multiple d'un octet afin de pouvoir assurer une
compatibilité avec le protocole USB utilisé dans liaison PC – Top PCB et de garder une certaine
cohérence. Cependant, comme les données utiles ne sont pas toujours multiples d'un octet, 3 bits
sont réservés pour déterminer le nombre de bits utiles dans le dernier octet de donnée (1 à 8 bits
utiles).
Bits 13 - 3
Bit 2-0
Taille des données en octets Bits utiles dans le dernier octet
Data : Données utilisées par le Power Block (TDI JTAG ou données à écrire dans un registre).
CRC : Champ CRC (Cyclic Redundancy Check ) destiné à vérification l'intégrité de la trame
(n'inclut pas le champ Sync dans le calcul). Le polynôme utilisé pour le calcul est le suivant :
C(x) = x8 + x2 + x + 1
b) Trame PB-BOT (Frame PB-BOT)
Une trame PB-BOT est envoyée par un Power Block quand celui-ci reçoit une trame BOT-PB
correcte.
En-tête
Données
CRC
12 bits
7
bits
2
bits
18
bits
6
bits
6
bits
13 bits
0 à 1008
octets
8
bits
Sync
Source
Destination
Frame
ID
PB Destination
Command
Length
Data
CRC
Figure 2-7: Trame PB-BOT
Les champs Sync, FrameID, PBDestination, Command sont une copie des même champs de la
trame BOT-PB à laquelle la trame PB-BOT répond.
Source : constitué à partir de la trame BOT-PB reçue :
Page 17
Bits 6-5
Champ Destination de la trame BOT-PB
Bits 4-0
Champ Subdestination de la trame BOT-PB
Destination : copie du champ source de la trame BOT-PB reçue.
Length : est identique au même champ de la trame BOT-PB reçue excepté pour la lecture d'un
registre (le champ Data n'est alors pas vide et contient les données du registre)
Data : contient les données destinées au logiciel (TDO JTAG, contenu registre).
CRC : calculé selon le même polynôme que pour la trame BOT-PB.
c) Trame Erreur PB (Frame Error PB)
Une trame d'erreur est envoyée par un Power Block lorsqu'une erreur avec un trame BOT-PB se
produit. Pour le FPGA du Bottom PCB, cette trame se différencie de la trame PB-BOT par le
premier bit du champ Frame ID (1 pour une trame d'erreur et 0 pour une trame PB-BOT).
12
bits
Sync
7 bits
2 bits
18 bits
9 bits
8 bits
Source
Destination
Frame ID
Error Code
CRC
Figure 2-8: Trame Erreur PB
La trame erreur PB se base sur les mêmes standards que les deux trames précédentes à l'exception
du code d'erreur (Error Code) :
Error Code
Valeur Décimale
Type d'erreur
0
Erreur CRC
1
Erreur Régulateur
2
FIFO TDI plein
3
FIFO TDO plein
4
Commande JTAG Illégale
autres
inutilisé
Page 18
CHAPITRE 3 : CONCEPTION DU FPGA DU POWER-BLOCK
CHAPITRE 3 : CONCEPTION DU FPGA DU
POWER-BLOCK
Les protocoles de communication du WaferBoard™ établis, le design et la programmation du FPGA
peuvent commencer. Ceci constitue la deuxième étape de ma contribution au projet, la troisième
étant l'élaboration d'un environnement de test destiné à la vérification et au débogage du design.
3.1 Choix technologiques
Des choix technologiques concernant ce PCB miniature qu'est le Power Block ont été préalablement
effectués : schéma du circuit, choix des composants.
En se référant à ces choix, le schéma des communications concernant le FPGA est le suivant (figure
3-1) :
Figure 3-1: Communications du FPGA
3.1.1 FPGA Actel Igloo AGL060
Le FPGA implanté dans les Power Blocks est produit par la société Actel. Il fait partie de la famille
Igloo qui est réputée pour sa basse consommation de puissance. Le modèle choisi est l'AGL060V5
avec un package de 121 broches (CS121).
C'est un FPGA de petite taille (6mm x 6mm), avec des ressources limitées pour un design
relativement complexe à mettre en œuvre :
• 96 entrées / sorties.
• 1536 bascules (flip-flops)
Page 19
•
•
4 blocs de mémoire SRAM de 4kbits chacun pouvant être configurés en FIFO (synchrones
uniquement), 1 kbit de FlashROM.
6 blocs CCC (Clock Conditioning Circuit) permettant d'agir sur le signal d'horloge. Il n'y a
cependant pas de possibilité d'implanter une PLL pour resynchroniser l'horloge.
3.1.1 Régulateur iP1202
Le régulateur iP1202 est produit par International Rectifier. Il comporte deux sorties commandées
par des entrées « enable » qui sont ici couplées (voir figure 3-1).
Deux entrées Soft Start (SS1 et SS2) permettent une mise en tension plus lente des sorties.
Une sortie PGOOD est activée lorsque la tension d'une des deux sorties est inférieure à 85% de la
tension de référence.
3.2 Conception du bloc-diagramme
La conception du bloc diagramme est une étape indispensable pour un design de cette complexité.
C'est une étape plus longue que la programmation en elle-même. Cela demande une vision
d'ensemble des fonctionnalités devant être assurées par le FPGA et une connaissance des
possibilités matérielles du circuit.
3.2.1 « Top-Level »
Le « Top-Level » (figure 3-2 de la page suivante) est l'architecture globale du FPGA du Power
Block. Les blocs de ce top-level comportent pour la plupart des sous-blocs. Chacun de ces blocs
trouve son équivalence dans un fichier VHDL, qui est le langage de description matérielle choisi
pour concevoir le circuit.
Voici une description sommaire du rôle de chaque bloc (classé par ordre alphabétique) :
clock_controller :
• Règle la fréquence d'envoi des données JTAG aux réticules par la création du signal
d'horloge tck_ret.
frame_rx :
• Reçoit du Bottom PCB les données sérielles (Frame BOT-PB) et l'horloge (clock
forwarding).
• Crée une horloge locale synchronisée sur les données (clk) en utilisant un CCC (clock
conditionning circuit) du FPGA.
• Analyse, segmente la trame BOT-PB reçue : vérification CRC, longueur de la trame,
destination.
• Envoie au header_crc_fifo les données utiles de la trame BOT-PB pour constituer les trames
PB-BOT ou Error PB : Source, Destination, Subdestination, Frame ID, PB Destination,
Command, Length ainsi que l'information sur la validité du CRC. Ces données sont aussi en
partie utilisées par reticule_fsm (PB Destination, Command, Length) lorsque la trame est
destinée aux réticules.
• Suivant les champs PB Destination et Command, effectue une des actions suivantes :
◦ Si la trame est destinée aux réticules et contient des données : envoie les données vers le
tdi_fifo.
◦ Si la trame est destinée au régulateur : envoie les données du champ command (6 bits)
vers le regulator controller.
Page 20
Figure 3-2: Bloc-Diagramme "Top-Level"
Page 21
◦ Si la trame est destinée au réglage de tck_ret (horloge des signaux JTAG) : envoie les
données du champ data vers le clock controller.
◦ Si la trame est destinée à la lecture des registres de frame_rx : envoie les données des
registres vers register_ctrl.
• Contient les registres : last_id_reg (FrameID de la dernière trame reçue), counters_reg
(compteur de trames et compteur d'erreur CRC) et freq_ctrl_reg (réglage de la fréquence
tck_ret)
frame_tx :
• Gère l'envoi des trames PB-BOT / Error PB vers le Bottom PCB.
• Reçoit du header_ctrl les données pour constituer les trames (header).
• Reçoit du tdo_fifo et du register_ctrl les données pour constituer les trames (champ Data).
Mets en forme les données tdo (sérialisation et alternance).
• Reçoit les informations « fifo plein » et génère alors une trame d'erreur.
• Génère le CRC de la trame envoyée.
• Reçoit du reticule_fsm, l'information « données prêtes » à partir de laquelle les données de
tdo_fifo peuvent être lues.
header_crc_fifo :
• « Hard FIFO » synchrone de 4608bits : 9 bits de large, 512 bits de profondeur. Contient les
données « header » utiles pour constituer les trames PB-BOT ou Error PB : Source,
Destination, Subdestination, Frame ID, PB Destination, Command, Length (52 bits). +
information sur la validité du CRC + 1 bit à 0 (non utilisé). Soit 54 bits au total.
• Transmet ces 54 bits au bloc header_ctrl sur demande, en 6 blocs de 9bits.
header_ctrl :
• Vient lire les 54bits (6 mots de 9bits) contenus dans header_crc_fifo dès que celui-ci n'est
pas vide. Stocke ses 6 mots dans des registres.
• reticule_fsm vient lire les registres afin de déterminer si la trame est destinée aux réticules
(les registres ne sont pas vidés).
• Lorsque frame_tx vient lire les registres, ceux-ci sont effacés, une nouvelle lecture de
header_crc_fifo peut commencer.
jtag_demux :
• Dirige les données JTAG envoyées par jtag_fsm et tdi_fifo vers le réticule sélectionné par
reticule_fsm (envoi des données synchronisé sur tck_ret).
• Arrête le signal tck du réticule sélectionné sur ordre de reticule_fsm.
jtag_fsm :
• Fonctionne selon une machine à états finis.
• Doit générer des séquences de signaux TMS conformément à la machine à état tap controller
de la norme JTAG : reçoit l'état courant et « futur » de la machine par ret_last_states.
• Mets à jour ret_last_states à la fin du traitement.
• Contrôle le fonctionnement de jtag_demux et la lecture de tdi_fifo.
register_ctrl :
• Envoie les données des registres vers frame_tx lors d'une requête en lecture.
• Commande les reset des FIFO tdi_fifo et tdo_fifo.
regulator_controller :
• Commande les signaux SS1, SS2 et Enable du régulateur. Reçoit les informations PGOOD
(niveaux de tension des sorties corrects ou non).
• Possède un registre interne (voir spécifications protocoles, annexe 1) . Les données de ce
Page 22
registre sont envoyées à register_ctrl si demandé.
ret_last_states :
• Reçoit du reticule_fsm la commande jtag avancée ainsi que le réticule à commander (3 bits +
2 bits).
• Envoie à jtag_fsm l'état courant et l'état « futur » du réticule (états conformes à la machine à
état tap controller) : 2bits + 2bits
• Stocke les états courants des 4 machines à états tap controller (une machine par réticule).
• État courant du réticule mis à jour par jtag_fsm lors de l'arrêt de la machine à état.
reticule_fsm :
• Fonctionne selon une machine à états finis.
• Accède aux données contenues dans header_ctrl et vérifie si elles sont destinées aux
réticules.
• Commande jtag_demux afin de sélectionner le réticule actif.
• Commande ret_last_states, en lui fournissant les nouveaux états JTAG d'un réticule.
• Autorise l'envoi des signaux TDI vers les réticules (commande de tdi_fifo).
tdi_fifo :
• « Hard FIFO » synchrone de 4096 bits : 1 bit de large et 4096 bits de profondeur, rendu
asynchrone par la logique l'accompagnant. Contient le bitstream TDI destiné aux réticules.
• Avertit frame_tx lorsque le FIFO est plein et reticule_fsm lorsqu'il est vide.
tdo_fifo :
• « Hard FIFO » synchrone de 4096 bits : 4 bits de large (1 bit TDO par réticule) et 1024 bits
de profondeur, rendu asynchrone par la logique l'accompagnant.
• Blocs logiques permettant le remplissage correct du FIFO (gestion des 4 signaux entrants,
horloge tck_ret).
• Avertit frame_tx lorsque le FIFO est plein.
3.2.2 Bloc de réception frame_rx
Le bloc frame_rx reçoit les trames BOT-PB et commande les différents blocs du Top-Level en
fonction des données contenues dans la trame. Étant donné son rôle central, une description plus
précise de ce bloc est nécessaire (voir figure 3-3 page suivante pour le bloc-diagramme).
a) Horloge et données entrantes
Le bloc frame_rx reçoit du Bottom PCB des données sérielles sur son entrée « data_i » et un signal
d'horloge les accompagnant (clock forwarding). La possibilité est donnée d'implanter un CCC (voir
documentation Actel, équivalent au DCM chez Xilinx), un bloc de conditionnement d'horloge
permettant de synchroniser les données sur l'horloge par l'ajout d'un retard paramétrable. Ce dernier
doit être déterminé en fonction de la synthèse du circuit et des futurs essais sur un Power Block.
L'implantation d'une PLL (boucle à verrouillage de phase) aurait permis d'ajuster la différence de
phase aisément mais les CCC de ce FPGA n'en disposent pas.
Le module sync_detector scrute en permanence les données arrivant sur l'entrée data_i afin de
détecter le champ sync du début de trame. Une fois le début de trame détecté, les données sont
acheminée au bloc delimiter qui, en fonction du champ « length » de la trame, détecte la fin de la
trame, quelle que soit sa longueur.
La trame délimitée (hors champ CRC) est reçue par le bloc crc, toujours de manière sérielle, pour le
Page 23
calcul de redondance cyclique avec le polynôme générateur indiqué dans les spécifications.
Figure 3-3: Bloc-Diagramme frame_rx
b) Dispatcher
Le bloc dispatcher a plusieurs fonctions importantes :
• Vérifier la validité de la trame en comparant le CRC de la trame et le résultat provenant du
bloc crc.
• Il analyse tous les champs de la trame afin de commander les autres blocs du top level en
fonction du destinataire (réticules, registres, régulateur, générateur de tck) et de la
commande.
• Il communique directement avec 3 registres implantés dans frame_rx : freq_ctrl_reg
(fréquence du signal JTAG tck), last_id_reg (dernier identifiant de trame reçue),
counters_reg (compteur de trames reçues et de trames ayant une erreur de CRC).
3.2.3 FIFOs
Un FIFO (First In, First Out) est une mémoire-tampon où les premières données écrites sont les
première données lues. Le FPGA Actel AGL060V5 dispose de 4 blocs SRAM de 4 kbits, chacun
pouvant être configuré en FIFO. On parle alors de FIFO embarqué ou « hard » FIFO. Ces blocs
peuvent être mis en cascade.
Nous en avons besoin ici par le fait que les données destinées aux réticules (TDI du protocole
JTAG) sont envoyées à une fréquence différente de la fréquence de fonctionnement du circuit : 160
Mhz pour l'horloge de base du circuit, et de l'ordre de 1 Mhz ou moins pour l'horloge TCK des
Page 24
signaux JTAG. C'est également indispensable pour renvoyer les données provenant des réticules
(TDO du protocole JTAG) dans une trame PB-BOT. Il faut noter qu'étant donné la petite taille du
FPGA (1536 flip-flops), nous ne pouvons implanter des FIFO « soft » de plusieurs kbits comme
cela est nécessaire par la quantité de données TDI pouvant être envoyées à un réticule.
Avec le modèle de FPGA utilisé dans les Power Blocks, il n'est possible d'implanter que des FIFO
synchrones. L'astuce pour rendre son utilisation asynchrone est de coupler le Hard FIFO synchrone
avec un registre ou un FIFO asynchrone d'un bit. C'est ce qui a été fait pour les blocs tdi_fifo et
tdo_fifo.
Le troisième FIFO utilisé est header_crc_fifo, « purement » synchrone et contenant les données de
l'en-tête de la trame BOT-PB.
3.2.4 Registres
Outre les trois registres contenus dans frame_rx (voir section 3.2.2), des registres sont implantés
dans le bloc regulator_controller afin de commander et/ou de connaître l'état des entrées / sorties du
régulateur.
Lors d'une écriture ou d'une lecture sur un registre, le contenu de celui-ci est envoyé de manière
sérielle vers le bloc register_ctrl pour être ensuite transmis vers frame_tx. Ce dernier est alors
chargé d'envoyer les données du registre dans la trame PB-BOT.
3.2.5 Génération des signaux JTAG
La partie permettant de générer les signaux JTAG (TMS, TCK, TDI et TRST) est la plus complexe
du design. Une description du protocole JTAG est disponible en annexe 2 où apparaît en particulier
la machine à état du tap controller. Le FPGA doit pouvoir contrôler l'évolution de 4 machines à états
de ce type, une par réticule, de manière indépendante.
Plusieurs architectures ont été envisagées pour la commande de ces machines à états. Il aurait été
possible de créer un bloc « machine à état tap controller » par réticule. Cette duplication entraînerait
cependant une consommation évitable de flip-flops du FPGA puisque les machines à états
n'évoluent jamais simultanément. L'idée retenue est de n'implanter qu'une seule machine à état,
évoluant d'un état de départ à un état d'arrivée de la machine suivant le réticule sélectionné. Ces
états sont fournis par un bloc mémorisant les états courants et « futurs » (en fonction de la
commande avancée JTAG) de chacune des 4 machines à états : ret_last_states.
Il est important de noter que les machines à états de type « tap controller » peuvent être stoppées à
tout moment par l'arrêt du signal TCK, comme cela a été vérifié dans le cadre du projet (essais sur
circuits de test « Test Chip » v1 et v3).
Enfin, Le bloc jtag_demux est chargé de diriger les 4 signaux JTAG vers le bon réticule.
a) Fonctionnement de reticule_fsm
Ce bloc joue le rôle de « chef d'orchestre » pour la génération des signaux JTAG puisqu'il
commande jtag_fsm, jtag_demux et ret_last_states. Une machine à état en assure le fonctionnement
(figure 3-4) :
Page 25
•
•
Figure 3-4: Machine à états du bloc reticule_fsm
wait_cmd : attente de l'arrivée de données dans le bloc header_ctrl (en-tête d'une trame
BOT-PB).
read_and_update : analyse de l'en-tête de la trame. Si celle-ci est adressée à un réticule
(champ PB Destination) alors le bloc jtag_fsm est « activé », la sélection du réticule est
effectuée pour jtag_demux et ret_last_states est mis à jour.
Page 26
•
run_jtag_fsm_nodata : le bloc jtag_fsm est « activé », il n'y a pas de donnée TDI à lire car la
commande avancée JTAG est trst ou reset. Lorsque jtag_fsm a traité la commande
(end_cmd_i =1), un retour à l'état initial s'effectue.
•
run_jtag_fsm_data : le bloc jtag_fsm est « activé », il y a des données TDI à lire dans
tdi_fifo car la commande avancée JTAG concerne les registres d'instructions ou de données.
Si le FIFO est vide, on attends l'arrivée de données (wait_tdi_data).
•
read_tdi_data : Un décompteur est chargé de contrôler la lecture dans tdi_fifo. On passe à
l'état suivant lorsque le dernier bit de donnée doit être lu (voir Fonctionnement de jtag_fsm).
•
end_read_tdi : arrêt de jtag_fsm et retour à l'état initial.
b) Fonctionnement de jtag_fsm
Le rôle principal de jtag_fsm est de générer des séquences de signaux TMS conformément à la
machine à états du tap controller de la norme JTAG. Pour cela, il faut créer une machine à états qui,
en quelque sorte, en sera le miroir : si les états évoluent en fonction des signaux TMS pour le tap
controller, ce sont les états traversés qui vont conduire à la génération des signaux TMS dans
jtag_fsm.
jtag_fsm reçoit une commande de ret_last_states sous la forme d'un état de départ (dernier état du
tap controller du réticule commandé) et d'un état d'arrivée (état futur du tap controller du réticule
commandé).
Il faut également ajouter que pour créer la machine à état de jtag_fsm, il faut faire références aux
résultats des tests effectués dans le cadre du projet DreamWafer™ sur le circuit de test « test chip
v3 ». C'est une base pour la génération des signaux TDI et TMS puisque ces séquences ont été
validés. Un exemple de commandes sur le registre d'instruction est disponible figure 3-5, c'est en
quelque sorte une référence à suivre pour la génération de séquences de signaux JTAG. La logique
est identique pour les commandes sur le registre de données.
Figure 3-5: Exemple de référence pour l'envoi de signaux vers les réticules
La machine à états créée sur ces bases apparaît sur la figure 3-6 ci après :
Page 27
Figure 3-6: Machine à états du bloc jtag_fsm
Observations :
•
Les états sur fond bleu sont les états possibles de départ et d'arrivée (commandés par
ret_last_states).
•
next_state : état d'arrivée
Page 28
3.2.6 Bloc de transmission frame_tx
Le rôle de frame_tx est d'envoyer les trames PB-BOT (vers le FPGA du Bottom PCB) selon les
spécifications des protocoles. Pour cela, l'en-tête de la trame BOT-PB est récupérée afin d'être
réutilisée. Le cas échéant, les données provenant de tdo_fifo ou de register_ctrl sont incluses dans la
trame et le champ length est recalculé. Enfin le calcul du champ CRC est effectué.
3.3 Précisions sur la programmation VHDL des blocs
L'arborescence des fichiers vhdl (figure 3-7 ci-dessous) fait apparaître l'ensemble des blocs du
design dont ceux décrits dans ce chapitre. Les fichiers comportent tous une en-tête descriptive
standard
et
de
nombreux
commentaires. Quelques règles de
programmation communes [8] pour
le projet sont appliquées : nom des
variables, organisation des répertoires
pour le code source, les tests, la
synthèse...
3.3.1 Librairies et Packages
Deux libraires sont utilisées :
•
work
qui
rassemble
l'ensemble
des
fichiers
sources crées
•
igloo pour la création des
FIFO Actel et l'utilisation de
bascules.
Le fichier power_block_constants
regroupe toutes les constantes
utilisées dans les fichiers vhdl telles
que les tailles des bus, la position des
bits dans les trames. Ainsi, en cas de
modification future des spécifications
des protocoles, les changements à
apporter aux fichiers VHDL sont
moindres.
power_block_functions regroupe des
fonctions de calcul utilisées par les
autres fichiers.
Figure 3-7: Arborescence des fichiers VHDL
3.3.2 Registres et Machines à états
Les blocs suivants comportent des machines à états [9] : frame_rx, header_ctrl, jtag_fsm,
ret_last_states, reticule_fsm, frame_tx.
Différents types de registres ont été également implémentés [10] :
Page 29
•
registres à décalage pour la sérialisation ou la désérialisation de données
•
registres de données de différents types suivants les spécifications (présence d'une entrée
reset, taille...)
3.3.3 Blocs FIFO
Les blocs FIFO (blocs multicolores sur la figure 3-7) ont été générés à partir de l'outil SmartGen
disponible avec le logiciel Libero IDE d'Actel puisqu'ils utilisent des blocs mémoires SRAM du
FPGA. Le comportement des FIFOs a provoqué quelques ajustements dans la programmation en
raison du nombre de cycles entre la commande en lecture et l'arrivée des données ou entre la lecture
du dernier bit du FIFO et la mise à 1 du signal « FIFO vide ». La solution à ces désagréments à été
d'ajouter des bascules D et un signal intermédiare afin de « retarder » les signaux d'un cycle ou bien
d'ajouter une étape d'attente dans une machine à état. Une séquence implantée dans la machine à
états de frame_rx effectue un reset sur les trois FIFOs à la mise sous tension via register_ctrl.
3.3.4 Génération de TCK
Le bloc clock_controller chargé de produire l'horloge TCK des signaux JTAG est commandé par un
bus de 8 bits fixant la valeur d'un compteur interne (256 valeurs possibles). Une opération interne
fixe les bornes de fréquences suivante (clk est fourni par le Bottom PCB) :
•
fréquence minimum : clk / 64 soit 2,5 Mhz
•
fréquence maximum : clk /16384 soit 9,8 kHz
Cette plage peut être aisément modifiés dans le fichier VHDL.
3.3.5 Débogage
Le débogage du design s'est d'abord effectué bloc par bloc. Ainsi, à chaque bloc du « top-level »
correspond un fichier banc de test (test bench) créé pour visualiser le comportement de l'entité en
fonction de l'état de ses entrées sous le logiciel ModelSim. Les fichiers de test reprennent le nom de
leur entité correspondante précédé de « tb_ ».
Pour le bloc frame_rx, les données entrantes, ou stimuli, proviennent d'un fichier texte contenant
une suite de bits (trame BOT-PB).
3.4 Environnement de Travail
La création des fichiers VHDL (codes sources, test benches), la création des bibliothèques et le
lancement des simulation s'est fait indépendamment du logiciel de développement d'un constructeur
(Actel Libero ou Xilinx ISE) afin de garder une lisibilité future pour d'autres utilisateurs qui
pourront utiliser d'autres environnements. Une description des fichiers et répertoires de travail est
disponible en annexe 5.
3.4.1 Outils logiciels
•
Codage VHDL : NotePad ++
•
Compilation et Simulation : ModelSim 6.6b
•
Génération des blocs Actel : Libero IDE v9.0
Page 30
•
Outil de synthèse : Synplify Synthesis (inclus dans Libero IDE 9.0)
•
Codage C++ : Code::Blocks
3.4.2 Scripts et Simulation
Deux fichiers scripts ont été crées : le premier pour la création des bibliothèques utilisées par les
fichiers VHDL et le second pour compiler les fichiers VHDL et lancer la simulation d'un bloc du
top-level ou du top-level en totalité (menu à l'exécution du script, voir figure 3-8).
Figure 3-8: Scripts de simulation
Dans ce dernier cas, un fichier de simulation .do est exécuté où sont paramétrés les signaux à
visualiser sous ModelSim et le temps de la simulation.
Tous ces fichiers peuvent être modifiés suivant la simulation voulue et l'environnement de
l'utilisateur.
Pour la simulation du top-level, les sorties TDI sont connectées aux entrées TDO afin de pouvoir
récupérer des données. Le comportement qui en découle est cependant conforme à la réalité :
l'émission d'un « bit TDI » entraîne systématiquement la réception d'un « bit TDO ».
Quelques cas de simulation sont décrits en annexe 3 de ce rapport, on peut y observer les signaux
les plus pertinents.
3.5 Environnement de Test
Si le comportement de chaque bloc a été vérifié par simulation, la vérification du fonctionnement du
design créé ne peut cependant se limiter à des simulations unitaires ou a une simulation globale
avec une quantité de stimuli limitée.
Il est nécessaire d'effectuer des tests plus poussés afin de tester le design et de procéder à un
débogage plus exhaustif.
Page 31
3.5.1 Objectifs
L'environnement de test doit remplir les fonctions suivantes :
•
la création de séries de trames BOT-PB selon les spécifications des protocoles. Chaque série
de trame créée est appelée « vecteur de test »
•
La mise en forme de ces trames afin de les utiliser dans l'environnement de simulation
•
La récupération des données de la simulation : remise en forme des trames PB-BOT,
signaux JTAG, commandes régulateur.
•
La comparaison entre les trames BOT-PB émises et les trames PB-BOT reçues puis la
signalisation d'erreurs éventuelles.
3.5.2 Réalisation
L'environnement de test a été développé en langage C++. Ce langage m'était le plus familier pour
une réalisation rapide et fiable.
Le projet, réalisé sous le logiciel Code::Blocks comporte 6 Fichiers sources (.cpp) ayant chacun son
fichier header correspondant. Voici une description sommaire de chaque fichier (voir également les
commentaires inclus dans les fichiers sources) :
•
main.cpp : menu principal, instanciation d'objets des classes FrameBotPb, ParserBotPb,
VecCompare.
•
FrameBotPb : associé à la classe du même nom. Un objet de cette classe est instancié pour
chaque trame BOT-PB. Les attributs de la classe sont principalement les champs de la
trame et les méthodes des outils de manipulation ou conversion de types, de création de
fichiers textes (vecteurs de tests, fichier log, trame PB-BOT attendue en fin de simulation).
•
FramePbBot : associé à la classe du même nom. Un objet de cette classe est instancié pour
chaque trame PbBot identifié par ParserBotPb lors de l'analyse des résultats de la
simulation.
•
ParserBotPb : associé à la classe du même nom, effectue une analyse des résultats de la
simulation, par la lecture de fichiers textes. Un objet de la classe FramePbBot est créé pour
chaque trame identifiée.
•
Crc : regroupe des fonctions permettant le calcul du champ CRC des trames BOT-PB.
•
VecCompare : associé à la classe du même nom, effectue une comparaison entre les trames
PB-BOT attendues et celles générées lors de la simulation. Les différences sont alors
signalées sur l'interface (numéro de ligne de l'erreur).
3.5.3 Utilisation
L'environnement de test possède son interface utilisateur (figure 3-9, page suivante) permettant de
créer des séries de trames BOT-PB conformément aux spécifications par un système de question /
réponse menant à la génération de l'ensemble des champs de la trame. Certains champs sont générés
aléatoirement (une partie du FrameId, le champ Data pour des données envoyés aux réticules).
Cette méthode était la plus rapide pour injecter des trames de façon rigoureuse.
Page 32
L'ensemble de la méthode employée est décrite figure 3-10. Elle fait intervenir l'environnement de
test et le script de simulation décrit auparavant.
Figure 3-9: Interface de l'environnement de test
Figure 3-10: Méthode de test employée
Page 33
Le menu utilisateur regroupe toutes les fonctionnalités de l'environnement de test. Chaque série de
trames générée, crée deux répertoires :
• un répertoire placé sous « testvector_input » regroupant :
◦ un fichier vec*.txt par trame BOT-PB (contient un bit par ligne)
◦ un fichier interframe.txt qui représente les données injectées entre les trames (espace
intertrame). Cet espace peut-être modifié selon les besoins dans une boucle contenue
dans le destructeur de la classe FrameBotPb
◦ un fichier LogFileIn.log (voir figure 3-11) récapitulant les trames générées dans une
série (beaucoup plus lisible que les fichiers vec*.txt)
◦ un fichier vectorsforsim.txt créé par le script modelsim par concaténation des fichiers
vec*.txt et interframe.txt. Ce fichier est directement utilisé par le test bench du top-level
sous ModelSim.
• un répertoire placé sous « testvector_output » regroupant :
◦ un fichier vecExpect*.txt par trame PB-BOT attendue (en réponse à une trame BOT-PB)
◦ un fichier resultsfromsim.txt contenant les données issues de la simulation (fichier de
sortie du test bench du top-level
◦ un fichier JtagData.txt créé par l'environnement de test lors de l'analyse des résultats de
la simulation et contenant les signaux JTAG envoyés aux 4 réticules
◦ un fichier RegulData.txt créé par l'environnement de test lors de l'analyse des résultats
de la simulation et contenant les signaux envoyés au régulateur du Power Block
◦ un fichier vec*.txt par trame PB-BOT détectée par l'environnement de test dans le fichier
resultsfromsim.txt lors de l'analyse des résultats de la simulation
◦ Un fichier LogFileOut.log (voir figure 3-12) récapitulant les trames PB-BOT issues de la
simulation sous une forme plus lisible.
Figure 3-11: Fichier LogFileIn (trames pour simulation)
Page 34
Figure 3-12: Fichier LogFileOut (résultats simulation)
3.5.4 Vecteurs de tests pour le débogage
Les vecteurs de tests sont nommés suivant l'élément testé :
•
•
•
•
clk* : test sur le clock_controller (génération du signal tck)
regist* : tests sur registres implantés dans le FPGA
regul* : tests sur le régulateur et ses registres
retic* : envoi de données vers les réticules (signaux JTAG)
Des erreurs de plusieurs sortes peuvent être introduites : modification d'un fichier vec*.txt pour y
changer 1 bit, modification du CRC, commande avancée JTAG illégale (par exemple une
commande on_shift_dr sur un réticule en n'ayant pas envoyé de commande start_shift_dr au
préalable).
Seule la partie concernant l'envoi de signaux JTAG n'a pu être vérifiée en totalité par manque de
temps, les cas à tester étant très nombreux : mauvaises commandes, alternance sur plusieurs
réticules, tests sur FIFO plein.
Voici un tableau récapitulant les premiers tests effectués avec cet environnement dédié :
Page 35
Nom
Nb
Trames
Description
Statut
regist0
5
Écritures et lectures sur freq_ctrl_reg
OK
regist1
7
Écritures sur fifo_rst
OK
regist2
4
Lectures de last_id_reg
OK
regist3
7
Lectures / Reset de counters_reg + trames avec erreurs crc
OK
regist4
8
Écriture / lecture sur les 4 registres
OK
regul0
6
Commande Régulateur (enable, soft start)
OK
regul1
6
Lecture registres, écritures
OK
ret0
4
Commande avancée trst sur 4 réticules successivement
OK
ret1
1
start_shift_ir 8 bits sur réticule 1
OK
ret2
3
start_shift_ir reticule2 (16 bits)/ chgt fréquence tck / on shift_ir réticule
2 (8bits)
OK
ret3
1
start_shift_dr (11 bits) sur réticule 3
OK
ret4
3
Reticule 4 : start_shift_dr (8bits) / on_shift_dr (16bits) / end_shift_dr
(8bits)
OK
ret5
4
Reticule 2 : start_shift_dr (16bits), Reticule 1 : start_shift_ir (7bits),
Reticule 3 : trst, Reticule 2 : on_shift_dr (12bits)
OK
tck0
5
Changements de la fréquence tck par le registre freq_ctr_reg
OK
3.6 Synthèse et tests sur carte d'évaluation
La synthèse logique du circuit a été effectuée avec l'outil Synplify Synthesis. L'outil de synthèse a
été régulièrement utilisé au cours de la description fonctionnelle afin de vérifier la conformité de la
syntaxe des fichiers et de connaître la consommation de flip-flops du circuit.
Les dernières synthèses exécutées rapportaient une utilisation de 69% des cellules logiques du
FPGA utilisé.
Une carte d'évaluation est disponible pour le projet DreamWafer™. Elle est équipée d'un FPGA
Actel SmartFusion (semblable à celui implanté sur le Bottom PCB et même famille que celui du
Power Block), d'un processeur ARM Cortex-M3.
Une implantation du design sur cette carte n'a pu être effectuée au moment de la rédaction de
rapport. Cependant une réflexion sur la façon de mener des tests sur cette carte à été menée :
• Implanter dans la mémoire FlashROM de la carte les vecteurs de tests (trames BOT-PB).
• L'utilisation des blocs FIFO et des blocs de conditionnement d'horloge (CCC) ne posent pas
de problème puisqu'ils sont du même type que ceux du FGPA du Power Block.
• Quatre sorties utilisateur de la carte peuvent être utilisées afin de visualiser les signaux
JTAG d'un réticule déterminé. On peut également décider d'afficher sur l'écran OLED de la
carte le numéro du réticule commandé et, à l'aide d'un multiplexeur, diriger les signaux du
réticule vers les sorties de la carte.
Page 36
CHAPITRE 4 : BILAN PERSONNEL
4.1 Planification du travail personnel
Le travail que j'ai effectué sur cette période de cinq mois et demi est récapitulé dans le diagramme
de la figure 4-1.
Figure 4-1: Diagramme de Gantt
Après le premier mois de ma période de stage, débutait début la phase 11 du projet DreamWafer™,
couvrant la période de Mai à Septembre. Pour chaque phase, chaque participant du projet rédige un
document où il détermine les points sur lesquels il va travailler. A la fin de la période, le document
est repris, les tâches achevées sont barrées, celles non achevées sont commentées.
Mes documents pour la phase 11 figurent en annexe 4. J'ai rédigé ces points en fonction des
échanges avec mon tuteur de stage, M. Yves Blaquière.
Il est cependant difficile d'évaluer le temps pris pour chaque tâche, les difficultés rencontrés étant
évidemment assez imprévisibles.
La phase d'apprentissage pour entrer réellement dans un projet de cette envergure est assez longue
et frustrante puisqu'elle consiste en la lecture de nombreux documents. Elle est cependant
indispensable avant de pouvoir produire un quelconque travail.
4.2 Organisation du projet
J'ai pu remarquer que la difficulté majeure pour un projet de cette envergure, réunissant autant de
personnes, était la coordination, la communication interne et le partage d'informations. En effet, les
participants sont souvent éloignés physiquement. Les réunions organisés par Gestion Technocap,
toutes les 3 ou 4 semaines, sont alors un lieu d'échange très riche et assez captivant pour un
« junior ».
Les intervenants peuvent travailler dans des domaines très différents allant du PCB à la mécanique
en passant par l'informatique et la thermique. C'est une chance de pouvoir participer à ces réunions
où les sujets abordés peuvent être éloignés de son champ de compétences mais où la qualité et
l'expérience des intervenants est souvent captivante.
Plus concrètement, la communication autour du projet est gérée par Technocap. Les étudiants
produisent à chaque réunion un document (rédigé en anglais) envoyé à leur responsable
hiérarchique avant d'être inclus dans l'agenda de la réunion et imprimé dans le dossier remis à
chaque participant lors de la réunion. Les réunions se passent en grande majorité en anglais. Elles
sont l'occasion de resserrer les liens dans l'équipe, de coordonner les différents travaux, de porter à
la connaissance de chacun les avancées en cours ou les difficultés.
Page 37
L'efficacité de ces réunions, menées par Richard Prytula de Technocap, est assez impressionnante :
les discussions sont précises et des concensus sont souvent trouvés rapidement. Malgré ça,
l'ambiance y est assez détendu, le cadre « quasi-familial » aidant. C'est aussi l'occasion de discuter
en apparté avec différents membres de l'équipe ou avec des intervenants extérieurs et conseillers
techniques.
4.3 Expérience vécue
Sur le plan technique, j'ai pu apprendre beaucoup sur le langage VHDL, le design de FPGA et la
manière de valider son fonctionnement. J'ai aussi apporté un soin à rendre mon travail exploitable
rapidement pour les personnes amenées à poursuivre le travail engagé.
Au delà de l'aspect plus technique, travailler dans un pays étranger, avec des mentalités différentes
sur le plan professionnel est riche d'enseignements : l'efficacité et le travail effectué priment ici sur
l'apparence ou le CV de la personne !
La manière de mener les réunions et de prendre des décisions dans un projet sont également très
formatrices.
La compétence et l'expérience des personnes côtoyées dans ce projet m'ont aussi impressionné et
apporté beaucoup :
M. Richard Norman (détenteur des brevets) est un ingénieur en physique qui a travaillé pour IBM,
fondé sa propre compagnie et est co-fondé la société Hyperchip (1997) pour la création du premier
routeur scalable, il possède une vingtaine de brevets.
M. Yvon Savaria, professeur à l'Ecole Polytechnique de Montréal depuis 1985 spécialiste des
circuits de type Wafer-Scale, est titulaire d’une chaire de recherche du Canada en conception des
systèmes microélectroniques avancés. Il est auteur et co-auteur de plus de 200 articles scientifiques.
M. Yves Blaquière est professeur à l’UQÀM depuis 1987 a travaillé sur de nombreux projets ASIC
et FPGA standard et Wafer-Scale, il est directeur du laboratoire de microélectronique de l’UQÀM.
Cette expérience de presque six mois fut une grande source d'enseignement pour ma future vie
professionnelle. J'ai apprécié travailler en équipe sur un projet de cette dimension et j'espère pouvoir
retrouver un tel cadre de travail.
Page 38
CONCLUSION
CONCLUSION
Avec la rédaction des spécifications des protocoles de communications, c'est une étape vers
la mise au point des communications internes du WaferBoard™ et plus généralement vers
l'élaboration du logiciel qui a été franchie. Les fonctionnalités et l'architecture du FPGA du
Power Block ont été établies précisément. Son design n'a pu être totalement vérifié et validé
malgré l'élaboration d'un environnement de test efficace dans cette optique. C'est d'ailleurs
un enseignement personnel de constater à quel point le temps nécessaire à la programmation
est minime par rapport à celui nécessaire aux tests et à la validation. Les cas de test pour ce
circuit sont très nombreux et nécessiteraient plusieurs semaines de travail.
J'ai acquis des compétences techniques dans le domaine des FPGA, des langages VHDL et
C++ et de l'électronique numérique en général.
Mais ce qui m'a apporté le plus dans l'optique de ma future vie professionnelle reste le fait
d'avoir participé à un projet innovant de grande envergure. Travailler dans une équipe
regroupant des talents de tous horizons restera une expérience marquante et valorisante. Je
retiendrai également de cette période les méthodes de travail efficaces, la confiance et la
liberté de travail accordée aux étudiants.
Le projet DreamWafer™ est en constante progression et évolution. Des personnes arrivent
et partent de ce projet en ayant chacune apporté quelque chose à l'élaboration de ce système
de prototypage rapide qui pourrait être une innovation majeur dans le monde des systèmes
électroniques. Je suis fier d'avoir pu apporter ma contribution à ce projet.
Page 39
Glossaire
Glossaire
ASIC (Application-Specific Integrated Circuit) : circuit intégré spécialisé produit selon des
besoins détérminés. La production de ces circuits se fait généralement pour de gros volumes. Les
ASICs de grande taille intégrant processeur, mémoires et interfaces sont qualifiés de system-on-chip
(SoC).
CRC (Contrôle par Redondance Cyclique ou Cyclic Redundancy Check) : Système de contrôle de
l'intégrité d'un paquet de données basée sur une opération mathématique, la division polynomiale.
FIFO (First In First Out) : Méthode de gestion de stockage de données (mémoire) dans laquelle les
premières données entrées sont les premières sorties.
FPGA (Field-Programmable Gate Array) : circuit intégré logique pouvant être reprogrammé après
sa fabrication.
JTAG (Joint Test Action Group) : terme souvent utilisé au lieu du terme générique Boundary Scan
pour désigner une technique de test des cartes électroniques numériques. Des ports JTAG sont
également souvent utilisés pour configurer des circuits (ex : FPGA). Le JTAG est défini par la
norme IEEE 1149.1
PCB (Printed Circuit Board) : support permettant de relier électriquement des composants
électroniques, autrement appelé circuit imprimé.
TSV (Through-Silicon-Vias) : connexion électrique verticale réalisée à travers un wafer ou tranche
de silicium.
VHDL (Very high speed integrated circuits Hardware Description Language) : langage de
description matérielle définissant le comportement et l'architecture d'un système électronique
numérique, très utilisé dans la conception de circuits ASIC ou FPGA
WaferBoard™ : Système de prototypage rapide de systèmes électroniques développé par l'équipe
DreamWafer™.
WaferIC™ : Circuit de type WSI utilisé dans le WaferBoard™ (les composants y sont déposés).
WaferNet : Réseau d'interconnexion interne du WaferBoard™ .
WSI (Wafer Scale Integration) : Système de construction de circuits intégrés large échelle (taille
de la tranche de silicium).
Page 40
Références Bibliographiques
Références Bibliographiques
[1] US Patent 11/611,263 - Richard Norman, “Reprogrammable Circuit Board with
Alignment-Insensitive Support for Multiple Component Contact Types”.
[2] Basile-Bellavance et al., “Faults Diagnosis Methodology for the WaferNet
Interconnection Network” IEEE NEWCAS-TAISA Conference, Toulouse, France, June 28July1, 2009
[3] P. K. Parker, “The boundary-scan handbook: analog and digital”, 2nd ed., Ch. 1.4.,
Kluwer Academic Publishers Boston/ Dordrecht/ London, 1998
[4] Norman et al., “An Interconnection Network for a Novel Reconfigurable Circuit Board”
IEEE NEWCAS-TAISA Conference, Montreal, Canada, Jun 22-25, 2008
[5] R. Norman, O. Valorge, Y. Blaquiere, E. Lepercq, Y. Basile-Bellavance, Y. El-Alaoui, R.
Prytula. Y. Savaria, “An Active Reconfigurable Circuit Board”, NEWCAS 2008.
[6] M. Madou, “Fundamentals of Microfabrication: The Science of Miniaturization”, (2nd
ed.), CRC Press, 2002.
[7] « USB Serial Bus specification »,
http://www.usb.org/developers/docs/
disponible
sur
le
site
usb.org
:
[8] Open Core HDL modeling guidelines, disponible sur le site opencores.org :
http://cdn.opencores.org/downloads/opencores_coding_guidelines.pdf
[9] Pong P. Chu, “FPGA Prototyping by VHDL Examples”, page 77 (4.2.2 Register), WileyInterscience, 2008.
[10] Pong P. Chu, “FPGA Prototyping by VHDL Examples”, page 107 (Chapter 5, FSM),
Wiley-Interscience, 2008.
Sites Internet
UQAM, Génie microélectronique : http://www.micro.uqam.ca/
Projet DreamWafer : http://www.dreamwafer.com/
Vidéo de présentation du WaferBoard :
http://www.youtube.com/watch?v=LNNXgW2wUfU
TechnoCap : http://www.technocap.com/
Actel : http://www.actel.com/
Page 41
ANNEXES
ANNEXES
Sommaire Annexes
Spécifications Protocoles......................................................................................................43
Protocole JTAG.................................................................................................................... 59
Cas de simulation.................................................................................................................62
Rapports Phase 11................................................................................................................65
Présentation CD / Contenu SVN..........................................................................................68
Page 42
ANNEXES
ANNEXE 1
Spécifications Protocoles
Page 43
ANNEXES
ANNEXE 2
Protocole JTAG
Page 59
ANNEXES
En 1985, un groupe de compagnie ont formé un consortium dans le but de mettre au point un
nouveau standard pour le test de PCB basé sur un protocole de communication sérielle entièrement
contrôlable par logiciel. L’objectif du standard est d’accéder au contrôle et à l’observation des
broches des circuits intégrés d’un circuit imprimé (PCB) dans le but de tester les interconnexions
des circuits discrèts sur le PCB. Le terme « boundary scan » (chaîne de balayage) a été ainsi créé.
Ce groupe s’est appellé Joint European Test Action Group (JETAG). Quelques années plus tard, le
concept s’est généralisé en Amérique du Nord pour prendre le nom de JTAG et a été accepté comme
standard IEEE 1149.1.
Le test JTAG n’influe en rien sur la fonctionnalité du noyau logique. En fait, le chemin du
Boundary- Scan est indépendant de la fonction du composant.
Soit la carte ci-dessous :
Cette figure montre une carte contenant quatre composants JTAG. Notons qu’il existe sur la carte
un connecteur en entrée nommé TDI connecté sur l’entrée TDI du premier composant. Le TDO du
premier composant est relié au TDI du second composant. Et ainsi de suite jusqu’à la sortie du
dernier composant appelée TDO. Les TCK et TMS sont reliées à chacun des composants en
parallèle. Dans ce chemin, certains tests particuliers peuvent être appliqués à chacun des
composants par l’intermédiaire du chemin de scan global. Ainsi il va être possible de charger une
valeur spécifique dans les cellules JTAG d'entrées via la broche TDI de la carte (opération de
décalage d’entrée), d’appliquer cette valeur au composant (opération update), de mémoriser la
réponse du composant (opération capture), et de sortir cette valeur sur la broche TDO de la carte
(opération décalage de sortie).
Un système de test JTAG possède un certain nombre d’éléments :
•
“Tap Controller” : une machine à état fini dont le diagramme d’état est représenté à
sur la figure de la page suivante.
•
“Bypass register” : un registre simple obligatoire dans le standard utilisé pour
raccourcir les chemins sériels entre les circuits intégrés sous test.
•
“Instruction register” : défini le mode dans lequel la chaîne de balayage est utilisée.
Page 60
ANNEXES
Ainsi que les 5 ports JTAG :
•
Le port tdi: signal d’entrée des données sérielles de test à appliquer aux chaînes de
balayage
•
Le port tms : signal de contrôle du “Tap Controller” (voir figure G.2).
•
Le port tck : signal d’horloge activé lors du mode test
•
Le port tdo : signal de sortie des données sérielles (résultats du test appliqué)
•
Le port trst : signal de réinitialisation
Page 61
ANNEXES
ANNEXE 3
Cas de simulation
Page 62
ANNEXES
Cas 1 : Changement de la fréquence du signal tck JTAG par deux trames destinées au
registre freq_ctrl_reg :
Cas 2 : Envoi d'une commande avancée JTAG start_shift_dr sur le reticule 4 avec 8 bits de
données :
Page 63
ANNEXES
Cas 3 : Envoi de différentes commandes JTAG sur les réticules (cas de test ret5)
Cas 4 : Commande jtag « rst » sur les 4 réticules successivement (cas de test ret0)
Page 64
ANNEXES
ANNEXE 4
Rapports Phase 11
Page 65
ANNEXES
Romain Clochard WorkPlan
Phase 11 (May-Aug 2010)
DreamWafer™



Waferboard Communication Protocols
◦
Definition of a communication architecture
◦
Establish specifications
Power-Block FPGA
◦
Write VHDL code according to the communication architecture
◦
Perform simulations to test and debug
◦
Implementation on Spartan 3 Board : test generation
◦
Implementation on AGL060V5
Bottom-PCB FPGA
◦
FPGA selection (with BrioConcept)
◦
◦
◦
Implementation on Spartan3 Board : test generation
Page 66
ANNEXES
Romain Clochard WorkPlan
Phase 11 (May-Aug 2010)
DreamWafer™


Waferboard Communication Protocols
◦
Definition of a communication architecture
◦
Establish specifications
Power-Block FPGA
◦
◦
◦
Implementation on Spartan 3 Board : test generation
(POWER BLOCK FPGA DESIGN NOT TESTED WITH THE ACTEL
EVALBOARD)
◦

Implementation on AGL060V5
Bottom-PCB FPGA
◦
FPGA selection (with BrioConcept)
◦
◦
◦
Implementation on Spartan3 Board : test generation
◦

Added Tasks
◦
Test Environment creation for Power-Block FPGA debugging
◦
Writing master's degree internship report
Page 67
ANNEXES
ANNEXE 5
Présentation CD / Contenu SVN
Dans cette partie est détaillé le contenu du CD accompagnant ce rapport. L'organisation des
répertoires reprend en partie celle créée sous l'espace de partage SVN du projet DreamWafer™ où
les membres du projet pourront retrouver les fichiers et codes produits pendant cette période de
stage.
/Design FPGA/
Bloc-diagrammes du FPGA du Power Block
/Documentation Logiciels_Matériel/
Documents contructeur sur le FPGA Actel Igloo AGL060, la carte d'évaluation Actel A2F.
Documents sur les logiciels ModelSim (Mentor Graphics) et Synplify Synthesis (Synopsis).
/fpga_pb/
bench/
fichiers VHDL de type « test bench »
doc/
documentation sur l'utilisation du bloc CRC VHDL.
document « OpenCores Coding Guidelines » sur des règles de programmation
en VHDL
Description des composants de la Librairie Igloo
Guide d'utilisation de SmartGen
Fichiers Log issus de SmartGen et de la génération des blocs FIFO
lib/
Librairies work et igloo utilisées par les fichiers VHDL
rtl/
Codes VHDL (1 fichier par bloc)
scripts/
Scripts power_block_lib (création des librairies) et power_block_sim (script de de
simulations)
Fichiers .do de configuration de la simulation (signaux, durée)
syn/
Fichiers liés à la synthèse du FPGA sous Synplify Synthesis
test/
document décrivant les tests effectués avec l'environnement de test
Page 68
ANNEXES
CodeBlocksProject/
Projet crée sous Code::Blocks pour élaborer l'environnement de test
src/
Fichiers sources C++ (.cpp et .h)
testvector_input/
Contient un répertoire par série de trames créé sous l'environnement de test.
Chaque répertoire contient les fichiers interframe.txt (espace intertrame),
LogFileIn.log, vec*.txt (1 fichier par trame BOT-PB) et vectorsforsim.txt
(créé par le script de simulation par concaténation des fichiers interframe et
vec*).
testvector_output/
Contient un répertoire par série de trames créé sous l'environnement de test.
Chaque répertoire contient les fichiers resultsfromsim.txt (resultats de la
simulation), vecExpect*.txt (prévisions trame PB-BOT), vec*.txt (1 fichier
par trame PB-BOT issue de l'analyse de resultsfrom.sim.txt), JtagData.txt
(signaux JTAG issus de la simulation), LogFileOut.log, RegulData.txt
(signaux régulateur issus de la simulation).
/Gestion de Projet/
Tâches personnelles pour la phase 11 du projet
/Protocoles/
Frames Description : fichier décrivant les champs de trames BOT-PB, PB-BOT et les
données contenues dans le FIFO header_ctrl.
Envoi Signaux JTAG : exemple de référence pour l'envoi de signaux JTAG aux réticules.
Spécifications des Procotoles du WaferBoard™
/Rapport de Stage/
Rapport de stage sous format Open Office et PDF
/WaferBoard/ (ensemble des documents en anglais)
Glossaire, Liste des brevets déposés ou en cours, revue de presse, présentation du
WaferBoard™, terminologie autour du projet.
Research Papers/
Publications scientifiques de l'équipe DreamWafer™.
Page 69
RÉSUMÉ
Ce stage s'inscrit dans le projet de recherche DreamWafer™ qui vise à développer
une plateforme de prototypage rapide pour les systèmes électroniques appelée
WaferBoard™. L'ambition du projet est de réaliser pour les systèmes électroniques ce
que les FPGA sont aux microprocesseurs : rendre possible une reprogrammation
complète du circuit.
L'utilisateur du WaferBoard™ place les composants sur la surface du WaferIC™ et
referme un couvercle : les composants sont repérés, identifiés, alimentés. Les
connexions entres les circuits peuvent être configurées : le prototype est prêt à
fonctionner.
Pour son fonctionnement interne, le WaferBoard™ comprend plusieurs PCB équipés
de FPGAs.
Ce document porte sur ma contribution à ce projet sur les points suivants :
• La création des protocoles de communication entre FPGA ainsi que la
rédaction des spécifications.
• La conception ou « design » des FPGA des Power Blocks (circuits imprimés
inclus dans le WaferBoard™ ) en langage VHDL.
• La mise au point d'un environnement de test en langage C++, conforme aux
spécifications établies et permettant un débogage avancé du design.
Ces travaux constituent une première étape importante dans le design des FPGA des
autres PCB ainsi que dans la création du logiciel qui pilotera le WaferBoard™.

Conception de FPGA et communications inter-FGPA dans le

Transcription

Documents pareils

Responsable Administratif et Financier

Intermediate/Senior FPGA Designer

N° N° - ATF Flexo

Abderrezak HALILALI

Introduction au JTAG 1 - Le bus JTAG - ISIL-Electro

Bien concevoir avec un FPGA

Spcifications techniques pour la gravure de CD et de DVD