Une architecture basée sur un bus pour distribuer les données de scan permet de véritables flots de DFT bottom-up hiérarchiques

L’augmentation considérable de la durée du test en production des systèmes sur puce (SoC) complexes d’aujourd’hui provient de l’utilisation d’approches traditionnelles permettant de déplacer les données de scan depuis les ports d’entrée/sortie de la puce jusqu’aux canaux de test des blocs qui la composent. L’utilisation d’un TAM (Test Access Mechanism ou multiplexage des ports) convient parfaitement aux designs de petite taille, mais peut devenir problématique avec la complexité croissante des systèmes actuels, ainsi qu’avec l’augmentation du nombre de blocs. La nouvelle révolution dans le domaine des outils de DFT pour réduire la durée, le coût du test et les efforts de mise en œuvre de la DFT, va permettre d’éliminer les défis inhérents à l’utilisation d’un TAM, en dissociant les contraintes DFT requises par les blocs, des ressources disponibles pour le test au niveau de la puce.

Les défis d’une DFT se basant sur l’utilisation d’un TAM

Une façon courante de connecter les canaux de test des blocs aux ports d’entrée/sortie de la puce consiste à recourir à un réseau de multiplexage permettant de sélectionner les blocs que l’on souhaite tester. Cette méthode convient particulièrement aux designs de petite taille, mais devient problématique avec l’augmentation du nombre de blocs, des niveaux de hiérarchie, et de la complexité des systèmes. Elle présente des limitations lorsque l’on souhaite tester des blocs en parallèle de manière efficace afin de gagner en temps et en coût. Les défis sont les suivants :

• S’astreindre à l’utilisation d’un nombre limité d’entrées/sorties disponibles pour le test
• S’astreindre à l’utilisation d’un nombre limité de canaux dédiés pour le test au niveau du cœur
• Mettre en place des configurations de test prédéterminées lors du processus de conception
• Anticiper des risques de congestion du routage provenant de canaux supplémentaires nécessaires pour le test

Avec une approche bottom-up de la DFT, les ingénieurs DFT allouent généralement au début du flot un nombre fixe de canaux de test à chacun des blocs, généralement le même nombre pour chaque bloc. Il s’agit de l’approche la plus simple, mais elle peut se traduire par un gaspillage de bande passante parce que les différents blocs regroupés dans la même session de test peuvent présenter des longueurs de chaînes de scan différentes et un nombre de vecteurs de test différent (fig. 1).

Figure 1. Dans un flot de DFT hiérarchique, investir moins d’efforts dans une implémentation se basant sur un TAM (Test Access Mechanism – multiplexage des ports d’entrée/sortie) peut engendrer une utilisation sous-optimale de la bande passante
 

Une autre approche permettant d’une part de diminuer le gaspillage de la bande passante et d’autre part de réduire la durée du test, consiste à réallouer les ressources dédiées au scan, une fois que la configuration requise par les blocs est bien identifiée. Cette méthode implique toutefois une reconfiguration de la compression, de nouvelles étapes de routage des canaux de test, et une régénération des vecteurs de test (fig. 2).

Figure 2. Construire un réseau de multiplexage plus complexe pour mieux aligner les entrées et sorties des canaux de test permettra de réduire la durée du test, mais au prix d’un effort plus important de mise en œuvre.
 

L’effort supplémentaire justifie-t-il les économies réalisées en termes de durée du test ? Chaque équipe de DFT doit statuer sur ces compromis. De nouveaux défis et compromis nécessitent d’être surmontés pour les designs comportant des structures hiérarchiques plus complexes, un grand nombre de cœurs identiques, ou encore un layout avec des designs physiques en « tuiles » qui sont abutées les unes par rapport aux autres.

L’approche avec un réseau de données de scan

Une nouvelle approche de distribution des données de scan sur un SoC, appelée Streaming Scan Network (SSN), permet de réduire à la fois l’effort d’implémentation de la DFT ainsi que la durée du test en production, avec une prise en charge totale des designs en tuiles et une optimisation pour les designs qui contiennent des cœurs identiques instanciés plusieurs fois. L’approche SSN repose sur le principe de dissociation des contraintes DFT requises par blocs, des ressources disponibles pour le test au niveau de la puce, en utilisant un bus synchrone à haut débit pour transmettre aux blocs les données de test regroupées sous forme de paquets.

Le nombre de canaux de test dédiés aux blocs est entièrement indépendant de la largeur du bus SSN, et du nombre de canaux de test disponibles au niveau de la puce, et ceci quel que soit le nombre de blocs qui composent le design. Transmettre des données de test de cette manière simplifie la planification et la mise en œuvre du design, en permettant de définir le regroupement des blocs à tester en parallèle à un stade ultérieur dans le flot, à savoir pendant le reciblage des vecteurs de test et non lors de la phase initiale du design. L’architecture SSN est flexible (la largeur du bus est déterminée par le nombre de ports d’entrées/sorties disponibles pour le test), permet de réduire les problèmes de congestion du routage et facilite enfin les tâches de vérification de timing, car elle élimine le TAM nécessaire au niveau du top, ce qui la rend également idéale pour les designs reposant sur des tuiles abutées.

