Testbench für komplexe Designs

[Martin O. (ossi-2)]

Mich interessiert, wie Ihr eure Testbench gestaltet. Insbesondere 
interessiert mich, wie ihr das Testen bei komplexen Designs gestaltet. 
Baut ihr eine kpmplette Testumgebung oder testetet ihr einzelne 
Baugruppen?

Beispiel könnte folgendes Software Designed Radio (SDR) Design sein: Ein 
ADC tastet das "Antennensignal" ab. Dann kommen digitale Filter, dann 
ein digitaler Mischer, dann Filter mit Dezimation, dann Demodulation und 
wieder Filter dann eventuell noch Datenverarbeitung mit nem Softcore. Es 
könnte auch eine Software-PLL vorkommen, die einige MegaSamples braucht, 
bis sie eingerastet ist.

Eine Testbench für das komplette Design zu schreiben stelle ich mir sehr 
schwierig vor. Was ratet ihr mir?

[Duke Scarring (Gast)]

Martin O. schrieb:
> Baut ihr eine kpmplette Testumgebung oder testetet ihr einzelne
> Baugruppen?
Sowohl als auch.

[...]
> Eine Testbench für das komplette Design zu schreiben stelle ich mir sehr
> schwierig vor. Was ratet ihr mir?
Mit den Modultestbenches wird die Funktionalität der einzelnen Module 
sichergestellt. Die Gesamttestbench prüft dann nur noch das 
Zusammenspiel der Einzelkomponenten. Da kann man i.d.R. nicht mehr alle 
Grenzwerte der Einzelkomponenten anfahren.

Externe Komponenten (ADC, DAC) und Schnittstellen (UART, Display, 
Ethernet) werden einzeln modelliert und dann in der Systemtestbench 
instanziiert.

Duke

[Blechbieger (Gast)]

Testbench für das Gesamtdesign kann schwierig werden da die Simulation 
sehr langsam wird wenn das Zeilenlimit der Simulatorlizenz überschritten 
wird.

[J. S. (engineer)]

Blechbieger schrieb:
> Testbench für das Gesamtdesign kann schwierig werden da die Simulation
> sehr langsam wird wenn das Zeilenlimit der Simulatorlizenz überschritten
> wird.

Auch ohne limitierte Simulatoren (freie Versionen) sind Simulationen des 
kompletten Designs kaum möglich. A) weil es zu langsam ist, und B) weil 
es zu viele Varianten gäbe.

Um eine vollständige Testabdeckung zu erzielen, kommt man um Modultests 
nicht herum, bei denen jeweils nur die spezifischen Eingänge variiert 
werden. Das ist am Ende auch schneller und einfacher angesetzt und 
durchgeführt.

Eine vollständige Simulation nutze ich nur, um sicherzustellen (und zu 
beweisen) dass alles im FPGA beschaltet ist und durchgängig 
funktioniert. Ansonsten braucht man das, wenn mehrere FPGAs miteinander 
reden sollen. Dann nutzt man am Besten Ersatzdesigns ohne rechnende 
Innereien, die nur Interfaces kennen.

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

Jürgen S. schrieb:
> Um eine vollständige Testabdeckung zu erzielen, kommt man um Modultests
> nicht herum, bei denen jeweils nur die spezifischen Eingänge variiert
> werden. Das ist am Ende auch schneller und einfacher angesetzt und
> durchgeführt.

Sehe ich auch so und verwende dazu gerne VUnit 
(https://vunit.github.io/). Wird ständig weiter entwickelt und die 
Entwickler sind erreichbar. Das hilft enorm beim Verwalten der ganzen 
Testcases.

Mein Favorite Stack besteht aus Gitlab CI - Docker - Modelsim / 
Questasim / GHDL - VUnit.

Auch einen Blick in UVVM und OSVVM lohnt sich, auch zwei hervorragende 
Libraries zur Functional Coverage.

Damit sind auch mal noch ein paar Buzzwords in den Raum geworfen. ;-)

[Strubi (Gast)]

Martin O. schrieb:
> Beispiel könnte folgendes Software Designed Radio (SDR) Design sein: Ein
> ADC tastet das "Antennensignal" ab. Dann kommen digitale Filter, dann
> ein digitaler Mischer, dann Filter mit Dezimation, dann Demodulation und
> wieder Filter dann eventuell noch Datenverarbeitung mit nem Softcore. Es
> könnte auch eine Software-PLL vorkommen, die einige MegaSamples braucht,
> bis sie eingerastet ist.


Für ein SDR musst du ja nicht ne Wahnsinns-Verifikation hinlegen. Und 
auch die Datenverarbeitung mit dem Soft-Core kannst du anstatt im 
Simulator in den Emulator (qemu, o.ä.) packen.

Bei so pipelined Datengeschiebe bietet sich Co-Simulation mit div. 
Komponenten an, und zwar insofern, dass du die Sachen multi-threaded 
laufen lassen kannst. Ich habe für BV-Anwendungen z.B. MyHDL (virtueller 
Sensor, also Datenquelle und Arithmetik-Modell), qemu (CPU-Kern) und 
GHDL (DSP/Peripherie) zusammengekoppelt, solange irgendwie asynchron 
Daten in eine Richtung fliessen, ist das recht effizient, und man kann 
weitgehend von V* HDL-TBs absehen (mühsame bis unübersichtliche 
Schreiberei). MyHDL ist beim Simulieren übrigens teils erstaunlich 
flott, trotz interpretiertem Python.

Beim Thema Einzelmodul-Test versus gesamte Simulationskette gibt's 
sicher kein Generalrezept. Wenn mal alles einzeln läuft, willst du 
vermutlich alles rekonstruierbar regress-testen/kontinuierlich 
integrieren, wenn das Projekt dynamisch wächst. Macht nur Sinn, 
frühzeitig alle benötigten Primitiven und Komponenten mal im Trockendock 
(separat) zu überprüfen, da gibt's auch schon Showstopper, wenn für das 
Ziel-FPGA z.B. zur Lieblings-HDL die passenden Modelle fehlen oder für 
einen $$$-Simulator, der just nicht vernünftig Co-Simulation beherrscht, 
verschlüsselt sind.