QSYS SDRAM Controller funktioniert in Simulation aber nicht mit echter Hardware

Also was ich mit nicht funktioniert meine ist, dass die Farben nicht 
mehr richtig sind und die Pixel in ihrer Position nicht bleiben. Wenn 
ich nur lesen aktiviere schwankten die Rows ein bisschen und wenn ich 
Save aktiviere verschiebt sich das ganze noch mehr. Ich kann gerade 
keine Bilder zeigen, aber werde die dann wenn ich nach Hause komme 
nochmal schicken, falls das hilft.

Leon B. schrieb:
> QSYS SDRAM Controller funktioniert in Simulation aber nicht mit echter
> Hardware
Dann kann es eigentlich nur noch dran liegen, dass das Modell bzw. die 
Testbench nicht der Realität entspricht.

Leon B. schrieb:
> Also was ich mit nicht funktioniert meine ist, dass die Farben nicht
> mehr richtig sind und die Pixel in ihrer Position nicht bleiben. Wenn
> ich nur lesen aktiviere schwankten die Rows ein bisschen und wenn ich
> Save aktiviere verschiebt sich das ganze noch mehr.
Miss mal das Timing an den FPGA Pins und kontrolliere, ob die Timing 
Constraints dazu passen.

> nicht mehr richtig
Die waren also schon mal richtig? Was hast du dann geändert?

> Dann kann es eigentlich nur noch dran liegen, dass das Modell bzw. die
> Testbench nicht der Realität entspricht.
Ich hab gerade noch nen anderes Simulationsmodell (nicht das von Intel) 
gefunden. Damit probier ichs dann nochmal

> Miss mal das Timing an den FPGA Pins und kontrolliere, ob die Timing
> Constraints dazu passen.
Mach ich dann wenn ich zuhause bin, aber auch mit anderen Einstellungen 
(großzügigen Verzögerungen und kleinerer Frequenz) wird das ganze ehr 
nur noch schlimmer.

> Die waren also schon mal richtig? Was hast du dann geändert?
Im Vergleich zum internen RAM

Leon B. schrieb:
> Also was ich mit nicht funktioniert meine ist, dass die Farben nicht
> mehr richtig sind und die Pixel in ihrer Position nicht bleiben.

D.h. die einzelnen Pixelwerte stehen an einer falschen Stelle im RAM. 
Haeufig ein Zeichen fuer fehlende Speicherbandbreite.

Hast du eine Chance mal die Datenmenge zu reduzieren? Z.B. erstmal nur 
ein 16x16 Pixel groesses Bild zu buffern und dieses immer groesser 
werden lassen bis der Fehler wieder auftritt?

Gerne nehme ich als auch einen Testbildgenerator und kodiere die x/y 
Position als RGB Wert (z.b. die oberen 12 Bits als y und die unteren 
fuer x). Dann kann man via Analyzer relativ einfach schauen welches 
Pixel wohin verrutscht ist.

Falsche Farben und falsche Position klingt für mich eher so als lägen 
die Daten und Adresse zur Taktflanke noch nicht stabil an. Messen wäre 
natürlich super, aber du kannst auch probieren den Takt relativ zu den 
Daten und der Adresse zu verschieben bis es gut aussieht.

Die Idee mit dem Testbild aus x und y ist sehr fein. Einfach zu 
schreiben und Fehler fallen dank der großen Flächen mit einer Farbe 
schnell auf.

Danke für die Antworten! Werde das dann ausprobieren und mal hoffen, 
dass sich da was finden lässt

> Hast Du zwischen SDRAM und HDMI-out einen FIFO drin?
So in der Art. Habe 2x RAM mit 256 Wörtern drin, in denen die Daten 
gebuffert werden.

> Kannst Du beim SDRAM den Autorefresh abschalten?
Ich kann nur die Zeit höher stellen bei dem QSYS Ding

So ich hab jetzt mal ein bisschen mit den Frequenzen und der Bildgröße 
gespielt.
1. Testbild (einfacher Farbverlauf) bei 100MHz RAM, 25MHz Pixel Clock 
und voller Auflösung
2. Testbild bei 50MHz RAM, 2.5MHz Pixel Clock und 1/4 Auflösung. Wird 
aber mit voller Auflösung ausgelesen (wenn ich das abschalte ist der 
untere Teil halt schwarz)
3. Testbild bei 25MHz RAM, 2.5MHz Pixel Clock und voller Auflösung

