Entwicklungsstandards wie DO-254 verlangen Testbenches mit 100% statement coverage. Nun gibt es kommerziele Tools die VHDL testbenches/designs auf vollständige Testabdeckung prüfen, allerdings sollte das auch mit Script-Bordmittel erreichbar sein. Beispielsweise ein Script, das nach jeder relevanten VHDL-Zeile ein assert o.ä. einfügt und man nur noch schauen muss ob alle asserts-ausgaben im log zu finden sind. Kennt jemand dergleichen?
Mit GHDL solls auch ohne solche Klimmzüge gehen, habs aber nicht probiert... http://home.mnet-online.de/al/ghdl_gcov/ghdl_gcov.html
Interessantes Thema. Ich habe seinerzeit mal mit ModelSIM gearbeitet, das ein Coverage-Modul bietet. So richtig zufrieden bin ich damit aber nicht gewesen. Meines Erachtens ist es aber auch ein Unterschied, ob ich das formelle coverage betrachte, das in existenten Formulierungen auftritt (das wird vom ModelSIM in erster Linie analysiert) oder ob ich ein case-coverage im Sinne einer Überdeckung der funktionellen Optionen habe / erhalte. Ich sehe da auch gewisse Probleme! Ich kann mir ad hoc verschieden Fälle einfallen lassen, bei denen je nach Sichtweise keine oder eben doch eine funktionell vollständige Überdeckung gegeben ist und das Tool das ohne weitere Infos ohnehin nicht entscheiden kann. Wer kann mehr zu dem Thema sagen?
Naja, diese ganze Coverage-Geschichte taugt IMO überhaupt nur, wenn das jemand macht, der sich auch wirklich mit dem Design auskennt und wenn auch die Tests umfassend sind. Nur mal eben so einen Coverage-Lauf machen, damit man irgendwelche lästigen Formalien erfüllt hat, hilft nicht viel. Es gibt wohl leider kein Tool, dass einem zu einer Testbench sagt, welchen (kritischen) Fall man nicht getestet hat ;)
Vielleicht lohnt sich ein Blick auf http:/www.synthworks.com. Jim Lewis, der Inhaber, sitzt in den VHDL Standard Committees und macht sich eigentlich viel Mühe eine OpenSource Lösung für Randomisation und Coverage in VHDL an den Mann zu bringen. Du brauchst halt einen Simulator dazu. Bin mir nicht sicher, ob GHDL reicht. Die günstigste Lösungen im Augenblick dürften die Modelsim Altera Edition oder Active-HDL in der Lattice Edition (diese wäre sogar mixed Language) Meine persönliche Meinung ist, dass Coverage eben nur eine Massnahme von vielen ist um ans Ziel zu gelangen. Zusammen mit Randomisation ist es aber durchaus effektiv. Grüße, Charles
Wer garantiert, dass das "randomize" voll covered? Klingt nach Zufall!
cfgardiner schrieb: > Vielleicht lohnt sich ein Blick auf http:/www.synthworks.com. > Du brauchst halt einen Simulator dazu. Bin mir nicht sicher, ob GHDL > reicht. Die günstigste Lösungen im Augenblick dürften die Modelsim > Altera Edition oder Active-HDL in der Lattice Edition (diese wäre sogar > mixed Language) > Mir gehts es bei der Frage um eine Simulatorunabhängige Lösung, eine Ergänzung des Quelltextes um Code der misst ob die Zeile ausgeführt wurde oder nicht. Unterstütz der Altera modelsim coverage checks? mein erste Kanditat wäre der Xilinx - isim. MfG,
VHDL-ING schrieb im Beitrag #2765790: > Wer garantiert, dass das "randomize" voll covered? > > Klingt nach Zufall! Von der Forderung full covered hat man sichbei den heutigen komülexen designs verabschiedet. "Randomize ist eine Möglichkeit schnell viele Teststimuli zu erzeugen, der Zufall garantiert das mensch nicht aus Betriebsblindheit kritische Szenarien auslässt. In der Regel werden die zufälligen generierten Testvektoren gefiltert und analysiert um möglichst alle typischen Fälle abzudecken, für die atypischen erhält man ebenfalls Simuläufe und kann so auch die Ausfälle aus "kuriosen" Randbedingungen simulieren. MfG,
Jürgen S. schrieb: > Interessantes Thema. Ich habe seinerzeit mal mit ModelSIM gearbeitet, > das ein Coverage-Modul bietet. So richtig zufrieden bin ich damit aber > nicht gewesen. Meines Erachtens ist es aber auch ein Unterschied, ob ich > das formelle coverage betrachte, das in existenten Formulierungen > auftritt (das wird vom ModelSIM in erster Linie analysiert) oder ob ich > ein case-coverage im Sinne einer Überdeckung der funktionellen Optionen > habe / erhalte. > > Ich sehe da auch gewisse Probleme! Ich kann mir ad hoc verschieden Fälle > einfallen lassen, bei denen je nach Sichtweise keine oder eben doch eine > funktionell vollständige Überdeckung gegeben ist und das Tool das ohne > weitere Infos ohnehin nicht entscheiden kann. Konkrete Beispiele bitte. Nach meinem Erachten zielt Statement Coverage vorrangig. auf eine Verbesserungen der Qualität des Entwicklungsprozeßes und hebt damit indirekt die Qualität des Produktes. Es zwingt überhaupt zur Simulation und macht die Überprüfung messbar, da 100% hier wirklich angebbar ist. Hundert Prozent funktionale Abdeckung dagegen kann nur als 100% Abdeckung der Testfälle resp Requirements gemessen werden. Und die ist nun leider davon abhängig wie gut/umfangreich der Ingenieur diese Testfälle/Funktionen spezifiziert hat. Ich sehe statement coverage als Mittel neben funktionallen Test nicht als Allheilmittel. MfG,
Georg A. schrieb: > Naja, diese ganze Coverage-Geschichte taugt IMO überhaupt nur, wenn das > jemand macht, der sich auch wirklich mit dem Design auskennt und wenn > auch die Tests umfassend sind. Nur mal eben so einen Coverage-Lauf > machen, damit man irgendwelche lästigen Formalien erfüllt hat, hilft > nicht viel. Doch, er gibt die Sicherheit mindestens das quantifizierbare Minimum an Tests ausgeführt zu haben. Es ist eben nicht ein Coverage - Lauf sondern das Erstellen einer Testbench mit überprüfbarer Qualität. Und es kann von jemanden ausgeführt werden der nur Teile des Designs kennt (und somit auch von Trugschlüssen wie: "Wenn ich das geschrieben habe, passiert ein solcher Fehler nicht" einigermassen gefeit ist. MfG,
Ist meiner Ansicht nach auch immer eine Frage, wo man Coverage Tools
(statement, case, toggle etc.) sinnvollerweise einsetzt.
Bei meinem früheren Job (ASIC-Entwicklung) war's ein ("ein", nicht
"das") unabdingbares Tool in der Verifikationskette und hat mindestens
die blockbasierte Verifikation enorm beschleunigt (weniger Probleme in
der Toplevel- und Funktionalsimulation welche dann auch mit "randomize"
Methoden gemacht wurde).
Bei meiner momentanen FPGA-Tätigkeit sehe ich die Notwendigkeit eines
solchen Tools nicht zwingend. Da tut's eine grobe Funktionalsimulation,
und dann geht's ab aufs System, welches ja (keine NRE wie beim ASIC)
tipp-topp für's Debugging eingesetzt werden kann...
Fritz Jaeger schrieb: >> Du brauchst halt einen Simulator dazu. Bin mir nicht sicher, ob GHDL >> reicht. Die günstigste Lösungen im Augenblick dürften die Modelsim >> Altera Edition oder Active-HDL in der Lattice Edition (diese wäre sogar >> mixed Language) >> > > Unterstütz der Altera modelsim coverage checks? Würde mich wundern. Selbst für ModelSim PE braucht man eine extra Lizenz:
1 | VSIM> toggle add -r /* |
2 | # ** Error: Failure to license for coverage. Unable to checkout msimcoverage license feature. |
3 | # ** Error: (vsim-43) toggle coverage is not supported in this version. |
Duke
Duke Scarring schrieb: > Würde mich wundern. Selbst für ModelSim PE braucht man eine extra > Lizenz: Für's "PE" ja, das hatte ich seinerzeit auch. Coverage musste (ich glaube, für 2,5TEUR) hinzubestellt werden. In der "SE" war es damals 2006 aber drin, meine ich.
Peter K. schrieb: > Ist meiner Ansicht nach auch immer eine Frage, wo man Coverage Tools > (statement, case, toggle etc.) sinnvollerweise einsetzt. > > Bei meinem früheren Job (ASIC-Entwicklung) war's ein ("ein", nicht > "das") unabdingbares Tool in der Verifikationskette und hat mindestens > die blockbasierte Verifikation enorm beschleunigt (weniger Probleme in > der Toplevel- und Funktionalsimulation welche dann auch mit "randomize" > Methoden gemacht wurde). > > Bei meiner momentanen FPGA-Tätigkeit sehe ich die Notwendigkeit eines > solchen Tools nicht zwingend. Da tut's eine grobe Funktionalsimulation, > und dann geht's ab aufs System, welches ja (keine NRE wie beim ASIC) > tipp-topp für's Debugging eingesetzt werden kann... Hm die zu Anfang erwähnte DO254 behandelt zwar auch FPGA's, will aber wohl adHoc inEcht-Test ohne den versuch einer Verifikation per Simulation vermeiden. -> ist ja airborne, das tut auch ohne NRE richtig weh. Und in der Simu sind einige Fehlerszenarien einfacher herbeiführbar als in Echt. (Bspw: IR-Request aller Peripherien gleichzeitig in Verbindung mit einem DMA-Request bei einer Write back Cache Implementierung ...). Eine Kombination von in System test mit Pattern die aus einer Simu mit dabei nachgewiesener 100 % Statement Coverage stammen, dürfte ein guter mittelweg sein. MfG
Zum Thema rand Coverage: da kann ich jedem nur osvvm.org nahelegen. Jim Lewis hat hier ganze Arbeit geleistet und die docu lässt auch keine Fragen offen. Gruß helge
helge schrieb: > Zum Thema rand Coverage: > > da kann ich jedem nur osvvm.org nahelegen. > > Jim Lewis hat hier ganze Arbeit geleistet und die docu lässt auch keine > Fragen offen. > > Gruß > helge Hab mal kurz reingeschaut, selbst wenn es für die DO254 wohl nicht anwendbar ist (die mag keine Extra-Analyse-Logik) sehr vielversprechend. jetzt hab ich ein thema füs wochenende (neben Nachwuchspflege ;-)). MfG,
VHDL-ING schrieb im Beitrag #2765790: > Wer garantiert, dass das "randomize" voll covered? Niemand. Daher braucht man ja eine umfangreiche coverage Infrastruktur, mit deren Hilfe man ermittelt, welche der gewünschten Testszenarien bereits ausgeführt wurden. Wichtiger als structural (code) coverage ist hierbei die functional coverage. Code coverage sagt nichts über den Kontext aus in dem ein Statement ausgeführt wurde. Mit code coverage kann man auch nicht feststellen, ob Zeile X genau dann ausgeführt wurde, während sich die FSM gerade im Zustand Y befindet. Gruß Marcus
helge schrieb: > Jim Lewis hat hier ganze Arbeit geleistet und die docu lässt auch keine > Fragen offen. Ich hab'schon vor Jahren mit Jim darüber argumentiert[1], dass VHDL schlicht nicht die Ausdrucksweise bietet, die /constrained random verification/ benötigt. Alle Lösungen für VHDL in Form von Bibliotheken sind mehr schlecht als recht angeflanscht. Grüße Marcus Footnotes: [1] http://groups.google.com/group/comp.lang.vhdl/msg/f77132730e5d41c6?hl=en
Wie ist denn nun der Stand bezüglich der coverage Geschichte? Falls Fritz noch mitliest ...
Mr. Zulu schrieb: > Wie ist denn nun der Stand bezüglich der coverage Geschichte? > > Falls Fritz noch mitliest ... Mit dem "für Arme" Teil habe ich mich nicht weiterbeschäftigt. In ein paar Wochen treffe ich aber einen aus der osvvm.org Usergroup. Mal sehen was der zu berichten weiß. Code-Coverage mit modelsim konnte ich antesten. Ging schnell ist aber ernüchternd. Die Simulation überdeckt den gesamten Code, was aber nicht heisst das alles implentiert wurde oder es unter allen Umständen funktioniert. Eine TB mit Stimuli aufzusetzen die jede zeile "ausführen lässt" schafft man auch mit manuellen Durchlesen des Codes, solange es man strukturiert macht: jede Verzweigung anschauen bspw "(if a = 23) then" Dann testcase spezifiezieren (bspw im Dokument testspezifikation schreiben "#Test042: Einagng a auf 23 testen, Ausgang auf wert f(23) testen); schließlich implementieren Code coerage hat im ASIC Bereich sicher seine berechtigung ich würde aber die tools dafür nicht überbewerten. MfG,
Fritz Jaeger schrieb: > Code-Coverage mit modelsim konnte ich antesten. Ging schnell ist aber > ernüchternd. Die Simulation überdeckt den gesamten Code, was aber nicht > heisst das alles implentiert wurde oder es unter allen Umständen > funktioniert. Code- und Expression-Coverage testet NICHT ob du dein Pflichtenheft erledigt hast. Kann es ja auch nicht. Aber es hilft dir darin, das alles was implementiert ist vollständig getestet ist, inkl. allen seltenen Fällen abseits vom meistens auftretenden Nutzungsfall. Und es ist auch wichtig, dass es für den Entwickler schnell und einfach geht, sonst wird diese Funktion im Simulator auch nicht genutzt. Habe das für meine Designs hier mit dem Active-HDL angetestet (Test-Lizenz). Hat mir sehr gut gefallen, da die Auswertung auch übersichtlich und, aus meiner Sicht, aussagekräftig war (VHDL Source grün und rot einfärben für Code-Coverage). Leider wurde mein Antrag zum Kauf abgelehnt. Fehlervermeidung ist immer so schwer in Geldwert auszudrücken. ("Brauchst du das zwingend zum Arbeiten?" - "Nein, aber es hilft mir meine eigenen Fehler zu finden" - "Abgelehnt. Jemand soll ein Code-Review machen" Das hat bis heute nicht stattgefunden). Fritz Jaeger schrieb: > Eine TB mit Stimuli aufzusetzen die jede zeile "ausführen > lässt" schafft man auch mit manuellen Durchlesen des Codes, solange es > man strukturiert macht: Um das geht es ja gerade. Wir alle machen hin und wieder Fehler oder sind nicht zu jeder Uhrzeit genau gleich strukturiert. Dafür soll die Code- und Expression-Coverage da sein: Den Entwickler unterstützen damit der Entwickler sicherer sein kann seine Arbeit korrekt gemacht zu haben.
Christoph Z. schrieb: > Aber es hilft dir darin, das alles was implementiert ist vollständig > getestet ist, inkl. allen seltenen Fällen abseits vom meistens > auftretenden Nutzungsfall. Genau das leistet Code Coverage (CC) nicht. Wie ich oben schon beschrieben hatte, werden Informationen nicht in Beziehung zueinander gesetzt. Vom Verifikationsstandpunkt ist CC ziemlich wertlos. Besser als gar nichts, aber nicht viel besser. Ich könnte das auch sarkastischer formulieren: CC hilft dabei Teile des Source Codes zu identifizieren, die bereits durchlaufen wurden, also vermutlich nicht vollkommen funktionslos sind. -- Marcus
Marcus Harnisch schrieb: > Vom Verifikationsstandpunkt ist CC ziemlich wertlos. Besser als gar > nichts, aber nicht viel besser. Und darum soll ich mit "nichts" mein Zeugs hier entwickeln? Ich arbeite hier im Worst-Case: Selbe Person macht das Design und die Verifikation. Ich nehme alles was ich kriegen kann, damit ich nicht über meine eigenen Füsse (menschlichen Schwächen) falle. Marcus Harnisch schrieb: > Genau das leistet Code Coverage (CC) nicht. Wie ich oben schon > beschrieben hatte, werden Informationen nicht in Beziehung zueinander > gesetzt. Deine grundsätzliche Kritik verstehe ich und kann ich nachvollziehen. Ein kurzer Abriss wo bei ASICs/FPGAs der aktuelle Stand des Denkens ist gibt dieser gute Blog Artikel von Brian Bailey: http://webcache.googleusercontent.com/search?q=cache:p0LfpYBeAzkJ:www.programmableplanet.com/author.asp%3Fsection_id%3D2010%26doc_id%3D257477+&cd=4&hl=en&ct=clnk&gl=ch&client=firefox-a Marcus Harnisch schrieb: > Code coverage sagt nichts über den Kontext aus in dem ein Statement > ausgeführt wurde. Mit code coverage kann man auch nicht feststellen, ob > Zeile X genau dann ausgeführt wurde, während sich die FSM gerade im > Zustand Y befindet. Wenn ich Brian Bailey richtig verstehe, kann das bis jetzt keine Technik sicherstellen. (Testen mit Randomization ist ein guter Ansatz, nutze ich auch. Dokumentieren ob wirklich alles getestet wurde, Traceability, scheint hier das Problem zu sein).
Christoph Z. schrieb: > Ein kurzer Abriss wo bei ASICs/FPGAs der aktuelle Stand des Denkens ist > gibt dieser gute Blog Artikel von Brian Bailey: Na ja, viel geredet, wenig gesagt. Vor allem hat er einen der Hauptvorteile von Constrained Random nicht erwähnt, den Fritz bereits weiter oben aufgeführt hat: Es werden eben auch jene Fälle getestet, an die der Mensch eben gar nicht gedacht hat. > Marcus Harnisch schrieb: >> Mit code coverage kann man auch nicht feststellen, ob >> Zeile X genau dann ausgeführt wurde, während sich die FSM gerade im >> Zustand Y befindet. > > Wenn ich Brian Bailey richtig verstehe, kann das bis jetzt keine Technik > sicherstellen. Ich kann selbstverständlich alle Zustände (auch Zustandsübergänge) der FSM mit allem möglichen anderen Input kreuzen, und mir anschauen, ob alle von mir gewünschten Fälle getestet wurden. Brian Bailey wites > [Functional coverage] also does not verify that actual results checking > occurred or was even possible based on the recorded coverage events Dass Coverage die Funktion der Testbench garantiert ist auch gar nicht ihre Aufgabe, obwohl sie dabei helfen kann. Man kann natürlich auch Zustände der Testbench aufzeichnen lassen, z.B. ob ein Vergleicher, der keinen Fehler gemeldet hat, im Test überhaupt aktiviert wurde.
:
Bearbeitet durch User
Marcus Harnisch schrieb: > Es werden eben auch jene Fälle getestet, an > die der Mensch eben gar nicht gedacht hat. Genau, darum finde ich das auch wichtig Randomization zu nutzen. Derzeit mache ich das vor allem so, dass ich definiere was sicherlich nie passieren darf und schreibe Checks dazu bzw. baue einen Überwacher (z.b für eine bestimmte Art Ausgänge). Dann lasse ich genügend Zufallswerte auf die Eingänge prasseln. Die eigentlich geforderte Funktionalität teste ich dann mit direkten Tests, Input anlegen, Testen auf geforderten Output. Da wäre sicher noch Raum zur Optimierung vorhanden. Die Testabdeckung reicht bisher jedenfalls, so dass noch kein böser defekt in der Leistungselektronik passiert ist und dass unsere Firmwareentwickler meine FPGA Sachen nutzen können und dann kleine Änderungen, meistens in der Spezifikation, vorgenommen werden. Marcus Harnisch schrieb: > Ich kann selbstverständlich alle Zustände (auch Zustandsübergänge) der > FSM mit allem möglichen anderen Input kreuzen, und mir anschauen, ob > alle von mir gewünschten Fälle getestet wurden. Diese Aussgage finde ich spannend. Wie machst du das in der Praxis? Also hast du das in deiner Testbench alles automatisiert?
Christoph Z. schrieb: > Also hast du das in deiner Testbench alles automatisiert? Ja klar, sonst geht das gar nicht. Dazu nimmt man eben eine HVL (Hardware Verification Language) und definiert das alles[1]. Auch ein Referenzmodell der simulierten Schaltung wird damit implementiert. Am Ende lässt man den Simulator so lange arbeiten, bis man alle interessanten Fälle getestet hat. Footnotes: [1] Zu versuchen, etwas annähernd vergleichbares in VHDL oder Verilog (IEEE1364) nachzubauen ist vertane Zeit.
Marcus Harnisch schrieb: > [1] Zu versuchen, etwas annähernd vergleichbares in VHDL oder Verilog > (IEEE1364) nachzubauen ist vertane Zeit. Das impliziert allerdings, dass man die Verfikation komplett im Simulator, also "soft" erledigen kann und will. Wie sieht es diesbezüglich mit hardware-acceleration aus? Lässt sich das auch noch damit bewerkstelligen? Ein weiterer Punkt: Erstellt man Modelle und Stimuli in VHDL, lassen sich diese auch in das FPGA integrieren und Selbsttests konstruieren, bzw das System in Form eines Komplements als Trigger/Stimulator für andere Systeme verwenden.
:
Bearbeitet durch User
Die üblichen HVL haben selbstverständlich Interfaces zu Emulatoren. Verifikation != Selbsttest. Letzterer ist auch nur ein Teil der Schaltung und muss seinerseits verifiziert werden. Aber was ich eigentlich mit meiner Anmerkng sagen wollte, ist dass die genannten Sprachen selbst nicht die Konstrukte bereitstellen, um derart abstrakte Zusammenhänge sinnvoll zu beschreiben. Natürlich kann man sich was basteln, aber der nötige Aufwand rechtfertigt den Nutzen kaum. Oder willst Du per Hand alle zigtausend Zähler definieren, mit zu beobachtenden Signalen verbinden, parametrieren und auswerten?
Marcus Harnisch schrieb: > Die üblichen HVL haben selbstverständlich Interfaces zu Emulatoren. Was könntest Du da empfehlen? Marcus Harnisch schrieb: > Natürlich kann man sich > was basteln, aber der nötige Aufwand rechtfertigt den Nutzen kaum. Kommt drauf an. Wenn es ein eine überschaubare Menge ist, hat man sich die doppelte Arbeit gespart. Falls es ein so komplexes Szenario ist, mit "tausenden Signalen" (und Zuständen), wie Du es beschrieben hast, ist das freilich was anderes. Man muss halt immer überlegen, was man wo investiert.
Marcus Harnisch schrieb: > Aber was ich eigentlich mit meiner Anmerkng sagen wollte, ist dass die > genannten Sprachen selbst nicht die Konstrukte bereitstellen, um derart > abstrakte Zusammenhänge sinnvoll zu beschreiben. Wahrscheinlich war das der Grund, dass PSL in den VHDL-2008 Standard eingebaut wurde. (Also: "VHDL-2008 now includes the simple subset of PSL as part of the standard VHDL syntax." http://www.doulos.com/knowhow/vhdl_designers_guide/vhdl_2008/vhdl_200x_major/) Würde das jetzt schon ausreichen für deine Beipspielhaft genannten Fälle, oder brauchts immer noch mehr als das, was VHDL-2008 hergibt?
Jürgen Schuhmacher schrieb: > Was könntest Du da empfehlen? Na ja, tatsächlich gibt es aktuell nur zwei HVL, die durch die jeweiligen Hersteller unterstützung bekommen: SystemVerilog (bzw. dessen spezielle Konstrukte zur Verifikation), das von allen nennenswerten Herstellern implementiert wird, und Specman/e von Cadence. > Marcus Harnisch schrieb: > Falls es ein so komplexes Szenario ist, mit > "tausenden Signalen" (und Zuständen), wie Du es beschrieben hast, ist > das freilich was anderes. Ein Beispiel: Mach Dir mal eine Liste, was Du alles benötigst um lediglich alle legalen Pfade durch eine FSM zu covern, also sicherzustellen, dass die FSM vollständig durchlaufen wurde. Bonus: Verweilen in einem Zustand muss natürlich auch dabei sein, aber nur in Form von flexibel definierbaren Bereichen, 1 Takt, mehrere Takte, lange. Ich habe mal Code eines mittelgroßen Projekts ansehen müssen, in dem die Entwickler gezwungenermaßen (sehr einfache) Coverage nachbauen mussten. War nicht schön und nahezu unwartbar. Und dann hast Du mit der händischen Implementierung auch noch nicht das Problem der Auswertung gelöst. Rot-gelb-grüne Ampel anzeigen und so. Mal eben umschalten zwischen Coverage pro Instanz gegenüber der Coverage pro Modul/Architecture, oder ähnliches.
Christoph Z. schrieb: > Wahrscheinlich war das der Grund, dass PSL in den VHDL-2008 Standard > eingebaut wurde. > > Würde das jetzt schon ausreichen für deine Beipspielhaft genannten > Fälle, oder brauchts immer noch mehr als das, was VHDL-2008 hergibt? PSL dient der Assertion Based Verification (ABV). Damit kann man zeitliches Verhalten formal darstellen (ähnlich wie regular expressions nur eben über zyklen statt Zeichen), und zum Beispiel Fehler ausgeben wenn das tatsächliche Verhalten davon abweicht. Man kann das -- soweit vom tool unterstützt -- auch zur Sammlung von Coverage verwenden. ABV ersetzt aber keine Coverage, sondern liefert nur einen Beitrag. In einer händischen Coverage Implementierung kann es helfen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.