Schwerpunkte

Validierung von Prototypen – Teil 1

Portierbare Stimuliermethode für Post Silicon Validation

11. Februar 2021, 07:00 Uhr   |  Von Gaurav Bhatnagar und Courtney Fricano


Fortsetzung des Artikels von Teil 1 .

System-C-basierte Leistungsanalyse des Interconnect-Busses

Die Leistungsanalyse des Interconnect-Busses wird mit quantitativen Messungen der Systemleistung und der Stromaufnahme so früh wie möglich im SoC-Entwicklungsprozess ausgeführt. Die Leistung eines Interconnect-Busses muss für eine große Palette an Anwendungsplattformen und Verbindungskonfigurationen – Schaltungen, Eigenschaften, Konfiguration etc. – evaluiert werden. Dies schließt das Erfassen von Anforderungen und Erstellen von Spezifikationen mit ein. Anschließend werden diese Spezifikationen genommen und in einen geschlossenen Entwurf übertragen, der die Anforderungen an Leistung, Leistungsbedarf und Flächenbedarf erfüllt. Dies ist ein iterativer Vorgang, der über die gesamte Entwicklung abläuft. Mit jeder Iteration müssen die Spezifikationen wieder aufgenommen und an die Entwicklungsteams kommuniziert werden.

Der Ablauf der Leistungsanalyse mit der SystemC-Modellierung beginnt mit der Konfiguration des Tools zur Generierung der SystemC-Modelle. Sie müssen so konfiguriert werden, dass sie die Anforderungen des Systems erfüllen
© Analog Devices

Bild 2. Der Ablauf der Leistungsanalyse mit der SystemC-Modellierung beginnt mit der Konfiguration des Tools zur Generierung der SystemC-Modelle. Sie müssen so konfiguriert werden, dass sie die Anforderungen des Systems erfüllen.

Erreicht wird das mit auf SystemC basierenden TLM-Modellen der gegebenen SoC-Spezifikation, die genutzt werden können, um das Verhalten des Systems präzise vorherzusagen. Bild 2 zeigt diesen Ablauf angefangen bei der Konfiguration des Tools zur Generierung der SystemC-Modelle. Diese Modelle sind Teil des Tool-Kits, die so konfiguriert werden können, dass sie die Anforderungen des Systems erfüllen. Sie können dazu verwendet werden zyklusgenaue oder angenäherte Modelle für AMBA-Master und -Slaves, Taktgeneratoren und Stimuli zu erzeugen. Sind diese Modelle einmal platziert, müssen die Traffic-Pattern auf dieser Ebene geschrieben werden, entweder manuell oder mit automatischen Scripts, um die Spezifikation in eine aktuelle Simulation umzusetzen und Ergebnisse zu erhalten. Die Modelle werden dann mit speziellen Simulatoren simuliert, die dabei helfen, eine Lösung zu finden, die die Leistung quantifiziert.

Obwohl Modellier- und Analyse-Werkzeuge vorhanden sind, ist der Einsatz dieses Tools für mehr als einige wenige bestimmte Entwürfe eine zeitaufwendige Angelegenheit. Der Einsatz dieser Scripts zum Generieren von Datenverkehr liefert zwar geeignete Arten von Pattern, aber das Erstellen eines umfassenden Szenarios bleibt weiterhin ein Problem. Da die Simulationen zeitaufwendig sind, steigert eine Analyse am Ende der Simulation vor allem die Anzahl der Versuche Funktionen zu modellieren. Folglich besteht hier Bedarf für einen stärker automatisierten Ablauf, der mit einer einzigen Quelle beginnt. Die PSS-basierten Techniken sind ein effektiver Weg, diese Probleme zu lösen.

Der Randomisierungs-Mechanismus in den PSS-basierten Werkzeugen startet mit einer abstrakten Beschreibung der gültigen Übergänge zwischen den Zuständen auf der hohen Ebene des Prüflings und zählt automatisch den minimalen Satz an Tests auf, die nötig sind, die Pfade durch diesen Zustandsraum abzudecken. Die PSS-basierten Werkzeuge haben einen Mechanismus zur Fehlerabdeckung, der messen kann, wie umfassend die Testkonditionen im vorgegebene Zustandsraum abgedeckt wurden. Dies erlaubt das Messen der Abdeckung sogar noch bevor irgendeiner der generierten Stimuli abläuft, was viel Zeit in diesem Prozess einspart. Die PSS-basierte Fehlerabdeckung erlaubt dem Anwender einen Einblick in die Querverbindungen und ermöglicht es, Tests zu generieren, sodass die maximale Länge des Graphen abgedeckt wird. So lässt sich eine höhere Abdeckung mit weit weniger Zyklen erzielen als bei der eingeschränkten traditionellen zufallsgesteuerten Verifikation.

