# L'apprentissage par projet en microélectronique numérique
Vers l'acquisition d'un savoir-faire

G. Lehouque<sup>a</sup>, A. Costani<sup>a</sup>, M. Portolan<sup>b</sup>, L. Fesquet<sup>b,c</sup>

<sup>a</sup> Grenoble INP*, Phelma, Grenoble, France

<sup>b</sup> Univ. Grenoble Alpes, CNRS, Grenoble INP*, TIMA, Grenoble, France

<sup>c</sup> Univ. Grenoble Alpes, Grenoble INP*, CIME Nanotech, Grenoble, France

*Institute of Engineering Univ. Grenoble Alpes

Contact e-mail : laurent.fesquet@univ-grenoble-alpes.fr

Dans le cadre de la filière par apprentissage Microélectronique et Télécoms (MT) de l'école d'ingénieurs Phelma-Grenoble INP, les étudiants de seconde année effectuent un projet au sein du CIME Nanotech durant leur second semestre dont l'objectif est la conception d'un « digital baseband controler » pour la norme ZigBee. Ils sont ainsi confrontés à une situation très proche de celle qu'ils connaîtront en milieu industriel car la conception d'une puce nécessite, non seulement d'en imaginer les plans, mais aussi d'effectuer de très nombreuses vérifications garantissant la manufacturabilité du circuit intégré, étapes nécessaires avant d'envoyer un circuit en fabrication via le CMP (Circuits Multi-Projets). Ces vérifications, pourtant indispensables, sont rarement effectuées lors des apprentissages en école car ces étapes sont extrêmement chronophages et requièrent persévérance et ténacité. Enfin, l'organisation de l'équipe et la gestion des tâches aux quotidiens sont aussi des éléments clés du succès. Cet article relate cette aventure humaine et pédagogique unique vécue par dix étudiants de la filière MT de Phelma.

## I. Introduction

L'école d'ingénieurs en physique, électronique et matériaux (Phelma) de Grenoble INP possède des formations dans les domaines de la technologie et de la conception microélectronique. Parmi les filières dédiées, la filière par apprentissage Microélectronique et Télécoms (MT) s'évertue à donner une solide formation théorique et pratique en conception analogique et numérique. En effet, la scolarité est organisée autour d'enseignements classiques (cours, TD, TP) mais aussi d'un projet dont l'objectif est la conception d'un système radiofréquence *ZigBee*. Lors de la mise en place de la maquette pédagogique, l'équipe enseignante a souhaité impulser la dimension pratique de la formation afin de répondre au plus près aux besoins des industriels (1). En effet, de très nombreuses applications nécessitent l'usage de puces électroniques dédiées (2) dans des domaines aussi variés que l'informatique, l'aéronautique, l'automobile, les télécommunications, le médical, la sécurité, la domotique, l'environnement, etc.

Ainsi, avec l'objectif de former des ingénieurs parfaitement qualifiés, avec une bonne compréhension de leur environnement et un vrai savoir-faire (3), la filière MT de Phelma s'appuie fortement sur les équipements du CIME Nanotech, que ce soit pour les travaux
pratiques en salle blanche, les outils de CAO, les plateformes de caractérisation et de prototypage. Les élèves travaillent ainsi en équipe sur les plateformes du CIME Nanotech autour d'un projet de conception d'un système intégré radiofréquence *ZigBee* pour l'Internet des Objets. Les circuits sont conçus jusqu'au dessin des masques et envoyés en fabrication dans le cadre d'un « run multiprojets » grâce à CMP (Circuits Multi-Projets), une unité de service du CNRS et des universités grenobloises permettant l'accès à des fonderies silicium.

Grâce à cet environnement technique, les étudiants de la filière MT ont mené à bien le développement des blocs matériels analogiques et numériques d'un système *ZigBee*. Nous nous proposons de relater dans cet article les travaux nécessaires à la conception du système numérique *ZigBee* en détaillant la puce, ses blocs et les stratégies de test associées. Le travail a été mené depuis la définition d'une architecture RTL jusqu'aux dessins des masques, suivi des nombreuses et indispensables vérifications avant envoi en fonderie. Ce travail, mené par dix étudiants, a aussi été une formidable occasion d'apprendre à organiser et gérer une équipe. Enfin, mener un tel exercice à son terme nécessite de l'engagement, de la rigueur, de la persévérance, voire même de la ténacité.

