Schwerpunkte

Design for Testability

Keine Kompromisse, dank Paket-basierten Testdaten

12. Mai 2021, 06:00 Uhr   |  Von Geir Eide

Keine Kompromisse, dank Paket-basierten Testdaten
© Siemens EDA

Die bisher übliche Design-for-Testability-Methode stößt bei komplexen SoCs an Grenzen und zwingt Entwickler zu Kompromissen. Eine neue Testmethode kennt diese Limitierungen nicht. Sie nutzt eine Bus-Architektur um Testdaten paketweise zu übertragen – schneller und effizienter als zuvor.

Die drastische Zunahme der Testdauer in der Produktion heutiger großer und komplexer SoCs basiert auf den tradi­tionellen Ansätzen für den Transfer von Scan-Testdaten von den Chip-Pins auf die Scan-Kanäle der einzelnen Blöcke. Der Pin-Multiplex-Ansatz (Mux) funktioniert gut bei kleineren SoCs, kann aber mit einer steigenden Anzahl an Blöcken und Komplexität heutiger SoCs problematisch werden. Moderne DFT-Tools (Design for Testability), die Testzeit, Testkosten und den Aufwand der DFT-Implementierung adressieren, beseitigen die Limitierungen des Pin-Mux-Ansatzes, indem die DFT-Anforderungen auf Blockebene von den Ressourcen für Testdaten auf Chipebene entkoppelt werden.

Herausforderungen des Pin-Mux-Ansatzes

Eine gängige Möglichkeit, Scan-Kanäle auf Blockebene mit Chip-Pins zu verbinden, ist die Verwendung eines Mux-Netzwerks, um festzulegen, welche Blöcke mit Chip-Pins verbunden sind. Was bei kleineren SoCs gut funktioniert, wird problematisch, wenn die Anzahl der Blöcke wächst, mehr Hierarchieebenen hinzukommen und der gesamte SoC-Entwurf komplexer wird. Die Methode blockiert eine effiziente Parallelisierung des Tests von Blöcken. Zu den Herausforderungen gehören:
➔ Begrenzte Verfügbarkeit von E/As für Scan-Tests
➔ Begrenzte Anzahl an Kanälen auf Blockebene
➔ Starre Testkonfigurationen, die während des Entwurfprozesses festgelegt wurden.
➔ Zusätzliche Scan-Kanäle können das Routing erschweren.

Bei einem Bottom-up-DFT-Ansatz ordnen DFT-Ingenieure jedem Block normalerweise zu Beginn des Entwurfs eine feste Anzahl von Scan-Kanälen zu, in der Regel dieselbe Anzahl für jeden Block.

In einem hierarchischen DFT-Ansatz kann ein nicht-optimiertes Multiplexer-Netzwerk die maximal mögliche Datenübertragungsrate nicht ausschöpfen
© Siemens EDA

Bild 1. In einem hierarchischen DFT-Ansatz kann ein nicht-optimiertes Multiplexer-Netzwerk die maximal mögliche Datenübertragungsrate nicht ausschöpfen.

Dies ist der einfachste Ansatz. Er kann aber dazu führen, dass die Datenübertragungsrate nicht maximal ausgenutzt wird. Denn die verschiedenen Blöcke, die für Tests zusammengefasst werden, können unterschiedliche Scan-Kettenlängen und eine unterschiedliche Anzahl an Testmustern haben (Bild 1).

Ein weiterer Ansatz, der die Datenübertragungsrate besser ausnutzt und Testzeit spart, ist die Neuzuweisung der Scan-Ressourcen, sobald die erforderlichen Daten pro Block bekannt sind.

Der Aufbau eines optimierten Multiplexer-Netzwerks ermöglicht zwar einen besseren Abgleich der Scan-Kanal-Ein- und Ausgänge und spart Testzeit
© Siemens EDA

Bild 2. Der Aufbau eines optimierten Multiplexer-Netzwerks ermöglicht zwar einen besseren Abgleich der Scan-Kanal-Ein- und Ausgänge und spart Testzeit, erhöht jedoch den Aufwand für die Implementierung

Dazu gehört jedoch die Anpassung der Scan-Konfiguration, die Umverteilung der Scan-Kanäle und die Neugenerierung der Testmuster (Bild 2).

Lohnt sich dieser Mehraufwand für die Einsparung an Testzeit? Jedes DFT-Team muss über diese Kompromisse entscheiden. Bei SoC-Entwürfen mit komplexeren hierarchischen Strukturen, einer großen Anzahl identischer Blöcke oder tile-based Layouts müssen zusätzliche Herausforderungen und Kompromisse gemeistert werden.

Ansatz ohne Kompromisse: Streaming Scan Network

Ein neuer Ansatz für die Verteilung von Scan-Testdaten in einem SoC – als Streaming Scan Network (SSN) bezeichnet – reduziert sowohl den DFT-Aufwand als auch die Testzeit, bei vollständiger Unterstützung von tile-based Entwürfen und einer Optimierung für identische Blöcke. Der SSN-Ansatz basiert auf dem Prinzip der Entkopplung der Testanforderungen auf Blockebene von den Testressourcen auf Chipebene. Dazu wird ein leistungsfähiger synchroner Bus verwendet, um Scan-Testdaten als Pakete an die Blöcke zu übertragen.

Die Anzahl der Scan-Kanäle pro Block ist unabhängig von der Breite des SSN-Busses und der Anzahl der Scan-Kanäle auf Chipebene sowie von der Anzahl der Blöcke. Die Übertragung von Testdaten auf diese Art und Weise vereinfacht die Planung und Implementierung und ermöglicht die Festlegung von Blockgruppen zu einem späteren Zeitpunkt im Projekt – während der Wiederverwendung von Testmustern (Retargeting) und nicht während des ursprünglichen Entwurfsprozesses. Die SSN-Architektur ist flexibel – die Busbreite wird durch die Anzahl der verfügbaren Scan-Pins bestimmt – und entlastet damit Layout- und Timing-Closure, da sie das Multiplexen im Testmodus auf der obersten Ebene eliminiert. Deshalb eignet sich SSN auch ideal für tiled-based SoC-Entwürfe.

Teil der SSN-Architektur sind Host-Knoten auf Blockebene, die lokal Testsignale erzeugen. Die Host-Knoten stellen sicher, dass die richtigen Daten vom SSN-Bus erfasst und an die Scan-Eingänge des Blocks gesendet werden und dass die Ausgabedaten wieder auf den Bus gebracht werden. Jeder Knoten weiß, was zu tun ist und wann es zu tun ist, basierend auf einem einfachen Konfigurationsschritt, der die IJTAG-Infrastruktur (IEEE 1687) nutzt. Welche Gruppen von Blöcken gemeinsam getestet werden und welche sequen­ziell getestet werden, ist mit dem
SSN-Ansatz konfigurierbar, nicht festverdrahtet. Die Konfiguration erfolgt einmal pro Mustersatz und nach dessen Abschluss sind alle Daten auf dem SSN-Bus reine Nutzdaten.

Seite 1 von 2

1. Keine Kompromisse, dank Paket-basierten Testdaten
2. Scan-Testdaten paketweise übertragen

Auf Facebook teilen Auf Twitter teilen Auf Linkedin teilen Via Mail teilen

Verwandte Artikel

Mentor GmbH & Co. Präzisions-Bauteile KG, Siemens Aktiengesellschaft