Forum: FPGA, VHDL & Co. [S]uche VHDL Experte für Unterstützung im Projekt


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 Holger K. (holgerkraehe)


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

von -gb- (Gast)


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

von Holger K. (holgerkraehe)


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

von -gb- (Gast)


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

von Holger K. (holgerkraehe)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
-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
von Martin S. (strubi)


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

von Holger K. (holgerkraehe)


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

von -gb- (Gast)


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

von Holger K. (holgerkraehe)


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

von Gustl B. (-gb-)


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

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
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
von Gustl B. (-gb-)


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

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
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:
type t_Memory_row is array (0 to 47) of integer range 0 to 65535;
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.

von Gustl B. (-gb-)


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

von Holger K. (holgerkraehe)


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

von Gustl B. (-gb-)


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

von Achim S. (Gast)


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

von Gustl B. (-gb-)


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

von Holger K. (holgerkraehe)


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

von Achim S. (Gast)


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

von Gustl B. (-gb-)


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

von Robert P. (fpgazumspass) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Holger K. (holgerkraehe)


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

von SB (Gast)


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

von Achim S. (Gast)


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

von Holger K. (holgerkraehe)


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

von Achim S. (Gast)


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

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.