Die PSS-basierten Werkzeuge liefern auch eine visuelle Repräsentation der Testintension, die eine bessere Visualisierung des Szenarios erlaubt, das generiert werden kann. Der sogenannte Directed-Test – Satz an vordefinierten Stimuli, die entwickelt wurden, um eine spezielle Funktion im Entwurf auszuführen – zur Abdeckung spezieller Testkonditionen kann einfach mit dieser Eigenschaft geladen werden. Er erlaubt auch die Einschränkung von bestimmten Sätzen an Konditionen, wodurch eingeschränkte Zufallsszenarien für bestimmte Funktionen erzeugt werden. Die Einführung von PSS-basierten Techniken erhält im Wesentlichen den Entwicklungsablauf wie in Bild 2 dargestellt, wobei jedoch der Prozess zur Erstellung der Leiterbahnen erheblich geändert ist.

Das Herz des Traffic-Generators ist ein generisches PSS-Modell, das den Algorithmus enthält, um verschiedene Arten von Traffic-Pattern zu erzeugen. Es ist eine einzige Repräsentation von Stimulus- und Testszenarien. Dieses Modell kann unterschiedlich konfiguriert werden, um Tests zu erzeugen, die eine von mehreren Permutationen enthalten, die Traffics ermöglichen. Es besteht aus den folgenden drei Teilen:

  • Exec Blocks: Die Exec Blocks sind Statements von externem Code, die in den Zielplattformen unter dem PSS-basierten Wrapper genutzt werden. Für die Anwendung auf der SystemC-Seite enthalten sie spezifischen Code, der verschiedene Arten von Schreibe- und Lesezyklen für die zugrundeliegende Umgebung ausführt. Für den UVM-SV-Teil (SV, System Verilog) enthalten sie eine Logik, die von Makros stammt, die von den Tools zur Verfügung gestellt werden (Transceiver-Generation). Diese Logik übersetzt in und interagiert mit der SV-Welt über PLI-basierte (PLI, Program Language Interface) Systemaufrufe. Sie haben auch einen Teil (C-Generierung), der in die C-Seite übersetzt wird und mit dieser interagiert und eine nahtlose Wiederverwendung über unterschiedliche Plattformen ermöglicht.
  • PSS Model: Dies ist das aktuelle Modell des Anwendungsfalls, das auf einem kompletten Satz an Spezifikationen basiert. Es besteht aus einer Sammlung an Funktionen, die das Äquivalent von Sequenzen höherer Ebene sind, um die nötigen Aktionen auszuführen. Der Traffic-Generator enthält unterschiedliche Algorithmus-Sätze, die in Form unterschiedlicher einfacher und zusammengesetzter Aktionen repräsentiert sind. Diese Funktionen rufen evtl. die Funktionen von den Exec Blocks auf, um Befehle für die SV-Seite auszuführen.
  • PSS Configuration: Damit die Modelle generisch sind, brauchen sie spezifische Informationen, um spezielle Tests zu generieren. Dies können Informationen aus der Verifikation sein, wie die Anzahl der AMBA-Master, Slaves, Master-Typ, Quell- und Zieladresse, Zugriffsart, charakteristische Bandbreite, Burst-Größe, Datengröße, Frequenz und Anforderungen an die Bandbreite. Diese Information muss von der Spezifikation hergeleitet werden, um eine korrekte Repräsentation des Testzwecks zu erstellen.
PSS-basierter Prozess zum Generieren von Traffic-Pattern
© Analog Devices

Bild 3. PSS-basierter Prozess zum Generieren von Traffic-Pattern.

Bild 3 zeigt den Ablauf zur Erstellung der PSS-basierten Traffic-Pattern, der mit dem Parsing der Spezifikation beginnt. Ein Python-basiertes Script analysiert mehrere Aspekte der in den Kalkulationstabellen eingetragenen Spezifikationen und extrahiert daraus die Daten in einem bestimmten Format, das vom generischen PSS-Modell und der Konfiguration gelesen werden kann.

 Anhand der visuellen Repräsentation des Testzwecks und der PSS-basierten Testabdeckung (rechts) lässt sich leicht erkennen, welche Konditionen mit weiteren Tests untersucht werden sollten
© Analog Devices

Bild 4. Anhand der visuellen Repräsentation des Testzwecks und der PSS-basierten Testabdeckung (rechts) lässt sich leicht erkennen, welche Konditionen mit weiteren Tests untersucht werden sollten.

Das PSS-Modell und die Konfiguration werden dann von den PSS-Tools analysiert, um eine visuelle Repräsentation des Testzwecks zu kreieren. Bild 4 zeigt einen Teil dieser visuellen Darstellung der Testabsicht. Dabei sind die Konditionen als Schreib- oder Leseoperationen, Einfach- oder Burst-Modus, unterschiedliche Bus-Größen etc. dargestellt, die so gesteuert werden können, dass sie unterschiedliche Arten an Traffic-Pattern erzeugen. Die Teile in Violett repräsentieren die Konditionen die geladen werden, wogegen die in Blau nicht in Betrachtung gezogen werden. Dies hilft dem Anwender verschiedene Aspekte des erforderlichen Datenverkehrs zu visualisieren und zu begrenzen.

