Hallo zusammen Ich suche Unterstützung von einem VHDL-Experten in einem VHDL Projekt gegen Bezahlung. Projekt: Stickwort: Lokales dimmen der Hintergrundbeleuchtung. Es handelt sich um eine HW mit FPGA (Lattice MachxO3 FPGA) und einer Leiterplatte mit 250 LEDs. Die LEDs lassen sich mittels eines Schieberegisters einzeln dimmen. Das FPGA bekommt zusätzlich noch RGB-Daten. Ziel ist es nun, aus den RGB-Daten die zugehörigen LEDs zu steuern. So dass bereiche welche aufgrund des Bildinhalts weniger hell sind, auch das zugehörige LED entspreched gedimmt werden. Stand: Es existiert bereits eine VHDL Basis. Grundsätzlich geht es aktuell darum, das einsampeln der RGB-Daten, die anschliessende Verrechnung gemäss Algorithmus und die Ausgabe an den LED-Treiber umzusetzen. Der LED-Treiber als solches ist ebenfalls bereits als VHDL-Modul vorhanden. Hier gibt es bereits eine vergleichbare Arbeit in Verilog: http://acikerisim.deu.edu.tr:8080/xmlui/bitstream/handle/20.500.12397/8265/276466.pdf?sequence=1&isAllowed=y Vorgehen: Interessenten bitte per PN melden. Anschliessend kann eine kurzes Meeting per Teams oder Skype durchgeführt werden. Darin würde ich das Projekt kurz zeigen. Freue mich auf eure Rückmeldung.
Klingt jetzt nicht so irre schwer. Wo kommen die RGB Daten denn her? Mit dem machxo3 wirst du kaum direkt HDMI/DP abtasten. Für die LEDs hast du dann intern einen Speicher mit den 250 Helligkeitswerten. PWM ist auch einfach, serielle Ausgabe der Bits ebenfalls.
-gb- schrieb: > Wo kommen die RGB Daten denn her? Mit > dem machxo3 wirst du kaum direkt HDMI/DP abtasten. Die RGB-Daten liegen bereits digital an. Sprich, HSYNC, VSYNC etc. Auch die Auswertung wurde bereits umgsetzt. Spricht, X und Y Koordinaten mit den zugehörigen 3x 8-Bit RGB-Werten sind vorhanden. -gb- schrieb: > Für die LEDs hast du dann intern einen Speicher mit den 250 > Helligkeitswerten. PWM ist auch einfach, serielle Ausgabe der Bits > ebenfalls. PWM muss nicht vom FPGA gemacht werden. Dies wird bereits durch den externen Treiber umgesetzt. Das FPGA muss lediglich pro LED einen 16-Bit Helligkeitswert in ein Schieberegister schieben. Damit ist gemeint, dass die 250 LEDs aus sicht des FPGAs wie ein Schieberegister mit 250x16Bit aussehen. Dies bedeutet aber auch, dass immer alle LEDs auf einmal aktualisiert werden müssen. Die Ansteuerung des externen Treibers ist ebenfalls bereits vorhanden,. Ein Bild entspricht je nach Auflösung z.b. 1920 x 720 Pixel (in diesem Beispiel). Diese Pixel teilen sich nun auf über 250 LEDs. Jedes LED entspricht nun sozusagen einem Hintergrundbeleuchtungssegment. Ein Segment umfasst nun eine bestimmte Anzahl pixel. z.B. 20 x 20 pixel. Die Aufgabe besteht nun darin, diese 20x20 pixel pro segment (davon gibts ja eben 250) zu sammeln und zu verrechnen. mit verrechnen ist gemeint, die Helligkeit dieses Segments gemäss einem Algorithmus (davon gibt es bereits welche im Internet, auch in verilog) zu berechnen und aufgrund dieses Wertes nun die Helligkeit des entsprechenden LEDs zu setzen. Da die LEDs über ein Schieberegister angesteuert werden, müssen immer alle LEDs auf einmal aktualisiert werden. Daher muss deren Wert zwischengespeichert werden. Pro LED sind 16-Bit PWM möglich. Somit 244 x 16-Bit = 3904 Bit. Ich glaube das sollte noch ins Block-Ram passen. Eine Schwierigkeit bei diesem Projekt besteht darin, die Positionen zu mappen. Sprich, du musst ja dafür sorgen, dass die Information vom Segment oben links (X=0,Y=0) auch bei der Hintergrundbeleuchtung die LED an Position 0,0 ansteuert. Dieses Mapping hat bisher bei meinen Versuchen zu einer ungeheuer grossen Logik geführt. Da zu jedem Zeitpunkt (Pixel-Takt) jede mögliche Position geprüft wurde.
Holger K. schrieb: > Dies bedeutet aber auch, dass immer alle LEDs auf einmal aktualisiert > werden müssen. > Die Ansteuerung des externen Treibers ist ebenfalls bereits vorhanden,. Wunderbar! Holger K. schrieb: > Ich glaube das sollte noch ins Block-Ram passen. Das sind nicht viele Daten. Holger K. schrieb: > Da zu jedem Zeitpunkt (Pixel-Takt) jede mögliche Position geprüft wurde. Verstehe ich nicht. Die Pixel kommen doch vermutlich schön nacheinander an. Dann kann man über horizontale und vertikale Position also bestimmen zu welcher led das pixel gehört und die Farbinformation des einkommenden Pixels in die led Helligkeit einarbeiten. Wenn man sein led datenarray etwas geschickt anlegt, dann sieht das so aus wie das Bild nur eben mit niedrigerer Auflösung. Wie schnell werden die bits denn in die Schieberegister geschoben? Schnell genug um das für jedes Frame aktualisieren zu können?
Angehängte Dateien:
-
LEDZuordnung.PNG
14 KB
-gb- schrieb: > Verstehe ich nicht. Die Pixel kommen doch vermutlich schön nacheinander > an. Dann kann man über horizontale und vertikale Position also bestimmen > zu welcher led das pixel gehört und die Farbinformation des einkommenden > Pixels in die led Helligkeit einarbeiten. > Wenn man sein led datenarray etwas geschickt anlegt, dann sieht das so > aus wie das Bild nur eben mit niedrigerer Auflösung. > > Wie schnell werden die bits denn in die Schieberegister geschoben? > Schnell genug um das für jedes Frame aktualisieren zu können? Grundsätzlich richtig. Aktuell ist der Pixelclock bei ca. 75MHz. Nun gibt es mehrere optionen. Entweder es werden zuerst alle Pixel gesammelt und erst am ende verrechnet (erfordert somit ein Abbild eines Frames im FPGA. Dazu ist nicht genügend Speicher vorhanden). Oder aber es wird jedes einkommende Pixel in die Helligkeit eingearbeitet, so wie du dies beschrieben hast. Dies hängt dann auch etwas vom vorhandenen algorithmus ab. Bei der einarbeitung pro Pixel muss jedoch berücksichtigt werden, dass die Rechenoperation nicht mehr wie 1-Takt benötigen darf, oder es muss mittels PLL eine Frequenzerhöhung stattfinden. Alternativ könnte die Berechnung auch Segment-Reihenweise am Ende jeder Reihe durchgeführt werden. (front-porch area) Was jedoch zu probleme führen könnte ist die Tatsache, dass die LEDs bzw. die Daten des Schieberegisters nicht gleich angeordnet sind, wie die einlaufenden Daten des Displays. Beim Display laufen die Daten von oben link nach unten rechts. Bei dem LED-Array ist das Mapping von obel links nach unten und dann wieder nach oben. (siehe Bild im Anhang). Dies kann bei ungeschickter Implementierung zu einem Problem werden. -gb- schrieb: > Wie schnell werden die bits denn in die Schieberegister geschoben? > Schnell genug um das für jedes Frame aktualisieren zu können? Die Treiber können 25MHz SPI. Dies aufgeteilt auf die anzahl bits ergibt eine Refresh-Rate von 6.4kHz Daher wollte ich eigentlich die Aktualisierung nach jeder Segment(LED)-Zeile durchführen.
:
Bearbeitet durch User
Moin, Holger K. schrieb: > Was jedoch zu probleme führen könnte ist die Tatsache, dass die LEDs > bzw. die Daten des Schieberegisters nicht gleich angeordnet sind, wie > die einlaufenden Daten des Displays. Deiner Grafik nach ist das ja einfach nur eine Vertauschung von Address-Bits. Also brauchst du nur einen Pingpong-Buffer fuer die Datenbloecke, allenfalls noch ein extra FIFO wegen unterschiedlicher Taktdomaenen. Sollte nicht gross anders sein als bei den unzaehligen Neopixel-Implementationen. Koennte mit CPU-Kern noch auf einen MachXO2 7k passen.
Danke für deine Antwort. Nun, das hört sich doch vielversprechend an. So wie du darüber schreibst, scheint dies ja eine relativ kurze implementierungsarbeit zu sein? Wärst du denn daran interessiert, dies umzusetzen?
Holger K. schrieb: > Bei der einarbeitung pro Pixel muss jedoch berücksichtigt werden, dass > die Rechenoperation nicht mehr wie 1-Takt benötigen darf, oder es muss > mittels PLL eine Frequenzerhöhung stattfinden. Man kann auch Pipelines bauen. Holger K. schrieb: > Daher wollte ich eigentlich die Aktualisierung nach jeder > Segment(LED)-Zeile durchführen. Ja das kann man dann tatsächlich machen. Wie arbeiten eigentlich aktuelle lcd Monitore? Speichern die ein komplettbild und zeigen es dann an wenn es vollständig angekommen ist oder zeichnen die jedes pixel sobald es ankommt? Bei der led Beleuchtung wäre es ja gut wenn die möglichst zeitgleich zu dem Bild gezeichnet wird
-gb- schrieb: > Man kann auch Pipelines bauen. Genau deshalb brauche ich jemanden, der sich damit auskennt :) -gb- schrieb: > Ja das kann man dann tatsächlich machen. > > Wie arbeiten eigentlich aktuelle lcd Monitore? Speichern die ein > komplettbild und zeigen es dann an wenn es vollständig angekommen ist > oder zeichnen die jedes pixel sobald es ankommt? > Bei der led Beleuchtung wäre es ja gut wenn die möglichst zeitgleich zu > dem Bild gezeichnet wird Aktuelle TFT-Panels aktualisieren Pixel für Pixel, so wie es gerade rein kommt. Ja, eine möglichst zeitgleiche aktualisierung wäre wünschenswert. Nur ist dies frühestens nach z.B. 20 Zeilen möglich, wenn eine LED beuspielsweise 20x20 Pixel abdeckt. Denn vorher ist noch nicht bekannt, welche Helligkeit das Segment tatsächlich haben wird. Daher wäre die schnellste Möglichkeit, das Segment-Zeilenweise aktualiseren. Somit z.B. immer nach 20 RGB-Pixelzeilen.
Holger K. schrieb: > Aktuelle TFT-Panels aktualisieren Pixel für Pixel, so wie es gerade rein > kommt. Danke! Holger K. schrieb: > Ja, eine möglichst zeitgleiche aktualisierung wäre wünschenswert. Klingt vernünftig. Die Alternative wäre ja, dass man ein Vollbild zwischenspeichert und dann das Bild gemeinsam, also synchron mit den LED Daten ausgibt. Braucht aber viel RAM. Immerhin kannst du zum Glück die LEDs schnell genug ansteuern und musst nicht die Helligkeitswerte aus mehreren Bildern für eine LED-Aktualisierung zusammenrechnen.
Gustl B. schrieb: > Klingt vernünftig. Die Alternative wäre ja, dass man ein Vollbild > zwischenspeichert und dann das Bild gemeinsam, also synchron mit den LED > Daten ausgibt. Braucht aber viel RAM. > Immerhin kannst du zum Glück die LEDs schnell genug ansteuern und musst > nicht die Helligkeitswerte aus mehreren Bildern für eine > LED-Aktualisierung zusammenrechnen. Was auch noch möglich wäre: Das Schieberegister bzw. die LED-Controller schieben am Ende die Datenbits wieder heraus. So könnte man diesen Datenstrom wieder ins FPGA rein nehmen und so zusagen rotieren lassen. Nun müsste lediglich an der richtigen Stelle die 16-Bit Werte ausgetauscht werden. Genau hier sehe ich den Knackpunkt. Dieses Mapping von XY-RGB Position zu XY-LED Position. Hier hat es mir bisher die Logik aufgebläht. (aktuell ist jedoch keine Rückführung der Daten vorhanden.)
:
Bearbeitet durch User
Holger K. schrieb: > Das Schieberegister bzw. die LED-Controller schieben am Ende die > Datenbits wieder heraus. Naja, aber wozu sollte man die LED Helligkeiten wieder im FPGA brauchen? Holger K. schrieb: > Genau hier sehe ich den Knackpunkt. Dieses Mapping von XY-RGB Position > zu XY-LED Position. Hier hat es mir bisher die Logik aufgebläht. Martin S. schrieb: > Deiner Grafik nach ist das ja einfach nur eine Vertauschung von > Address-Bits. Sollte also eher wenig Logik brauchen.
Gustl B. schrieb: > Naja, aber wozu sollte man die LED Helligkeiten wieder im FPGA brauchen? Damit könnte man sich das vorhalten aller Helligkeitswerte ersparen. Da es sich bei den LEDs um ein Schieberegister handelt, muss man immer alle LEDs aktualisieren. Daher muss man im FPGA auch immer über die Helligkeitswerte aller LEDs verfügen. Wenn man nun die Daten rückführt, so muss man nur noch über die Helligkeitswerte einer einzelnen LED-Zeile verfügen. Im aktuellen Design sind dies 16 Zeilen. Somit muss man nur noch über 1/16 an Daten vorhalten. Wenn es auch auf herkömmlichem Wege geht, ist dies natürlich nicht zwingend notwendig. Das aktuelle array sah wie folgt aus:
1 | type t_Memory_row is array (0 to 47) of integer range 0 to 65535; |
2 | type t_Data_6Chip is array (0 to 5) of t_Memory_row; |
Der aufmerksame Leser wird bemerken, es handelt sich hierbei um 288 Einträge. Es sind auch tatsächlich 288 LEDs. Die obig erwähnten 250 LEDs waren einfach als "Hausnummer" genannt worden.
Tatsächlich 6 Zeilen je 48 LEDs? OK ... Ist das für eine feste Bildschirmauflösung gedacht oder darf sich die wild ändern auch im Seitenverhältnis von z. B. 16:9 bis 4:3. Und was macht der Monitor bei 4:3? Hat der dann auf beiden Seiten schwarze Balken bei denen die LEDs aus seien müssen?
Gustl B. schrieb: > Tatsächlich 6 Zeilen je 48 LEDs? OK ... Nein, in wirklichkeit sind es 16 Zeile zu je 18 LEDs. Aber pro Treiber IC (TLC5955) können 48 LEDs angesprochen werden. Daher 6 ICs * 48 Helligkeitswerte. Gustl B. schrieb: > Ist das für eine feste Bildschirmauflösung gedacht oder darf sich die > wild ändern auch im Seitenverhältnis von z. B. 16:9 bis 4:3. Und was > macht der Monitor bei 4:3? Hat der dann auf beiden Seiten schwarze > Balken bei denen die LEDs aus seien müssen? Das ist für eine feste Bildschirmauflösung. Hintergrundbeleuchtung muss zum Display passen. Daher fix. Natürlich ist es denkbar, auf Basis dieses Designs dann weitere, davon in der Spezifikation abweichende umzusetzen. gb: hast du das Gefühl, dass du diese Umsetzung durchführen kannst?
Holger K. schrieb: > Aber pro Treiber IC (TLC5955) können 48 LEDs angesprochen werden. Ah, man hat einen IC der die PWM macht, das ist fein. Ich habe hier auf meiner Bastelplatine zwei normale Schieberegister und mache da auf allen 16 Ausgängen PWM. Da muss dann aber auch schnell geschoben werden. Holger K. schrieb: > Das ist für eine feste Bildschirmauflösung. > Hintergrundbeleuchtung muss zum Display passen. Daher fix. Um so schöner. Holger K. schrieb: > gb: hast du das Gefühl, dass du diese Umsetzung durchführen kannst? Ich mache das nur als Hobby und habe noch nie etwas mit einem Lattice FPGA gemacht. An deiner Stelle würde ich das im Forum unter Ausbildung & Beruf als Sellenanzeige posten. Aber da du ja selbst schon angefangen hast könntest du ja auch Code posten und dir wird weitergeholfen. Cool wäre eine Testbench die die ankommenden Pixeldaten mit HSync und VSync simuliert und als Ausgabe auch das LED Array beinhaltet. Aber ich helfe auch gerne so eine Testbench zu schreiben. Dazu müsstest du aber genau erklären wie die Pixeldaten ankommen, von welcher Hardware mit Datenblatt oder du beschreibst einfach das Timing. Für mich klang das so als wäre das ein externer 75 MHz Takt und mit jedem Takt kommen 8 Bit je Farbe und zusätzlich HSync und VSync. Stimmt das? Sind die 6 PWM ICs hintereinander in Serie oder hat da jeder seine eigene FPGA-Anbindung?
Gustl B. schrieb: > Aber ich helfe auch gerne so eine > Testbench zu schreiben. Dazu müsstest du aber genau erklären wie die > Pixeldaten ankommen, von welcher Hardware mit Datenblatt oder du > beschreibst einfach das Timing. Für mich klang das so als wäre das ein > externer 75 MHz Takt und mit jedem Takt kommen 8 Bit je Farbe und > zusätzlich HSync und VSync. Das Thema hatten wir schonmal. Damals ging es im Kern darum, ein Mapping von X/Y-Positionen auf eine Postition im Datenstrom hinzukriegen. Beitrag "Re: FPGA überfüllt -> Brauche Hilfe bei der Optimierung." (und wie ich den aktuellen Thread lese, hat sich an der Problemstellung nichts geändert). Damals hatte ich vorgeschlagen, ein Block-ROM zu verwenden, dass für jede Position im Datenstrom die Position im X-Y Array angibt. Dann zählt man die Stelle im Datenstrom per Zähler durch und benutzt den Zähler als Adresse für das Block-ROM - an dessen Ausgang liegen dann die benötigten X-Y Werte. Ich denke immer noch, dass das die Lösung des Problems ist. Das Mapping stattdessen in einer komplexen Logik abzubilden, hat damals die Ressourcen des FPGAs gesprengt. Eine fest abgespeicherte Zuordnungstabelle sollte es tun. (Wenn das ganz im Betrieb umkonfigurierbar werden soll, müsste die Zuordnungstabelle natürlich überschreibbar gestaltet werden).
Achim S. schrieb: > Das Thema hatten wir schonmal. Damals ging es im Kern darum, ein Mapping > von X/Y-Positionen auf eine Postition im Datenstrom hinzukriegen. > Beitrag "Re: FPGA überfüllt -> Brauche Hilfe bei der Optimierung." > (und wie ich den aktuellen Thread lese, hat sich an der Problemstellung > nichts geändert). Sorry, kannte ich nicht. Nun, ich würde ja den Bildschirm, also den x-y-Adressraum in Bereiche unterteilen und mir ein 2D-Array mit den Werten für die LED anlegen. Wenn ein neues Frame kommt wird das Array mit 0 belegt. Und dann wird eben verglichen anhand von x und y in welchen Bereich das aktuelle Pixel fällt und dort dann das Arryelement irgendwie bearbeitet. Bei den Zeilen kann man auch einfach zählen, also wenn du 1080 Pixel vertikal hast und z. B. 16 Zeilen, dann zählst du nach dem front Prorch mit jeder 68. Zeile den Zeilenzähler nach oben. Und der wird dann für das LED-Array ebenfalls die Zeilenadresse. Ich habe aber tatsächlich keine Vorstellung davon wie sehr man in diesem FPGA eingeschränkt ist. Wenn ich die Tage mal viel Zeit habe schreibe ich eine Testbench ...
Gustl B. schrieb: > Cool wäre eine Testbench die die > ankommenden Pixeldaten mit HSync und VSync simuliert und als Ausgabe > auch das LED Array beinhaltet. Ein solcher Testbench ist bereits vorhanden. Ich könnte aktuell das jetzige Projekt noch unaufgeräumt hochladen wenn jemand interesse hat? Achim S. schrieb: > Damals hatte ich vorgeschlagen, ein Block-ROM zu verwenden, dass für > jede Position im Datenstrom die Position im X-Y Array angibt. Dann zählt > man die Stelle im Datenstrom per Zähler durch und benutzt den Zähler als > Adresse für das Block-ROM - an dessen Ausgang liegen dann die benötigten > X-Y Werte. Ja das ist korrekt. Leider hat es bei der Umsetzung nicht so funktioniert wie ich mir das vorgestellt habe. Gustl B. schrieb: > Wenn ein neues Frame kommt wird das Array mit 0 belegt. Und dann wird > eben verglichen anhand von x und y in welchen Bereich das aktuelle Pixel > fällt und dort dann das Arryelement irgendwie bearbeitet. Genau nach diesem Prinzip bin ich vorgegangen. Und dieses Mapping von X und Y Bereichen zu einer Array-Position führt zu unglablich grosser Logik. Gustl B. schrieb: > Ich habe aber tatsächlich keine Vorstellung davon wie sehr man in diesem > FPGA eingeschränkt ist. > Wenn ich die Tage mal viel Zeit habe schreibe ich eine Testbench ... Ich stelle gerne die bisher vorhandenen Projektdaten bereit. Gerne auch als github Projekt.
Holger K. schrieb: > Genau nach diesem Prinzip bin ich vorgegangen. Und dieses Mapping von X > und Y Bereichen zu einer Array-Position führt zu unglablich grosser > Logik. Die mapping-Info muss als Tabelle im RAM liegen - und damit entseht praktisch überhaupt keine Logik. Dein Problem ist wahrscheinlich, dass du versucht hast, die Berechnung dieser Tabelle als VHDL-Code zu beschreiben und dass damit - unbeabsichtigt - die Berechnungsformeln als Logik implementiert wurde. - Schreibe irgendeine Software, die dir die Mapping-Daten als Textfile schreibt. (am besten nicht in VHDL, denn dann kann daraus keine Logik generiert werden) - Nutze einen IP-Generator, um dir ein Block-RAM generieren zu lassen. Dann bist du sicher, dass es Block-RAM wird (deine Versuche, das BLock-RAM in VHDL zu beschreiben, sind bisher gescheitert und haben zu riesiger Logik geführt). - Gib dem IP-Generator das Mapping-File als Inhalt, mit dem das Block-RAM vorbelegt wird.
Wie kommt man eigentlich von den Pixeldaten zur LED Helligkeit? Bei 288 LEDs und jetzt als Beispiel 1920x1080 Pixeln sind das also 7200 Pixel je LED. Werden da stumpf alle Helligkeiten dieser Pixel aufsummiert und am Ende auf die 16 Bits für die PWM skaliert?
So wie ich das verstanden habe (aus dem Paper) ist das so. Da werden die Werte aufsummiert und am Ende durch die Anzahl geteilt. Bei 130Mhz+ (1920*1080) in einem MachXO3(welcher eigentlich?) wird das eine sehr sportliche Aufgabe. Deshalb bin ich überrascht, dass die Aufgabe für so leicht gehalten wird. Aber vielleicht irre ich mich auch, habe nur mal mit einem MachXo2 mit langsamsten Speedgrade gearbeitet und der konnte soweit ich mich erinnern kann keine 100Mhz an den Blockrams. edit: stimmt, das Datenblatt gibt Blockrams beim X02 mit 90Mhz an für den -3 Speedgrade, der Xo3 schafft aber schon 183Mhz im -6(schnellsten) Speedgrade
:
Bearbeitet durch User
Achim S. schrieb: > Die mapping-Info muss als Tabelle im RAM liegen - und damit entseht > praktisch überhaupt keine Logik. Stimmt, das macht Sinn! Gustl B. schrieb: > Wie kommt man eigentlich von den Pixeldaten zur LED Helligkeit? Die Helligkeit eines Pixels lässt sich wie folgt berechnen: Berechnung des HueWertes: https://stackoverflow.com/questions/596216/formula-to-determine-brightness-of-rgb-color Y = 0.299 R + 0.587 G + 0.114 B Gustl B. schrieb: > Bei 288 LEDs und jetzt als Beispiel 1920x1080 Pixeln sind das also 7200 Nun, in diesem Beispiel sind es 1920 x 720 Pixel Daher also 4800 Pixel Gustl B. schrieb: > Werden da stumpf alle Helligkeiten dieser Pixel > aufsummiert und am Ende auf die 16 Bits für die PWM skaliert? Das ist genau die Frage nach dem Algorithmus. Und hier gibt es sehr viele unterschiedliche Ansätze. Diese sind teilweise als Forschungsarbeiten verfügbar. Robert P. schrieb: > So wie ich das verstanden habe (aus dem Paper) ist das so. Da werden die > Werte aufsummiert und am Ende durch die Anzahl geteilt. Das ist wohl der einfachste Ansatz und der Funktioniert besser je mehr LED-Zonen vorhanden sind. Robert P. schrieb: > Bei 130Mhz+ (1920*1080) in einem MachXO3(welcher eigentlich?) wird das > eine sehr sportliche Aufgabe. Deshalb bin ich überrascht, dass die > Aufgabe für so leicht gehalten wird. Aktuell ein MachXO3-4300 speedgrade 6 Die ganze rechnerei der Helligkeit in einem Takt hat bereits einmal funktioniert mit multiplikator blöcken. Ohne das mapping war die Belegung des FPGAs bei ein paar wenigen Prozenten. Robert P. schrieb: > edit: stimmt, das Datenblatt gibt Blockrams beim X02 mit 90Mhz an für > den -3 Speedgrade, der Xo3 schafft aber schon 183Mhz im -6(schnellsten) > Speedgrade Speedgrade 6 ist vorhanden.
90 - 183 MHz gilt wohl für Single Bit transactions, wer schiebt bitte single bits in BRAM rein? Bei meinem letzten Projekt waren die Input Daten auch >90 MHz, die wurden dann einfach in 16bit Register aufgefangen und danach in den Speicher geschrieben. Effektive Anforderung war dann nur noch 5.625 MHz.
Robert P. schrieb: > Bei 130Mhz+ (1920*1080) in einem MachXO3(welcher eigentlich?) wird das > eine sehr sportliche Aufgabe. Deshalb bin ich überrascht, dass die > Aufgabe für so leicht gehalten wird. Das Berechnen der Helligkeitswerte kann durchaus eine Herausforderung für das FPGA werden - je nachdem, wie geschickt und aufwändig die Berechnung durchgeführt wird. Aber dafür hatte der TO ja schon eine funktionierende Implementierung. Gescheitert ist der TO bisher an einer Teilaufgabe, die sich sicher einfach lösen lässt: ein einfaches Ummapen von ein paar hundert Adressen, was sich sicher durch eine große Look-Up Table in einem BlockRAM lösen lässt. Dort ist der TO bisher gescheitert, weil seine Implementierung jeweils auf eine vielstufige kombinatorische Logik hinauslief, die die Adressabbildung "zur Laufzeit berechnen" wollte. Da die Adressabbildung fest ist, kann Sie vorab berechnet und in einem RAM gespeichert werden. Das einzige, was in dem Schaltungsteil ggf. mit der vollen Frequenz laufen muss, ist das Schieberegister zu seinen TLC5955. Aber wie SB schon schrieb kann der Rest der Logik dann auf einem Bruchteil der Frequenz laufen, mit dem das Schieberegister die Daten raustaktet.
Achim S. schrieb: > Das einzige, was in dem Schaltungsteil ggf. mit der vollen Frequenz > laufen muss, ist das Schieberegister zu seinen TLC5955. Aber wie SB > schon schrieb kann der Rest der Logik dann auf einem Bruchteil der > Frequenz laufen, mit dem das Schieberegister die Daten raustaktet. Nun, die restliche Logik muss ja auch mit mindestens dem Pixeltakt laufen oder nicht? Und dies wären dann 75MHz. Theoretisch wäre es auch möglich, den Takt zu halbieren und dafür anstatt mit 24-Bit, mit 48-Bits zu arbeiten. Das würde bedeuten, dass pro Pixeltakt dann einfach zwei Pixelinformationen gleichzeitig ankommen. Bisher habe ich dies aber als nicht sehr hilfreich erachtet.
Holger K. schrieb: > Nun, die restliche Logik muss ja auch mit mindestens dem Pixeltakt > laufen oder nicht? > > Und dies wären dann 75MHz. > > Theoretisch wäre es auch möglich, den Takt zu halbieren und dafür > anstatt mit 24-Bit, mit 48-Bits zu arbeiten. > > Das würde bedeuten, dass pro Pixeltakt dann einfach zwei > Pixelinformationen gleichzeitig ankommen. > > Bisher habe ich dies aber als nicht sehr hilfreich erachtet. Wenn du für den Rest der Logik schon eine funktionierende Lösung hast (wie du weiter oben schreibst), dann brauchst du daran nichts zu ändern. Löse das Problem, das jetzt deine Implementierung verhindert, statt dir den Kopf über bereits gelöste Probleme zu zerbrechen. Wenn du für den Rest der Logik keine funktionierende Lösung hättest, dann würde man analysieren, woran es hängt (z.B. an der erreichbaren Taktfrequenz), und dann nach Lösungen suchen (z.B. Parallelisierung, oder Pipelining komplizierter Berechnungen, ...) Aber das ist hier unnötig, denn: Holger K. schrieb: > Die ganze rechnerei der Helligkeit in einem Takt hat bereits einmal > funktioniert mit multiplikator blöcken. Ohne das mapping war die > Belegung des FPGAs bei ein paar wenigen Prozenten
Thread beobachten
Seitenaufteilung abschaltenBitte 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.