## II. Spécifications techniques de la puce

Le projet consiste à réaliser un système radiofréquence utilisant le protocole de communication *ZigBee*. Le cahier des charges fixé au préalable par les professeurs reprend beaucoup d'éléments de la norme *ZigBee*, c'est-à-dire l'utilisation de la bande de fréquence comprise entre 2,4GHz et 2,485GHz avec 16 canaux de 5 MHz de bande passante et une puissance d'émission de 14 dBm. Côté communication, notre système cible un débit de 250 kbit/s et utilise une modulation numérique de type MSK (*minimum-shift keying*) (4)(5).

Deux groupes d'étudiants ont été constitués dès le début du projet afin de répartir les tâches. Le premier groupe s'est consacré à la conception de blocs analogiques, alors que le second groupe s'est focalisé sur les blocs numériques. Parmi les blocs analogiques utilisés pour effectuer la transmission radiofréquence, des amplificateurs, des mélangeurs, des oscillateurs et des convertisseurs ont été conçus. Ainsi, un amplificateur de puissance (PA) pour l'émission permettant d'atteindre 14dBm en sortie a été réalisé ainsi qu'un amplificateur à faible bruit (LNA) utilisé pour la réception. Des oscillateurs contrôlés en tension (VCO) et des mixeurs ont été conçus pour la montée/descente en fréquence du signal. Il est à noter qu'une boucle à verrouillage de phase, intégrant le VCO a été implémentée. Enfin, un convertisseur analogique-numérique (CAN) effectuant l'interfaçage entre les mondes analogique et numérique a été également conçu.

L'autre groupe d'étudiants s'est concentré sur les blocs numériques que l'on trouve usuellement dans un *baseband controller* et qui permet d'effectuer la modulation, la démodulation et le traitement des données. Cet article se consacre exclusivement à la partie numérique du projet qui, outre l'apprentissage des fonctionnalités associées, met en œuvre un grand nombre d'outils CAO.

Les différents blocs numériques (aussi appelés IP pour *Intellectual Property*) du *baseband controller* permettent, à partir d'un CPU externe (Central Processing Unit), l'émission et la réception de données. Ainsi, un bloc FIFO (*First In First Out*) effectue l'interface entre le CPU et le module *ZigBee*. La FIFO peut stocker jusqu'à 32 octets en entrée (RX) et autant en sortie (TX). Elle utilise le protocole APB© pour communiquer avec le CPU. Côté émission, une unique IP permet d'effectuer le codeur I/Q (signaux en phase et en quadrature). Celle-ci prend en entrée les données envoyées par la FIFO et
génère en sortie des « demi-sinus » codés sur deux bus de six bits qui sont envoyés sur un convertisseur numérique analogique. Côté réception, trois blocs ont été réalisés. Le premier effectue la démodulation IQ des signaux ainsi qu’un filtrage anti-repliement. Ce bloc nommé *IQ-demodulation* traite les données issues des CAN et les transmet au bloc *Cordic*. Ce second bloc utilise les signaux I et Q pour quantifier la différence de phase entre les signaux I et Q. Cette phase est exploitée par le bloc de décision qui effectue la récupération des données. Ce troisième et dernier bloc traite alors les phases et envoie les données à la FIFO. Ces trois blocs de réception peuvent fonctionner de manière séparée afin de pouvoir les tester individuellement. Lorsqu’ils fonctionnent ensemble le circuit réalise les différents calculs nécessaires à la démodulation MSK.

<figure><img src="image_1.png" /><figcaption>Fig.1. Schéma des blocs et des fonctions implantés au sein de la puce ZigBee.</figcaption></figure>

### III. Flot de conception

