Hallo, Derzeit habe ich folgendes Problem: Ich habe einen bidirektionalen Bus an eine Komponente (SD-RAM). Den schalte ich entsprechend hochohmig wenn ichs brauche. Die Komponente ist in der Testbench instanziiert. Der Ausgang der Komponente wird immer kombinatorisch in meine entity geführt, z.B. an einen Addierer. Nun gibt es Situationen, da liefert die Komponente, wenn sie als Ausgang konfiguriert ist, 'X' (std_logic_vector). Das soll auch so sein und ist soweit egal, da die Werte zwar an den Adder gehen, aber kein Ausgangs"valid" erzeugt wird. Nun gibt es dadurch natürlich haufenweise Warnungen in der Simulation derart, dass eben ein Operand in einer arithemtischen Operation 'X' ist und der Ausgang deswegen 'X' ist. Das ist ja auch so geplant. Allerdings ist durch diese ständige Warnungen zu fast jedem Takt keine vernünftige Simualtion möglich (geht sehr langsam wegen der Ausgabe). Die Ausgabe von Warnungen komplett abschalten möchte ich allerdings nicht. Eine Abfrage in der Testbench derart, dass ich den bidir-Bus mit ...='X' abfrage und falls er X ist einfach 0 an meine entity leite funktioniert aus demselben Grund nicht, dann ist eben die Abfrage die arithemtische Operation die nicht sein darf. Also kurz gefragt: Gibt es eine Möglichkeit, einen std_logic_vector für die Simulation auf X abzufragen und entsprechend zu reagieren?
Wenn ich es richtig verstanden habe, liefert deine Komponente während der Simulation zu bestimmten Zeiten ein "X", statt eines sinvollen Wertes. Warum gehst du nicht den "sauberen" Weg und beschreibst deine Komponente vollständig, so dass in jedem Zustand ein definierter Wert an dem Bus anliegt? Ist meinst durch ein einfaches "else" o.Ä. erledigt. Ob man die Abfrage auf "X" mit einem Assert o.Ä. hinbekommt und dann den Wert korrigieren kann, wage ich zu bezweifeln.
> bidirektionalen Bus Auf einem bidirektionalen Bus darf keiner 'X' treiben, da sollte es nur '0', '1' und 'Z' geben. > Das soll auch so sein ... Eine reale Schaltung wird dir auch nie ein 'X' zurückgeben. D.h. das was du da simulierst kann niemals der Realität entsprechen. Wozu also die Simulation?
Danke für eure Antworten. >Warum gehst du nicht den "sauberen" Weg und beschreibst deine Komponente >vollständig, so dass in jedem Zustand ein definierter Wert an dem Bus >anliegt? Weil das nicht "meine" Komponente ist, sondern ein SD-RAM Simulationsmodell, welches ich nicht gewillt bin zu ändern. Bzw. ich es von meiner Komponente aus nicht brauche, siehe nächster Punkt. >Auf einem bidirektionalen Bus darf keiner 'X' treiben, da sollte es nur >'0', '1' und 'Z' geben. Das treibe nicht ich, sondern es wird vom SD-RAM zurückgegeben, während ich 'Z' treibe, also lese. Konkret lese ich an uninitialisierten Adressen, welche im Laufe der Simulation erst beschrieben und später zurückgelesen werden, also am Anfang noch 'X' enthalten. Natürlich könnte ich jetzt einen Sonderfall definieren und am Anfang noch nicht dort lesen usw. aber das würde eben wieder mehr Hardwareaufwand bedeuten, den ich in der realen Schaltung eben wirklich nicht brauche. Zur Zeit beschränkt sich der Sonderfall darauf, den Ausgang meiner Berechnung dann nicht weiter zu verwenden. Nur in der Simulation möchte ich die Warnungen darüber eben nicht haben. >Eine reale Schaltung wird dir auch nie ein 'X' zurückgeben. >D.h. das was du da simulierst kann niemals der Realität entsprechen. >Wozu also die Simulation? Damit ich meine Gesamtschaltung simulieren kann. Natürlich gibt es kein 'X' im realen, aber in der Simulation weiß ich wo es herkommt und kann damit leben, gerade weil ich weiß, dass es real kein X ist.
> Auf einem bidirektionalen Bus darf keiner 'X' treiben, da sollte es nur > '0', '1' und 'Z' geben. 'X' sollte da tatsächlich nicht vorkommen, aber zu '0', '1' und 'Z' können sich durchaus noch 'L' und 'H' dazugesellen. Das wären dann Pullup- und Pulldown-Widerstände. Im 'NUMERIC_STD' gibt es dazu Funktionen wie 'To_01'. Die Funktion wandelt alles außer '1' und 'H' in '0'.
Danke Matthias, das ist eine gute Idee. Leider überschreibt ein X gnadenlos jedes L und H. Das Problem ist, das X wird von der SD-RAM-Komponente wirklich getrieben. Liegt wohl daran, dass die in Verilog beschrieben ist und da gibts kein std_logic_vector, also entscheidet sich die Simulation bei unitialisierten Speicherstellen für X. Das to_01 lässt sich aber gut nutzen, hab nun eine ähnliche Funktion geschrieben, die mir nur aus X ein L macht und ansonsten alles so lässt. Also kein wirkliches Pulldown aber für diesen Simulationszweck reichts.
Bitte 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.