Wenn man bei 2.5MHz Pixel Clock RAM Clock wieder auf 100MHz bringt 
siehts übrigens so aus wie bei 1.

Kennt hier jemand vielleicht einen SDRAM Controller, der Bursts 
unterstützt? Ich denke mal da liegt das Problem, da bei geringerer 
Geschwindigkeit die Fehler abnehmen. Full Page wäre ein Traum.

Nein, ich widerspreche mir hiermit selbst und behaupte das ist der 
falsche Ansatz das zu testen. Der RAM Controller sollte funktionieren 
und zwar unabhängig von dem was da gespeichert wird und was das für eine 
Anwendung ist. Ein Test wäre also definierte Werte an bekannte Adressen 
zu schreiben, z. B. erstmal alles mit x"FF", dann alles mit x"00", dann 
abwechselnd, dann unterschiedliche Bereiche mit unterschiedlichen 
Mustern. Und zwar so, dass du das wieder auslesen und mit dem 
Geschriebenen vergleichen kannst.
Erst wenn das fehlerfrei funktioniert würde ich mit Grafik anfangen. 
Wenn es da dann weiterhin diese Fehler gibt, dass kannst du sagen, dass 
es nicht am RAM liegt.

Wenn irgendwo die Bandbreite limitiert würde ich mir die Kollisionen 
irgendwo ausgeben lassen. Ich habe in meinem VHDL oft so Zähler die 
zählen wie oft in ein z. B. FIFO geschrieben werden soll, es aber gerade 
voll ist. Ich finde das schön wenn man sich solche Daten quasi als 
Telemetrie ausgeben lassen kann. Aber ob das mit der Bandbreite 
funktioniert solltest du auch in der Simulation sehen können.

Gustl B. schrieb:
> Aber ob das mit der Bandbreite
> funktioniert solltest du auch in der Simulation sehen können.

Speicherbandbreite zu untersuchen ist mit das undankbarste was es in 
einer Simulation gibt. Zum einen braucht man ein vernuenftiges Modell 
vom Speicher, zum anderen sind viele Speichercontroller entsprechend 
komplex und die Simulationszeiten gehen rasant nach oben.

Es reicht es oft auch nicht einzelne Videoframes zu simulieren, sondern 
man muss abhaengig von den Refresh Cycles doch eine ganze Menge Frames 
simulieren, damit mal alle moegliche Timingvarianten bzgl. 
Speicherzugriff und Refresh Cycles durch hat. Ideal waere natuerlich den 
Refresh mit dem V-Sync zu triggern, bzw. ganz zu deaktivieren, das 
haengt natuerlich ganz von der Speichertechnologie und Framerate ab.

In der Regel erstellt man sich daher erstmal ein Simulationsmodell 
welches Speicher + Controller beinhaltet und vereinfacht, damit lassen 
sich die Simulationszeiten drastisch reduzieren. Problem ist nur das man 
eben vom realen Modell entsprechend abweicht und das spuert man 
besonders dann, wenn man versucht hart an die Grenze der 
Speicherbandbreite zu kommen. Oft hat man das in Kombination mit 
Multiport-Speichercontroller. Da muss man sich dann shcon genauer 
ueberlegen was man wie simuliert und was man messen will, sonst debuggt 
man bis zum Sankt Nimmerleinstag.

@Leon B.

Die Bilder sehen absolut so aus, als wuerden die Adressen nicht zu den 
Daten passen. Kannst du mal eine Graurampe erstellen und via Logic 
Analyzer schauen ob ueberhaupt korrekt adressiert wird? Sowohl beim 
Schreiben als auch beim Lesen.

Damit solltest du relativ schnell sehen wo der Controller Probleme hat. 
Vernuenftig dimensionierte FIFOs wirst du auch brauchen, damit du auch 
die Austastluecke nutzen kannst.

