Ich habe eine Frage zum Umgang mit x in Verilog-Netzlistensimulationen. Ich habe eine Meinungsverschiedenheit mit einem anderen Ingenieur (der etwas älter ist als ich) darüber, was der richtige Ansatz ist. Obwohl diese Frage meinungsbasiert erscheinen mag, denke ich, dass es eine richtige Antwort gibt, auch wenn die Ansichten geteilt sind.
Ich entwickle für Mixed-Signal-ASICs. Ich mache Netzlistensimulationen eines Mikroprozessors, dessen Programmregister nicht zurückgesetzt werden (es ist ein ARM Cortex-M3, es gibt eine Option, um die Register während der Synthese nicht zurücksetzen zu lassen).
Wir haben ein ROM, von dem der Prozessor nach dem Zurücksetzen mit der Ausführung beginnt. Während dieser Programmausführung enthält ein Programmregister (R6) x, da es nicht zurückgesetzt wurde. An einem Punkt in der Simulation breiten sich x aus diesem Register wie ein Lauffeuer durch den Rest des Designs aus und unterbrechen die Simulation. Wir sehen dieses Problem in RTL-Simulationen nicht.
Ich würde es vorziehen, eine Designänderung vorzunehmen, um zu bewirken, dass die Register zurückgesetzt werden, oder das ROM-Programm als erstes Nullen in diese Register schreiben zu lassen. Mein College ist sehr widerspenstig, Designänderungen vorzunehmen, um diese x zu beseitigen, und er würde es vorziehen, sie irgendwie in der Simulation zu maskieren.
Seine Behauptung ist, dass die "x's nicht real sind, weil x's in echter Hardware nicht existieren". Er kommt daher zu dem Schluss, dass die x in der Simulation nicht real sind und dass alle darauf basierenden Designänderungen keine gute Sache oder zumindest eine viel zu extreme Reaktion sind.
Meine Behauptung ist, dass, obwohl es zweifellos wahr ist, dass x in Hardware nicht existieren, sie unbekannte oder unvorhersehbare Werte darstellen. Ich glaube, die Gate-Bibliothek modelliert x, um sich pessimistisch zu verbreiten. Wenn sich also x verbreiten, um die Simulation zu beenden, deutet dies darauf hin, dass eine Kombination von Bits ein Problem verursachen könnte. Da dies eine Möglichkeit ist, sehe ich es nicht als zu extrem an, eine Designänderung vorzunehmen, um die x zu entfernen, selbst wenn ich nicht beweisen kann, dass sie absolut echt sind. (Ich nehme an, ich könnte versuchen, nach der schlechten Kombination von Bits zu suchen, aber das wäre eine Menge Arbeit.)
Nun kann ich mir als Antwort vorstellen, dass der richtige Ansatz davon abhängt, welche Art von Qualität hier entwickelt wird. Aber ich denke, dass die von mir vorgeschlagenen Designänderungen (Hinzufügen der Resets oder Löschen im Programm) sehr wenig kosten (insbesondere das Modifizieren des ROM-Programms). Ich denke, dass das Maskieren der Bits in der Simulation viel arbeitsintensiver wäre.
Was könnte ich aus seiner Sicht missverstehen? Was ist der beste Ansatz? Ist es wirklich so schlimm, eine Designänderung für ein Problem vorzunehmen, von dem Sie nicht beweisen können, dass es absolut real ist?
Ich nehme an, es hängt davon ab, wo sich die x's im Design befinden.
Nehmen Sie ein beispielhaftes Kommunikationsschema innerhalb des Chips. Möglicherweise möchten Sie Daten zwischen zwei Komponenten weitergeben, aber sagen wir nicht bei jedem Taktzyklus. Sie könnten sich dann für einen Datenbus und ein gültiges Signal entscheiden. Das gültige Signal gibt an, wann die Daten gültig sind. Aus diesem Grund spielt der Wert des Datensignals keine Rolle, wenn das gültige Signal niedrig ist (weil es ignoriert wird).
In diesem Beispiel wird das Design niemals etwas Unerwartetes tun, solange das gültige Signal niemals ein egal ist . Das Datensignal kann egal sein, es spielt keine Rolle, weil Sie immer wissen, dass es gültige Daten (was auch immer es sein mag) geben wird, wenn das gültige Signal hoch ist.
Wenn das gültige Signal jemals egal war, dann haben Sie ein Problem. Warum? weil es bedeutet, dass Sie ein Szenario haben, in dem Sie keine Ahnung haben, was passieren wird. Dies kann ein Problem verursachen oder auch nicht, aber Junge, ist es ein Alptraum, es aufzuspüren.
Also in Anbetracht dessen bin ich der Meinung:
xWenn Sie in einem Datenbus auf 's stoßen , ist das nicht das Ende der Welt, in Wirklichkeit wissen Sie sowieso nicht, was die Daten zu einem bestimmten Zeitpunkt sein werden.
Wenn sie in Steuersignalen erscheinen, kann es schlecht sein oder nicht, Sie wissen es nicht. In dieser Situation sollten Sie Ihre Simulation zweimal ausführen, einmal sicherstellen, dass don't care auf 0 gesetzt wird, und ein zweites Mal sicherstellen, dass es eine 1 ist. Auf diese Weise wissen Sie, was in beiden Fällen passieren wird .
Wenn Sie nicht sicher sein können (dh anhand des von Ihnen geschriebenen Codes), dass ein don't care keine Probleme verursacht, sollten Sie ihn nicht ignorieren, da es sich um xeine unbekannte potenzielle Katastrophe handelt. Wenn Sie wissen, dass der Wert an einem bestimmten Punkt keine Rolle spielt, xist dies vollkommen gültig.
Außerdem sollten alle Steuerregister, wofür auch immer sie sind, beim Zurücksetzen auf einen Wert initialisiert werden. Ein nicht initialisiertes Steuerregister beim Einschalten könnte katastrophal sein. Stellen Sie sich vor, Sie bauen ein Kontrollsystem zum Abfeuern von Atomwaffen und haben das „Start“-Register nicht auf 0 initialisiert. Wenn Sie den Strom einschalten, könnten Sie nach allem, was Sie wissen, den 3. Weltkrieg starten.
Es gibt viele verschiedene Ursachen für den X- Zustand in einer Simulation, aber leider werden sie alle durch einen Zustand in Verilog dargestellt. VHDL hat den U- Zustand, um einen nicht initialisierten Wert darzustellen. Dies hat möglicherweise keine physikalische Darstellung in Hardware, ist aber neben dem Spannungspegel des Signals sicherlich eine echte Eigenschaft eines Hardwaredesigns.
Eine genaue Ausbreitung des X-Zustands ist in der dynamischen Simulation für jede RTL oder Netzliste schwierig. Vielleicht möchten Sie sich zu diesem Zweck formale Tools ansehen - insbesondere für die Überprüfung des Zurücksetzens. Sie sind für diese Anwendung gut geeignet, um alle Kombinationen erschöpfend nachzuweisen.
Was die Kosten betrifft, die mit dem Hinzufügen von Reset-Logik verbunden sind, sind Designs in ihrer Spezifikation immer an einer Art Grenze; Leistung, Fläche, Funktionen. Sie möchten also sicherlich keine unnötige Logik hinzufügen, damit Ihre Netzlistensimulation funktioniert. Einige Simulatoren ermöglichen es Ihnen, die Logik zufällig zu initialisieren, sodass Sie zumindest ein gewisses Maß an Vertrauen gewinnen können, bevor Sie versuchen, die X zu maskieren.
Wenn Sie Code ausführen, der von einem 'C'-Compiler (anstelle von Raw-Assembler) auf einem ARM-Kern generiert wurde, werden Sie wahrscheinlich Probleme mit Netzlistensimulationen haben, es sei denn, Sie beginnen mit der Initialisierung der Registerbank. Je nachdem, wie aggressiv der Compiler war, müssen Sie möglicherweise alle Zustände initialisieren (und dies wird dann riskant).
Das offensichtlichste Problem besteht darin, dass Flag-Setting-Operationen an initialisierten Registern einen ziemlich harmlosen Datenpfad X auf eine Weise in den Steuerpfad verschieben, die nicht immer harmlos ist. Dies sollte in vernünftigerweise handgeschriebenem Code nicht passieren, aber der 'C'-Compiler hat (glaube ich) die Freiheit, Operationen neu zu ordnen und manchmal Dinge zu tun, bei denen er das Ergebnis ignoriert. Die RTL verhält sich konsistent, wenn ihr eine willkürliche numerische Eingabe gegeben wird, reagiert aber manchmal schlecht, wenn ihr X als Datenwert gegeben wird.
Sobald Sie eine Prefetch-Logik haben, die X-Daten ausgesetzt ist, ist es nicht schwer vorstellbar, dass mehr Steuerlogik ein X-Ergebnis anstelle eines schnellen/langsamen Leistungsverhaltens erzeugen kann.
RTL wird häufig so geschrieben, dass es X-pessimistisch ist, sodass alle X-Werte (die unbekannte Werte darstellen) durch ein Design geleitet werden.
Wenn Ihre Tests ausgeführt werden, ohne die Registerbank in Ihrem Init-Code auf 0 zu initialisieren, lassen Sie es so. Auf diese Weise ist es wahrscheinlicher, dass Sie ein Problem erkennen (z. B. das Ausführen des Code-Image in die Ausführung von Daten). Verzweifeln Sie nicht, wenn Sie einige Register in der Software initialisieren müssen, nur um auf einer Netzliste zu laufen.
Wenn Sie feststellen, dass Ihre Netzliste beim Zurücksetzen alle Flops initialisieren muss, müssen Sie die Kerndokumentation (Integrationshandbuch) überprüfen und bei Bedarf den Support kontaktieren.
Um diese Ansicht zu unterstützen, sehen Sie sich den Boot-Code an, der mit der Ausführungstestbench bereitgestellt wird. Wenn es dort einige Nullinitialisierungen gibt, werden Sie sie für die Netzlistensimulation benötigen (aber wahrscheinlich nicht in echtem Silizium).