Forum: FPGA, VHDL & Co. Sram Simulation funktioniert nicht richtig


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Jens W. (jensw)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

ich möchte meinen Memory Controller testen. Er stellt ein dual Port 
Memory dar, das einem µC und einem FPGA ermöglicht auf ein externes Sram 
zuzugreifen.

Jetzt habe ich die Testbench angefangen und dazu habe ich mir ein Sram 
Model besorgt und eingebunden.
Soweit funktioniert auch alles.

In der Vorarbeit habe ich eine Testbench nur für das Sram getestet. 
Läuft wie erwartet, keine Fehler.

Anders bei meinem Memory Controller.
Da kommt die Fehlermeldung:"-E- Data not valid at end-of-write to SRAM."
Die Meldung wird vom Sram-Model generiert.
Es muss also im Memory Controller irgendwas falsch sein.

Die Frage ist nun, Warum die Fehlermeldung kommt. Ich verstehe den 
Zusammenhang nicht, was passieren muss, damit diese Fehlermeldung kommt.
Ich werde einfach nicht schlau draus. Und solange ich das nicht 
verstanden habe werde ich den Fehler in meinem Code sicher auch nicht 
finden.

Ich hänge das Model vom Sram mit an.

Danke euch!

Grüße, Jens

von Gustl B. (-gb-)


Lesenswert?

Jens W. schrieb:
> Die Frage ist nun, Warum die Fehlermeldung kommt.

Guck in den angehängten Code, wann, also bei welcher Bedingung diese 
Meldung ausgegeben wird. Gekürzt:
1
IF do_write'EVENT and (do_write = '1') then
2
   IF NOT Check_For_Valid_Data(D) THEN
3
      IF D'EVENT AND Check_For_Valid_Data(D'DELAYED) THEN
4
5
      ELSE
6
         write(output, "-E- Data not valid at end-of-write to SRAM.");
7
      END IF;

Check_For_Valid_Data ist eine Funktion. So wirklich verstehe ich den 
Sinn nicht. Gut, für die Simulation prüft die ob alle Bits in den Daten 
tatsächlich '1' oder '0' sind und nicht UXZHL.

Jens W. schrieb:
> Es muss also im Memory Controller irgendwas falsch sein.

Warum zeigst du uns den denn dann nicht?

Ich würde erstmal vermuten, dass die Daten, das ist ja ein inout, beim 
Schreiben ins RAM mal auf 'Z' gesetzt sind.

von Fpgakuechle K. (fpgakuechle) Benutzerseite


Angehängte Dateien:

Lesenswert?

Jens W. schrieb:

> Die Frage ist nun, Warum die Fehlermeldung kommt. Ich verstehe den
> Zusammenhang nicht, was passieren muss, damit diese Fehlermeldung kommt.
> Ich werde einfach nicht schlau draus.

 Es ist doch simpel, schau auf dem Waveformviewer ob sich am Datenbus 
was tut, während der Datenbus ruhig sein soll.

VHDL ist eben nicht wie C wo textuelle Fehlermeldungen die einzige 
Rückmeldung zur Fehleranalyse sind, mit einem VHDL-Simulator kann man 
sich in einem y(t)-Diagramm anschauen, wie und wann die Signal schalten.

Ebenso solltest du lernen wie mann die timing diagramm im Datenblatt 
liest, Beispiel im Anhang.

von Jens W. (jensw)


Lesenswert?

Hallo zusammen,

Fpgakuechle K. schrieb:
> VHDL ist eben nicht wie C wo textuelle Fehlermeldungen die einzige
> Rückmeldung zur Fehleranalyse sind, mit einem VHDL-Simulator kann man
> sich in einem y(t)-Diagramm anschauen, wie und wann die Signal schalten.
>
> Ebenso solltest du lernen wie mann die timing diagramm im Datenblatt
> liest, Beispiel im Anhang.

Da bin ich ja dabei. Aber auch bei der Einarbeitung kommt es vor, dass 
man nicht alles auf Anhieb versteht.

Gustl B. schrieb:
> Check_For_Valid_Data ist eine Funktion. So wirklich verstehe ich den
> Sinn nicht. Gut, für die Simulation prüft die ob alle Bits in den Daten
> tatsächlich '1' oder '0' sind und nicht UXZHL.

Der Hinweis hat geholfen.
Beim Schreiben (nWE low -> high) ändern sich die Daten auf "Z". Und das 
schreibt er dann auch ins RAM. Und beim Auslesen merkt die Funktion, 
dass da nicht eindeutige Daten drin stehen (also UXZHL) und gibt den 
Fehler aus.

