Anbieter zum Thema
5. Design For Testability (DFT)
Die besten Boundary-Scan-Testsysteme mit den mächtigsten ATPGs können nichts ausrichten, wenn gewisse Designregeln schon beim Schaltplanentwurf oder noch einen Schritt eher, bei der Bauteilauswahl, nicht eingehalten wurden. Die folgenden Kriterien zeigen eine begrenzte Auswahl der wohl wichtigsten „Design For Testabilty“ Regeln:
- Compliance Pattern
Bei Boundary-Scan-fähigen Bausteinen ist es üblich, sich die TAP-Pins mit anderen Funktionen z.B. zum Debuggen zu teilen. Aus diesem Grund verfügt ein solcher Baustein in aller Regel über einen Pin, der über den Zweck entscheidet. Solch ein Pin könnte z.B. JTAG#/DEBUG heißen und würde bei einem High den Debug Mode aktivieren. In diesem Beispiel muss also zwingend ein Low am Pin angelegt werden, damit dieser mit Boundary Scan getestet werden kann.
- Testbusabschluss
Für eine schnelle Testabarbeitung ist ein guter Testbusabschluss unerlässlich. Als groben Anhaltspunkt kann man davon ausgehen, dass die Testzeit sich direkt proportional zur Frequenz des „Test Clock“ verhält.
Heutige Testsysteme sind in der Lage, das TCK-Signal mit 80 oder gar 100 MHz zu betreiben. Damit ist offensichtlich, dass große Sorgfalt bei der Verdrahtung der TAP-Signale angebracht ist.
- Flexible Scankette
Es ist übliche, Baugruppen in verschiedenen Bestückungsvarianten zu fertigen. Vorsicht ist dann geboten, wenn solch eine Bestückungsvariante auch die Boundary-Scan-fähigen Bausteine betrifft. Dann kann es passieren, dass ein Baustein in der Scankette fehlt und somit der serielle Pfad (TDI à TDO) unterbrochen ist. Das führt natürlich unweigerlich zum Totalausfall.
- Access = Success
“Access = Success”; diese „Design For Testability“ Grundregel gilt beim Boundary-Scan-Testverfahren ebenso, wie bei dem klassischen In-circuit-Testverfahren. Nur ist die Umsetzung in beiden Fällen eine völlig andere.
Beim In-circuit Test heißt es, Testpunkte zu setzen wo es nur geht. Bei Boundary Scan hingegen „schlummern“ diese in den Boundary-Scan- Bausteinen zum Teil ungenutzt in Form von nicht verdrahteten Bauteilspins. Dabei handelt es sich üblicherweise um in der „normalen“ Funktion der Baugruppe nicht benötigte Pins eines Bausteins (gerade bei programmierbaren Logikbausteinen).
Diese ungenutzten „Testpunkte“ einzusetzen, um die Testabdeckung wesentlich zu erhöhen sollen zwei typische Beispiele aufgezeigt werden.
Bild 5 zeigt als erstes Beispiel eine RAM-Bank, deren Takt von einer PLL verteilt wird. Um die RAM-Bausteine mit Boundary Scan testen zu können, ist jedoch ein statischer Zugriff auf sämtliche Bauteilpins erforderlich. Dies ist durch die PLL beim Taktsignal nicht gegeben, was zu einem großen Verlust bei der Testabdeckung führt. Bild 5 zeigt auch, wie der Zugriff auf einen einzigen Bauteilpin über die Testbarkeit eines kompletten Bausteins entscheidet.
Bild 6 zeigt einen Baustein mit integriertem NAND-Tree-Test. Er ließe sich somit optimal per Boundary Scan testen. Einzige Bedingung ist dabei, dass der NAND-Tree Test mit einem bestimmten Signalpegel an einem vorgegebenen Bauteilpin aktiviert werden muss. Im Bild ist dieser mit „TEST“ benannt.
(ID:259281)