Fügt der Anwender keine Einschränkungen hinzu, wählt das PSS-Tool bestimmte Konfigurationen zufällig aus und erstellt eingeschränkte Zufallstests. Dies ist auch ein Punkt, an dem die Tool-basierte Testabdeckung zusammengefasst werden kann, um eine frühzeitige Analyse auf Vollständigkeit zu machen. Die Tool-basierte Testabdeckung ist ein Maß dafür, wie gut die Testabsicht mit den vom Tool erstellten Tests abgedeckt wird.

In Bild 4 sind rechts die Anteile der PSS-basierten Testabdeckung dargestellt, die von den PSS-Tools generiert werden – in Pink die nicht abgedeckten Konditionen und in Grün die abgedeckten Konditionen. Der Anwender kann diese Darstellung betrachten und weitere Tests für die Konditionen erstellen, die nicht abgedeckt wurden.

Sind die Tests generiert, läuft ein Nachbearbeitungs-Script ab, um das Traffic-Pattern zu kreieren, das kompatibel mit der Simulation des Leistungsanalysewerkzeugs und seinem spezifischen Format ist. Im nächsten Schritt laufen die Simulationen ab und generieren Datenverkehr, um Riesenmengen an rohen Daten zu gewinnen. Diese Daten müssen in unterschiedlichen Metriken und Visualisierungen verarbeitet werden, um eine effektive Analyse der Ergebnisse zu ermöglichen.

 Summe der Daten, die in der PSS-Simulation erfasst wurden
© Analog Devices

Tabelle 1. Summe der Daten, die in der PSS-Simulation erfasst wurden.

Tabelle 1 zeigt einige Beispiele des mit Parametern generierten Reports, die zur Berechnung der Leistungsanalyse des Interconnect-Busses in einem SoC mit mehreren Mastern und Slaves in Betracht gezogen wurden. Um diese Analyse basierend auf den Plattformspezifikationen zu generieren, kann sie eine Eins-zu-Eins-Simulation (Master-zu-Slave) und Viele-zu-Einem-Simulationen (bezeichnet als Experimente) aufweisen. Experimente werden basierend auf einer statischen Analyse der Taktfrequenzen und Datenbreiten erstellt, die in der Plattformspezifikation definiert sind.

Die Plattformspezifikation wurde so konfiguriert, damit die Analyse bis zu ihrer theoretischen maximalen Bandbreite läuft. Allgemein gesagt, der PSS-basierte Datenverkehr erlaubt eine bessere Platzierung des Zufallsszenarios, das auf eine spezielle Bus-Konfiguration abzielt. Die visuelle Darstellung des Testzwecks ermöglicht auch die Erstellung von besseren Einschränkungen. Die Fähigkeit, die Testabdeckung darzustellen, führt zu besseren Traffic-Pattern und damit zu weniger Iterationen, um die höchstmögliche Bandbreite in einem vorgegebenen Master-Slave-System zu erreichen.

Der Einsatz von PSS-basierten Techniken führt zu einer Verbesserung hinsichtlich der Anzahl der Iterationen, die erforderlich sind, um die höchste mittlere simulierte Bandbreite zu erreichen.

Durch Reduzieren des erforderlichen Aufwands, um Modelle der Leistungsfähigkeit der Busverbindungen zu machen und auch um eine einzige zuverlässigen Datenquelle in einer vereinheitlichten Spezifikation zu erhalten, wird jeder Zeitaufwand zur Rekonfiguration signifikant reduziert. Dieser Entwicklungsablauf erlaubt es viele Entwurfsvarianten zu untersuchen, bevor eine Variante für die nächsten Schritte, Timing-Closure und RTL-Generierung, ausgewählt wird.

Die Autoren

Bhatnagar-Gaurav von Analog-Devices
© Analog Devices

Gaurav Bhatnagar von Analog Devices

Gaurav Bhatnagar

ist Staff Design Verification Engineer in der Engineering Enablement (EE) Group bei Analog Devices (ADI). Er ist Elektronikingenieur mit 15 Jahren Erfahrung und kam 2015 zu ADI. Er arbeitet an universellen, Format- und portierbaren Stimulus-Verifikationsmethoden.

gaurav.bhatnager@analog.com

Fricano-Courtney von Analog-Devices
© Analog Devices

Courtney Fricano von Analog Devices

Courtney Fricano

ist Staff Verification Engineer in der Engineering Enablement (EE) Group bei Analog Devices (ADI). Sie leitet das Verification-Subteam des Engineering Systems and Verification Center of Excellence. Courtney hat einen Bachelor-Abschluss von der Penn State University und einen Master vom MIT.

courtney.fricano@analog.com

Seite 2 von 2

1. Portierbare Stimuliermethode für Post Silicon Validation
2. System-C-basierte Leistungsanalyse des Interconnect-Busses

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

Verwandte Artikel

Analog Devices GmbH