mikrocontroller.net

Forum: FPGA, VHDL & Co. Verifikationsumbegung


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Tester (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo Forum!

Ich möchte hiermit einen Thread starten, in dem ein Austausch über 
diverse  Erfahrungen mit verschiedenen Test- & Verifikationsumgebungen 
stattfindet.


Wie verifiziert Ihr eure Designs?

Macht Ihr eher "Directed Tests" oder "Random Based"? Oder beides 
gemischt?

Sind Unit Tests üblich bei Euch für die Verifikation?

Wie sind Requirements formuliert? Welche Tools verwendet Ihr für 
"Requirements Engineering"? Verwendet Ihr Datenbanken oder macht ihr 
alles mit Excel? Andere Tools dafür?

Verwendet Ihr spezielle Tools?

Werden Teile auch formal verifiziert?

Habt Ihr eigens Skripte / Testumgebungen geschrieben?

Verwendet Ihr SystemC, SystemVerilog, PSL?

Autor: BoeserFisch (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Sieht schon aus wie ein Fragebogen..

Ich fasse mal kurz:
* Komplette Coverage, alle Zeilen im Code müssen abgedeckt sein und 
angesprungen werden
* MyHDL und eine eingekaufte Erweiterung erledigen die kompletten 
Random/Direkt generierten Testvektoren für das System, verifiziert wird 
alles nochmals auf VHDL-Ebene per Co-Simulation.
* Per MySQLdb-Modul gehn die Regression-Test-Ergebnisse in eine 
Datenbank

Der ganze System*-Ballast und High-Level-Simulation fällt damit weg, vor 
allem ist der Weg vom FPGA-spezifischen HDL zum ASIC leichter und wir 
müssen uns nicht auf die teuren Tools von M, C, oder S verlassen.
Die Requirements schreiben wir in einer Gerätebeschreibungssprache, die 
erzeugt die zu testenden Tabellen für die Regressionstests. Spart eine 
Menge Zeit.

Was willst Du denn testen/verifizieren?

Autor: Christian M. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Ich dachte, das sei ein deutschsprachiges Forum...?

Chregu

Autor: Tester (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian M. schrieb:
> Ich dachte, das sei ein deutschsprachiges Forum...?

Ja... Was soll ich machen, wenn ich den Tippfehler nachher erst sehe... 
:-*



BoeserFisch schrieb:
> * Komplette Coverage, alle Zeilen im Code müssen abgedeckt sein und
> angesprungen werden
> * MyHDL und eine eingekaufte Erweiterung erledigen die kompletten
> Random/Direkt generierten Testvektoren für das System, verifiziert wird
> alles nochmals auf VHDL-Ebene per Co-Simulation.
> * Per MySQLdb-Modul gehn die Regression-Test-Ergebnisse in eine
> Datenbank

Mhm... erzeugt Ihr euch dann mithilfe der Datenbank auch 
Traceability-Matrix und Requirements Coverage usw?

Ich merkte, dass zB manchmal Requirements so geschrieben sind, dass sie 
nicht 1:1 getestet werden können (zB mit PSL) und man dann mehrere Test 
Cases braucht um ein Requirement komplett abgedeckt zu haben. Mit Excel 
das ganze zu verwalten, ist irgendwie ein Krampf.

BoeserFisch schrieb:
> Die Requirements schreiben wir in einer Gerätebeschreibungssprache, die
> erzeugt die zu testenden Tabellen für die Regressionstests. Spart eine
> Menge Zeit.

Das klingt interessant. Denn ich denke gerade darüber nach, wie ich 
Testvektoren genieren lassen kann und dann diverse Listen zum 
Vergleichen von erwarteten und tatsächlichen Werten habe. Man müsste die 
Testvektoren, dann schon vorab sortieren/klassifizeren und letztendlich, 
glaube ich, würde dann ein eigenes Referenzmodel notwendig sein. zB 
können Frames verworfen werden usw, was es gar nicht mal so leicht macht 
sich aus Vektoren, die erwarteten Daten (pro Kanal) zu extrahieren.
Klingt so als würdet ihr genau das mit der MyHDL-Beschreibung erledigen.


BoeserFisch schrieb:
> Was willst Du denn testen/verifizieren?
Das ist so eine Art Gateway, das die Ansteuerung von diversen externen 
Kommunikationskontrollern übernimmt.



Bisher wurden eigentlich nur Direct Tests gemacht und das Ziel war/ist 
es, auf Random Based Assertions umzustellen.
Aber alleine schon zB die Formulierung von komplexeren Requirements in 
eine PSL-Assertion dauert lange. Dann braucht man zT auch noch 
Referenz-Modelle und relativ schnell merkt man, dass man mit Direct 
Tests schon weiter wäre.

Mir wäre am liebsten eine Kombination von beidem, also Assertion Based 
und Direct Tests... Und bei den Direct Tests wäre es halt fein, wenn man 
die Testvektoren und die zu erwarteten Daten einfach generieren kann.

LG

Autor: Marcus H. (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tester schrieb:
> Wie verifiziert Ihr eure Designs?

Constrained Random Testing, vorwiegend mit Specman.

Tester schrieb:
> Bisher wurden eigentlich nur Direct Tests gemacht und das Ziel war/ist
> es, auf Random Based Assertions umzustellen.
> Aber alleine schon zB die Formulierung von komplexeren Requirements in
> eine PSL-Assertion dauert lange. Dann braucht man zT auch noch
> Referenz-Modelle und relativ schnell merkt man, dass man mit Direct
> Tests schon weiter wäre.

Man muss dem Management immer wieder erklären, warum sich auch nach
Wochen die Coverage Datenbank noch nicht so richtig füllt. Leider
bleibt man bei Directed Tests am Ende der Fantasie des Test-Autors
stehen, während der Zufallsgenerator immer wieder neue “Einfälle” hat.

Directed Tests, vor allem die, die vom Designer selbst geschrieben
wurden, verlieren zudem durch Betriebsblindheit an Qualität. Viele der
der aufgedeckten Design- oder Spezifikationsfehler werden nur dadurch
gefunden, dass von einem typischen Szenario abgewichen wird.

> Mir wäre am liebsten eine Kombination von beidem, also Assertion Based
> und Direct Tests... Und bei den Direct Tests wäre es halt fein, wenn man
> die Testvektoren und die zu erwarteten Daten einfach generieren kann.

Meist verwendet man auch eine Kombination aus beidem. Um
beispielsweise Adressen durchzuklappern oder eine bestimmte,
in der Dokumentation beschriebene Konfiguration zu verifizieren,
brauche ich keinen Zufall.

Formale Verifikation habe ich persönlich nur für Connectivity Checks
verwendet, macht aber bei eingeschränkter Takttiefe und Suchraum die
Erzeugung komplexer Szenarien überflüssig. Ist also üblicherweise eher 
was für lokal begrenzte Verifikation und nicht für die gesamte 
Schaltung.

Autor: Strubi (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hi,

ich schmeiss auch mal noch was dazu. Die teuren $$$-Tools konnte/wollte 
ich mir nicht leisten, aber das Zeug doch einigermassen robust sein. 
Deswegen habe ich mir im Laufe der Zeit den Kram selber herangezüchtet.

Für div. CPU-Designs (MIPS und wüste Stackmaschinen-Hacks) hat sich 
MyHDL als exzellentes Tool erwiesen, die Unit bringt ihre Testbench 
gleich mit und testet sich quasi selbst, da kann man auf eine gewaltige 
Python-Library zurückgreifen. Allerdings musste ich da etwas tricksen, 
damit ein Regresstest nicht gleich Tage benötigt, d.h. "Model in the 
Loop" kommt da ins Spiel. Wenn ein Baustein in der Simulation 
funktioniert, kommt er in die HW - und in die Loop mit der Software bzw. 
Simulation.
Beispiel: Eine CPU hat einen Bug, dass eine Exception zu einer gewissen 
Cache-Konstellation und während Befehlssequenz A,B zu einem Fehler 
führt.
Das ist fast unmöglich, das alles im Trockendock der Virtualität zu 
erschlagen, also muss die Testsoftware in ein SoC, die alle diese Fälle 
zyklengenau und per In Circuit-Emulation durchspult. Die Kombination aus 
gut verifizierter CPU und speziell fehlerrobustem IP ist hier sicher 
sinnvoll.
An einem gewissen Punkt sind die ganzen Streitfragen theoretischer Art 
wie eben Direkt vs. Random zwecklos, da muss das System einfach gegen 
seinen typischen Antagonisten gegengetestet werden, bzw muss man einfach 
die beweisbaren Units gut von den non-deterministisch arbeitenden (wie 
eine CPU mit IRQ-Support) funktional trennen.

Tester schrieb:
> Das ist so eine Art Gateway, das die Ansteuerung von diversen externen
> Kommunikationskontrollern übernimmt.

Interessant. Mit sowas beschäftige ich mich des öfteren :-). Die 
Library, die ich für solche Zwecke entwickelt habe (nun 12 Jahre her) 
ist gerade für solche MIL (hier: Model in the Loop)-Sachen zu 
missbrauchen. Google mal nach den Stichwörtern "netpp ghdlex". Es liegt 
auch etwas Source herum. Damit kannst Du z.B. über einen virtuellen Bus 
deine HW gegen eine funktonierende Referenz (wie qemu oder eine 
verifizierte HW-Simulation) abgleichen und externe Daten wie 
Netzwerkpakete mit einschlaufen. Habs mal vor ein paar Jahren an der 
Embedded World vorgestellt, aber die Schergen in der Zielgruppe wollen 
lieber die Klickibunti-Sachen von Cadence und können sie sich meist auch 
leisten :-)

Grüsse,

- Strubi

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> BoeserFisch schrieb:
>
> * MyHDL und eine eingekaufte Erweiterung erledigen die kompletten
>> Random/Direkt generierten Testvektoren für das System,
Darf man wissen wie die heisst?


Tester schrieb:
> Ich merkte, dass zB manchmal Requirements so geschrieben sind, dass sie
> nicht 1:1 getestet werden können (zB mit PSL) und man dann mehrere Test
> Cases braucht um ein Requirement komplett abgedeckt zu haben.
Das ist leider war, daher bildet man sinnvollerweise die Funktionen auf 
mehrere Subfunktionen in der Umsetzung ab und generiert für jede 
Funktion ein Testset.

Ich benutze eine TM, aus der hervorgeht, welche Testanforderung durch 
welchen Test abgedeckt ist.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
>Tester schrieb:
> Ich möchte hiermit einen Thread starten, in dem ein Austausch über
> diverse  Erfahrungen mit verschiedenen Test- & Verifikationsumgebungen
> stattfindet.
Bei dem Thema bin ich mit von der Partie!


> Wie verifiziert Ihr eure Designs?
> Macht Ihr eher "Directed Tests" oder "Random Based"? Oder beides
> gemischt?
Random nicht. Es gibt ganz bestimmte Fälle für den Gutablauf und 
Fehlerfälle, die vorkommen können und nicht woanders abgefangen werden. 
Dazu gibt es eine Strategie die implementiert und ausdrücklich getestet 
wird.

> Sind Unit Tests üblich bei Euch für die Verifikation?
Sie sind Teil der Verifikation und oft die Einzigen, weil das 
Gesamtsystem nicht sinnvoll simulierbar ist. Mit HIL-Tests kann man aber 
einen Teil der Verfikation in die HW verlagern. Entweder mit eine 
compilierten Simulation mit entsprechenden Tools wie SystemGenerator 
oder mit Funktionstests, bei denen keine echten, sondern generierte 
"extreme" Daten am Eingang nehmen.

> Wie sind Requirements formuliert? Welche Tools verwendet Ihr für
> "Requirements Engineering"? Verwendet Ihr Datenbanken oder macht ihr
> alles mit Excel? Andere Tools dafür?
Je nach Vorgaben. In Branchen wie der MED oder MIL wird das inzwischen 
recht restriktiv gehandhabt. Doors wäre ein Beipspiel - wenn auch kein 
Optimales.

Autor: Markus F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tester schrieb:
> Aber alleine schon zB die Formulierung von komplexeren Requirements in
> eine PSL-Assertion dauert lange.

und dann ergibt sich die Problematik, dass die Formulierung gfs 
komplexer und damit fehleranfällig ist, als das zu testende Modul. So 
ein Vorgehen ist aber bei Regressionstests wichtig.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.