Anwendung der modellbasierten Verifizierung in der Automotive-ASIC-Entwicklung

In Halbleiterunternehmen, die die Automobilindustrie beliefern, werden die Entwicklungsteams aufgefordert, immer komplexere Systeme in engen Zeitplänen zu liefern. Das Einhalten dieser knappen Fristen ist mit Schwierigkeiten im Zusammenhang mit Tests im Spätstadium verbunden. Wenn man beispielsweise mit der Funktionsüberprüfung wartet, bis RTL verfügbar ist, besteht die Gefahr von Kostenüberschreitungen und Lieferverzögerungen. In dieser Phase festgestellte Konstruktionsfehler und Anforderungsprobleme sind wesentlich kostspieliger und schwieriger zu beheben, und die Teams verschwenden wertvolle Zeit mit der Fehlerbehebung bei unrealistischen Szenarien. In diesem Umfeld stellt Shift Left Testing, bei dem die Verifizierungsaktivitäten so früh wie möglich im Entwicklungszyklus durchgeführt werden, die Antwort auf solche Testherausforderungen in der Spätphase dar.

Einige unserer Teammitglieder bei Allegro MicroSystems haben einen neuen Shift-Left-Ansatz mit Model-Based Design für DSP-Blöcke übernommen, der die Generierung von HDL-Code für Mixed-Signal-ASICs sowie die Generierung von Testbenches der Universal Verification Methodology (UVM) für die Verifizierung auf RTL-Ebene umfasst. Mit diesem modellbasierten Verifikationsansatz profitieren wir von einer frühen Funktionsverifikation in Simulink^® und eine Systemebenenansicht des Designs, die die Zusammenarbeit zwischen Systemingenieuren und Verifizierungsteams erleichtert (Abbildung 1). Eine frühzeitige Modellüberprüfung führt zu einer besseren HDL-Qualität, da Probleme mit dem Design und den Anforderungen auf hoher Ebene vor der Codegenerierung erkannt und behoben werden. Wir erwarten, dass diese frühzeitige Fehlererkennung zwei Monate Verifizierungsaufwand einspart. Darüber hinaus profitieren wir von rigorosen Tests der HDL-Implementierung in unserer UVM-Umgebung und der projektübergreifenden Wiederverwendung von Modellen und Testressourcen.

Von den Anforderungen über die ausführbare Spezifikation bis zur Implementierung

In einem herkömmlichen Entwicklungsworkflow verfasst der Systemingenieur textbasierte Anforderungen, die vom digitalen Designteam (Systemarchitekten und RTL-Ingenieure) verwendet werden, um die Spezifikation und daraus das RTL-Design zu erstellen. Unsere Gruppe, das digitale Verifizierungsteam, wäre dann für die Erstellung eines Testplans basierend auf der Spezifikation und der Funktionsverifizierung verantwortlich, um sicherzustellen, dass das RTL-Design der Spezifikation entspricht. Wenn bei diesem Workflow ein Defekt erkannt wird – typischerweise spät im Entwicklungszyklus – kann es lange dauern, bis ermittelt wird, ob die Grundursache des Defekts bei der Implementierung, der Spezifikation oder den ursprünglichen Anforderungen liegt.

Bei unserem aktuellen Ansatz ist der Workflow so konzipiert, dass eine Überprüfung der Architektur und der Anforderungen deutlich früher möglich ist. Sobald die Anforderungen in Jama Connect^® durch den Systemingenieur definiert sind, erstellt das digitale Designteam ein Architekturspezifikationsmodell in Simulink. Dieses Modell dient als ausführbare Spezifikation des Systems. Indem das Team Simulationen mit diesem Modell ausführt, führt es Model-in-the-Loop-Unit- und Integrationstests durch, um Anforderungen zu validieren und die Architektur zu verifizieren (Abbildung 2). Bei unserem ersten Projekt mit diesem Ansatz halfen uns diese Simulationen dabei, mehrere Probleme zu erkennen, darunter ein Szenario, in dem sich bedingte Anweisungen widersprachen, was bei einigen Kombinationen von Eingabereizen zu einer ungültigen Ausgabe führte.

In der nächsten Entwicklungsphase übersetzt das Team das Architekturmodell in ein „hardwarefreundlicheres“ Implementierungsmodell zur Vorbereitung der Codegenerierung mit HDL Coder™. Hierzu kann beispielsweise die Konvertierung von Algorithmen von Gleitkomma- zu Festkomma-Algorithmen oder die Umstellung von der rahmenbasierten Verarbeitung auf Streaming gehören.

Testbench-Modelle und Verifizierung in Simulink

