Hallo, möchte für eine in VHDL beschriebene Schaltung eine Fault Simulation für stuck-at faults durchführen. Gibt es hierzu Tools, die direkt auf Basis des VHDL-Codes eine solche Simulation machen können?
SebKro schrieb: > eine Fault Simulation für stuck-at faults durchführen Was meinst du damit genau? Dass ein Signal länger als erlaubt auf einen Pegel oder in einem Zustand festhängt? > Gibt es hierzu Tools, die direkt auf Basis des VHDL-Codes eine solche > Simulation machen können? Das sollte jeder Simulator mit der passenden Testbench hinbekommen...
:
Bearbeitet durch Moderator
Mit stuck-at faults meinte ich dass ein Signal dauerhaft auf einem Pegel festhängt. Die Simulation der Fehler als solches, sollte in der Tat mit jedem VHDL-Simulator durchführbar sein. Was ich suche ist eine Möglichkeit, alle solche Fehler, die in einer Schaltung vorkommen könnten sowie die anzulegenden Testpattern zu deren Detektion automatisiert zu bestimmen.
SebKro schrieb: > Mit stuck-at faults meinte ich dass ein Signal dauerhaft auf einem Pegel > festhängt Auch interne Signale?
Eine solche "Möglichkeit" existiert nicht. Es wäre wie ein Programm, dass das Halteproblem (siehe Informatik) löst. In der Informatik nennt man solche Probleme Entscheidungsprobleme, und eben diese sind iA nicht lösbar. Beliebt neben dem Halteproblem ist z.B. der Wunsch der Entscheidbarkeit: "Ist mein Programm/Design korrekt?" Du kannst aber viele Probleme in HDL auf vielerlei Weise systematisch analysieren, z.B. auch Zustandmaschinen und deren Verbleib in Endlosschleifen etc. Dafür gibt's viele Algorithmen, die sich ohne Probleme in eine Simulation giessen lassen. Das wirst du aber selber machen müssen.
Mentor Graphics bewirbt gerade (wieder einmal) seinen HyperFault. Soweit mir bekannt, kann der aber nur Verilog. Musst also ein Verilog Compilat erstellen, am Besten über einen AutoCodeGenerator und HIL verwenden. Ich habe dazu mal ein Konzept für einen MIL-Hersteller gemacht, das auf System Generator und Simuling setzte. Die Simulation wird da durch real time Emulation gelöst, in dem alle Register ins RAM wanden und dies per dual Port mit Fehlern beschrieben wurde. Das ist naturgemäß ineffizient, weil alles durchgeackert werden muss. Eine richtige Fehlersimulationssoftware untersucht ja den Code und optimiert die Pfade bei der Analyse der Beobachtkarkeit. Aber: Wozu brauhst Du das? ASIC-Prototyping nehme ich an? Normalerweise sollte Dein ASIC Tool das integriert haben. Wir haben seinerzeit Cadence verwendet. Schau Dir mal Synopsis an. Die sind da eigentlich inzischen führend. Oder frag mal im ASIC-Forum. Hier wird Dir das keiner beantworten können, weil hier maximal FPGA-Gurus rumlungern und die brauchen sowas nicht. Wir untersuchen bestenfalls die funktionelle Sicherheit, nutzen Code Coverage etc. Fehlersimulation dient ja dazu, seine Testmengen dahingehend zu untersuchen, inwieweit sie geeignet sind, spätere reale stuck at Fehler zu erkennen, damit man Chips testen kann. Wir sehen bei der Entwicklung FPGAs als getestet und funktionabel an. Die Frage ist, wie die Hersteller das lösen. Ein Xilinx-Mann hat mir mal erklärt, dass sie in die FPGAs Testimages reinladen und alle Zellen toogeln. Die Config-Pfade werden ebenfalls getoggelt und die IOs per boundary scan gecheckt. Das ist aber 10 Jahre her und wer weiß, wie gut der informiert war.
was du machen kannst ist per synthese eine (asic-)netzliste generieren lassen, und dann einzelne standard-gates gegen fehlerhafte ersetzen
Sigi schrieb: > ine solche "Möglichkeit" existiert nicht. Es > wäre wie ein Programm, dass das Halteproblem > (siehe Informatik) löst. Hier geht es um was anderes. Bei der Fehlersimulation werden (theoretisch) alle erdenklichen Fehler in die Schaltung injiziert und untersucht, welche Beobachtbarkeit = Sichtbarkeit des Fehlers sich ergibt. Eine gute Sichtbarkeit ist dann gegeben, wenn der Fehler ohne oder mit wenigen Takten an möglichst vielen Ausgängen der Schaltung sichtbar wird. Damit kann man entscheiden, mit welchen Eingangsvektoren = Folgen von Input-Bits man alle möglichen Zustandswechseln in der Schaltung erzeugen kann, sodaß eventuell kaputte Leitungen und Flipflops oder Gatter erkennbar sind. Das dient dem Test von einzelnen Chips in der Fertigung. Das Ziel dabei ist natürlich, möglichst viele Fehler mit ein und demselben Vektor / bzw Vektorfolge zu erwischen um eine möglichst hohe Testabdeckung zu erreichen. Der Einfachheit halber nimmt man die Fehler so an, dass es nur die Fehler 0 und 1 gibt und die Leitungen festhängen. Um dies dann zu untersuchen, macht man mit allen erdenklichen Fehlern jeweils einen Logiksimulation = Gutsimulation. Real ist das aber nicht mehr möglich, weil die Chips zu aufwändig sind. Daher hat man Algorithmen entworfen, die einen Fehler über die Annahme der Beobachtbarkeit in die Schaltung reintreiben und so den anregenden Vektor finden. Da gibt es viel Literatur und Disserationen zu. Wir hatten es damals mit einem gewissen D-Algorithmus zu tun und das Programm dazu hiess DALGO - kam von Siemens soweit ich mich errinnere. Ist aber auch schon über 20 Jahre her. Heute gibt es da sicher noch ganz anderes.
Jürgen S. schrieb: > Aber: Wozu brauhst Du das? ASIC-Prototyping nehme ich an? Ich schreibe gerade an meiner Masterarbeit, die sich u.a. mit Built-In Self-Test beschäftigt. Eine bereits vorhandene in VHDL beschriebene Schaltung soll getestet werden. Jürgen S. schrieb: > Das Ziel dabei ist natürlich, möglichst viele Fehler mit ein und > demselben Vektor / bzw Vektorfolge zu erwischen um eine möglichst hohe > Testabdeckung zu erreichen. Genau! Ich möchte mittels der Ergebnisse der Fehlersimulation letztendlich die Testabdeckung meines Ansatzes bestimmen.
Hallo, ich denke, das ist eine Aufgabe, da hat man entweder Zeit oder Geld. Für die zeitaufwändige Lösung, die meisten VHDL Simulatoren erlauben einen 'Force' auf einem Schaltungsknoten zu setzen. Theoretisch könnte man z.B. mit Perl, Tcl o.ä jeder Knoten nach '1' oder '0' klemmen und schauen, ob die Simulation das merkt. Allerdings muesste man vorher nachgewiesen haben, dass die ungestörte Simulation alle Knoten tatsächlich exerziert (Coverage). Für die teure Lösung, muesste denke ich eine Linting oder DfT-Analyse tool herangezogen werden (Aldec, Cadence, Mentor ....). Das muesste relativ schnell gehen. Netzlist laden, analyse starten, Ergebnis in wenigen Minuten. Eigentlich ist Deine Aufgabe eine statische Analyse: es geht darum die Beobachtbarkeit (observability) bzw. Steuerbarkeit (controlability) von jedem Knoten zu berechnen. Es gibt bestimmt auch irgendwo ein mehr oder weniger fertiger OpenSource Ansatz. Früher (so vor 15, 20 Jahren) zu meinen guten alten Siemens/Fujitsu-Siemens Zeiten hatten wir ein selbstgeschriebenes Programm namens 'Lasar' verwendet (Edif rein, Ergebnis raus). Ich war der Meinung die Quellen wären inzwischen irgendwo veröffentlicht, aber Yandex/Hulbee hat vorhin nichts gefunden. Vielleicht täusche ich mich auch, ich war nur Anwender und kein Entwickler von der besagten SW.... Übrigens, so viel ich weiss sind bei Kupfer Technologien eine Degradierung der Laufzeit zwischen den Knoten genau so ein Problem wie die 'Stuck At' Fehler. Viele aktuelle DfT Technologien implementieren Test Schaltungen um sog. 'At-Speed' Tests machen zu können, gerade im Bereich von internen Embedded Memories.
Um das jetzt wieder in die Entwicklung zurück zu treiben: Fehlersimulation ist etwas, was der Fertiger braucht und ansonsten bestenfalls der Fehlermanager, der Ausfälle untersuchen muss. Beim Entwicklen von Schaltungen ist daher darauf zu achten, daß man immer wieder Stufen einbaut, wo man Zwischenergebnisse rausholen und auch reinstecken kann und zwar auch solche, die nicht entstehen können. Damit finden sich sehr leicht Pfade, mit denen man einzelne Bereiche der Chips (auch FPGAs!!) testen kann. Wohlgemerkt "testen" und nicht "verifizieren", also Bausteinchen prüfen und nicht Richtigkeit der Schaltungsfunktion generell prüfen. Diese Methodik korreliert aber stark mit den heutigen Anforderungen der Prüfung der Funktion der Schaltung - insbesondere bei hohen Anforderungen bei MIL und MED. Will sagen: Wer Schaltungen baut, die den Regeln der funktionellen Sicherheit genügen, hat a) eine Art Sicherstellen der maximalen Funktion und b) Optionen, die Physik mitzustesten. Noch konkreter: Bei einem sehr hohen Mass an Festfunktionen in der Schaltung, also vielen debug-Elementen, sind die Pfade für Fehlererkennung sehr kurz und die Vektrogeneration trivial. Damit könnte man in den Raum stellen, daß das Thema "funktionale Sicherheit" das Thema "Fehlersimulaion" aus Entwicklersicht absorbiert. Ist aber keine offizielle Lehrmeinung, sondern nur (m)eine Freitagnachmittagsthese.
SebKro schrieb: > Ich schreibe gerade an meiner Masterarbeit, die sich u.a. mit Built-In > Self-Test beschäftigt. Eine bereits vorhandene in VHDL beschriebene > Schaltung soll getestet werden. Aha, da sind wir genau bei dem was ich oben schrieb. Die Frage ist jetzt, was an self test konkret realisiert wurde. Vielleicht liesse es sich ja so machen, wie weiter oben vorgeschlagen: Ein ModelSim Script, das mit forces arbeitet. Brauchst also ein C Programm, das alle Leitungen sucht und die do-files fürs ModelSIM raushaut und diesen startet.
Hallo, noch ein Gedanke... Wenn es hier um ein BIST Thema geht, bin ich mir nicht so sicher, ob der VHDL Ansatz die richtige ist. Wenn Du eine Schaltung in VHDL beschreibst ist es eigentlich zunächst ein Verhaltensmodel. BIST ist eigentlich ein Thema für Fertigung aber auf jeden Fall für eine physikalisch Schaltung. Die Synthese wird sicherlich Dein VHDL optimieren und möglicherweise viele Knoten wegoptimieren bzw zusammenlegen. Ich wage die Behauptung, ein BIST Programm das nur für die VHDL Codebasis entwickelt wurde, für das Silizium nicht ausreichen wird. Normalerweise ist der Ansatz so: über Scan-Ketten werden alle Flip-Flops zu virtuellen Pins. Über die statische controlability/oberservability Analyse ermittelt man den notwendigen Muster-Satz um jeden Fehler in der kombinatorischen Logik an einem Pin (physikalisch oder virtuell) beobachten zu können. will heissen, wenn es nicht nur um eine theoretische Studie geht, musst Du eigentlich auf eine synthetisierte Netzliste (Edif, Verilog, VHDL) aufsetzen.
cfgardiner schrieb: > Wenn es hier um ein BIST Thema geht, bin ich mir nicht so sicher, ob der > VHDL Ansatz die richtige ist. Wenn Du eine Schaltung in VHDL beschreibst > ist es eigentlich zunächst ein Verhaltensmodel. Nö, man kann Netzlisten in VHDL erzeugen, auch post-synthesis Simulation genannt.
Nö-Sager schrieb: >> Wenn es hier um ein BIST Thema geht, bin ich mir nicht so sicher, ob der >> VHDL Ansatz die richtige ist. Wenn Du eine Schaltung in VHDL beschreibst >> ist es eigentlich zunächst ein Verhaltensmodel. > > Nö, man kann Netzlisten in VHDL erzeugen, auch post-synthesis Simulation > genannt. Nun, ich denke, wenn du das Posting ganz durchlesen würdest, könntest du vielleicht die Hinweise auf VHDL Code Basis (Verhaltensmodel) und Netzliste (Edif, Verilog, VHDL) möglicherweise erkennen. Was war jetzt dein fachlicher Beitrag wieder? Ach ja, die Bingo-Phrase "post-synthesis Simulation". Darüber hinaus natürlich noch der Beweis, dass man eine Diskussion oberflächlich folgen kann und immer eine Stelle findet wo ein gekonntes hineinfurzen noch hörbar ist. Oder wie es Karl Valentin mal formuliert hat, "damit wäre wohl alles gesagt, nur noch nicht von jedem" Nö-Sager ? ... Nomen est Omen
Moin, sowas geht mit den mir bekannten VHDL-Simulatoren nicht ohne externe Co-Simulationsroutinen, die Callbacks unterstützen. Das ganze wird so oder so recht hässlich, weil man sich u.U. mit Multithread-Eigenheiten herumschlagen muss. Mit den $$$-Tools geht das sicher, aber es gibt für die Forschung eine viel elegantere Lösung. Guck dir mal MyHDL und dessen Simulationskonzept an, da lässt sich relativ viel einbauen. Gerade Zufalls-Fehler-Injektionen sind damit ein Klacks. Gruss, - Strubi
Jürgen S. schrieb: > Schau Dir mal Synopsis an. Die sind da > eigentlich inzischen führend. Danke für den Tipp! TetraMax ATPG von Synopsys hört sich ziemlich genau nach dem an, was ich suche. Mal sehen, ob an meinem Lehrstuhl eine Lizenz dafür vorhanden ist. Jürgen S. schrieb: > Die Frage ist > jetzt, was an self test konkret realisiert wurde. Es wird eine angepasste Version von Circular BIST werden. Jürgen S. schrieb: > Vielleicht liesse es > sich ja so machen, wie weiter oben vorgeschlagen: Ein ModelSim Script, > das mit forces arbeitet. Brauchst also ein C Programm, das alle > Leitungen sucht und die do-files fürs ModelSIM raushaut und diesen > startet. Keine schlechte Idee. Falls ich keine andere automatisierte Lösung finden sollte, wäre diese sicherlich ein Kandidat. cfgardiner schrieb: > Wenn es hier um ein BIST Thema geht, bin ich mir nicht so sicher, ob der > VHDL Ansatz die richtige ist. Kann gut sein, dass VHDL vielleicht nicht optimal geeignet ist. Da die final zu testende Schaltung (ein Teil des LEON3 um genauer zu sein) aber in VHDL gegeben ist, bin ich in der Richtung schon ziemlich festgelegt. > [...] will heissen, wenn es nicht nur um eine theoretische Studie geht [...] Es handelt sich in der Tat eher um eine theoretische Studie. Zumindest wird wohl am Ende der Arbeit kein fertiges ASIC Design stehen. Strubi schrieb: > Guck dir mal MyHDL und dessen > Simulationskonzept an, da lässt sich relativ viel einbauen. Danke für den Tipp! Werde ich mir auch mal anschauen.
Halt uns bitte auf dem Laufenden. Wäre gut, wenn mal so eine Arbeit publiziert / hier gelinkt würde, wenn es fertig ist,
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.