Hallo, ich habe ein Riesenproblem mit einer Schaltung, die ich mir ausgedacht habe und gerne irgendwie, evtl mit FPGA, realisieren möchte. Vom Prinzip her ist die Schaltung absolut trivial aber beim Aufbau mit TTL etc. würde ich auf einige tausend (das ist nicht übertrieben!) ICs kommen - von den Kosten mal abgesehen praktisch nicht machbar. Kurze Schaltungsbeschreibung: Es handelt sich um eine Videoanwendung. Von einem DVI-Receiver IC werden zur Verfügung gestellt: der Pixeltakt (ca. 100MHz), 24 bit Pixelinformation (3 * je 8 bit R, G, B), HSync. Zusätzlich existiert noch ein aus HSync generierter Countertakt. Mit diesen Signalen soll eine RGB LED-Zeile so angesteuert werden, dass jeweils eine Videozeile für das menschliche Auge korrekt dargestellt wird. Sinnvollerweise wird die LED nicht in Abhängigkeit des Helligkeitswertes gedimmt sondern unter Berücksichtigung der Trägheit des menschlichen Auges entsprechend getaktet so dass die Helligkeit korrekt wahrgenommen wird. Nachdem die Zeilenfrequenz sowieso weit über dem liegt was der Mensch wahrnehmen kann ist es ausreichend, die LED pro dargestellter Zeile mit einem dem Helligkeitswert entsprechenden Tastverhältnis einmal ein- und auszuschalten. In konventioneller Technik würde das wohl so aussehen, dass getriggert durch den Pixeltakt in 24 parallele Schieberegister der Farbwert eingelesen wird. Ist die Zeile beendet bzw die Schieberegister komplett gefüllt werden durch HSync getriggert die (jeweils 8 bitigen) R, G und B Werte des einzelnen Pixels in jeweils einen 8bit-Counter geladen der mit dem Countertakt heruntergezählt wird. Ein 0-Komparator wertet jeden Counter aus. Solange Counter >0 wird die LED angesteuert. Soweit die Darstellung des Schaltungsprinzips. Mir ist klar, dass man soetwas mit vernünftigem Aufwand nur mit programmierbarer Logik realisieren kann, ebenso ist mir klar dass bei z.B. 640 darzustellenden Pixeln je drei LED pro Zeile ein FPGA nicht ausreicht und das Ganze modular und kaskadierbar ausgeführt werden muss. Mein Problem ist nun, dass ich (zu meiner Schande) vor ca. 15 Jahren aus der Digitaltechnik ausgestiegen bin und ich bis auf das Grundprinzip keine Ahnung von FPGAs und deren Programmierung habe. 1. Frage: Lässt sich oben beschriebenes Problem mit FPGAs sinnvoll lösen? Man beachte den Pixeltakt von 100MHz. 2. Frage: Ich kann falls FPGAs das Mittel der Wahl sind absolut nicht abschätzen welche der vielen Serien und Typen (Anzahl der Gatter, Cells, etc.) für die Anwendung am geeignetsten sind. Keine Ahnung wie die Komplexität der Schaltung zu bewerten ist. Kann mir bitte jemand einen Hinweis dazu geben? Ich möchte mich wegen der Kosten nach Möglichkeit gleich mit einem anwendungsgeeigneten FPGA-Typ in die Materie einarbeiten. Vor Vorteil sind natürlich auch ein kostengünstiges Entwicklungskit bzw Software. Eine ungewöhnliche Anwendung, viele dumme Fragen. Ich bin für jeden Hinweis dankbar. Ciao MiBom
Es wird sicherlich ein FPGA geben, daß das kann ohne Probleme. Abschätzen aus der entsprechenden "Schaltungsidee" und dann pro Flip-Flop mal ein Logikelement einrechnen. Das passt mal in etwa. Zum Testen such dir eine FPGA Software, die im Netz verfügbar ist (Webpack von Xilinx o.ä.) und relalisiere das damit. Dann kannst du das ganze Testen und nen Baustein auswählen ohne auch nur einen Pin verlötet zu haben. Und wissen, was du tust, musst du über kurz oder lang ja eh... Ganz trivial ist das sicherlich nicht, aber es kann ja auch Spaß machen...:o))) Gruß Thomas
DVI Receiver ist ein SIL 163B oder ein Typ mit vergleichbarer Funktionalität. Da gibt es jede Menge. Ciao Mike
Tja, das geht in Richtung Grundlagen: Offensichtlich geht es hier um ordinäre VGA-Signale (640x480??). Hier haben wir einen Pixeltakt von ziemlich genau 25MHz (100MHz??) Wenn also der LVDS-Receiver SIL163B die Daten nach parallel gewandelt hat, haben wir 3x8 Bit + Sync-Signale. Da macht es Sinn, diese Daten erst mal in ein RAM abzulegen. Wenn die dann mal da im RAM sind (vieleicht mit 2 Speicherseiten, in eine wird geschrieben, die andere wird angezeigt), werden sie zum geeigneten Zeitpunkt wieder ausgelesen und auf der LED ausgegeben. Dieses Panel wird übrigens schon durch die Abmessungen recht beeindruckend werden: beim Einsatz von kleinen SMD-LEDs mit 2mm Breite wird das Ding dann immerhin schon knapp 4 Meter breit. Richtig: sowas muß modular sein. Da brauchts zur Ausgabe der Daten an die LEDs dann schon ein Bussystem. Summa summarum sind das dann 640 x 480 x 3Farben = fast 1 Million LEDs. Aber Achtung: auch FPGAs (und die passenden Konfigurationsspeicher)kosten Geld. Viel Erfolg wünscht Lothar
evtl auch zu bedenken 1 Led angenommen mit 0,004W x 1000000Leds = 4kWatt ! Peter
Halt! :-) Jetzt geht die Diskussion in die falsche Richtung. Es geht hier nicht um die Ansteuerung einer Matrix, sondern lediglich um EINE EINZELNE ZEILE. Auf dieser Zeile soll NACHEINANDER jede Zeile des Videobildes dargestellt werden, genau so wie es die Videodaten vorgeben. Zu den angepeilten 100MHz für das Schaltungsdesign. Bei 640 Pixeln ist der Pixeltakt natürlich geringer, die Bauteile sollen kaskadierbar und auch für längere Zeilen bis 1280 Pixeln ausgelegt sein. Ciao Mike
Zur Erinnerung nochmal meine Fragen, nicht dass das in der Diskussion untergeht :-) 1. Sind FPGAs grundsätzlich für so eine Schaltung geeignet oder sollte man andere Bauteile verwenden? 2. Ist das mit den 100MHz ein Problem? 3. Kann mir jemand einen geeigneten Typ empfehlen? Ciao Mike
Moin... Verdammich... sowas habe ich doch schon mal gesehen/gelesen/gehört. Nur wo? Naja Egal. Das Problem das ich da sehe ist nicht der Pixeltakt. Die 100MHz schlucken die modernen FPGA schon. Nur wie schnell möchstest du die Ausgabe den abhandeln? Wenn du die Register zwischen zwei Zeilen wieder leer haben willst, wird das etwas hurtig oder das Timing läßt diese Pause zu. Evtl. die Struktur doppeln: eine Registerbank wird beschrieben, die andere taktet ihre PWM raus. Bei der Auflösung die ein Chip abarbeiten kann ist wohl nur die Anzahl der Pins entscheidend, interne FF sollten genügend da sein. -- Sven Johannes
@Sven: Wüsste nicht warum ich das Schieberegister leeren müsste. Die alten Daten werden bei der nächsten Zeile mit den neuen Daten herausgeschoben. Glaube nicht, dass ich hier einen Denkfehler habe. Ciao Mike
@Sven: Sorry, hätte vor der Antwort besser nachdenken sollen. :-) Ich bin bisher davon ausgegangen, dass ich die Pixeldaten in EIN 640 bit langes und 24bit breites Schieberegister lade. Nachdem dort die komplette Zeile geladen ist werden in der HSync Pause aus den 24bit eines jeden Pixels die 8bit Daten der Subpixel in einen 0-Counter geladen, der Counter auf 0 heruntergezählt und permanent auf einem eigenen Pin für jeden Counter ausgegeben ob Counter > 0. Dein alternativer Vorschlag ist, das Laden des Schieberegisterinhalts in eigene Counter dadurch wegzurationalisieren dass es ZWEI 640bit lange und 24bit breite Schieberegister gibt die abwechselnd mit den Informationen aufeinanderfolgende Zeilen geladen werden. In der Ladezeit des jeweils anderen nennen wir es mal Zeilenregisters wird der Inhalt eines jeden 24bit nennen wir es mal Pixelregisters in 8 Unterregister zerlegt und an Ort und Stelle heruntergezählt. Gute Idee, ich muss mal drüber nachdenken wo die Vor- und Nachteile der beiden Alternativen liegen. Danke! Ciao Mike
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.