Rapport de TP ASIC

Rapport de TP
ASIC
2008/2009
Par : Hamza BOUKABACHE
Olivier PISTRE
Application Specific Integrated Circuit
5eme AE
Dans un marché de plus en plus concurrentiel, l’électronique actuelle tend vers une
complexité d’intégration de plus en plus croissante dans le but d’exécuter toujours plus de
fonctions. Dans ce contexte là et dés les années 90, de nouveaux composants intégrés tels que
les ASIC (Application Specific Integrated Circuit) feront leurs apparition. Entièrement dédiés,
les ASICs permettent en général d’exécuter un grand nombre de fonctionnalités uniques et sur
mesure. Leurs gros tau d’intégration les rendent cependant assez cher à la production et donc
moins attractifs pour les petites série.
Pour ce rapport, nous proposons de suivre le flot de conception des ASICs pour la réalisation
d’un circuit simple et basique : Un compteur 8 bits
Figure N°1 : Compteur 8bits
Où :
CK
RST
LOAD
SENS
EN
Din
Dout
Horloge.
Reset (actif bas).
Signal de commande synchrone de chargement du compteur (actif haut).
Définit le sens du comptage.
Enable – permet au compteur de compter s’il est à la masse (actif bas)
Donnée à charger dans le compteur quand la commande LOAD est active
Sortie sur 8 bits
Lors de tout le processus de conception il est vital de suivre chaque étape du flot de
conception (Cf. figure n°2). Le non respect d’une de ces étapes peut mener au meilleur des
cas à un ASIC non fonctionnel. Nous structurerons dons notre rapport sur ce model, où
chaque étape de ce flot constituera un chapitre.
Conception
comportemental du
compteur en VHDL
Simulation après
placement routage
Simulation
fonctionnelle
Synthèse et
optimisation
Placement routage
Simulation après
synthèse
Figure N°2 : Le flot de conception ASIC
1 - La description comportementale du compteur :
La conception de l’ASIC se fait en utilisant un langage de description propre à ce genre
d’application. Il en existe plusieurs tel que Verilog ou SystemC. Dans notre cas nous
utiliserons le VHDL.
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
use IEEE.std_logic_unsigned.all;
entity counter is
port (
Rst, Load, En, Sens, Clk: in std_logic ;
Din : in std_logic_vector(0 to 7);
Dout : out std_logic_vector(0 to 7)
);
end counter;
architecture bah of counter is
signal Aux : std_logic_vector(0 to 7);
begin
process (Rst, Clk)
begin
if Rst='0' then
Aux <= "00000000";
elsif Clk'event and Clk='1' then
if En = '1' then
if Load = '1' then
Aux <= Din;
else
if sens = '0' then
Aux <= Aux+1;
else
Aux <= Aux-1;
end if;
end if;
end if;
end if;
end process ;
Dout <= Aux;
end bah ;
2 - Simulation fonctionnelle :
L’étape de simulation est nécessaire pour valider le code VHDL. Pour cela nous devons écrire
un autre code pour tester le bon fonctionnement du compteur en lui envoyant des signaux
logiques correspondant aux signaux d’entrées (Cf. figure N°1).
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
use IEEE.std_logic_unsigned.all;
entity test_counter is
end test_counter;
architecture bench of test_counter is
component counter is
port(
Rst, Load, En, Sens, Clk: in std_logic ;
Din : in std_logic_vector(0 to 7);
Dout : out std_logic_vector(0 to 7)
);
end component;
for all : counter use entity work.counter(bah);
signal Rst_T, Load_T, En_T, Sens_T: std_logic ;
signal Clk_T : std_logic :='0';
signal Din_T : std_logic_vector(0 to 7);
signal Dout_T : std_logic_vector(0 to 7);
begin
count: counter port map (Rst_T, Load_T, En_T, Sens_T, Clk_T,
Din_T, Dout_T);
Clk_T <= not Clk_T after 50 ns ;
Rst_T <= '0','1' after 80 ns ;
En_T <= '1','0' after 1200 ns;
Din_T <= "00000000","10000000" after 90 ns ;
Load_T <= '0','1' after 200 ns, '0' after 300 ns;
Sens_T <= '0','1' after 500 ns;
end bench ;
Cependant, une simulation réussit ne signifie pas forcement que le code est synthétisable et ne
garantie encore mois le bon fonctionnement l’ASIC. D’autres considérations sont à prendre
compte tels que les chemins critiques, la fréquence minimum de fonctionnement… Nous
verrons ces points après chacun en détail.
Pour tester le bon fonctionnement du compteur nous avons intégré le code counter.vhd
et son fichier teste dans la plateforme nclaunch de Cadence. Apres compilation nous lançons
finalement la simulation pour obtenir le résultat suivant :
Figure N°2 : Simulation fonctionnelle
La simulation étant satisfaisante nous pouvons passer à l’étape de synthèse logique.
3 - Synthèse logique
Une fois que le code a été simulé et qu’on a bien testé le bon respect du cahier des charges, on
passe à l’étape de synthèse. Cette étape consiste à produire à partir du code VHDL un circuit
électronique constitué de sous éléments basics tels que des portes logiques et des bascules
récupérés à partir d’une Library d’un fondeur de semi-conducteur.
La synthèse permet aussi de voire si le code VHDL tapé lors de la toute première étape est
cohérent. On peut ainsi vérifier par exemple que le nombre de bascules est acceptable ou dans
le cas contraire, revenir au code et modifier les parties responsable de l’anomalie.
Logique
combinatoire
R
E
G
I
S
T
E
Logique
combinatoire
R
E
G
I
S
T
E
R
E
G
I
S
T
E
Figure N°3 : Représentation des différents niveaux d’un circuit synchrone
La synthèse se fait à l’aide l’outil Design Analyser de Cadence qui permet de réaliser
automatiquement le circuit à partir de la description comportementale. L’outil offre plusieurs
niveaux d’abstraction, du simple schéma bloc au circuit électronique.
Figure N°4 : Vision block du compteur 8 bits
En descendant au niveau électronique nous obtenons le circuit suivant :
Figure N°5 : Le schéma électrique du compteur 8 bits
3- 1 Optimisation du circuit
Afin de pousser aux limites notre circuit, il est possible d’opérer une étape
d’optimiser lors de la synthèse afin d’obtenir une baisse de consommation et une fréquence de
fonctionnement plus rapide. Il est cependant très difficile d’obtenir les deux car
l’augmentation de la fréquence de commutation induit forcement une augmentation de la
consommation. La plupart du temps un compromis et trouvé. Dans notre cas nous nous
intéresserons qu’à l’optimisation en fréquence. Pour ce faire, le logiciel tentera de trouver les
chemins critiques (les chemins les plus longs entre deux niveaux de registre) et de les réduire.
Cette dernière se fait de façon incrémentale de sorte à ce qu’au final il n’y est plus de retard
sur les parties combinatoires.
Période
5ns
3ns
2ns
Nombre de cellules
60
72
Consommation
2.5mW
3.6mW
Design impossible
Design impossible
Tableau N°1 : Récapitulatif des résultats obtenus dans le journal de synthèse
Le résultat obtenu doit cependant être regardé de manière critique, même si dans l’apparence
le circuit parait fonctionner à la fréquence optimal, il est possible que la commutation des bits
au niveau des registres ne se fasse pas de façon synchrone. Cette anomalie peut être
occasionnée :
Une mauvaise répartition de l’arbre d’horloge due aux divers délais de
propagation
Une optimisation trop excessive des chemins combinatoire entre deux
niveaux mémoire
On verra qu’au final il peut y avoir d’autres origines au problème autres que l’optimisation en
elle même.
A la fin de cette étape nous remarquons que le circuit électronique a changé. En effet l’outil
d’optimisation en réduisant les chemins critique a changé la configuration des bascules et
portes logiques représentés figure N°5. On obtient ainsi un nouveau circuit :
Figure N°5 : Le circuit du compteur après optimisation
Remarquez que le circuit est organisé en plusieurs niveaux hiérarchiques tels que
l’additionneur ou le soustracteur non définit au niveau RTL et dont la présence se justifie par
l’utilisation de librairies.
Figure N°6 : Le circuit mise à plat après optimisation
Il est cependant possible de mettre à plat le circuit à l’aide de la commende ungroup. Il
devient ainsi possible de vérifier la cohérence entre le code VHDL et le circuit à proprement
dit (Cf. figure N°6). Le teste le plus simple serait de calculer le nombre de bascules existante.
Nous en comptant 8, ce qui correspond tout à fait à la nature du circuit.
4- Simulation après synthèse
Le circuit étant réalisé, le logiciel sait à partir des données fournis dans la librairie
AMS qu’elles sont les délais de propagation dans chaque porte logique. Le simulateur peut
ainsi calculer les retards que vont subir les signaux en passant le circuit. Pour ce faire nous
devons inclure le fichier contenant toutes ces données (.SDF) que nous avons sauvegardé
après la fin de l’étape d’optimisation.
A la fréquence maximale de fonctionnement (obtenu lors de l’étape d’optimisation) plusieurs
problèmes apparaissent :
Un retard de la commutation des états de sortis. Le comptage n’est donc
pas tout à fait synchrone avec les tops d’horloge. Ceci est du aux délais de
commutations des portes qui constituent le compteur.
Des états aléatoires du comptage à chaque top d’horloge. Ceci n’est pas
critique car le circuit fonctionne en logique synchrone.
5- Placement & routage :
La simulation après synthèse a permis de valider le bon fonctionnement de notre
circuit. Nous pouvons donc passer à l’étape de placement routage. Cette étape consiste à
passer de la vision abstraite du circuit à la version silicium. Pour cela nous utiliserons la
librairie de design kit AMS3.6 qui assure une technologie de 0.35µm à 4 niveaux de métal.
Cette étape est très critique car il existe un certain nombre de règles à respecter pour assurer le
bon fonctionnement du circuit.
La première d’entre elle est d’assurer une bonne répartition des alimentations à tout le circuit.
Pour cela on commence par dimensionner la surface de la puce pour laisser assez d’espace
aux annaux d’alimentations plus le circuit (Floorplan à 1 et core d’utilisation à 85%).
Pour assurer la bonne répartition des courants dans le circuit d’alimentation nous assurons une
largeur de piste de 4µm à 20µ du bord de la puce. Pour des raisons de CEM (Compatibilité
Electromagnétique) nous placerons respectivement une piste d’alimentation et une piste de
masse sur toute la surface de la puce (Cf. figure N°7).
On place ensuite les cellules électriques (standard cells) dont les layouts sont contenus dans le
fichier .LEF
Figure N°7 : La puce en vision abstraite avec son circuit d’alimentation
L’étape suivante consiste à designer l’arbre d’horloge pour distribuer le clock à
toutes les cellules histoire de minimiser les retards et les désynchronisations. Cette étape est
très critique et assez complexe, car il faut distribuer le signal d’horloge tout en minimisant la
longueur des pistes pour minimiser les effets RC liées à la techno et a la topologie du layout.
Nous nous contenterons donc de visualiser l’arbre d’horloge qui a été généré
automatiquement (Cf. Figure N°8).
L’étape suivante consiste à router les différentes interconnexions reliant les cellules entres
elles sur les différentes couches de métal. Heureusement le routage se fait automatiquement
(Cf. Figure N°9).
Figure N°8 : L’arbre d’horloge ici représenté en rouge.
Les Pins d’entrée
sortie
Figure N°9 : La puce avec ses interconnexions
Maintenant que toutes les étapes principales du routage ont été effectués nous pouvons
« zoomer » sur la puce au niveau transistor pour vérifier l’intégrité de la puce.
Figure N°10 : La puce avec ses différents niveaux de dopages
Remarquez la présence de nombreuses erreurs entourées par des carrés blancs. Ces erreurs
sont indiquées par le DRC (design rules check). Elles sont dues au non respect du design rule
(règles de routages liés à la technologie utilisée). Dans notre cas on ne respecte pas la distance
minimale entre deux niveaux dopé (N-well). Pour corrigé cela nous utilisons un fichier script
qui va fusionner tout les N-Well adjacents entre eux pour n’en former qu’un seul. Nous
obtenons ainsi la figure N°12.
SiO2
Poly Si
N-well
Erreur de type spacing
Figure N°12 : Erreur de type Spacing
Figure N°11 : La puce avec ses différents niveaux de dopages sans erreurs de DRC
6- Simulation après Placement et Routage – Backannotation
Cette étape est l’étape de validation finale, elle permet de vérifier que le layout final est bien
fonctionnel et qu’il est conforme aux attentes du cahier des charges. Cette étape consiste
l’ultime étape de vérification avant l’étape de réalisation. Malheureusement nous n’avons pu
tester notre circuit car le logiciel retournait une erreur du type : incohérence entre fichier SDF
et fichier VHDL.
Conclusion
Durant ce TP nous avons suivie le flot de conception d’un circuit ASIC avec tout se que
cela a impliqué comme optimisation en fréquence ou en consommation. Nous avons aussi
constaté la corrélation qui existe entre la technologie utilisée et le code VHDL sur les
performances souhaités. De se fait nous avons pu nous familiarisé avec un outil de conception
et de simulation puissant qu’est Cadence.