Validierung von Prototypen – Teil 2
Portierbare Stimuliermethode für Post Silicon Validation
Fortsetzung des Artikels von Teil 1
SoC-Verifikation des Interconnect-Busses
Wenn der Interconnect-Bus als Teil des SoC integriert ist, ist es wesentlich, seine Integration mit den unterschiedlichen Mastern und Slaves im System zu überprüfen. Dies wird üblicherweise mit C-basierten Tests gemacht, die auf dem Prozessor ablaufen, um die Integration des Interconnect-Busses zu überprüfen. Die generischen Master auf IP-Ebene wechseln zu spezifischen Bus-Mastern, wie Mehrfach-Prozessoren, DSP, DMA-Controllern und seriellen Protokoll-Mastern wie SPI, I2C, CAN und vielen weiteren anwendungsspezifischen Mastern und Slaves.
Dies erfordert spezielle Sequenzen oder Makros, die dazu dienen, diese unterschiedlichen Master und Slaves im SoC zu steuern. Diese Makros oder Sequenzen sind üblicherweise Register-programmiert, um es zu ermöglichen, Sende- und Empfangstransaktionen von den Mastern, wie DMA-Controllern, Speichern etc., zu ermöglichen. Es gibt auf dieser Ebene keine eingeschränkte Randomisierung, sodass jedes Szenario untersucht und manuell geschrieben werden muss.
In Bezug auf die Wiederverwendung können einige der UVM-Monitore aus der IP-Ebene genutzt werden, das Protokoll oder die Scoreboards anzuzeigen, um die besonders interessierenden Punkte zu überprüfen. Jedoch müssen die Tests und Sequenzen, die große Teile der Spezifikation beinhalten, mit einem anderen Fokus in C erneut erstellt werden.
Jobangebote+ passend zum Thema
Die PSS-basierte Verifikationstechnik wurde für die Wiederverwendung von Tests der IP bis zum fertigen SoC entwickelt. Bild 7 stellt die Wiederverwendung des PSS-Modells des Traffic-Generators in der Verifikation auf SoC-Ebene dar. Die auf IP-Ebene codierten Modelle sind gemäß der SoC-Spezifikation für unterschiedliche Adress-Maps konfiguriert und zielen auf die Generierung von C-Tests ab. Der gleiche Satz an Sequenzen, geschrieben auf IP-Ebene mit der Graph-basierenden eingeschränkten Randomisierung, ist für die Wiederverwendung nutzbar.
Nahezu alle Sequenzen im Modell – ausgenommen die Teile, die für den Exec-Code gedacht sind – sind wiederverwendbar, wenn das Modell für Prozessor-basierte Applikationen geschrieben wird. Allerdings ist der Exec-Code in diesem Fall komplexer und enthält komplette Enable- und Disable-Makros für eine Vielzahl von Mastern wie DMA- und Speichercontroller, die die Single- oder Burst-Transaktionen auf dem Interconnect-Bus initiieren können.
Für jeden generischen Master muss der Exec-Code neu geschrieben werden, sodass er in die Vielzahl von Mastern im SoC integriert werden kann. Die Tool-Randomisierung erlaubt mehrfache Kombinationen von Master- und Slave-Transaktionen. Die Einschränkungen zum Erstellen von gesteuerten Tests zur Überprüfung der Integration auf SoC-Ebene kann mit der visuellen Repräsentation des Tests gut verwaltet werden. Sind die C-Tests einmal kreiert, werden sie über eine systemspezifische Standardinfrastruktur in die SoC-Konfiguration integriert. Diese C-Tests werden dann kompiliert und laufen auf dem Prozessor, um Transaktionen zu generieren.
Bild 7 zeigt ebenfalls die Erstellung von Mehrkerntests mit den PSS-Werkzeugen, die manuell nur schwierig zu kreieren sind. Unterschiedliche Teile des Testzwecks können so ausgelegt sein, dass sie auf unterschiedlichen Prozessorkernen laufen, was das Generieren interessanter Szenarien erlaubt. Dies ist besonders in dem Fall hilfreich, in dem mehrere Busmaster vorhanden sind. Das Programmieren unterschiedlicher Master wird durch diese Funktionspalette möglich.
Die Fähigkeit, Graph-basierte eingeschränkte Zufallstests auf SoC-Ebene zu reproduzieren, ohne die Notwendigkeit Szenarien tatsächlich neu zu codieren, ist auch ein großer Vorteil. Sie erlaubt auch die Testgenerierung für unterschiedliche Fälle derselben IP mit verschiedenen Adress-Maps. Damit ist die Kreation von komplexen Szenarien möglich, wenn unterschiedliche Arten von PSS-Modellen für verschiedene IPs auf SoC-Ebene kombiniert werden. Manuell wären sie sonst nur sehr schwer zu codieren.
Validierung des Interconnect-Busses
Die Validierung ist nötig, um die Übereinstimmung des Produkts mit den Spezifikationen, der Nutzbarkeit und der Abnahmeprüfung sicherzustellen. Traditionell benötigt ein Evaluation-Board C-basierte Tests, die aus der Originalspezifikation manuell erstellt wurden. Dieser doppelte Aufwand kann mit Einsatz einer PSS-basierten Methode, mit der C-Tests, die kompatibel mit der Evaluierungssoftware sind, generiert werden können, wesentlich reduziert werden
Bild 8 repräsentiert den Validierungsprozess mit der PSS-basierten Methode. Das PSS-Modell für den Traffic-Generator kann entsprechend der SoC-Spezifikation für unterschiedliche Adress-Maps konfiguriert sein und auf die Erstellung von Eval-C-Tests abzielen. Die PSS-Werkzeuge haben üblicherweise die Fähigkeit, Tests für mehrfache Prozessorkerne zu generieren, was den Test spezifischer Szenarien einschließt. Die erstellten C-Tests werden von den Debuggern kompiliert und der Code wird mit Schnittstellen wie JTAG auf das Evaluation Board geladen. Die Tests können dann ablaufen und die Ergebnisse werden auf dem Evaluierungs-Board und dem Debugger-Interface angezeigt.
Derselbe Satz von Sequenzen, der auf SoC-Ebene mit der Graph-basierten eingeschränkten Randomisierung geschrieben wurde, kann komplett wiederverwendet werden. Zusätzlich erweist sich die visuelle Repräsentation des Testzwecks und die Fähigkeit Beschränkungen einzubinden als nützlich, um festgelegte Szenarien zu kreieren. Dies ist eine einzigartige und kontrollierbare Methode, um Tests in der Validierungsphase zu generieren und erfolgte traditionell komplett manuell.
Auch hier muss der Exec-Code für die spezifischen Anforderungen der Validierung des Bausteins neu geschrieben werden. Die grundlegenden Softwaretreiber von der Validierungsplattform, die genutzt werden, um die unterschiedlichen Master auf dem Bus wie DMA- und Speichercontroller zu steuern, können typischerweise auch für diese Art von Anwendung genutzt werden. Der generierte Code muss jedoch in ein Format übersetzt werden, das von den Evaluierungsplattformen akzeptiert wird. Dieser Prozess beinhaltet typischerweise die Wiederverwendung des Kopfes (Header) und nimmt Dateien von bereits vorher geschriebenem Validierungscode und verwendet ihn in dem generierten Integrationscode. Dieser Code wird dann kompiliert und läuft auf dem Ziel-Debugger, um einen sauberen Test auf dieser Ebene sicherzustellen.
Die PSS-Tools bieten üblicherweise die Fähigkeit, die Ergebnisse des Prüflaufs mit Applikationen auf den fertigen Bausteinen zu analysieren. Die visuelle Analyse der Testergebnisse zeigt entweder Gut oder fehlerhaft an und mit speziellen Codesegmenten lassen sich Ergebnisse ausgeben. Dies ist besonders im Validierungsprozess hilfreich, weil hier die traditionellen Debugging-Fähigkeiten sehr eingeschränkt sind.
Obwohl hier die C-Tests für das Traffic-Generator-Modell für die Applikationen auf den fertigen Bausteinen nicht wiederverwendet werden, lässt sich mit Sicherheit sagen, dass sie auf jeder Evaluierungsplattform eingesetzt werden können, die C-basierte Tests beinhaltet. Tatsächlich haben sich die Arten von Modellen, bei denen SoC-basierte PSS-Modelle für Post-Silizium-Evaluierungsboards wiederverwendet werden, für andere prozessorbasierte Anwendungen bewährt. Diese Wiederverwendung ist einzigartig und nur mit portierbaren Stimulus-basierten Methoden möglich.
Literatur
[1] Bhatnagar, G.; Fricano, C.: Validierung von Prototypen – Teil 1 – Portierbare Stimuliermethode für Post Silicon Validation. elektronik.de, 11. Februar 2021, www.elektroniknet.de/halbleiter/design/portierbare-stimuliermethode-fuer-post-silicon-validation.183454.html.
[2] Ajamian, T.: AMBA Interconnect Design Flow Automation. Synopsys, Inc., 2015, www.synopsys.com/news/pubs/snug/2015/boston/F1.2_Ajamian_paper.pdf.
[3] Gaurav, B.; Brownell, D.: Portable Stimulus vs. Formal vs. UVM: A Comparative Analysis of Verification Methodologies Throughout the Life of an IP Block. Design and Verification Conference (DVCon), 2018, Konferenzband, http://events.dvcon.org/2018/proceedings/papers/02_1.pdf.
[4] Portable Stimulus Working Group. Website, Accellera Systems Initiative, 2019, www.accellera.org/activities/working-groups/portable-stimulus.
[5] TrekUVM: Eliminating UVM Overhead. Website, Breker Verification Systems, 2019, https://brekersystems.com/products/trekuvm.
[6] Download UVM (Standard Universal Verification Methodology). Website, Accellera Systems Initiative, 2019, https://accellera.org/downloads/standards/uvm.
Die Autoren
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
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
- Portierbare Stimuliermethode für Post Silicon Validation
- SoC-Verifikation des Interconnect-Busses
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
