Beschleunigung der Verifizierung von integrierten Schaltkreisen zur Signalverarbeitung mit HDL Verifier

Die Verifizierung des Designs von integrierten Schaltkreisen (ICs) für die Signalverarbeitung bringt einige einzigartige Herausforderungen mit sich, die herkömmliche Testmethoden überfordern können. Die algorithmische Komplexität von Filtern, Mischern und anderen erweiterten Signalverarbeitungsfunktionen erfordert eine strenge Validierung, um sicherzustellen, dass sich der implementierte IC wie beabsichtigt mit bitgenauer Präzision verhält. Da ICs häufig mit einer großen Bandbreite möglicher Eingaben und Konfigurationen arbeiten, ist es außerdem wichtig, Sonderfälle zu bewerten – seltene, aber kritische Szenarien, die in Testplänen, die auf vordefinierten, vorhersehbaren Sequenzen basieren, nicht berücksichtigt werden können.

Mein Team bei NXP hat einen neuen Workflow zur IC-Verifizierung eingeführt, um diese Herausforderungen zu bewältigen. Basierend auf MATLAB^®, Simulink^®, und HDL Verifier™ umfasst dieser Workflow die Constrained-Random-Verifizierung und Techniken der Universal Verification Methodology (UVM), um Randfälle zu validieren und den Zustandsraum mit zufälligen Eingaben zu erkunden, während die Kontrolle durch Einschränkungen aufrechterhalten wird (Abbildung 1). In diesem Workflow, den wir kürzlich zur Verifizierung eines Radioempfänger-ICs für die Automobilindustrie verwendet haben, werden MATLAB und Simulink-Modelle mit HDL Verifier als SystemVerilog DPI-C-Komponenten exportiert und als Referenzmodelle in die Testbench für unsere Verifikationsumgebung basierend auf dem Cadence^® Xcelium™-Simulator integriert. Mit diesem Ansatz konnten wir nicht nur die Verifizierungszeit um 20 bis 30 Prozent verkürzen, sondern auch die Testabdeckung erhöhen und bereits früher in der Entwicklung mehr Implementierungsfehler finden.

Vergleich alter und neuer Workflows

Beim Testen ähnlicher IC-Designs in der Vergangenheit haben wir normalerweise MATLAB verwendet, um Eingangsreize für unser Gesamtsystem zu generieren. Wir haben dann Simulationen in MATLAB oder Simulink ausgeführt und die Ergebnisse als goldenes Referenzmuster erfasst. Sobald die RTL-Implementierung abgeschlossen war, wendeten wir dieselben Reize auf das Device under Test (DUT) an und überprüften die Ergebnisse anhand der goldenen Referenz. Dieser Ansatz funktionierte zwar, hatte aber einige Nachteile. Erstens erfolgte die Überprüfung größtenteils von Anfang bis Ende, was es schwierig machte, die Grundursache von Defekten zu ermitteln, da alle Komponenten zusammen getestet wurden. Zweitens war es nicht einfach, eine Constrained-Random-Verifizierung durchzuführen. Dies hatte zur Folge, dass zwar gängige Szenarien und Anwendungsfälle verifiziert wurden, viele Randfälle jedoch nicht. Drittens entsprach die Verifikation nicht UVM, das mittlerweile zum Standard-Framework für unsere Art der Implementierung von Testbenches geworden ist.

Im Gegensatz dazu ermöglicht der neue Workflow die direkte Wiederverwendung unserer vorhandenen MATLAB- und Simulink-Referenzmodelle in unserer HDL-Simulationsumgebung (Cadence Xcelium). Jede Komponente im Referenzmodell entspricht ihrem Gegenstück im DUT. Die in Abbildung 2 dargestellte beispielhafte Signalverarbeitungskette umfasst beispielsweise einen in Simulink modellierten Filter, gefolgt von einem Mischer und einem zweiten in MATLAB modellierten Filter. Wir verwenden HDL Verifier, um mit dem SystemVerilog DPI-C-Wrapper C-Code für das Modell zu generieren, sodass wir jede Komponente in die Testumgebung integrieren können.

Die Komponenten des Referenzmodells und die Komponenten des DUT werden parallel in der HDL-Simulationsumgebung ausgeführt, und ihre Ausgaben werden im laufenden Betrieb von einem Checker ausgewertet. Dieser fungiert als UVM-Scoreboard und führt bitgenaue Vergleiche der Ausgabe jedes zugehörigen Komponentenpaars (z. B. des Referenzmodellmischers und des DUT-Mischers) und der vollständigen Kette durch.