Während das digitale Designteam Komponenten im Implementierungsmodell erstellt, werden parallel Simulink Testbench-Modelle für diese Komponenten entwickelt. Jedes Simulink Testbench-Modell enthält die folgenden Subsysteme, die den UVM-Komponenten entsprechen: Sequenz, Treiber, DUT, Prädiktor, Monitor und Scoreboard (Abbildung 3). Für die Testbench-Generierung mit HDL Verifier™ werden nur die Sequenz-, DUT- und Scoreboard-Subsysteme benötigt.

Das Sequenz-Subsystem erzeugt Stimuli für das zu testende Gerät oder DUT-Subsystem, das in diesem Workflow das in Simulink erstellte Implementierungsmodell ist. Dieses Subsystem erzeugt und randomisiert Reize mit MATLAB^®-Code und Simulink-Blöcke, einschließlich des Test Sequence-Blocks. Sein Seed-Input wird zum Initialisieren des MATLAB Zufallszahlengenerators verwendet. Das Scoreboard-Subsystem sammelt die Ausgabe des DUT und vergleicht sie mit der erwarteten Ausgabe über Assertion for DPI-C-Blöcke, die zum Generieren von DPI-C-Komponenten verwendet werden, die SystemVerilog-Assertionen enthalten (Abbildung 4). (Das SystemVerilog Direct Programming Interface [DPI] ist eine Schnittstelle zwischen SystemVerilog und einer fremden Programmiersprache wie C. HDL Verifier kann DPI-C-Komponenten generieren, die aus C-Code mit SystemVerilog-Wrappercode bestehen; die resultierenden DPI-C-Komponenten können dann von HDL-Simulatoren ausgeführt werden, die SystemVerilog unterstützen.)

Durch Ausführen von Simulationen in Simulink mit dem Testbench-Modell zusammen mit verschiedenen Modellverifizierungs- und -validierungstools wie Simulink Test™ wird das Implementierungsmodell zusätzlich anhand der Anforderungen validiert. Wir übertragen die Ergebnisse dieser Simulationen von Simulink zurück in Jama, um anforderungsbasierte Tests zu ermöglichen. Darüber hinaus kann Simulink Design Verifier™ verwendet werden, um tote Code-Logik im Modus zu identifizieren.

Codegenerierung, Testbench-Generierung sowie HDL-Simulation und -Test

Nachdem das Implementierungsmodell und die Testbench-Modelle erstellt und zur Durchführung der Entwurfsverifizierungsphase des Workflows in Simulink verwendet wurden, beginnen wir mit der nächsten Phase: HDL-Codegenerierung und -verifizierung. In dieser Phase verwenden wir HDL Coder, um aus Implementierungsmodellkomponenten synthetisierbaren HDL-Code zu generieren. Wir verwenden auch HDL Verifier— und zwar die uvmbuild-Funktion aus dem ASIC Testbench Add-on – zum Generieren vollständiger UVM-Testbenches aus den Simulink-Testbenchmodellen (Abbildung 5). (Eine weitere Funktion in ASIC Testbench, dpigen, generiert DPI-C-Komponenten aus MATLAB-Code oder Simulink-Modellen für Designteams, die keine UVM-Umgebungen verwenden.)

Mithilfe der generierten Testbench führen wir dann in unserer UVM-Umgebung Tests mit dem aus dem Implementierungsmodell generierten Code mithilfe eines digitalen Simulators wie Cadence^® Xcelium™-Simulatoren durch (Abbildung 6). Wir erweitern den generierten UVM-Testbench nach Bedarf, um komplexere eingeschränkte Randomisierungen, Assertion-Checker und SystemVerilog-Cover-Gruppen für die funktionale Abdeckungsanalyse hinzuzufügen. Wenn ein Test in der UVM-Umgebung fehlschlägt, verwenden wir die Seed- und Speicherkonfiguration des fehlgeschlagenen Tests, um die Fehlerbedingungen in einer Simulink Simulation zu reproduzieren. Im Vergleich zum direkten Debuggen auf HDL-Ebene erleichtert dies dem Konstrukteur das Debuggen und Beheben des Fehlers erheblich.

Nächste Schritte

Da die Anforderungen der Kunden immer anspruchsvoller werden und die Lieferfristen immer kürzer werden, unterstützt der von uns eingeführte modellbasierte Verifizierungsansatz unsere Teams dabei, anspruchsvollere Algorithmen und Systeme in kürzerer Markteinführungszeit bereitzustellen. Wir planen, dieses Shift-Left-Konzept auf andere Projekte auszuweiten. Dabei erwarten wir, dass die Wiederverwendung von Modellen und zugehörigen Simulink-Testumgebungen durch das Verifizierungsteam bei Projekten mittlerer Komplexität bei Allegro weitere zwei Monate Entwicklungsaufwand einspart. Zukünftig prüfen wir auch Möglichkeiten zur Wiederverwendung von Modellen für unsere Systementwicklungsteams und unsere Kunden.