Le flot de conception peut être qualifié de classique. Il met néanmoins en jeu un grand nombre d'outils, ce qui rend complexe ce type d'enseignement. En effet, les étudiants sont tous novices en début de projet et ont peu pratiqué avec les outils (voire pas pour certains outils) malgré une série de TP qui les initie aux rudiments du métier. Ainsi, le projet proposé constitue une première mise en condition proche de la réalité industrielle. La première étape consiste à analyser les spécifications de la norme *ZigBee* et d'en comprendre les implications pratiques sur les signaux. Cette première phase « système » est réalisée avec les deux groupes d'étudiants dans laquelle des simulations *Matlab* du système complet sont effectuées. Cette étape est cruciale pour définir les bonnes spécifications des blocs matériels analogiques ou numériques. Une fois les caractéristiques des blocs à réaliser connues, les étudiants ont entrepris le codage des blocs numériques avec le langage *SystemVerilog*. A ce stade, ils constituent également un programme de test qui sera utilisé (pour simuler avec *Modelsim* de *Siemens EDA*) tout au long des étapes successives du projet. Ainsi, une fois la description du bloc matériel effectuée, les étudiants passeront du temps à le valider en s'assurant de la bonne compatibilité avec les simulations « système ». Cette étape franchie, les étudiants s'attacheront ensuite à rendre leur code synthétisable avec le logiciel *Spyglass* de *Synopsys*. Avec un code synthétisable (RTL), les étudiants se sont attaqués à la synthèse logique du circuit avec le logiciel *Design Vision* de *Synopsys*. A ce stade, ils feront notamment les premières vérifications de timing garantissant le fonctionnement des blocs. Suite à cette étape cruciale, les étudiants se sont lancés dans la réalisation du dessin des masques (*layout*). Pour ce faire, ils utilisent l'outil *Innovus* de *Cadence*. Après un premier *run* (première passe) sur les blocs pour prendre en main les opérations de placement et de routage, les étudiants ont affiné à ce stade le contenu de la puce en fonction des blocs qui seront ou pas disponibles pour l'envoi en fabrication via CMP. Une fois les contours de la puce définis, les étudiants ont réalisé les scripts nécessaires à la génération de l'anneau contenant les plots d'entrées-sorties, le placement-routage de chacun des blocs et leur placement hiérarchique dans la puce finale. C'est à ce
stade que les choses se compliquent un peu car il faut effectuer les vérifications de DRC (Design Rule Checking) et LVS (Layout Versus Schematic) avec l'outil Calibre de Siemens EDA qui ne sont jamais une sinécure ! Avec de nombreuses corrections et allers-retours avec le CMP, les choses se sont finalement décantées pour arriver à un dessin des masques de la puce sans erreur. Enfin, il est à noter que des simulations logiques *post-layout* rétro-annotées (avec un fichier .sdf) ont été réalisées afin de garantir que les fonctionnalités de la puce étaient bien conservées après les opérations de placement et de routage.

<figure><img src="image_2.png" /><figcaption>Fig.2. Le flot de conception avec les nombreux outils CAO professionnels utilisés.</figcaption></figure>

## IV. Organisation du travail

Le groupe d'étudiants travaillant sur le projet est composé de 5 binômes qui se sont répartis les blocs à concevoir. Au lancement du projet, chaque binôme travaillait en autonomie sur la description RTL des blocs qu'il avait à concevoir. Il communiquait peu et uniquement pour connaître les besoins des blocs adjacents. Rapidement, le groupe se rend compte que l'intégration logique du système nécessite d'avantage d'interactions et qu'il faut se mettre d'accord sur des méthodes de validation communes. Ce travail de validation a pris forme progressivement et insidieusement dans le groupe. Toutefois, les choses se sont accélérées, quand les premiers groupes ayant testé et synthétisé leur code RTL en *SystemVerilog* ont commencé à écrire les scripts de synthèse et placement et routage sur la base des travaux pratiques du cours de flot de conception que les étudiants avaient suivi au premier semestre. En effet, le travail en groupe isolé devenait impossible. Il fallait s'organiser, d'une part, parce que la tâche était conséquente et, d'autre part, parce qu'il fallait songer à réaliser une puce cohérente et testable à la fois globalement et par bloc.