Randomisieren von Eingaben und Visualisieren von Ergebnissen

Nachdem vorläufige Tests – in diesem Fall mit einer Reihe vordefinierter AM-, FM- und DAB-Radiostreams – auf dem Prüfstand ausgeführt wurden, um die grundlegende Funktionalität der Signalverarbeitungsalgorithmen zu überprüfen, besteht der nächste Schritt im Workflow in der Constrained-Random-Verifizierung. Diese Phase umfasst umfangreiche Simulationen, bei denen allen Konfigurationseinstellungen für das Design zufällige Werte innerhalb eines eingeschränkten Bereichs zugewiesen wurden. Beispielsweise variieren wir Mischereinstellungen, Filtereinstellungen, Verzögerungen, Verstärkungen und andere wichtige Konfigurationsparameter und führen Simulationen durch, um die Leistung des Designs für jeden Satz zufällig ausgewählter Konfigurationsoptionen zu bewerten.

Für jeden Test können wir detaillierte Ergebnisse überprüfen, einschließlich der verwendeten spezifischen Einstellungen, der als Stimuli für das IP verwendeten Eingaben, der Ergebnisse aus der Referenzmodellimplementierung, der Ergebnisse aus der RTL-Implementierung und des Ergebnisses des Checker-Vergleichs (Abbildung 3).

Wir überprüfen auch Berichte, die zusammengefasste Ergebnisse für eine komplette Reihe von Komponenten zeigen (Abbildung 4). Diese Berichte zeigen die Anzahl der für jede Komponente in der Kette durchgeführten Prüfungen und die Anzahl der Fehler, d. h. die Anzahl der zwischen den RTL- und Referenzmodellausgaben festgestellten Abweichungen.

Wenn ein Fehler festgestellt wird, überprüfen wir sowohl die Implementierung des Referenzmodells in MATLAB oder Simulink als auch die RTL-Implementierung. In einigen Fällen konnten wir die Ursache der Diskrepanz auf das ursprüngliche Referenzdesign zurückführen, häufiger ist das Problem jedoch auf einen RTL-Implementierungsfehler zurückzuführen. In beiden Fällen führen wir die Testsimulationen erneut aus, sobald der Defekt diagnostiziert und behoben wurde, um zu überprüfen, ob durch die Korrektur alle Unterschiede zwischen dem Referenzmodell und der RTL-Implementierung vollständig behoben wurden.

Wichtige Verbesserungen und nächste Schritte

Ein klarer Vorteil unseres neuen Workflows auf Basis von HDL Verifier ist die Möglichkeit, die Fehlerquelle schnell zu identifizieren. Im Vergleich zu einem Ansatz, der auf End-to-End-Tests basiert, ist es mit einem von uns angewandten UVM-orientierten Ansatz, der Tests sowohl auf Komponenten- als auch auf Systemebene ermöglicht, viel einfacher, das Subsystem mit dem Defekt sowie die spezifischen Stimuli für diese Komponente zu identifizieren, die zum Replizieren des Defekts verwendet werden können.

Da das System mit zufällig gewählten Einstellungen häufig auf eine Weise getestet wird, die die Konstrukteure möglicherweise nicht erwartet haben, erleichtert der neue Arbeitsablauf im Vergleich zu herkömmlichen Testplänen, die sich auf gut etablierte Anwendungsfälle konzentrieren, die Aufdeckung von Implementierungsfehlern viel früher im Entwicklungsprozess. Kurz gesagt: Wir können Fehler finden, ohne sie manuell prüfen zu müssen und ohne Zeit auf das Ausdenken ungewöhnlicher Szenarien und Randfälle zu verwenden, die wir testen könnten.

Wir können unsere vorhandenen MATLAB- und Simulink-Modelle in HDL-Simulationen wiederverwenden und die Vorteile dieser Wiederverwendung werden bei jeder weiteren Überarbeitung oder Revision des IC noch größer. Zusammengenommen haben diese Vorteile zu der erheblichen Verkürzung der Verifizierungszeit – bis zu 30% – beigetragen, die wir beim Funksignalverarbeitungs-IC erreicht haben. Basierend auf dieser Metrik und den anderen Vorteilen, die wir erkannt haben, möchten andere NXP-Teams denselben Arbeitsablauf für die Entwicklung eines Funk-Frontends für einen Radar-IC und andere IC-Designs übernehmen.