Automatisieren von C-Testfällen für die Verifizierung eingebetteter Systeme

Während System-on-Chip (SoC)-Designs immer komplexer werden, werden Testsuiten mit Tausenden von Codezeilen für die Verifizierung auf Systemebene weiterhin von Hand geschrieben, eine seltsam alte Schule und ineffektive Praxis, die dem Sprichwort „Automatisieren“ trotzt wenn möglich." Dies gilt insbesondere für C-Tests, die auf den eingebetteten Prozessoren eines SoC ausgeführt werden, um das gesamte Gerät vor der Herstellung zu überprüfen.

Es hat sich gezeigt, dass die Automatisierung der Zusammensetzung von Verifizierungstests nach Möglichkeit die Produktivität in vielen Phasen der SoC-Entwicklung erhöht. Constrained Random-Techniken, beispielsweise in einem UVM-Testbench (Universal Verification Methodology), verwenden randomisierte Testvektoren, die auf bestimmte Szenarien ausgerichtet sind, um die Abdeckung zu erhöhen. Während diese die Verifikationseffizienz auf Hardwareblockebene erhöht haben, wird das Design immer noch als Blackbox mit separat geschriebenem Stimulus-, Checks- und Coverage-Code wahrgenommen, immer noch eine mühsame und fehleranfällige Aufgabe für große Blöcke.

Es ist schwierig, diese Methodik auf die Systemebene auszudehnen, da Prozessortestcode mit E/A-Transaktionen kombiniert werden muss, die oft auf einem Emulator- oder Prototyping-System ausgeführt werden. Um einen SoC ordnungsgemäß zu verifizieren, müssen die Prozessoren selbst trainiert werden. UVM und andere eingeschränkt zufällige Ansätze berücksichtigen nicht den Code, der auf den Prozessoren ausgeführt wird. Um UVM auf einem SoC zu verwenden, werden die Prozessoren oft entfernt und durch virtuelle Ein- und Ausgänge auf dem SoC-Bus ersetzt, sodass das Subsystem abzüglich des Prozessors verifiziert werden kann.

SoC-Verifikationsingenieure erkennen die Grenzen von Constrained-Random-Testbenches und zwingen sie dazu, C-Tests von Hand zu schreiben, die auf den Prozessoren sowohl für die Simulation als auch für die Hardware-Emulation ausgeführt werden, obwohl sie das SoC-Design nur eingeschränkt voll ausüben können. Die Leistung dieser Verifikationsplattformen ist nicht gut genug, um ein vollständiges Betriebssystem (OS) auszuführen, daher werden diese Tests „bare-metal“ ausgeführt, was den Kompositionsaufwand erheblich erhöht. Es ist ungewöhnlich, dass handschriftliche Tests, insbesondere ohne die Hilfe von Betriebssystemdiensten, auf koordinierte Weise über Multi-Core-Prozessoren hinweg ausgeführt werden, die mehrere Threads nutzen. Das Ergebnis ist, dass Aspekte des SoC-Verhaltens, wie z. B. gleichzeitige Operationen und Kohärenz, nur minimal überprüft werden.

C-Tests automatisch generieren

Natürlich werden automatisch generierte C-Tests die Engineering-Ressourcen effizienter nutzen. Sie erhöhen auch die Abdeckung. Generierte C-Testfälle können mehr Funktionen des SoC ausüben als handgeschriebene Tests und suchen nach schwer vorstellbaren komplexen Eckfällen. Testfälle mit mehreren Threads und mehreren Prozessoren können alle parallelen Pfade innerhalb des Designs ausüben, um die Parallelität zu überprüfen. Sie können Daten zwischen Speichersegmenten verschieben, um Kohärenzalgorithmen zu betonen, und mit den I/O-Transaktionen koordinieren, wenn Daten an die Eingänge des Chips gesendet oder von seinen Ausgängen gelesen werden sollen. Der Gesamteffekt hiervon besteht darin, die funktionale Abdeckung des Systems zu erhöhen, in der Regel mehr als 90 % von Zahlen, die charakteristischerweise viel niedriger sind.

Die Testgenerierungssoftware, bekannt als Test Suite Synthesis, verwendet ein leicht verständliches, grafenbasiertes Szenariomodell, das das beabsichtigte Designverhalten erfasst. Diese Modelle können mit dem Accellera Portable Stimulus Standard unter Verwendung von nativem C++ geschrieben oder visuell beschrieben werden. Szenariomodelle werden von Design- oder Verifikationsingenieuren als natürlicher Teil der SoC-Entwicklung erstellt, da sie traditionellen Chip-Datenflussdiagrammen ähneln, die auf einem Whiteboard gezeichnet werden können, um einen Teil der Designspezifikation zu erklären.

Diese Modelle enthalten von Natur aus Stimulus-, Check-, Coverage-Detail- und Debug-Informationen und versorgen den Generator mit allem, was er braucht, um hochwertige, selbstüberprüfende C-Testfälle zu erstellen, die jeden Aspekt des Designs betonen. Da sie hierarchisch und modular aufgebaut sind, können alle auf Blockebene entwickelten Tests vollständig als Teil des vollständigen SoC-Modells wiederverwendet und problemlos mit verschiedenen Teams und projektübergreifend geteilt werden. Schließlich kann das einzelne Absichtsmodell vom Synthesetool zerlegt werden, um die gleichzeitigen Tests über Threads und E/A-Ports hinweg bereitzustellen, die alle miteinander synchronisiert sind.

Vorteile Testsuite-Synthese

Ein wesentlicher Vorteil der Testsuite-Synthese ist die Möglichkeit, Abdeckungsziele im Voraus im Intent-Modell zu definieren. Sobald die Absicht festgelegt wurde, kann das Tool sie analysieren, um die Anzahl der Tests zu ermitteln, die erstellt werden könnten, und die Abdeckung der funktionalen Absicht, die erreicht werden würde.

Bei einem SoC kann dies viele tausend Tests umfassen. Abdeckungsziele können dann festgelegt werden, indem die zu testende Absicht eingeschränkt und das Tool auf Schlüsselbereiche fokussiert wird. Diese Funktion erspart die schmerzhafte iterative Schleife, die bei herkömmlichen Ansätzen auftritt, dh die Tests einzurichten, das Verifizierungstool auszuführen, die erreichte Abdeckung zu verstehen und die Tests dann immer wieder zurückzusetzen.

In einem typischen Projekt auf einem großen SoC, das von einem bekannten Halbleiterunternehmen entwickelt wurde, reduzierten die Verifikationsingenieure die Zeit für die Testzusammensetzung auf 20 % der zuvor handschriftlichen Tests. Die Automatisierungstechnologie erzeugte strengere Testfälle und erhöhte die Abdeckung von 84 % auf 97 %. Außerdem sind die Modelle tragbar.

Ein einziges Modell kann Testfälle für virtuelle Plattformen, RTL-Simulationen (Register Transfer Level), Emulationen, FPGA-Prototypen (Field Programmable Gate Array) oder einen tatsächlichen Chip im Labor generieren, der nach der Siliziumvalidierung validiert wird.

Debug ist eine weitere Zeitsenke für Ingenieure, insbesondere auf SoC-Ebene. Wenn ein Testfall einen lauernden Designfehler aufdeckt, muss der Verifikationsingenieur verstehen, welcher Test den Fehler ausgelöst hat, um seine Quelle aufzuspüren. Ein Fehler im Testfall kann auf einen Fehler im Szenariomodell zurückzuführen sein, daher muss es möglich sein, den Testfall wieder dem Diagramm zuzuordnen, in dem die Entwurfsabsicht erfasst wurde. Dieser Prozess erstellt hochmodulare und in sich geschlossene Tests, die leicht zerlegt werden können, sodass der Test, der auf den entdeckten Fehler ausgeführt wurde, leicht zu sehen ist.

