Gibt es eine "Standard" -Methode, um HDL einer Zustandsmaschine zu überprüfen?

Zustandsmaschinen sind ein Muster, das sehr häufig beim Schreiben von synchronen Designs verwendet wird. Sie dienen als Controller im Design. Gibt es also eine Standardmethode, um sie zu überprüfen, ob sie mit VHDL oder Verilog/SystemVerilog geschrieben wurden? Oder ist es besser, sie mit einer GUI zu zeichnen und dann stattdessen Code aus der GUI zu generieren?

Standardmäßig meine ich ein Codemuster, das verwendet wird, um sie zu verifizieren. Es gibt immer verschiedene Möglichkeiten, die Katze zu „häuten“, aber vielleicht gibt es eine Methode, die sehr beliebt ist.

Die Sache ist, dass Zustandsmaschinen ziemlich groß sein können und man Code schreiben müsste, um jeden Zweig in der Zustandsmaschine zu verifizieren, was zu viel Code in der Testbench führt.

Bearbeiten: Ich überprüfe nur den fsm selbst, um zu überprüfen, ob er mit dem fsm-Zustandsdiagramm übereinstimmt und keine Fehler in der RTL-Codierung vorhanden sind.

Ich bin gespannt, was andere dazu sagen. Ich habe viele Zustandsautomaten geschrieben, aber nein, ich habe keinen Standard-Verifizierungsprozess. Für mich ist das Schreiben von HDL zum Implementieren eines bestimmten Zustandsmaschinendesigns nicht wirklich der schwierige Teil – der schwierige Teil besteht darin, sicherzustellen, dass das Design der Zustandsmaschine selbst das Verhalten aufweist , das die Anwendung unter allen möglichen Eingabekombinationen erfordert.
Ich dachte, wenn ein spezielles GUI-Tool dafür existiert und wir es verwenden, können wir davon ausgehen, dass der Code korrekt ist, solange das Zustandsmaschinendiagramm korrekt ist. Wie Sie bereits betont haben, ist das Schreiben des gesamten Testbench-Codes zum Überprüfen aller möglichen Routen, die der Zustandsautomat nehmen muss, selbst für einfache Zustandsautomaten ärgerlich. Das Hauptproblem ist, wenn ich merke, dass die Zustandsmaschine geändert werden muss und dann der Code neu geschrieben oder geändert werden muss. Es ist langweilig.
Nun, im Grunde habe ich vor einiger Zeit einen Kurs in Comprehensive VHDL von Doulos in Großbritannien gemacht. Es war ein fantastischer Kurs. Darin lehrten sie auch, wie man Zustandsmaschinen in VHDL schreibt. Die Idee war, die synchronen Prozesse, die den nächsten Zustand dem aktuellen Zustand zuweisen, von dem asynchronen (nicht taktenden) Prozess zu trennen, der den Wert für den nächsten Zustand aus dem aktuellen Zustand und den aktuellen Eingaben generiert . Das war sehr interessant, da es viele Fallstricke im Design von Zustandsmaschinen beseitigt. Während sie jedoch ausschließlich das Design von Zustandsmaschinen abdeckten, gilt dies nicht für die Verifizierung von Zustandsmaschinen.
Stateflow von MathWorks ist ein GUI-Tool zum Codieren von FSMs.
@quantum231 ModelSim von Mentor Graphics definiert auch die Finite-State-Machine-Coverage, die für die State- und State-Transition-Coverage verwendet wird. Siehe meine Antwort für weitere Details.
Ja, ein einheitlicher Ansatz zur Verifizierung von FSMs ist unter diesem Link zu finden: verificationacademy.com/verification-horizons/…
Der bessere Weg ist die formale Überprüfung! Ich habe meine Antwort aktualisiert, nachdem ich es selbst ausprobiert hatte. Machen Sie sich keine Sorgen mehr um diesen Eckfall!
In Ordnung Shashank bhai. Ich habe versucht zu lesen, wie man tatsächlich eine formale Überprüfung durchführt. Ich bin auf das Konzept der Verwendung von Eigentum und Behauptung (SVA oder PSL) gestoßen. Ich habe eine Erwähnung von Logic Equivalence Check gefunden. Ich fand auch Erwähnung von Model Checking. Ich stieß auf den Namen eines Programms namens Jasper. In all dem konnte ich jedoch nichts finden, was mir sagt, wie ich selbst mein Design formal überprüfen kann. Ich wünschte, Formal würde auch auf Universitätsniveau gelehrt.

