Hallo, ich habe einen VHDL Code geschrieben mit einer FSM und einem asynchronen Reset. Das ganze ist für einen CPLD gedacht. Beim asynchronen Reset werden zwei Ausgangsignale auf 1 gesetzt und innerhalb der FSM werden sie kurzzeitig auf 0 gesetzt und später wieder auf 1. Wenn ich das ganze in einer normalen Simulation betreibe werden die Signale korrekt auf 0 gesetzt und später wieder auf 1. Starte ich jedoch eine Post-Fit Simulation zeigt diese an der Stelle wo die Signale 0 werden sollen einen Treiberkonflikt (X) an. Eigenartigerweise arbeitet das ganze richtig, wenn ich während des Resets die Signale auf 0 setze und beim ersten Zustand der FSM dann auf 1 und später zu gegebener zeit kurzzeitig wieder auf 0. Kann es sein, dass man während des Resets keine Signale setzen darf sondern nur löschen? Warum arbeitet die Normale Simulation richtig? Ich dachte mir ich könnte den Effekt umgehen indem ich bei RESET die signale auf 0 setze und sie durch eine Kombinatorische Logik invertiere. Leider geht das auch nicht.
Angehängte Dateien:
-
falsche_wave.jpg
120 KB
Hier ist nochmal ein Bild von der Post-Fit Simulation. Die einfache behavioral Simulation hat diesen Fehler nicht.
Und hier das VHDL Test Bench was ich benutze... Der Fehler tritt nicht auf, wenn ich in der CONTROLLER.vhd beim Reset die Signale RAM_RD und RAM_WR mit 0 anstatt mit 1 zurücksetze. Eventuell ist dies ja eine Eigenheit der Hardware von der ich nichts weiß. Leider habe ich auch keinen Anhaltspunkt wonach ich da suchen könnte... Aber wer weiß, vielleicht jagt mich ModelSim da auch ins Boxhorn... Ich benutze einen Xilinx CPLD XC95144XL Ich hoffe jemand von euch hat eine Idee woran das liegt.
Das CPLD hat wahrscheinlich nur FF ohne Preset-Eingang. Das wäre zumindestens das 1. was mir einfällt dazu. Einfach mal im Datenblatt schauen...
>Das CPLD hat wahrscheinlich nur FF ohne Preset-Eingang. Das wäre >zumindestens das 1. was mir einfällt dazu. Einfach mal im Datenblatt >schauen... Das würde ja schon meine erste Vermutung unterschreiben. Aber: Wenn es so wäre könnte ich das Problem umgehen indem ich die beiden Signale mit 0 initialisiere und später zum Steuern auf 1 setze. Am Ende wird das Signal durch kombinatorische Logik einfach invertiert. Aber genau das hat zu dem gleichen Effekt bei der Post-Fit Simulation geführt.
Ich habe sicherheitshalber nochmal geguckt: Die XC95xxx Reihe verfügt über Reset und Set an den FFs welche je nach Bedarf am FF geschaltet werden.
Hm, mir ist was anderes aufgefallen: PORT1_E wird von zwei FSM getrieben und zwar gesetzt wenn SM1 im z9 und gelöscht wenn SM3 im z2. Ist es möglich das beide Fälle gleichzeitig auftreten? Also das FF PORT1_E in einem Takt gesetzt und gelöscht werden soll? Das sieht vielleict nicht gut aus. Das 'x' kommt vielleicht im zustand Z7 von sm1 zustande, da in der Postlayout simu das Signal PORT_WR das Signal nicht '1' ist, er also den default wert aus der Signaldekleration nicht nimmt, sondern 'U' ansetzt. Vielleicht ändert sich was, wenn du in der Testbench die Port MAP von PORT1_WR => PORT1_WR, auf PORT1_WR => '1', änderst. Oder ist ein interner PullDown an PORT1_WR aktiv? Rätsel raten...
Grad ist mir noch was eingefallen, einige Modelsimversionen können alle Treiber eines Signals anzeigen, der Punkt heisst wohl "Datapath" oder "Dataflow". Das kann verraten wer aus der '1' ein 'x' macht. Rechter Doubleclick aufs wave des Signal lässt wohl dieses Fenster aufklappen. (Müsst ich morgen mal im Büro ausprobieren).
Aller guten dinge sind drei. was für ein CPLD is es denn? XC95????. Falls dein reset ein PowerUp reset ist (also nur beim einschalten aktiv) kannst du auf den resetwert verzichten und statt dessen den User-defiened preload state nutzen, also in der signaldeklaration einen default-wert angeben. der ist dann powerUp garantiert (zumdest bei XC95??XL). Standard ist '0'. High aktiver reset könnte das Verhalten auch ändern. Es könnte sein das R und S gleichzeitig aktiv sind (durch synthesefehler?) und in der Post_layoutsimulation das zu 'X' führt.
Angehängte Dateien:
-
driver.jpg
82 KB
Ja das Problem mit dem Port0_E und Port1_E habe ich wohl übersehen. Ich habe nun für das Schalten von PORTn_E auf 1 eine weitere Bedingung eingefügt. PORTn_E schaltet im Zustand Z4 und Z9 der SM1 nur dann auf 1 wenn PORTn_RD_S = 1 und PORTn_MODUS = USED. Falls einen Takt vor dem Z4 oder Z9 der SM1 die Signale PORTn_WR_S und PORTn_RD_S auf 1 sind. (Das lesen bzw. schreiben auf dem Port wurde vorzeitig abgebrochen) wird die SM2 oder SM3 "aktiviert" und einen Takt später das Signal PORTn_E auf 0 gesetzt. Gleichzeitig befindet sich SM1 jedoch inzwischen um Zustand Z4 oder Z9 und würde PORTn_E auf 1 setzen. Doch SM2 und SM3 haben einen Takt zuvor PORTn_MODUS auf UNUSED gesetzt wodurch PORTn_E von der SM1 nicht mehr gesetzt werden kann. Und vor lauter setzen und zurücksetzen verliere ich jetzt fast den Überblick ;) Deine Problemlösung bezüglich des X Problems kann ich jedoch nicht ganz nachvollziehen da die SM1 theoretisch in der Simulation niemals den Zustand Z7 erreichen kann, denn auf Port 1 wird kein Lesen oder Schreiben eingeleitet. Außerdem sind bei mir in der Post-Fit Simulation die Signale PORTn_WR immer 1 und nicht U es sei denn es gibt einen Schreibzugriff auf Port n, dann sind sie 0. Aber ich glaube ich habe dich mißverstanden. Dieses Dataflow habe ich schon ausprobiert. Zwar steige ich in der Bedienung noch nicht 100%ig durch aber ich bin mir sicher, dass er keinen zweiten Treiber für das Signal RAM_WR anzeigt. Ich habe einen Bild oben angefügt. Ich habe die Leitung nach dem angezeigten Treiber mit der rechten Maustaste angeklickt und "expand net to driver" gewählt. Das dürfte die Funktion sein die du meinst. Ich danke schonmal für deine Mühe und hoffe das der Fehler gefunden werden kann. Er hält mich immerhin schon ein paar Tage vom ruhigen Schlaf ab ;)
>Aller guten dinge sind drei. was für ein CPLD is es denn? XC95????.
Oh ich habe die ganze Zeit geschrieben und hab deine neue Antwort erst
jetzt gesehen.
Ich verwende tatsächlich einen XC95xxx.
Also jetzt ist es zu spät um noch was zu testen, aber morgen nach der
Arbeit setze ich mich gleich ran und berichte.
Ich wünsche eine gute Nacht :)
Guten Morgen, <Deine Problemlösung bezüglich des X Problems kann ich jedoch nicht ganz <nachvollziehen da die SM1 theoretisch in der Simulation niemals den <Zustand Z7 erreichen kann, denn auf Port 1 wird kein Lesen oder <Schreiben eingeleitet. Außerdem sind bei mir in der Post-Fit <Simulation <die Signale PORTn_WR immer 1 und nicht U es sei denn es gibt einen <Schreibzugriff auf Port n, dann sind sie 0. <Aber ich glaube ich habe dich mißverstanden. dann habe ich falsch geraten, also ich bin davon ausgegegangen das der state erreicht wird (mal die Zustandsvariable SM1 (bzw, deren FF) mit ins wave nehmen) was aber wohl nicht, und zweitens hielt ich es für möglich das die PostFit simulation fälschlicherweise den stimuli nicht als '1' sondern als 'U'. Ist unwahrscheinlich. Das FF in der Macrocell wär mein nächster Ansatzpunkt. Eigentlich müsste man sich die Verdrahtung im Chip mal anschauen also fpgaeditor für fpga's bei dir ist es wohl der chipviewer (cpld). und man schaut sich in der simu alle Signale des FF an. ---- Modelsim zeigt im Dataflow keine weitere Signaltreiber (ich versteh das datapath fenster auch nicht recht), also wirds das X wohl aus dem FF kommen. Obwohl lt. Libraray guide nie ein X aus den FF rauskommt, (zumindest mach schneller durchsicht der FF Primitive) .... ---- Aber Moment, selbst wenn statisch alles OK ist (also der Fall R=S=1 ist lt. xilinx auch definiert) wie siehts dynamisch aus?! Stammt das X vielleicht aus einer Setup/Hold Verletzung? Schau mer mal: Dein clk in der simu hat eine Periode von 16 ns, also 62.5 MHz. Das ist eigentlich nicht viel. Und setup und HoldsVerletzungen müssten ja eine Warning bei Modelsim erzeugen (Oder kann man diese ausschalten?) Rätsel über rätsel. was steht in den Logdateien? also fitreport, Pin report (wenns sowas gibt).
Tag, ich habe den Fehler gefunden. Schau mal in die Postfit-VHDL-Datei. Dort gibt es ein GSR-Signal, "NlwRenamedSignal_GSR" heisst das bei mir (ich benutze WebPack 8.1). Das wird zwar bei zwei Komponenten benutzt, aber dummerweise nicht initialisiert, d.h. es hat den Wert 'U'. Das hat dann zur Folge, das mehrere interne Signal den Wert 'U' oder eben 'X' bekommen. Setz das Signal auf '0', dann funktioniert es.
Angehängte Dateien:
-
mcrocell.jpg
130 KB
@FPGA-Küchle: Ich habe mir mal die Macrocell angesehen, sieht ja ganz normal aus :) Richtig schlau werde ich nicht draus, da die angegebenen Signale in der Simulation andere Namen haben. Also habe ich Namen geraten z.B. habe ich anstatt SM1_FFd3 das Simulatorsignal SM1_FFd3/o genommen und damit eien Simulation durchgeführt. Dabei war keines dieser Signale in einem merkwürdigen Zustand. Alle waren immer auf 1 oder 0. Da diese ja mit einer kombinatoren Logik an das FF gebunden sind kann ich mir auch nciht vorstellen das eines dieser Signale am Eingang des FFs gegen ein anderen Signal treibt. Zumindest kannich mir nicht vorstellen was das Synthesetool-Tool soetwas zulassen sollte. Ich habe dir mal ein Bild der Macrocell angehangen. Das Setup und Hold Zeiten verletzt werden und das bei 62MHz kannich mir schwer vorstellen, der Timing Report zeigt mir zumindest eine maximale Clockfrequenz von 90MHz. Auch sonnst wird keien Warnung ausgegeben, aber ich bin noch nciht so geübt was das durchschauen des Reports angeht, daher hänge ich dir die gezipten HTML-Seiten mal an, vieleicht siehst du da was ungewöhnliches. @Xenu: In der Simulation habe ich dieses Signal nun auch entdeckt. Und wenn ich es auf 0 "force" läuft die Simulation vernüftig. Bleibr aber die Frage: Woher kommt das Signal? Warum ist es da? Und was denkt sich das Synthesetool dabei? Handelt es sich hier um ein Fehler der Post-Fit-Model Berechnung oder gar der Synthese?
Und hier die gezipten HTML Seiten des Fit und Timing Reports... Die Startseite ist: CONTROLLER_html\fit\appletref.htm
So ich habe versucht den Fehler den das komische Signal auslöst zu analysieren. Das Signal NlwRenamedSignal_GSR geht auf ein OR Gatter mit dem invertierten Reset als zweiten Eingang. Solange das Reset = 0 also im /GSR Eingang des OR Gatters = 1 gibt das Gatter 1 aus. Sobald Reset = 1 also /GSR am Or Gatter = 0 gibt es ein U aus, da das NlwRenamedSignal_GSR ebenfalls 0 ist. Der Ausgang des Gatters heißt RAM_WR_OBUF_tsimcreated_prld_Q_427 und geht auf den SET Eingang des Ausgangs-FF von RAM_WR. Am D Eingang liegt RAM_WR_OBUF_D_428 an, welches ein durch kombinatorische Logik zurückgekoppeltes Signal von RAM_WR ist. Solange das design also im Reset ist bekommt das FF am SET Eingang eine 1, womit das FF sich auf 1 setzt. Wenn Reset gelösht wird liegt am SET Eingang ein U an, was aber nicht schlimm ist, da das FF die 1 von D weiterhin übernimmt. Erst wenn D auf 0 geht wirkt sich der fehlerhafte SET Eingang auf das FF aus und das FF schaltet auf X. Das X Signal wird übrings (und logischer Weise) über eine kombinatorische Logik zeitversetzt wieder auf D zurückgekoppelt... aber sobald diese kombinatorische Logik, welch eden Zustand der SM1 auswertet wieder auf 1 schaltet und somit am FF auch 1 anliegt übernimmt das FF den Status 1. Das gleiche passiert natürlich auch bei einem RESET. Also wenn ich mir das so angucke, wie ein komplettes Signal einfach so in der Luft hängt habe ich das Gefühl, dass mich hier das Synthesetool verarscht. Und vor allem: Wieso denkt es sich diese bescheuerten Signalnamen aus... der Informatikstudent würde dafür eine 6 kassieren! ;-)
Sorry ein kleiner Fehler: >Sobald Reset = 1 >also /GSR am Or Gatter = 0 gibt es ein U aus, da das >NlwRenamedSignal_GSR ebenfalls 0 ist. Das NlwRenamedSignal_GSR ist dauerhaft auf U.
Interessant ist die Tatsache, dass fast jeden FF in dem Design ein OR Gatter vor dem RESET oder SET Eingang besitzt. Wobei eines der Signale der invertierte Reset und das andere eingangssignal normalerweise GND ist. Wenn ein FF am RESET Eingang angesteuert wird (wird bei Reset auf 0 initialisiert) ist der eine Eingang des OR Gatters GND und der andere der invertierte RESET. Wenn ein FF am SET Eingang angesteuert wird (wird bei Reset auf 1 gesetzt) ist der eine Eingang des OR Gatters dieses komische Signal NlwRenamedSignal_GSR und der andere Eingang der invertierte RESET. Das ist auch so, wenn ich andere Signale beim Reset auf 1 setze. Bei all diesen Signalen tritt dann der Fehler auf. Außer bei den Signalen PORT0_E und PORT1_E, wenn diese mit 1 initialisiert werden funktionieren diese. Dort wird der SET Eingang am FF direkt durch den invertierten RESET angesteuert ohne vorher ein "obligatorisches" OR Gatter zu durchqueren. Interessant ist ebenfalls, das im RTL Schaltplan, den das Synthesetool erzeugt weder OR Gatter am RESET oder SET der FFs geschaltet sind noch ein Signal wie das NlwRenamedSignal_GSR in der Luft hängt. Da stellen sich einige Fragen bei mir ein: 1.) Warum erzeugt er im Post Fit Model diese OR Gatter, die in wirklichkeit keine Schaltfunktion haben (ein Pin auf GND) und im Zweifelsfall sogar eine Fehlerquelle darstellen (ein Pin auf NlwRenamedSignal_GSR)? Vielleicht aus Laufzeitgründen? 2.) Warum vergeigt das Synthesetool beim Ansteuern des SET Einganges das eine Signal? Ein Fehler im Tool? 3.) Wenn diese OR Gatter im RTL Plan nicht existieren und die SET/RESET Eingänge richtig angesteuert werden dürfte dieser Fehler im praktischen Design nicht existieren... das muß mal gestestet werden! Also da sind wir ja heute schon wieder ein Schritt weiter gekommen, aber mit jedem Schritt werden neue Fragen in den Raum geworfen. Gute Nacht...
Hat jeman dovon euch noch das WebPack 7.x installiert und könnte das ganze mal dort versuchen zu simulieren? Vielleicht haut er beim 7ner WebPack diesen fehler nicht rein...
Ich habe das mal im Projekt angegeben das ich anstatt eines XC95xxx einen Coldrunner2 benutze und dann die Post Fit Simulation durchgeführt. Dann funktioniert alles wunderbar. Auch hier gibt es vor den FFs OR Gatter am SET und RESET Eingang, doch werden diese IMMER mit GND an IO1 und /GSR am IO2 angesteuert, so wie es sein muss. Ich bin mir inzwischen ganz sicher, dass es sich hierbei um einen BUG in der Software handeln muss. Er ist ärgerlich, doch habe ich ja schließlich auch einiges gelernt bei der ganzen Fehler-Suchaktion. Die Frage ist nur: Weiß Xilinx bereits von diesem Fehler? Oder bin ich der erste Mensch auf dieser Welt dem der Fehler aufgefallen ist. Im Xilinx Forum konnte ich eine Fragestellung zu diesem Problem noch nicht entdecken, werde aber mal weiter suchen.
>Ich bin mir inzwischen ganz sicher, dass es sich hierbei um einen BUG >in der Software handeln muss. Freilich ist das ein Fehler. >Weiß Xilinx bereits von diesem Fehler? Wieso schreibst Du ihnen nicht einfach? => http://www.xilinx.com/support/clearexpress/websupport.htm
Tja leider kann ich mich da nicht ohne weiteres einloggen und irgend wo anders steht keine Support EMail-Adresse. Bleibt nur das Forum, aber da ist es mir etwas zu peinlich mit einem schwachen Englisch :)
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.