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?
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?
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
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.
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
> 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.
>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.
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.
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
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten