Testbench-Automatisierung vs. Constrained Random Verification
Fortsetzung des Artikels von Teil 2
Testbench-Automatisierung vs. Constrained Random Verification
In einer ersten Validierungsphase werden mit Hilfe der CRV-Umgebung getrennte Testbench-Blöcke für die APB-, DMA- und IRQ-Schnittstellen entwickelt. Dies geschieht zusammen mit separaten Verifikationsblöcken für Peripheriekomponenten auf dem I²C-Bus, der I²C-Master und I²C-Slaves enthält. Jeder CRV-Testblock ist so konfiguriert, dass er willkürlich abläuft. Parallel dazu werden einmalige Testkombinationen generiert.
Mit dem nächsten Schritt sind, um die Coverage zu maximieren, auf einer Server-Farm ungefähr fünfzig Simulationen parallel durchgeführt worden. Jede davon hat verschiedene Startwerte, und ein separates Werkzeug bearbeitet die Simulationsergebnisse nach, um die funktionale Coverage zu bestimmen. Für den Fall, dass die Coverage nicht erreicht wird, hat man noch weitere gezielte Tests entwickelt.
In Bild 1 sind auch jene inFactiVC-Elemente abgebildet, welche die DUT-Schnittstellen ansteuern – unter anderem also Standard-inFact-iVCs (blau dargestellt) für I²C-Master, I²CSlave und APB-Bustreiber. Eine kundenspezifische inFact-„CPU/DMA“-Testbench generiert alle High-Level-Testszenarien für das DUT und koordiniert die Testaktivitäten für alle DUT-Signalschnittstellen. Darüber hinaus wird ein kundenspezifisches „Scoreboard“ zur Anwendung für den Vergleich der I²C-Bustransaktion implementiert.
Jobangebote+ passend zum Thema
Die CPU/DMA-Testbench verwaltet die Aktivitäten aller DUT-Signalschnittstellen mittels Transaktionsschnittstellen, um I²C-Master-, I²CSlave- und APB-iVC-Blöcke auf eine „systematische“ nicht-willkürliche Weise anzusteuern und zu überwachen. Als Resultat werden sich nicht wiederholende komplexe Testsequenzen generiert.
Das I²C-Controller-DUT unterstützt mehrere I²C-Modi und -Konfigurationen, die verifiziert werden müssen:
- DUT-Betrieb im I²C-Master-, I²CSlave- oder I²C-Master/Slave-Modus mit programmierbarer I²CAdressierung.
- Der DUT-Datenfluss wird entweder vom CPU/IRQ- oder DMA-Betrieb kontrolliert.
- Konfigurierbare DMA-Transfermodi und Burst-Sizes.
- Konfigurierbare FIFO-Grenzwerte während des CPU/IRQ-Datentransfers.
- Konfigurierbare I²C-Busgeschwindigkeit für Standard-, Fast- oder Highspeed-Modi.
- Unabhängig konfigurierbare Größen für Tx- und Rx-FIFOs.
Da dies ein Universal-I²C-Master/ Slave-Controller ist, wird das gesamte Spektrum der I²C-Transferprotokolle unterstützt. Verifiziert werden müssen demnach:
- Alle I²C-First-Byte-Conditions und Datentransfermodi.
- Transfers zwischen I²C-Masters und -Slaves unterschiedlicher Größe, I²C-Busgeschwindigkeiten und Richtungen, bei denen das DUT Master, Slave oder beides sein könnte.
- Simultane Transfers zwischen DUT und externen I²C-Mastern zu gleichen oder verschiedenen Slaves, um das korrekte DUT-Verhalten während der I²C-Bus-Arbitrierung zu verifizieren.
- Generierung verschiedener I²C-Bus-Terminierungen.
- I²C-Clock-Stretching durch inFact-I²C-Slaves, um festzustellen, ob das DUT dem I²C-Protokoll folgt.
Die verschiedenen DUT-Modi und I²C-Busse wurden in einem inFact-Regelgraphen in der CPU/DMA-Testbench spezifiziert, die während der Simulation algorithmisch durchlaufen wird. Bild 2 zeigt einen Regelgraphen, der dem im Benchmark verwendeten ähnelt. Er wurde vereinfacht, also ohne kundenspezifische Daten dargestellt. Die sonst als „Aktionen“ bekannten ovalen Graphen wurden auf die Testbench-Code-Segmente gemappt, die entweder in C++ oder SystemVerilog geschrieben worden sind. Die Code-Segmente werden anschließend dann aufgerufen, wenn der Graph eine bestimmte Aktion aktiviert hat.
Der obere Teil des Graphen ist jeweils für die Auswahl der Testkonfigurationsoptionen verantwortlich – also für DUT-Master/Slave-Betriebsmodi, IRQ- oder DMA-Transfermodi, FIFO-Grenzwerte oder Größe des DMA-Bursts, Adressbreite des Slave-Targets sowie Größe und Richtung des I²C-Transfers. Um die Konstruktion des Graphen zu vereinfachen, spezifizieren einige der Graphen-Ovale mehrere Auswahlmöglichkeiten für die Parameter des Graphen.
- Testbench-Automatisierung vs. Constrained Random Verification
- CRV benötigt ein Vielfaches an Testdurchläufen
- Testbench-Automatisierung vs. Constrained Random Verification