Tobias B. schrieb:
> Die Bilder sehen absolut so aus, als wuerden die Adressen nicht zu den
> Daten passen. Kannst du mal eine Graurampe erstellen und via Logic
> Analyzer schauen ob ueberhaupt korrekt adressiert wird? Sowohl beim
> Schreiben als auch beim Lesen.
>
> Damit solltest du relativ schnell sehen wo der Controller Probleme hat.
> Vernuenftig dimensionierte FIFOs wirst du auch brauchen, damit du auch
> die Austastluecke nutzen kannst.

Also erstmal ist das Vidor Board echt bescheiden um an freie FPGA Pins 
zu kommen (nur auf dem PCIE Anschluss), aber ich konnte mal die ersten 7 
bits von den Adressen aufnehmen und entweder es liegt an meinem 10€ 
logic analyzer oder die sehen echt nicht richtig aus

Hier nochmal mit 12.5MHz. Das sollte der eigentlich packen (mit 24MHz 
Sampling Rate)

Ich habe jetzt mal ein anderes Simulationsmodell genommen und damit 
funktioniert das Lesen nicht mehr.

> Auch gab's Schwierigkeiten wenn ich die sdram clock durch die pll
> nicht um, ich glaube es waren - 54 Grad, zur main clock des designs
> versetzt habe. Aber letzteres ist wohl eher abhängig vom Chip der auf
> deinem board ist.

Bei -54 Grad ist es noch schlimmer

Oh und mir ist gerade aufgefallen, dass der Buffer auf 8 und nicht 256 
stand. Bei 256 sieht die ganze Sache nochmal schlechter aus. (Wenn ich 
den Buffer aber zu klein mache, werden die Daten nicht mehr schnell 
genug übertragen)

Bekommst du dein Speichercontroller ueberhaupt in einem Minimalistischen 
System zum laufen? Einfach mal 128 Werte in Speicher schreiben und 
wieder auslesen.

Hast du keinen internen Logic Analyzer via JTAG angeschlossen? So wirst 
du nie fertig mit debuggen.

Die ganzen Bilder sehen aus, als haettest du neben Problemen im Code 
(oder Bandbreite, das kann man noch nicht sehen) auch Probleme mit 
deinen Timings. Zumindest spricht die Messung bei -54 Grad dafuer 
(sofern das ueberhaupt noch im erlaubten Temperaturbereich ist).

Tobias B. schrieb:
> Hast du keinen internen Logic Analyzer via JTAG angeschlossen? So wirst
> du nie fertig mit debuggen.

Oh es gibt ja bei Quartus auch nen Logic Analyzer? Ja ich glaub den 
probier ich auch mal

Tobias B. schrieb:
> Speicherbandbreite zu untersuchen ist mit das undankbarste was es in
> einer Simulation gibt.

Ja, stimmt. Daher gucke ich mir gerne so Telemetrie an. Also alle 
Kollisionen wenn FIFO voll aber trotzdem geschrieben werden muss werden 
gezählt und in ein Register geschrieben. Das kann ich über UART auslesen 
und zurücksetzen.

Leon B. schrieb:
> Hier nochmal mit 12.5MHz. Das sollte der eigentlich packen (mit 24MHz
> Sampling Rate)

Taste das deutlich schneller ab. Du willst ja genau sehen wann in 
Relation zu Daten und Adresse die Taktflanke ankommt.
Als LA empfehle ich einen aus dieser Liste:
https://sigrok.org/wiki/Supported_hardware
Ich habe den Sysclk LWLA1034 und bin sehr zufrieden. Gibt es aber glaube 
ich nicht mehr zu kaufen.  Jedenfalls für <100€ gibt es bei eBay Geräte 
mit 16 Kanälen und 100 MHz Abtastrate. Sowas wäre bei dir geeignet.

Leon B. schrieb:
> Oh und mir ist gerade aufgefallen, dass der Buffer auf 8 und nicht 256
> stand. Bei 256 sieht die ganze Sache nochmal schlechter aus.

Welcher Buffer? Bei Video muss man mit Latenzen aufpassen. Wenn ein 
Pixel ausgegeben werden soll, dann reicht es nicht, wenn man dann erst 
anfängt dieses aus dem RAM zu holen und das dann noch einen FIFO 
durchlaufen muss. Da gibt es verschiedene Ansätze, z. B. kann man in der 
horizontalen Lücke immer die nächste Zeile aus dem RAM lesen und in 
einen BRAM stecken.