Après une phase de *brainstorming* (ou remue-méninges) permettant d'affiner les contours de la puce et sa stratégie de test, il a fallu valider chaque bloc individuellement et ensuite dans son environnement au sein de la puce. Par ailleurs, l'avancement des binômes était disparate, ce qui rendait la validation de la puce assez difficile. Ainsi, les groupes les plus avancés ont mis en place un flot de conception pour le placement et le routage générique afin de faciliter cette étape pour les groupes qui bataillaient encore avec les étapes de synthèse. Ce travail, en avance de phase, a permis aux groupes les moins avancés de compléter leur code sereinement, et de profiter du savoir-faire acquis par leurs camarades sur les étapes de placement-routage qui, rappelons-le sont nombreuses : définition d'une couronne de plot, tracé du plan de masse (*floorplanning*), placement des cellules, construction des lignes d'alimentation, génération d'un arbre d'horloge, routage de l'horloge et des signaux critiques, routage global de la puce. L'échéance du projet arrivant rapidement, il a été décidé de concentrer les efforts de mise en place du flot sur le
bloc CDR (Clock Data Recovery) car il s'agit d'un bloc relativement petit. Il générerait donc ainsi un nombre d'erreurs limité durant les étapes de DRC (comparé à d'autres blocs) et serait donc un bon vecteur de mise au point du flot. Il nous a aussi permis de valider les nécessaires étapes de vérification LVS et DRC. Ainsi, l'ensemble des blocs ont pu être routés en un temps très raisonnable. En parallèle au perfectionnement du flot avec le bloc CDR, deux étudiants se sont focalisés sur l'assemblage des blocs réalisés. D'un point de vue système, cela correspond à ajouter des multiplexeurs permettant d'envoyer et de récupérer tous les signaux nécessaires au débogage de la puce, le tout avec la contrainte d'un package de 48 pins (broches) seulement ! Nous avions en effet pris la décision d'utiliser un boîtier DIL 48. Cette tâche ayant été terminée assez rapidement, il a fallu produire le plan de la puce comprenant toutes les blocs réalisés ainsi que l'environnement de test qui avait été ajouté. Les dernières étapes de ce travail, que sont les vérifications DRC/LVS du circuit, ont nécessité l'aide du CMP. En effet, les étudiants n'avaient pas l'expérience nécessaire pour résoudre la totalité des problèmes rencontrés.

## V. Organisation interne de la puce

L'architecture interne choisie, permet de sélectionner les IPs pour les tester individuellement, mais également de les chaîner si nécessaire. Cette disposition permet de limiter le nombre de plots d'entrées-sorties puisque les pins du boîtier sont mutualisés pour tous les sous blocs de la puce. Le bus de sélection commun à tous les multiplexeurs est alors composé de 4 bits : le bit de poids fort permet de choisir entre les parties réception ou émission, et les bits restants sélectionnent les différents modes de test. On peut alors utiliser chaque sous blocs individuellement, les connecter par deux mais également tester la chaîne de réception et/ou d'émission entièrement. Les valeurs de sélections restantes sont attribuées au mode DEFAULT, qui permet seulement une recopie des bits appliqués au bus d'entrée, sur le bus de sortie. Le tableau 1 et la figure 3 illustrent l'organisation interne de la puce ainsi que la table des correspondances des modes de test avec la valeur du sélecteur.

<table><caption>Tableau 1. Table de codage des modes en fonction de la valeur du sélecteur.</caption><thead><tr><th>MODE</th><th>Ctrl3 [RX/TX]</th><th>Ctrl2</th><th>Ctrl1</th><th>Ctrl0</th><th>sel</th></tr></thead><tbody><tr><td>FIFO_TX</td><td>0</td><td>0</td><td>0</td><td>1</td><td>1</td></tr><tr><td>MOD_TX</td><td>0</td><td>0</td><td>1</td><td>0</td><td>2</td></tr><tr><td>Conf_TX</td><td>0</td><td>0</td><td>1</td><td>1</td><td>3</td></tr><tr><td>DEM_RX</td><td>1</td><td>0</td><td>0</td><td>1</td><td>9</td></tr><tr><td>CORDIC_RX</td><td>1</td><td>0</td><td>1</td><td>0</td><td>10</td></tr><tr><td>CDR_RX</td><td>1</td><td>1</td><td>0</td><td>0</td><td>12</td></tr><tr><td>DEM..CORDIC_RX</td><td>1</td><td>0</td><td>1</td><td>1</td><td>11</td></tr><tr><td>CORDIC..CDR_RX</td><td>1</td><td>1</td><td>1</td><td>0</td><td>14</td></tr><tr><td>Conf_RX</td><td>1</td><td>1</td><td>1</td><td>1</td><td>15</td></tr><tr><td>Fonctionnel</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td></tr><tr><td>DEFAULT</td><td>X</td><td>X</td><td>X</td><td>X</td><td>X</td></tr></tbody></table>
<figure><img src="image_3.png" /><figcaption>Fig.3. Schéma interne de l'organisation des IPs avec les multiplexeurs.</figcaption></figure>