Das Interface vom Controller reiche ich nur durch. Aber da muss ich die 
Daten wohl noch etwas verzögern, dann wird das Timing da sauber.
Ich versuchs weiter und geb Bescheid.

Danke euch!

Grüße, Jens

von Jens W. (jensw)


Lesenswert?

Hallo,

kurze Info:
Genau das war es.
Das nWE von low auf high und die Daten am SRAM haben sich gleichzeitig 
geändert.
Ich habe nun die Änderung der Daten von der Flanke auf nWE verzögert.
Das hat geholfen. Keine Fehlermeldung mehr.

Danke euch!

Grüße, Jens

von Gustl B. (-gb-)


Lesenswert?

Lob und Anerkennung (-;

von Jens W. (jensw)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

jetzt muss ich noch was fragen. Ich hoffe der Thread hier ist nicht 
schon zu alt und es liest keiner mehr.

Ich habe nun alles im Simulator zum Laufen bekommen. Da funktioniert 
alles wie es soll.
Wenn ich nun aber das Bitfile auf mein Target schiebe, dann verhält sich 
die Geschichte nicht mehr so wie im Simulator.
Ich beschreibe mal was ich mache.
Auf dem Board ist ein µC und ein FPGA. Beide teilen sich das RAM. Jetzt 
läuft erstmal nur ein Speichertest-Programm. Der µC schreibt den 
Speicher voll mit Primzahlen. Das FPGA nimmt diese und macht eine XOR 
Verknüpfung mit einem Wert und schreib den neuen Wert zurück ins SRAM.
Der Controller liest nun wieder die Werte, macht die gleiche logische 
Operation und schaut, ob das Ergebnis gleich ist.
Lesen und Schreiben von µC ins SRAM läuft ohne Probleme.
Nur wenn ich die Operation im FPGA anstoße lese ich nur noch 0 zurück.
Also muss bei der Operation im FPGA was schief laufen.
Nur, in der Simulation sieht das gut aus. Warnungen bekomme ich auch 
keine, die auf ein Problem hindeuten würden.

Wo könnte ich noch schauen? Müsst ich nicht in irgendwelchen Synthese 
Reports Hinweise finden?

Ich hänge euch mal den Code für die Operation im FPGA mit an und das 
Blockschaltbild.

Grüße, Jens

von Duke Scarring (Gast)


Lesenswert?

Jens W. schrieb:
> Ich habe nun alles im Simulator zum Laufen bekommen. Da funktioniert
> alles wie es soll.
Wenn es dann real nicht klappt, ist irgendwas in der realen Welt anders, 
als es in der Simulation angenommen wird. So ist zumindest meine 
Erfahrung.

Sehe ich das richtig, das uC und SRAM beide im FPGA sind oder ist das 
Schaltbild nur eine Skizze?

Und der SRAM ist eigentlich gar kein SRAM, sondern eher ein 
Rechenbeschleuniger mit SRAM-Interface, oder?

Duke

von Jens W. (jensw)


Lesenswert?

Hallo Duke,

das Schaltbild ist die Top Entity.
Das SRAM ist ein echtes SRAM auf dem Board. Und der µC ist ein echter µC 
auf dem Board.
Im FPGA wird nun der Zugriff auf das RAM geregelt.
Den Platz brauche ich noch für die echte Anwendung.
Hier ist ja nur Schreiben und Lesen der beiden Kandidaten geregelt.

Ich bin auch ein Stückchen weiter.
Ich vermute, dass ich ein Timing Problem habe im FPGA.
Ich versuche gerade die einzelnen Schritte für den Lese- und 
Schreibzugriff zu verlangsamen und alles Schritt für Schritt der Reihe 
nach zu machen auch wenn das erstmal länger dauert.
Um die Geschwindigkeit kümmere ich mich später. Erstmal muss die Karre 
laufen.

An der Umsetzung an sich kann man jetzt wohl keine groben Schnitzer auf 
den ersten Blick erkennen oder?

Grüße, Jens

von Testuser (Gast)


Lesenswert?

Hast du ein Timingmodell von dem RAM in VHDL für die Simulation? Das 
wäre mein Ansatz, simulieren bis da keine Fehler auftreten und dann auf 
die Hardware. Welcher SRAM Baustein ist das genau, dann gucke ich mal ob 
ich ein Modell finde oder schreibe.

von Jens W. (jensw)


Lesenswert?

Hallo,

das Modell für die Simulation habe ich.
Die Werte für die Zeiten habe ich aus dem Datenblatt übertragen. Das 
sollte passen.
Meine Vermutung ist, dass ich mit Signallaufzeiten innerhalb des FPGA zu 
kämpfen habe.

Irgendwie ist da ein Effekt, den die Simulation nicht richtig erfasst. 
Was dann einen Unterschied zwischen Modell und Wirklichkeit bedeutet und 
in dem Fall, dass es fehl schlägt.

Gibt es ein File, wo ich reinschauen kann, das mir Infos für die 
Signallaufzeiten bereit stellt?
Wo fängt man an zu debuggen, wenn man Glitches oder 
Synchronisationsprobleme hat?

Grüße, Jens

von Gustl B. (gustl_b)


Lesenswert?

Du kannst das Zeug im FPGA constrainen damit das eben Timings einhält. 
Wenn das nicht geschafft wird sagt dir das die Toolchain.

Die Timings im FPGA kannst du im Timing Report lesen.

von Martin S. (strubi)


Lesenswert?

Jens W. schrieb:
> Wo fängt man an zu debuggen, wenn man Glitches oder
> Synchronisationsprobleme hat?

Post-Map bzw. Post-PnR-Simulation (mit den 'realen' Timings) schon 
gemacht?
Von was fuer Zyklendauern/Taktfrequenzen reden wir?

von Jens W. (jensw)


Lesenswert?

Hallo,

ich bin mit 96MHz unterwegs. Das SRAM ist ein Typ mit 10ns, das dachte 
ich mir, da komme ich mit der Frequenz gut hin ohne extra Waitstates. 
Wobei die aber drin sind. Momentan habe ich 3 Takte als Waitstate.

Ich bin einen Schritt weiter. Ich habe in dem File "SRAM_Operation.vhd", 
das ich oben angehängt hatte ein bisschen weiter gemacht.
Da wird ja noch ein XOR-Verknüpfung mit den Werten gemacht. Und ich 
dachte, ich kommentiere das mal aus und schaue, ob dann auch noch 
Schrott ins SRAM geschrieben wird.
Und es sieht so aus, dass es dann passt. Das würde bedeuten, dass ich 
gar kein Timing Problem habe, sondern die Werte irgendwie nicht passen.
(Wobei in das dann auch nicht mit der Simulation übereinstimmt, denn da 
sehe ich die Werte, die ich erwarte).

Ich werde morgen die Geschichte mit der XOR Verknüpfung nochmal neu 
machen und dann schauen, ob es klappt.
Könnte von euch nochmal jemand in das File schauen, ob da ein grober 
Schnitzer drin ist? Ich sehe den Fehler noch nicht.

Grüße, Jens

von Bernhard K. (bkom)


Lesenswert?

Jens W. schrieb:
> Da wird ja noch ein XOR-Verknüpfung mit den Werten gemacht. Und ich
> dachte, ich kommentiere das mal aus und schaue, ob dann auch noch
> Schrott ins SRAM geschrieben wird.

Möglich das ohne das XOR vor dem "internal_SRAM_Data_out" IOB-Flipflops
verwendet werden (so kenn ich das von Xilinx), und damit würde das Delay
des FPGA internen Routings wegfallen.

So meine ich kann man bei z.B..Xilinx kein IOB_Flipflop verwenden:
>when modify =>
>    internal_SRAM_Data_out <= to_stdlogicvector(SRAM_Data_in) XOR int_crc;

So wäre es eher möglich:
>when modify =>
>    internal_SRAM_Data_out <= to_stdlogicvector(SRAM_Data_in);

Möglicher auch das die andere Logik dazwischen funkt ...
Wie sehen die anderen Schaltungsteile aus?

von Jens W. (jensw)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

ich habe die Stelle gefunden. Es ist nicht die XOR Verknüpfung selbst, 
sondern die Stelle, wo ich den crc-Wert überschreibe mit dem neuen Wert.

int_crc <= internal_SRAM_Data_out;

Diese Zeile ist es.
Wenn ich die raus nehme funktioniert alles bestens.

Warum das nicht geht habe ich leider nicht heraus finden können.
Aber als Fazit, ein Timing Problem ist es nicht.

Entsteht da irgendeine rekursive Schleife oder sowas?

Grüße, Jens

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Lesenswert?

Jens W. schrieb:
> Entsteht da irgendeine rekursive Schleife oder sowas?

Nope, das passt alles.

Jens W. schrieb:
> Aber als Fazit, ein Timing Problem ist es nicht.

Steht das so in den Timing Reports?

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]
  • [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.

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