Vous avez besoin d’un coup de pouce pour permettre à votre équipe de procéder à la vérification physique d’une puce entière dans un flot d’implémentation parallélisé ? L’adoption d’un flot de vérification DRC d’interface permet une validation précoce de la conception au niveau de la puce complète tout en minimisant les fausses erreurs , évite les reprises coûteuses associées aux flots utilisant différentes solutions de DRC et facilite la transition vers la vérification finale (sign-off).
Dans la plupart des entreprises faisant de la conception, les équipes chargées de l’implémentation physique au niveau de la puce entière, responsables du floorplanning dans les environnements de placement-routage (P&R) gèrent également la vérification physique de haut niveau depuis les premières étapes du floorplanning jusqu’au « tapeout ». Dans les premières étapes du floorplanning, les blocs placés dans le floorplan au niveau de la puce entière sont généralement encore en cours de développement. La fusion de ces blocs incomplets avec l’interconnexion au niveau de la puce pour la vérification des règles de conception (DRC) sign-off produit généralement un nombre considérable d’erreurs à partir du cœur du bloc et le long de la frontière du bloc à l’interface au niveau de la puce. Même si certaines de ces erreurs s’avèrent en fait réelles, trier tous les résultats pour les trouver prend beaucoup de temps et apporte très peu au processus.
Les flots de conception et les bonnes pratiques de conception varient d’une entreprise à l’autre (et souvent même d’une équipe à l’autre au sein d’une même entreprise). En revanche, ce qui est constant, c’est le désir de tous de respecter les délais de tapeout extrêmement serrés. La suppression d’activités inutiles comme l’examen des résultats DRC incorrects améliore certainement la situation. Une solution idéale consisterait à permettre aux concepteurs responsables de la puce de valider les interfaces d’interconnexion et de bloc au niveau de la puce dans leur floorplan sans générer une multitude de résultats DRC incorrects.
Une approche consiste à modifier le flot de vérification « signoff » au niveau de la puce entière afin de créer un flot DRC d’interface provisoire qui exclut les règles et les données qui ne peuvent être vérifiées de façon fiable lorsque les blocs sont incomplets. Un flot d’implémentation parallèle peut présenter des blocs à différents stades de développement au même moment. Bien entendu, la vérification des blocs (chacun pouvant se trouver à un stade différent de conception physique) dans le contexte de la puce entière est plus complexe qu’une méthode plus simple de conception en cascade (waterfall), où tous les blocs sont terminés avant d’être placés au niveau de la puce entière pour vérification. Toutefois, l’adaptation du flot de validation sign-off pour prendre en charge la DRC d’interface permet également de valider les conceptions au niveau de la puce entière, évite les reprises coûteuses associées aux flots utilisant plusieurs solutions de DRC et facilite la transition vers la vérification « sign-off » complète .
Vérification d’interface au niveau de la puce
Les jeux (« decks ») de règles DRC contiennent l’ensemble complet des règles (telles que définies par le fondeur) requises pour valider les géométries, les blocs et les cellules individuelles des puces complètes. En général, ces decks contiennent également des groupes de règles et des variables qui aident les utilisateurs à simplifier la configuration pour exécuter les règles au niveau des puces, des blocs ou des cellules. Par exemple, la définition d’une option au niveau des cellules ou des blocs peut exclure les vérifications au niveau de la puce comme les règles densité ou les antennes, qui peuvent s’avérer inutiles pour la vérification des cellules et des blocs. A l’opposé, les exigences relatives à la vérification de la puce entière imposent des vérifications au niveau des cellules et des blocs, ainsi que des vérifications de densité, des antennes et d’autres vérifications au niveau de l’assemblage, pour répondre aux critères de validation sign-off. Les exigences de la DRC d’interface diffèrent des deux cas précédents, se situant quelque part entre les deux.
Les flots de vérification « sign-off » supposent que les bases de données d’entrée sont complètes. Cependant, dans un flot de conception parallèle, les enveloppes de blocs définis dans le floorplan de P&R au niveau de la puce sont remplacées par le détail complet des blocs en format GDS ou OASIS, qui contiennent géométries physiques produites par d’autres équipes. Un flot DRC d’interface n’utilisera pas toujours des blocs terminés au format GDS ou OASIS, mais l’empreinte, l’emplacement des broches et certaines interconnexions existent déjà. Le cœur du bloc peut inclure des placements ou des interconnexions, selon le niveau d’avancement sur chaque bloc individuel. Exclure les cœurs de blocs incomplets tout en incluant la périphérie du bloc lors de la DRC d’interface permet d’identifier et de signaler toutes les violations contextuelles au concepteur chargé de la puce entière, mais évite les résultats d’erreurs DRC dûes au coeur (que le concepteur ne peut pas corriger).
La vérification d’interface simplifie le flot de vérification en exécutant sélectivement des contrôles uniquement au niveau de la puce (qui génèrent des résultats corrects sur des données de conception incomplètes) et en ne vérifiant que les bords des blocs incomplets dans leur contexte au niveau de la puce. Certaines méthodologies de conception prennent en charge le routage par dessus les cellules, tandis que d’autres exigent qu’un routage qui traverse une cellule doive être ramené au niveau du bloc. Le placement des blocs dans les floorplans de P&R peut comprendre des canaux de routage entre les blocs, des placements abutés ou un mélange des deux (Figure 1).
Figure 1 : (à gauche) floorplan basé sur des canaux avec routage au-dessus des cellules ; (à droite) floorplan abuté avec routage par couture (“stitch”).
En raison de ces facteurs et d’autres, les exigences particulières d’un flot DRC d’interface peuvent varier. La solution de DRC d’interface présentée ici peut être utilisée par les deux méthodologies de floorplanning, mais elle convient mieux au placement adjacent sans routage au-dessus des cellules.
Voici les éléments clés nécessaires à l’implémentation d’un flot de DRC d’interface :
• déterminer quand activer ou désactiver la vérification de certaines règles au niveau de la puce
• exclure les données des blocs ou cœurs incomplets de la vérification ou des résultats DRC
Choix des règles DRC à vérifier
Pour simplifier le processus de sélection de l’ensemble correct de vérifications à appliquer au niveau des cellules, des blocs ou des puces, les fonderies définissent souvent des groupes de règles de contrôle dans le fichier de règles (par exemple, CELL ou CHIP) qui définissent la liste des vérifications requises pour chaque niveau de conception. Les concepteurs qui travaillent sur le développement de cellules spécifient le groupe de vérifications CELL, tandis que les équipes en charge de la puce utilisent le groupe de vérifications CHIP.
Dans un flot d’implémentation parallèle, la vérification au niveau de la puce requiert le groupe de vérifications CHIP, mais de fausses erreurs dues à des blocs incomplets peuvent entraver les efforts de débogage. La création d’un groupe INTERFACE contenant un sous-ensemble de vérifications au niveau de la puce permet aux concepteurs de cibler les vérifications appropriées pour les différentes étapes de conception et évite de perdre du temps à déboguer les fausses violations au niveau de la puce (Tableau 1).
Tableau 1 : Groupes de vérifications DRC
Cependant, l’intégration de nouveaux groupes de vérifications au « deck » existant d’une fonderie peut nécessiter des modifications de ce deck, ce qui ne représente pas toujours une option viable pour les équipes de conception. Une autre méthode consiste à utiliser l’en-tête du fichier de règles pour exclure spécifiquement les vérifications qui ne doivent pas être exécutées au niveau de la puce entière et inclure le « deck » non modifié de la fonderie. L’exemple de pseudocode suivant montre comment la variable de règle de validation est utilisée pour activer les vérifications au niveau de la puce pour un fichier de règles de validation Calibre®. La commande « Include » de l’en-tête du fichier DRC atteint le même objectif que l’utilisation d’un groupe de vérifications INTERFACE. Pour supprimer les vérifications qui ne doivent pas être exécutés pour la DRC de l’interface, il suffit de désélectionner leur nom.
<Exclude chip-level checks>
INCLUDE FILE “signoff_calibre.rules” // Include foundry Calibre sign-off rule file. SET CHECK_LEVEL = ”CHIP” // Set chip-level check variable.
DRC DESELECT “Rule_4 Rule_6” // Un-select chip-level checks for interface DRC.
Exclusion des blocs incomplets
Le deuxième défi associé à la mise en place d’une méthode de vérification des interfaces au niveau de la puce pour les flots d’implémentation parallèle consiste à éliminer les cœurs de blocs incomplets, tout en conservant la périphérie du bloc pour vérifier les interfaces de placement au niveau de la puce. Plus tard, une fois le layout des blocs terminé, la vérification au niveau de la puce doit inclure le bloc entier, pas seulement la périphérie (Figure 2).
Figure 2 : La DRC d’interface applique la vérification d’interface aux blocs incomplets et permet la vérification complète des blocs au fur et à mesure qu’ils sont complets. La DRC de sign-off final vérifie les géométries internes des blocs une fois qu’ils sont tous complets.
Les concepteurs peuvent exclure des cœurs de blocs de la vérification en définissant des régions d’exclusion dans le même en-tête du fichier de règles que celui utilisé pour définir les vérifications au niveau de l’interface. Par exemple, la syntaxe du format des règles de vérification standard (SVRF) de Mentor peut interpréter ces régions d’exclusion comme des “fenêtres” de layout qui ne doivent pas être vérifiées. Ces régions peuvent être créées rapidement (Figure 3) à l’aide d’un script TCL (Tool Command Language) qui réalise les étapes suivantes :
1. Lire uniquement le marqueur de limites de P&R dans l’éditeur de layout.
2. Rechercher les instances de blocs de niveau supérieur qui sont incomplètes.
3. Voir les géométries de chaque instance pour promouvoir la limite de P&R au niveau supérieur.
4. Itérer sur les frontières de P&R au niveau supérieur.
5. Rétrécir chaque forme par la valeur du « halo ».
6. Exporter les coordonnées de la forme en tant que région d’exclusion SVRF.
Figure 3 : Un script TCL peut rapidement convertir les limites de placement des blocs (en bleu) en régions d’exclusion au niveau de la puce (en rouge) et les sortir en SVRF.
La valeur du halo de sous-dimensionnement doit être suffisamment grande pour inclure la périphérie du bloc qui permet la DRC d’interface, mais suffisamment petite pour limiter les fausses erreurs le long du bord des régions d’exclusion. Les régions d’exclusion peuvent également être utilisées pour identifier et filtrer les résultats indésirables à l’intérieur de la périphérie du bloc. À mesure que les blocs sont complets, ils ne devraient plus avoir besoin de régions d’exclusion. Sur la Figure 4, les limites sous-dimensionnées des placements incomplets (blocs A et B) sont converties en déclarations d’exclusion SVRF, qui définissent les données de conception à exclure de la vérification de l’interface. Une fois le bloc C complet, seules les références de A et B doivent générer des régions d’exclusion.
Figure 4 : Les placements incomplets (A et B) peuvent être exclus de la DRC d’interface.
Le script TCL peut ajouter ces régions à l’en-tête du fichier de règles qui définit les vérifications d’interface à exécuter. En associant les fenêtres d’exclusion générées aux sélections de la DRC d’interface, la configuration du fichier de règles d’entrée requis pour exécuter la vérification au niveau de la puce est réalisée, tandis que les blocs sont définis en parallèle pour le niveau supérieur de la puce. Lorsque l’implémentation des blocs est presque terminée, les concepteurs peuvent facilement passer au flot DRC sign-off.
Conclusion
Les équipes de conception des puces qui veulent améliorer la vérification physique au niveau de la puce entière dans un flot d’implémentation parallélisé peuvent gagner beaucoup de temps en améliorant les flots DRC de validation existants à l’aide de la vérification DRC incrémentale de l’interface. La définition des vérifications à inclure ou à exclure et la méthode pour exclure les cœurs de blocs incomplets de la vérification DRC représentent les deux principaux défis associés à la configuration du flot de vérification « sign-off » . D’autres solutions axées sur des méthodologies de conception différentes peuvent nécessiter des stratégies quelque peu différentes, mais les équipes qui adoptent un flot de DRC d’interface basé sur leur méthodologie de validation raccourciront les sessions d’exécution de la DRC et de débogage pendant l’implémentation des blocs et auront la certitude que leur conception est vérifiée avec le « sign-off » défini par la fonderie.
Auteur : James Paris
Mentor, A Siemens Business
James Paris est ingénieur technico-marketing au sein de la division Design to Silicon de Mentor, une entreprise de Siemens, et est en charge des interfaces Calibre avec les outils de conception. Avant de rejoindre Mentor, il était responsable de l’implémentation physique des circuits analogiques/mixtes et du développement des flots dans diverses sociétés de conception de circuits intégrés. James est titulaire d’un B.S. en ingénierie CAO et d’un M.B.A. en marketing. Il est joignable à l’adresse james_paris@mentor.com.
Pour en savoir plus, cliquez ici
