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
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.
:
Bearbeitet durch User
Danke für die Antworten! Werde das dann ausprobieren und mal hoffen, dass sich da was finden lässt
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
> 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.
:
Bearbeitet durch User
Sieht irgendwie scheisse aus das dritte Bild
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.
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!
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.
:
Bearbeitet durch User
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
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.
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?
Bitte 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.