mikrocontroller.net

Forum: FPGA, VHDL & Co. QSYS SDRAM Controller funktioniert in Simulation aber nicht mit echter Hardware


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 Leon B. (leonbeier)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Hallo,

ich habe mir so ein ARDUINO MKR VIDOR 4000 gekauft und wollte jetzt mal 
CSI Kamera und HDMI ausprobieren. Das funktioniert auch schon wenn ich 
die Daten komprimiere und im internen RAM speicher, aber wenn ich die 
Auflösung beibehalten will und die Daten in dem SDRAM zwischenspeichere 
nicht mehr.

Hier mein Projekt: 
https://github.com/leonbeier/VHDPlus_Libraries_and_Examples/tree/master/Examples/Hardware/Input/SDRAM_Camera
Und die SDRAM Controller Controller Datei:
https://github.com/leonbeier/VHDPlus_Libraries_and_Examples/blob/master/Examples/Hardware/Input/SDRAM_Camera/Camera/Camera_Capture_SDRAM.vhdp
(Nicht wundern: Ist mit meiner eigenen Sprache geschrieben aber im 
Generated Ordner sind auch die VHDL Dateien)

Es werden die Daten immer zu 256 Wörtern à 16bit zusammengefasst und in 
den RAM geschrieben und wieder ausgelesen.
Für die Einstellungen habe ich die gleichen genommen wie in dem 
offiziellen Projekt von Arduino (100MHz CLK und 180° Phasenverschiebung 
für SDRAM CLK).

Ich würde ja auch gerne das mit nem full page Burst machen, aber da hab 
ich keinen kostenlosen Controller gefunden, der mehr als 8 Wörter 
unterstützt.

Vielleicht hab ihr ja auch generell einen Vorschlag wie ich das besser 
machen kann.

Vielen Dank im Voraus!
Leon

: Bearbeitet durch User
von Leon B. (leonbeier)


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

von Lothar M. (lkmiller) (Moderator) Benutzerseite


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

von Leon B. (leonbeier)


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

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


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

von Gustl B. (gustl_b)


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

: Bearbeitet durch User
von Leon B. (leonbeier)


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

von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Leon B. schrieb:
> und die Pixel in ihrer Position nicht bleiben
Vermutlich ist das Auslesen der Daten aus dem SDRAM mit Jitter behaftet.

Hast Du zwischen SDRAM und HDMI-out einen FIFO drin?
Kannst Du beim SDRAM den Autorefresh abschalten?

Duke

von Leon B. (leonbeier)


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

von Leon B. (leonbeier)


Angehängte Dateien:

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

: Bearbeitet durch User
von Truthahnsandswich (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
Sieht irgendwie scheisse aus das dritte Bild

von Leon B. (magischerrauch)


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

von Gustl B. (-gb-)


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

von Romani (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Nein, ich widerspreche mir hiermit selbst

Lass das nicht zur Gewohnheit werden!

von Christian G (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mit der sdram controller qsys Komponente hab ich immer Probleme wenn ich 
das qsys generieren lassen und vhdl anstelle von verilog ausgewählt 
habe. 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. Gab auch schon so kuriose Sachen wie qsys generiert, 
getestet -> komische Fehler wie z.b. Avalon waitrequest wird nicht mehr 
released, zig Sachen erfolglos probiert um es zu fixen, einfach nochmal 
das qsys generiert und der Fehler tauchte nie wieder auf. Sowas ist für 
mich als noob natürlich ganz toll!

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


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

von Leon B. (leonbeier)


Angehängte Dateien:

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

von Leon B. (leonbeier)


Angehängte Dateien:

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

von Leon B. (leonbeier)


Angehängte Dateien:

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

von Leon B. (leonbeier)


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

von Leon B. (leonbeier)


Angehängte Dateien:

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

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


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

von Leon B. (leonbeier)


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

von Gustl B. (-gb-)


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

von Leon B. (leonbeier)


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

: Bearbeitet durch User
von Gustl B. (-gb-)


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

von Leon B. (leonbeier)


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

von Christophz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Leon B. schrieb:
> Ich würde ja auch gerne das mit nem full page Burst machen, aber da hab
> ich keinen kostenlosen Controller gefunden, der mehr als 8 Wörter
> unterstützt.

Die Controller unterstützen das, was auch der RAM Chip unterstützt. Das 
SDRAM unterstützt Bursts von 8 Wörtern (weil intern eine ?Row? gerade so 
lange ist). Das ist dann auch die typische Cacheline Länge eines 
Prozessors aus der selben Zeit. Nach einem solchen Burst muss zwingend 
neu Adressiert werden.

Aber du kannst dir natürlich so etwas ähnliches wie ein DMA Controller 
darüber bauen, der sich dann um ganze Pages kümmert.

von Leon B. (leonbeier)


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

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.

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