Une partie de l’architecture SSN est constituée de nœuds hôtes au niveau du bloc qui génèrent localement les signaux DFT. Les nœuds hôtes veillent à ce que les données adéquates soient collectées sur le bus SSN puis envoyées sur les entrées de test du bloc et à ce que les données de sortie soient replacées sur le bus. Chaque nœud sait précisément quoi faire et à quel moment, selon une étape de configuration simple tirant parti de l’infrastructure IJTAG (IEEE 1687). Grâce à SSN, les groupes de blocs qui seront testés ensemble et ceux qui seront testés séquentiellement sont totalement reconfigurables, même lorsque le design a été achevé. Cette configuration est effectuée une fois pour chaque jeu de vecteurs, à l’étape de test setup. Lorsque celle-ci est terminée, l’intégralité des données du bus SSN sont des données dédiées au test en scan.

Qu’est-ce que la transmission de données de scan regroupées en paquets ?

Prenons l’exemple d’un design dans lequel deux blocs doivent être testés simultanément en utilisant SSN (fig. 3). Le bloc A comporte 5 canaux de scan, le bloc B en contient 4. Un paquet est le volume total de données nécessaires pour effectuer un cycle de shift sur les deux cœurs. La taille du paquet dans cet exemple est de 9 bits. Cependant, 16 ports sont disponibles pour le scan (8 entrées, 8 sorties). Le bus SSN présente donc une largeur de 8 bits. 

Figure 3. Test de deux blocs en parallèle. Avec l’utilisation d’un TAM, neuf ports d’entrée dédiés au test au niveau de la puce et neuf ports de sortie seraient nécessaires. Avec SSN, la taille du paquet est de 9 bits, et ce dernier est transmis sur un bus de 8 bits.
 

Le tableau dans la partie gauche de la figure 3 illustre comment les données sont transmises aux blocs par le bus synchrone SSN. Il faudra deux cycles sur le bus SSN pour transmettre toutes les données nécessaires à l’exécution d’un cycle de shift dans les deux blocs. Notez que l’emplacement des bits de données correspondant à chaque bloc se décale d’un paquet à l’autre. Les nœuds hôtes savent exactement où les données correspondant à chaque bloc résident sur le bus, et quand est-ce qu’il est nécessaire de générer les signaux DFT locaux, notamment l’horloge de shift du bloc, afin d’utiliser ces données pour le test du bloc en question.

Comment SSN réduit la durée du test et le volume des données de test

SSN compte plusieurs fonctionnalités permettant de réduire la durée du test ainsi que son volume de données. L’une d’elles provient de l’indépendance des cycles de shift et de capture. Dans de nombreux schémas de reciblage, les cycles de capture de tous les blocs concernés doivent être alignés. Si plusieurs blocs ont des cycles de shift simultanés (fig. 4) et présentent des longueurs de chaines de scan différentes, les cycles des blocs ayant des chaînes plus courtes doivent être comblés afin de réaliser une capture simultanée de tous les blocs. Avec SSN, les nœuds hôtes sont programmés de sorte que chaque bloc puisse opérer ses cycles de shift de manière indépendante, ainsi que la capture qui a lieu en parallèle une fois que les blocs ont terminé le chargement et le déchargement de leurs chaines de scan.

Figure 4. Lorsque les cycles de capture doivent être alignés, certains cœurs nécessitent de recourir au padding (remplissage avec des données non utilisées), ce qui représente une perte de données et de temps de test.

SSN effectue également une optimisation de l’utilisation de la bande passante. Plutôt que de fournir autant de bits par paquets que de canaux de test disponibles par bloc, SSN peut allouer moins de bits à un bloc qui nécessite globalement moins de données. Pour un bloc ayant un nombre moindre de vecteurs ou qui comporte des chaînes de scan plus courtes, un volume moins important de données est alloué dans chaque paquet, ce qui permet de mieux répartir les données entre les blocs et, in fine, de réduire la durée du test.

SSN est une architecture évolutive permettant de tester un nombre quelconque de cœurs identiques avec un volume de données et une durée de test constants. Pour les cœurs identiques, un circuit de comparaison est inclus dans chaque nœud hôte. Les données fournies aux cœurs qui sont identiques sont les entrées de scan, les données attendues et les données de masquage. Cela permet d’effectuer une comparaison dans chaque cœur. Les résultats de test de tous ces cœurs identiques sont ensuite accumulés pour fournir un état final qui est transféré sur le bus SSN. Un bit de réussite/échec spécifique à chaque cœur est également capturé dans l’hôte et analysé via IJTAG.

Résumé

SSN a été développé en collaboration avec plusieurs grands fabricants de semi-conducteurs. Nous avons présenté un papier conjointement avec Intel lors de l’International Test Conference 2020. Ce papier décrit la technologie et présente les résultats clés de la validation de SSN par Intel. Par rapport à une solution reposant sur le TAM, Intel a constaté une réduction de 43% du volume de données de test, ainsi qu’une réduction de 43% des cycles de test. Les étapes du flot de conception et de reciblage ont été 10 à 20 fois plus rapides avec SSN.

SSN élimine les difficiles compromis entre la mise en place d’un flot d’implémentation efficace et rationalisé d’une part, la réduction et l’optimisation du coût de test d’autre part.

Geir Eide est directeur de la gestion de produits DFT (Design-for-Test, conception en vue du test) Tessent chez Siemens Digital Industries Software. Fort d’une expérience de 20 ans dans le secteur de la DFT et du test de circuits intégrés, Geir a travaillé avec des fabricants de semi-conducteurs de premier plan. Il a effectué des présentations techniques et des séminaires sur la DFT, le test et le processus d’apprentissage du rendement dans le monde entier. Geir a obtenu sa maîtrise en ingénierie électrique et informatique à l’université de Californie à Santa Barbara, et sa licence en microélectronique à l’université du sud-est de la Norvège (USN).