Tobias B. schrieb:
> Bekommst du dein Speichercontroller ueberhaupt in einem Minimalistischen
> System zum laufen? Einfach mal 128 Werte in Speicher schreiben und
> wieder auslesen.

Exakt sowas würde ich versuchen. Erstmal den Speicher an z. B. UART 
anschließen und da vom PC aus mit einem Script Daten reinfüllen, und 
wieder rauslesen und dann vergleichen. Das ist dann aber langsam und 
testet vielleicht noch nicht gut ob du den Refresh richtig gemacht hast.
Danach kannst du im FPGA viele Daten erzeugen, sehr schnell ins RAM 
schreiben und diese dann vom PC/UART auslesen und vergleichen oder auch 
schnell im FPGA auslesen und vergleichen. Da kannst du dann auch 
ausprobieren ab welchem Takt das nicht mehr fehlerfrei funktioniert.

Gustl B. schrieb:
> Taste das deutlich schneller ab. Du willst ja genau sehen wann in
> Relation zu Daten und Adresse die Taktflanke ankommt.
Hab mir mal den Inno-Maker LA1010 gekauft. Der kann 100 MHz.
Eigentlich wollte ich den Signal Tap Logic Analyzer ausprobieren, aber 
da kommt "Invalid data received" und "Error (261003): Can't continue the 
established JTAG communication.  Reconnect communications cable and 
device".

> Welcher Buffer? Bei Video muss man mit Latenzen aufpassen.
Es werden immer die 8 pixel, die als nächstes gebraucht werden aus dem 
SDRAM gelesen, im internen RAM gespeichert und dann wenn sie vom HDMI 
Interface gebraucht werden ausgelesen.

> Tobias B. schrieb:
>> Bekommst du dein Speichercontroller ueberhaupt in einem Minimalistischen
>> System zum laufen? Einfach mal 128 Werte in Speicher schreiben und
>> wieder auslesen.
Also mit dem Beispiel von Arduino (gleiche SDRAM Einstellungen und mit 
NIOS Prozessor) funktioniert der RAM.

Leon B. schrieb:
> Es werden immer die 8 pixel, die als nächstes gebraucht werden aus dem
> SDRAM gelesen, im internen RAM gespeichert und dann wenn sie vom HDMI
> Interface gebraucht werden ausgelesen.

OK, das kann man so machen. Aber man muss beachten, dass das Lesen aus 
dem DRAM und auch der BRAM Latenz haben. Wenn du also im Takt n das 
erste dieser 8 Pixel brauchst, dann reicht es nicht im Takt n-1 mit dem 
Lesen anzufangen, sondern schon viele Takte vorher, da kann ja auch 
immer ein DRAM Refresh dazwischenkommen.

Gustl B. schrieb:
> OK, das kann man so machen. Aber man muss beachten, dass das Lesen aus
> dem DRAM und auch der BRAM Latenz haben. Wenn du also im Takt n das
> erste dieser 8 Pixel brauchst, dann reicht es nicht im Takt n-1 mit dem
> Lesen anzufangen, sondern schon viele Takte vorher, da kann ja auch
> immer ein DRAM Refresh dazwischenkommen.

Ja deswegen hab ich immer zwei von denen aneinander.
1. Der liest die Daten aus dem 1. buffer für die HDMI Daten
2. Wenn der am Ende angekommen ist, werden neue Daten von dem SDRAM 
angefordert und die letzten SDRAM Daten werden aus dem 2. buffer kopiert
3. Daten aus dem SDRAM werden in den 2. buffer geschrieben

Und nach der Simulation (die für den internen RAM ja funktionieren 
sollte) funktioniert das ganze auch

Ja also ich habe jetzt einen Controller genommen der Bursts mit 8 
Wörtern unterstützt, habe die Auflösung auf 16 bit reduziert (sodass die 
Pixel nicht mehr in mehrere Wörter aufgeteilt werden und habe die 
Frequenz auf 80MHz reduziert. Dabei gibt es immernoch einige Flasche 
Pixel, aber ich habe mich jetzt erstmal auf die Bilderkennung 
konzentriert.

Gibt es nicht auf Github oder so schon ein Projekt wo von einer Kamera 
die Daten an ein Display weitergeleitet werden?