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