|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Main Menu
  
|
|
Von Armin Bart und Donna Mitchell, erschienen in Design & Elektronik, May 2002 Grafische Code-Generierung löst VerifikationsproblemeSteigende Komplexität funktioneller Verifikation wird so manchen dazu zwingen, seine Methoden zur Testbench-Entwicklung zu überdenken. Die zur Verfügung stehenden Möglichkeiten zu bewerten ist schwierig. Halten Sie sich an Modellierungssprachen wie VHDL, Verilog oder SystemC? Oder wechseln Sie zu einer der neuen Verifikationssprachen wie OpenVera oder .e.? Wie auch immer Sie sich entscheiden, Sie werden in jedem Fall mit der Aufgabe konfrontiert sein, komplexe Testbenches zu entwickeln und diesen Code über die Dauer von mehreren Projekten und möglicherweise mehreren Verifikations-Ingenieuren zu pflegen. Grafische Code-Generierung bietet eine sprachunabhängige Lösung zur Testbench-Entwicklung, die es erlaubt, Testbenches schnell und in einer klaren und präzisen Art und Weise zu beschreiben. Grafische Testbench-Generierung ist die automatische Erzeugung von Testbench-Quellcode aus der Schnittstellenbeschreibung und den Bus-Transaktionen eines Designs. Anstatt die Testbench von Hand zu codieren, wird das zu testende HDL-Modell an einen Testbench-Generator geleitet, der automatisch die Schnittstellensignale des Designs in einen Timingdiagrammeditor extrahiert. In dieser Umgebung werden dann Timingdiagramme erzeugt, die die Bustransaktionen der Testbench beschreiben. Durch die Automatisierung der zeitaufreibenden Code-Entwicklung kann sich der Ingenieur auf die wesentlichen Aspekte wie Design und Funktion konzentrieren. Erweiterte ModellierungTestBencher von SynaptiCAD ist ein einfacher und intuitiv zu bedienender grafischer Testbench-Generator. Die grafische Oberfläche ist geeignet um komplexe Bus-Transaktionen und Schnittstellenbeschreibungen zu modellieren. Sogar Pipelining, Split-Phase-Transaktionen, Datenstrukturen und Speicher, sowie Sequenzerkennung können implementiert werden. Aus den Timingdiagrammen erzeugt TestBencher Bus-Transactor-Quellcode in der vom Anwender bevorzugten Verifikationssprache. Durch die Verwendung von Timingdiagrammen arbeitet der Ingenieur in einer hohen Abstraktionsebene, frei von den Codierungsproblemen, die rein aus der Wahl einer bestimmten Verifikationssprache entstehen. Im Folgenden werden wir einige der allgemeinen Probleme untersuchen, die bei der funktionellen Verifikation entstehen, und diskutieren, wie diese durch die grafische Generierung des Testbenchcodes vermindert werden können. Race-ConditionsTestbenches sind laufend mit Nebenläufigkeits- und Synchronisationsproblemen konfrontiert, die zu Race-Conditions und unbestimmtem Laufzeitverhalten führen. Während diese Probleme in der Theorie einfach zu lösen sind, sind sie in der Realität bei Codierung von Hand äußerst schwierig zu bewältigen. Ein Grund dafür ist, daß Race-Conditions durch subtile Design-Entscheidungen verursacht werden, und im Gegensatz zu syntaktischen Fehlern nicht automatisch gefunden werden können. Diese Probleme treten erst zur Laufzeit ans Licht. Und oft können sie nicht einmal zur Laufzeit erkannt werden, weil der verwendete Simulator zufällig den .richtigen. Ausführungspfad wählt. Ein anderer Simulator, der theoretisch parallele Operationen in einer anderen Reihenfolge ausführt, kann ein völlig anderes Ergebnis liefern. Dies wirft ein besonderes Problem für IP-Händler auf, die Testbenches an Kunden weitergeben, die Simulatoren von verschiedenen EDA-Anbietern verwenden. Sogar auf dem selben Simulator kann diese Art von Race-Conditions Probleme verursachen, da es durchaus möglich ist, daß in einer zukünftigen Version eines Simulators zur Verbesserung der Simulationsperformanz die Ausführungsreihenfolge von Operationen geändert wird. Die Pflege des Codes kann dadurch ernsthafte Sorgen bereiten. Ein grafischer Code-Generator behandelt Gegebenheiten, die Race-Conditions verursachen können, automatisch. Z.B. treten Race-Conditions oft in getakteten funktionellen Testbenches auf, in denen Signale häufig zur selben Taktflanke, aber zu einem Simulationszeitpunkt nacheinander gesetzt und abgetastet werden. Grafik 1 zeigt ein vereinfachtes Beispiel für eine Möglichkeit der Entstehung dieser Race-Conditions. Bei der Codierung von Hand muß sichergestellt werden, daß der Code in einer Weise geschrieben wird, so daß das Abtasten während jedes Taktzyklusses als erstes ausgeführt wird. In Hardwarebeschreibungssprachen, wo Signale ihren Zustand innerhalb eines Taktzyklusses oft mehrere Male wechseln, ist dies keine leichte Aufgabe. In einem Timingdiagramm dagegen sind die Race-Conditions verursachenden Zustandsübergänge offensichtlich, wodurch diese Art von Race-Conditions leicht vermieden werden kann.
Kontrollierte ZufallsdatenBei der Implementierung einer handcodierten Testbench können sich leicht falsche Portgrößen oder andere kleine Fehler einschleichen. Automatische Code-Generierung erleichtert es, Informationen ein einziges Mal zu definieren und dann in der ganzen Testbench zu verwenden. Dies trifft besonders für die Erzeugung und Pflege komplexer Datenstrukturen zu, die zur Speicherung von Zustandsinformationen für verschiedene Transaktionen verwendet werden. Kleine änderungen an einer dieser Datenstrukturen ziehen häufig Code-Anpassungen an vielen verschiedenen Stellen der Testbench nach sich. Nutzt man jedoch ein grafisches Interface, so wird jede änderung einer einmal definierten Datenstruktur an alle entsprechenden Stellen der Testbench propagiert. Moderne Verifikationssprachen unterstützen außerdem erweiterte Datenstruktur-Features, wie z.B. die kontrollierte Generierung von Zufalls-Test-Stimuli während einer Simulation. Die Verwendung eines grafischen Interfaces macht es sehr einfach, mit verschiedenen Parametern und Optionen der Zufallsdaten-Generierung zu experimentieren, da änderungen an Datenstrukturen nur an einer Stelle durchgeführt werden müssen. Das Beispiel in Grafik 2 zeigt die Definition einer Datenstruktur, die kontrollierte Zufallsdaten für eine Transaktion bereitstellt. Für die einzelnen Felder einer Struktur stehen die Typen Element, Array, Assoc Array und Queue zur Verfügung. Für jedes Feld können, abhängig von der Testbench-Sprache und dem verwendeten Datentyp, verschiedene Eigenschaften definiert werden.
Darüber hinaus bietet TestBencher die Möglichkeit, in einfacher Weise komplexe Datenstrukturen zu definieren, die es erlauben, Daten im Hauptspeicher zwischenzuspeichern oder in eine Datei im Tabellenformat zu schreiben bzw. daraus zu lesen. Auf diese Weise können Daten von einer Transaktion abgelegt und danach von einer anderen verwendet werden. Pipelined TransaktionenEine weitere Herausforderung bei der Design-Verifikation ist die Implementierung von pipelined Bus-Transaktionen. Häufig ist es nötig, eine Art von pipelined Bus-Master zu modellieren, der seine Transaktionsdaten aus einer Queue (FIFO) von Datenpaketen erhält. Bei leerer Queue veranlasst ein von der Queue getriebenes Signal die Ausführung solange anzuhalten, bis neue Daten in die Queue fließen. Andernfalls entnimmt der Bus-Transaktor das nächste Datum aus der Queue und die Ausführung der Transaktion wird unverzüglich fortgesetzt. Grafik 3 zeigt, wie mit einem einzigen Timingdiagramm Read- und Write-Transaktionen eines AMBA AHB (Advanced High-Performance Bus) Master-Device modelliert werden können. Der AHB-Bus ist der Haupt-Systembus der ARM Mikroprozessorfamilie, die Pipelined-Burst-Reads und Writes unterstützt. Im Beispiel erhalten die Signale HADDR, HWDATA und HWRITE ihre Daten aus einer Queue, die von einem Standalone-Prozess im Top-Level der Testbench befüllt wird. Ein Sampling-Prozess namens CheckForRead_THEN verwendet eine weitere Queue, um während einer Read-Operation Daten abzulegen. Der erste Taktzyklus im Diagramm setzt die Signale HADDR und HWRITE. Handelt es sich um eine Write-Operation, so werden die zu dieser Adresse gehörenden Daten während des nächsten Taktzyklusses angelegt. Im Falle einer Read-Operation werden die gesampelten Daten in eine Queue geschoben, die vom Top-Level der Testbench überwacht werden, oder in eine Datei ausgegeben werden kann. Zwei Marker implementieren eine Schleife, so daß fortwährend Adressen angelegt und Daten gelesen/geschrieben werden, bis die Adress-Queue leer ist. Dabei wird jeweils zeitgleich mit den Daten des aktuellen Read-/Write-Zyklusses bereits die Adresse für die nächste Read-/Write-Operation übertragen.
Sequenz-ErkennungEine Sequenz von Ereignissen zu erkennen und als Reaktion darauf, abhängig von der Art der erkannten Sequenz, entsprechenden Code auszuführen, setzt eine als Zustandsautomat implementierte Testbench-Transaktion voraus. Es ist viel einfacher, eine grafisch beschriebene Sequenz von Ereignissen zu verstehen, als den die erwartete Sequenz implementierenden HDL-Code zu interpretieren. In Grafik 4 wird am Beispiel eines PCI-Slave-Devices gezeigt, wie mit Hilfe von grafischer Sequenzerkennung mehrere verschiedene Transaktionen durch ein einziges Timingdiagramm implementiert werden. Ein solches Device könnte z.B. durch jeweils ein Diagramm für jeden möglichen Transaktionstyp modelliert werden. Dabei würde jedes Diagramm einen Verhaltensmodus des Designs, wie Read-, Write- oder Disconnect-Transaktionen repräsentieren. Bei Verwendung von Sequenzerkennung werden die erwarteten Ereignisse für jedes Signal in das Timingdiagramm eingetragen, wobei die getriebenen Ereignisse nicht erscheinen, solange die Sequenzerkennung nicht die erwarteten Ereignisse erkannt hat. Stellt die Sequenzerkennung unerwartete Ereignisse auf den sensitiven Signalen fest, so wird die Transaktion abgebrochen und neu gestartet, d.h. der Zustandsautomat wird auf seinen Startzustand zurückgesetzt. Während der Simulation arbeiten die verschiedenen Transaktionstypen nebenläufig, und stellen so das Slave-Device dar.
Testbench-PflegeIn einer Testbench läuft eine hohe Zahl von über die ganze Testbench verteilten Vorgängen parallel ab. Testbench-Quellcode ist deshalb trotz Verwendung modularer Programmiertechniken häufig schwer zu verstehen. Timingdiagramme ermöglichen eine weitaus klarere, knappere und leichter verständliche Beschreibung der Signalaktivitäten und Interaktionen zwischen Prozessen. Die Zusammenarbeit mehrerer Ingenieure an einer Testbench wird durch die grafische Darstellung in Timingdiagrammen enorm erleichtert, da kein Quellcode mehr interpretiert werden muß. Jeder mit dem Design vertraute Ingenieur ist in der Lage, aus einem gegebenen Timingdiagramm sofort ein Verständnis für das Verhalten des Transaktors zu gewinnen, was die Pflege der Testbench drastisch vereinfacht. ZusammenfassungGrafische, automatische Testbench-Generierung bietet eine gute Lösung für viele der Probleme, mit denen man während der funktionellen Design-Verifikation konfrontiert wird. Bei dieser Lösung werden Timingdiagramme verwendet, um Bus-Transaktionen in einer Testbench zu beschreiben. Ingenieure sind mit Timingdiagrammen vertraut, diese werden deshalb leicht verstanden und die grafische Darstellung ermöglicht eine schnelle Visualisierung der Testbench in einer höheren Abstraktionsebene. Timingdiagramme sind außerdem sprachunabhängig, die selbe grafische Beschreibung kann so zur Generierung von Testbenches in jeder der bekanntesten Sprachen wie VHDL, Verilog, SystemC, .e. oder OpenVera verwendet werden. Die im Timingdiagramm dargestellten Transaktionen formen modulare Komponenten einer Testbench, die einfach verändert und in anderen Designs wiederverwendet werden können. Dies ebnet den Weg für eine schnellere Verifikation zukünftiger Designs. AutorenArmin Bart ist der Entwickler von SynaptiCAD.s GigaWave Viewer. Er ist außerdem verantwortlich für die Integrierung der von ihm entwickelten Signaldaten-Kompressionstechnologie in SynaptiCAD.s TestBencher pro. Bart ist momentan dabei, sein Informatik-Studium an der Fachhochschule Landshut abzuschließen.
Donna Mitchell ist Vize-Präsident für Strategisches Marketing bei SynaptiCAD Inc. Sie erlangte ihren BS- und MS-Degree in Electrical Engineering an der Virginia Tech Universität. Mitchell ist eine der zwei Gründer von SynaptiCAD Inc. Sie kann per erreicht werden.
SynaptiCAD Inc. |
|
|
