mikrocontroller.net

Forum: FPGA, VHDL & Co. eigenartige Post-Fit Simulation


Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. N. (netbandit)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier ist nochmal ein Bild von der Post-Fit Simulation.
Die einfache behavioral Simulation hat diesen Fehler nicht.

Autor: A. N. (netbandit)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier der VHDL Code.
Es handelt sich dabei um den versuch eines Dual Port Ram Controllers.

Autor: A. N. (netbandit)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: T.M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. N. (netbandit)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 :)

Autor: FPGAküchle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Xenu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. N. (netbandit)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@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?

Autor: A. N. (netbandit)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Und hier die gezipten HTML Seiten des Fit und Timing Reports...

Die Startseite ist: CONTROLLER_html\fit\appletref.htm

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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! ;-)

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Xenu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.