Anwendungsszenarien

Synthetisierte Testfälle können realistische Anwendungsfälle, sogenannte Anwendungsszenarien, für das Design erproben. Betrachten Sie zum Beispiel den in Abbildung 1 gezeigten Digitalkamera-SoC.

Klicken für größeres Bild

Abbildung 1:SoC-Beispiel für die Bildverarbeitung. (Quelle:Breker Verification Systems)

Die Komponenten auf Blockebene des SoC umfassen zwei Prozessoren, die Peripheriegeräte und den Speicher. Ein einfaches Diagramm für den SoC ist unter dem Blockdiagramm gezeigt. Der Graph enthält die möglichen High-Level-Pfade, die im SoC-Verifizierungsprozess ausgeführt werden können. Beispielsweise liest ein mögliches Szenario, ausgedrückt im oberen Pfad des Diagramms, ein JPEG-Bild von der SD-Karte und übergibt es über einen zugewiesenen Bereich im Speicher an den Fotoprozessor. Das Bild wird zu einem Formular verarbeitet, das angezeigt und in einen zweiten Block im Speicher geladen werden kann. Von dort wird es an den Display-Controller weitergegeben. Natürlich ist jeder dieser Blöcke auf hoher Ebene hierarchisch aufgebaut, wobei viele Aktionen und Entscheidungen als Teil des Prozesses ausgeführt werden.

Das Synthesetool nimmt den randomisierten Test vor und plant ihn entsprechend. In der einfachsten Form, wie in der Abbildung gezeigt, könnte der Test in einem einzelnen Thread geplant werden, gefolgt vom nächsten Test und so weiter. Die Fähigkeit von Testfällen, den SoC zu belasten, kommt jedoch von der Verschachtelung von Anwendungen über mehrere Threads und mehrere Prozessoren hinweg. Das Tool führt so viele Anwendungen parallel aus, wie dies durch die inhärente Parallelität des Designs unterstützt wird, und weist den Speicher so umständlich wie möglich zu. Dies wird auch als Alternative in der Abbildung gezeigt, in der die Tests auf drei Threads verteilt sind, wobei verschiedene Regionen verwendet werden, die den SoC-Speichern zugewiesen sind.

Natürlich wird dieses Beispiel auf einem hohen Niveau präsentiert, um den Prozess zu verdeutlichen. In Wirklichkeit wird der hierarchische Graph durch das Synthesetool abgeflacht, wodurch eine große Anzahl von Aktionen und Verbindungen erstellt wird. Dazu gehören auch randomisierte Entscheidungen, die durch einen Solver-Algorithmus ausgeführt werden müssen. Beim Durchlaufen des Graphen werden KI-Planungsalgorithmen eingesetzt, die die gewünschten Ausgaben prüfen und die Eingabetests entsprechend optimieren. Das Synthesewerkzeug umfasst betriebssystemähnliche Dienste, die Speicher zuordnen, Adresszuordnungszugriff, Prozessunterbrechungen und andere Aufgaben bereitstellen, die zum Vervollständigen von Teststrukturen erforderlich sind. Die Tests werden dann nach dem Zufallsprinzip geplant, wobei Speicher und andere Ressourcen entsprechend zugewiesen werden.

Schlussfolgerung

Ähnlich wie bei Constrained-Random-Testbenches manuelle Arbeit für die Blockverifizierung eliminiert wurde, hat sich gezeigt, dass synthetisierte Testinhalte für eingebettete prozessorbasierte SoCs den Verifizierungsaufwand auf Systemebene reduzieren. Darüber hinaus wird diese Lösung jetzt auf Blockebene und für die Post-Silizium-Validierung angewendet. In diesem Beispiel wenden automatisierte C-Testfälle das Sprichwort „nach Möglichkeit automatisieren“ an, wodurch die Abdeckung drastisch verbessert und gleichzeitig die Verifizierungszeitpläne verkürzt werden.