Antworten (2)

Die Verifizierung ist ein großer Teil des Designprozesses; Bei einem komplexen Design ist es nicht ungewöhnlich, dass Sie genauso viel Zeit oder sogar mehr Zeit für die Überprüfung aufwenden als für das eigentliche Design. In Anbetracht dessen ist eine Frage, bei der es sich im Wesentlichen um die Frage „Wie verifiziert man komplexe Konstruktionen“ handelt, ziemlich weit gefasst.

Wenn das Design eine große Anzahl von Szenarien bewältigt, was durch sehr viele Zustände in Ihrem Zustandsautomaten angezeigt wird, wäre es ein guter Ausgangspunkt für die Testsuite, separate Tests zu haben, die das Design stimulieren, um alle zu replizieren diese Szenarien. Sie können dann Codeabdeckungstools verwenden, um zu sehen, welche Zustandsübergänge abgedeckt wurden, und neue Tests hinzufügen, bis alles abgedeckt ist. configurationMit dem Konstrukt in VHDL können Sie verschiedene Testfälle verwalten

Es kann häufig der Fall sein, dass es Szenarien gibt, die Variationen eines Themas sind, z. B. das Empfangen eines Pakets irgendeiner Art, aber mit unterschiedlichen Paketlängen, Längen, die außerhalb der Grenzen liegen usw. In diesen Fällen können Sie Tests schreiben, die generieren eine Anzahl von Paketen mit zufälliger Länge; Sie müssten dann sicherstellen, dass alle Ihre Grenzfälle erfüllt sind, zum Beispiel die Mindest- und Höchstlängen, das Minimum plus eins, das Maximum minus eins usw., und dass Ihr Design in jedem Fall das Richtige tut. Möglicherweise müssen Sie auch Kombinationen von Eingaben für das Design testen, und diese Kombinationen könnten wiederum durch einen Testfall generiert werden, anstatt sie einzeln manuell zu schreiben.

Es gibt eine Reihe von Methoden, die versuchen, den Prozess der Generierung von Stimuli und der Aufzeichnung der Ergebnisse zu steuern. Ich verwende OSVVM , das ich vor ein paar Jahren durch einen Kurs kennengelernt habe. Ich mag es, weil es die gleiche VHDL-Sprache verwendet, die ich gewohnt bin, zusammen mit ein wenig TCL-Skripting, und keine "Extras" benötigt, um mit meinem Simulator zu arbeiten. Es gibt viele Alternativen, die ich hier nicht aufzulisten versuche, aber eine schnelle Google-Suche nach „FPGA-Verifizierung“ bringt eine Menge Ressourcen hervor.

Ich meinte nur, die Zustandsmaschine selbst zu testen, dass ihr Verhalten mit dem Zustands-fsm-Diagramm übereinstimmt
Der beste Weg, es zu testen, ist als Teil des Systems, das es steuert. Wenn Sie es isoliert testen, riskieren Sie, es nicht mit dem gleichen Stimulus zu versorgen, den es im realen System erhält. Sie müssen sowieso einen Prüfstand für das System als Ganzes erstellen , also können Sie genauso gut einen Prüfstand bauen, der alles kann.

Ich empfehle die Verwendung formaler Verifizierungstechniken.

Schreiben Sie 2 Behauptungen:

  1. Behauptungen, um zu überprüfen, ob jeder Zustandsübergang unter der richtigen Bedingung auftritt.
  2. Behauptungen, um jeden Ausgangsübergang nur im beabsichtigten Zustand zu überprüfen.

Manchmal können Sie eine einzelne Assertion schreiben, um die gesamte FSM-Funktionalität zu überprüfen, wie ich es hier getan habe: https://electronics.stackexchange.com/a/505842/238188

Zeichnen Sie kleinere FSMs in eine GUI und generieren Sie HDL-Code oder generieren Sie das Zustandsübergangsdiagramm aus dem HDL-Code und untersuchen Sie das Diagramm.

Mir sind 2 Lösungen für diese 2 Fälle bekannt:

  1. StateFlow von MathWorks kann den HDL-Code aus einem Zustandsmaschinendiagramm generieren.
  2. ModelSim von Mentor Graphics verfügt über einen integrierten FSM-Viewer, um die vom HDL generierte Zustandsmaschine anzuzeigen.
Gibt es eine "Standard" -Methode, um HDL einer Zustandsmaschine zu überprüfen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v