Un premier envoi de la puce complète au CMP a pu être réalisé avant la fin du projet pédagogique. Toutefois, cette version ne passait pas complètement les dernières étapes de validation. Deux étudiants ont alors pris en charge cette tâche et ont terminé le travail au-delà de l'échéance du projet. En échangeant de manière très régulière avec le CMP pour comprendre au mieux les dernières erreurs et les corriger en modifiant les scripts de placement et de routage, le circuit a finalement pu être envoyé au fondeur sans erreur et dans les temps. La figure 4 présente le dessin des masques et la puce finale produite et mise en boîtier lors de ce projet.

<figure><img src="image_4.png" /><figcaption>Fig.4. Le dessin des masques (layout) et la puce packagée dans son boîtier DIL 48.</figcaption></figure>
# VI. Conclusion : retour sur le travail réalisé et perspectives de test

Ce projet a été sans aucun doute très formateur car il va au-delà des attentes et préconisations d'un enseignement conventionnel. Il oblige en effet les étudiants à se placer dans un contexte quasi-professionnel et à produire les plans d'une puce qui puisse être envoyés en fabrication. Actuellement, peu de cursus dans le monde offrent une telle possibilité à ce niveau d'études (Master). Le projet constitue forcément une étape clé dans le long apprentissage nécessaire à la conception des circuits électroniques intégrés et restera probablement un moment fort de la formation de ces étudiants. Au-delà de l'enseignement technique, ce projet a aussi mis en exergue des qualités humaines comme l'effort, la rigueur, la persévérance, la ténacité et la solidarité. Cette aventure technique a également été une aventure humaine pour les dix étudiants.

A l'heure où nous écrivons ces lignes, nous avons reçu la puce fabriquée et mise en
boitier. L'histoire ne s'arrêtera pas là car les étudiants auront la possibilité de tester la puce
qu'ils ont conçue en seconde d'année durant leur troisième année d'école. C'est prévu dans
le syllabus de leur filière. Le test de la puce devrait avoir lieu en juin 2022.

Remerciements

Les étudiants et leurs professeurs souhaitent vivement remercier le CIME Nanotech et
le CMP pour le support qui leur a été apporté tout au long du projet. Le CIME Nanotech a
accueilli les étudiants tout au long du projet et leur a fourni un environnement professionnel
de CAO. Le CMP a, quant à lui, offert quelques millimètres carrés de silicium et une aide
extrêmement précieuse au débogage des erreurs DRC dans la phase de validation finale.
Au-delà des structures, les remerciements s'adressent tout particulièrement aux personnels
techniques qui ont facilité, voire permis cette réalisation.

Références

1. Olivier Bonnaud, Laurent Fesquet, "Communicating and Smart Objects: multidisciplinary topics for the innovative education in microelectronics and its applications", 14th International Conference on Information Technology Based Higher Education and Training, ITHET 2015, 11-13 June, 2015, Caparica, Lisbon, Portugal, pp 1 - 5, DOI: 10.1109/ITHET.2015.7217961.

2. Olivier Bonnaud, Laurent Fesquet, "Microelectronics at the heart of the digital society: technological and training challenges", 34th SBMicro – Symposium on Microelectronics and Devices, August 26 to 30, 2019, São Paulo, Brasil.

3. Olivier Bonnaud, Laurent Fesquet, "The practice in microelectronics: a mandatory complement of the online courses in the context of digital society", 33rd Symposium on Microelectronics Technology and Devices - SBMICRO 2018, Bento Gonçalves – Rio Grande do Sul – Brazil – August 27-31, 2018.

4. Promotion 2019 MT Phelma, Rapport final projet Zigbee (2021), archive de Grenoble INP/Phelma.

5. Promotion 2019 MT Phelma, Rapport système projet Zigbee (2021), archive de Grenoble INP/Phelma.