Hi zusammen. Ich suche einen IC, der mir aus einem FullHD-Bild einen Teil (sagen wir SVGA oder WVGA oder auch QVGA) an definierter Position (zur Not default links oben) ausschneidet und per LVDS ausgibt. Der Eingang ist entweder auch LVDS oder idealerweise Displayport. Ich bin bei meiner Suche über den Begriff Scaler gestolpert, allerdings ist das nach meinem Verständnis nicht das richtige. Bildbereiche außerhalb meines definierten Fensters möchte ich ignorieren, und wie ich es verstehe versucht der Scaler das Bild im Ganzen auf die neue Auflösung umzurechnen. Beim Suchen bin ich auf den TW8834 gekommen, allerdings ist das Datenblatt nicht öffentlich zugänglich. Wenn ich beim mouser oder farnell in die Video-ICs schaue finde ich zwar den TW8834, aber nicht durch seine Eigenschaften, nur durch den Namen. Wie nennt man so einen IC? Und wie finde ich mehr als einen :)
Richtig umsetzen erfordert mitunter ein Übersetzen des timings von schnellem HD auf langsameres SD (geringerer Takt) und damit einen Bildspeicher für annähernd das halbe Bild. Schau Dir mal iChips an: Die machen u.a. picture in picture, das muss nur umgedreht werden, dann noch das Ganze zurück auf einen der Inputs und Hochskalieren. Retiming können die auch im begrenzten Umfang. Anbindung DDR inklusive. Wenn das nicht reicht, muss ein FPGA ran. Das wird dann etwas kniffeliger. Mit dem Nexys Video geht sowas z.B.
Darf es auch ein PC sein? Die VJs haben solche Systeme, um in Echtzeit Videos zu zerteilen und auf einen HDMI-Ausgang zu geben. Ist recht erstaunlich, was die können!
Wie nennt man denn die Funktion, die ich suche? Image resizing? Würde es etwas bringen, wenn ich meine Anforderung auf Halbieren bzw. Vierteln der Auflösung beschränke, also dass ich QVGA aus VGA oder SXVGA erzeuge? Der Hintergrund ist, dass das Zieldisplay nativ nur QVGA hat. Wenn ich das per HDMI oder DP übertrage, unterschreite ich die minimalen Pixeltakte von afaik 25MHz, und auf dem Display erscheint nur Unsinn. Nein ein PC würde nichts bringen. Auch da würde ich beim Ausspielen des Bildes wieder die Takte unterschreiten.
Angehängte Dateien:
-
bild.gif
220 KB
Stefan M. schrieb: > Der Hintergrund ist, dass das Zieldisplay nativ nur QVGA hat. Wenn ich > das per HDMI oder DP übertrage, unterschreite ich die minimalen > Pixeltakte von afaik 25MHz, und auf dem Display erscheint nur Unsinn. Du musst ohnehin die Pixeltaktfrequenz selber herstellen und zwar exakt. Wie gross die genau ist, ist recht unerheblich. Dein Problem ist ein anderes: Das Bild hat ein vollständig anderes timing, als das Ziel. Z.B. kommt der kleine Bildausschnitt in 8ms an und soll aber später 16ms dauern, damit es wieder ein 50Hz Bild wird. Du musst also die Zeilen aufblähen und die Spalten. Uas heisst, Pixels speichern und langsam ausgeben, aber auch Zeilen aufnehmen, zwischenspeichern und langsam ausgeben. In Echtzeit geht das nur, wenn das Display in der Lage ist, völlige ansynchron Zeilen zu beschreiben, ohne Rücksicht auf den Vertikaltakt. Dann braucht aber das Display einen Speicher, oder die Zeilen werden nicht passend zu jedem Bild aktualisiert, sondern mitten in den Zeilen.
Stefan M. schrieb: > Wie nennt man denn die Funktion, die ich suche? > Image resizing? "image cropping" wird das genannt. Das ist jedenfalls das, was du primär beschreibst. Bevor du dich aber auf die Suche nach chips machst, sollte erst einmal das interface klar sein. Braucht das Display ein echtes Videotiming, oder sind die Zeilen einzeln zugänglich? Meistens muss schon irgend ein HS/VS/BL-timing erzeugt werden, d.h. du brauchst eine Schaltung, die dir die neuen HVB-Signale macht. Das geht am einfachsten mit einem FPGA. Bei ausreichender Größe ist die Zwischenpufferung der Zeilen auch kein Problem.
Leider ist es so einfach nicht. Das Display wird nicht direkt per LVDS angesteuert, sondern über APIX mit Daten versorgt. Im Prinzip soll der Signalweg so aussehen: Displayport/HDMI (mit irgendner typischen Auflösung, sagen wir XGA) DP/HDMI Receiver -> LVDS -> Cropping-IC -> LVDS -> INAP375T -> APIX -> INAP375R -> LVDS/24-bit RGB -> Panel Ich bezweifel dass da die Zeilen einzeln zugänglich sind, im LVDS werden ja Sync und Takt mit übertragen. Wenn ich mir jetzt bswp den Renesas TW8845 anseh, bzw das spartanische Datenblatt dazu, dann seh ich da einen openLDI-Eingang, einen Block Bildverarbeitung und einen Block openLDI-Ausgang. In der Beschreibung steht "Supports programmable cropping of input video and graphics". Das ist doch genau das, was ich suche?
Stefan M. schrieb: > Das ist doch genau das, was ich suche? Kann sein, aber das kann solange niemand beurteilen, solange du uns nicht verräst, was du vor hast.
Ich fass es gern nochmal zusammen: Bildausgabe soll auf kleinem Display mit 480x240 Pxieln erfolgen, angesteuert per DP oder HDMI von einem PC aus. Native Auflösung ist zu gering und unterschreitet den üblichen Pixeltakt, deswegen erscheint auf dem Display Mist. Idee: Vom PC mit höherer Auflösung rausgehen, von besagtem cropping-IC den gewünschten Ausschnitt per APIX weiterleiten, wie hier beschrieben: DP/HDMI Receiver -> LVDS -> Cropping-IC -> LVDS -> INAP375T -> APIX -> INAP375R -> LVDS/24-bit RGB -> Panel Der INAP375 hat kein Problem mit geringen Auflösungen und Pixeltakten. FPGA soll wenns geht nicht benutzt werden.
Das durfte ich auch schon einmal suchen. Zum kostengünstigen Erfolg bin ich nicht gekommen. Was mich gewundert hat, denn jeder Monitor kann das, und daher düften solche Chips Massenware sein. Natürlich ist es möglich, dass in einem Monitor schlicht nur eine CPU mit HDMI drin ist. Bei uns konnte man die Auflösung im Bios des "PC" nicht umstellen. Unser Problem war nicht ganz identisch mit deinem, aber ähnlich (Upscaling von 800x600 auf HD). Das Problem dabei ist, dass die üblichen HDMI-LVDS-Konverter-IC das nicht können, weil man dazu einen Framebuffer braucht. Man muss sozusagen ein ganzes Bild in den Speicher schreiben, und dann einen Auschnitt weitergeben, oder das Bild hochskalieren. Ein normaler HDMI-Receiver wie der gute alte TFP401A schreibt die Pixel einfach 1:1 raus, wie sie kommen. Analog Devices (die haben viele Video-Chips) hat mir auf Nachfrage einen Prozessor mit HDMI-IN und LVDS-Out empfohlen, sie hätte nichts einfacheres was das kann. Ist aber 2 Jahre her, Nachfrage kann nicht schaden. Ein FAE eines Distributors hat mir ein XILIX-FPGA empfohlen, da hätten wir sogar Sourcen bekommen. Solche Dinge soll meinen Recherchen nach mit einem FPGA recht einfach machbar sein. Beispiel für HDMI: https://www.xilinx.com/support/documentation/ip_documentation/v_hdmi_rx_ss/v3_1/pg236-v-hdmi-rx-ss.pdf Das dürfte die kostengünstigste Lösung sein, man sparst sogar den SERDES und HDMI-Receiver ein, wenn man das FPGA richtig aussucht. Es gibt China-Chips die das auch können, blos bekamen wir diese nicht, und Informationen dazu schon gar nicht. Gelöst wurde das Problem bei uns duch den Hersteller des Boards, der stellte uns die Auflösung im Bios um. Ich verfolge den Beitrag weiter mit Spannung, denn das Problem poppt bei uns sicher auch nochmal auf! Wenn du ein Bastler bist: Es gibt Boards die das tun. Von diesen kenne ich besagte China-Chips, die man nicht bekommt.
Moin, Stefan M. schrieb: > FPGA soll wenns geht nicht benutzt werden. Wieso nicht? Da gibts wenigstens die 1000+ seitigen Datenblaetter dazu. Renesas ist ja nicht gerade dafuer bekannt, normalen Sterblichen da irgendwie viel Support / Chips in haushaltsueblichen Mengen zu liefern. Dein cropping, so wie du's haben willst, ist auch eher problematisch, weil du dann deutlich mehr als z.b. eine Zeile puffern musst (=du brauchst externes, hurtiges RAM + dessen Ansteuerung). Die Umwandlung waere simpler, wenn man z.B. jedes 2. Pixel und jede 2. Zeile "rausschmeissen" koennte. Also der PC dann eine Aufloesung von z.b. 960x480 Pixeln erzeugen muesste. Natuerlich muss das Bild auf dem PC auch "dafuer gemacht" sein, dass da die Aufloesung spaeter so reduziert wird. Sonst muesste man noch Tiefpaesse vor dem Rausschmeissen der Pixel/Zeilen reinbauen. jemand schrieb: > Das dürfte die kostengünstigste Lösung sein, man sparst sogar den SERDES > und HDMI-Receiver ein, wenn man das FPGA richtig aussucht. Das glaube ich nicht Tim. FPGAs mit eingebauten Serdes sind ueblicherweise deutlich teurer als ein Simpel-FPGA und externer HMDI/DP Receiver zusammen. Gibts den IP-Core fuer umme? Gruss WK
Dergute W. schrieb: > jemand schrieb: >> Das dürfte die kostengünstigste Lösung sein, man sparst sogar den SERDES >> und HDMI-Receiver ein, wenn man das FPGA richtig aussucht. > > Das glaube ich nicht Tim. FPGAs mit eingebauten Serdes sind > ueblicherweise deutlich teurer als ein Simpel-FPGA und externer HMDI/DP > Receiver zusammen. Gibts den IP-Core fuer umme? Die Spartan-6 Serie hat Devices mit SERDES drin: https://www.xilinx.com/products/silicon-devices/fpga/spartan-6.html Selbst die kleineren (z.B. XC6SLX4-2TQG144I) haben welche, und das ist am unteren Ende angesiedelt. Die Frage ist natürlich, ob die ausreichen, aber ausschließlich ein Feature teurer FPGAs ist das nicht. Einige Spartan-6 bieten auch TMDS-Receiver an, womit sich HDMI umsetzen lässt. Ich habe mir das natürlich auch nicht in großer Tiefe angesehen, das muss ich schon zugeben. Grund war, dass eine FPGA-Lösung von oben abgelehnt wurde. Mir hat aber ein (vertrauenswürdiger) FAE eine FPGA-Lösung empfohlen. Mein Vorgehen wäre gewesen, sich ein passenden Evalboard zu holen und sich das mal anzusehen. Was die Kosten das IP-Cores angeht, oder die Komplexität eines HDMI-Receivers, da fehlt mir der Einblick. Der LVDS-Teil dürfte keine Raketenwissenschaft sein.
Moin, Ja, ok. Ueber diese SerDes Funktion der normalen IO Leitungen, wirds datenratenmaessig bei der kleinen Aufloesung wohl auch irgendwie gehen. Und an der XAPP1064 fuehrt auch bei LVDS Eingaengen kein Weg vorbei. Aber die 1:7 Umsetzung fuer LVDS ist da schon fast fertig drinen; die 1:10 Geschichte fuer HDMI wird man wohl per "Gearbox" mit 1:5 und 1:2 hintereinander machen muessen, und danach noch die TMDS -> normal Wandlung. So richtig echtes HDMI koennen die Spartan-6 IOs eh nicht, da gibt's iirc auch nur so ne komische Geschichte mit Trenn-Cs und irgendwelchen Pull-irgendwohin-Rs. Oerks. Dass der FAE das empfiehlt, ist mir klar. Das ist technisch auch eine schoene Loesung und wenn man viele der "richtigen" (GTP,GTX, whatever) Tranceiver uebrig hat und bei neueren, dickeren Bausteinen als gerade Spartan6. Aber halt von der Entwicklungszeit/Wirtschaftlichkeit her... Gruss WK
Das Ding ist halt, von FPGAs habe ich bisher wenig Ahnung. Mein Ansatz wäre gewesen das erstmal mit einem diskreten IC aufzubauen und mir das FPGA-Fass zu sparen. Ich hätte auch kein Problem damit mit der doppelten bzw vierfachen Auflösung aus dem PC zu gehen. Aber ich seh schon, dass ich um den FPGA vermutlich nicht rumkommen werde.
Dergute W. schrieb: > Das glaube ich nicht Tim. FPGAs mit eingebauten Serdes sind > ueblicherweise deutlich teurer als ein Simpel-FPGA und externer HMDI/DP > Receiver zusammen. Gibts den IP-Core fuer umme? Nö, die FPGAs sind insgesamt schon billiger, nur braucht es auch noch ein bissl was fürn guten Pegel, also einen buffer. Es wird also nicht wirklich platzsparender. >Gibts den IP-Core fuer umme? Nein, jedenfalls nicht von Xilinx. Muss gekauft werden, weil die HDMI.org was abhaben will. Ich plädiere daher auch eher für einen Receiver-Chip. ADV75xx oder sowas. Der macht Pegel, Clock-Refresh, Retiming, Übersetzung der Daten auf Parallel und löst das Lizenzproblem. Wenn es nur ein Empfangskanal sein sollte, ist das dann sogar auch billiger, ganz abgesehen von den Entwicklungskosten. Es ist nämlich BEI WEITEM nicht damit getan, einfach den HDMI-Core ins design fallen zu lassen und nach hause zu gehen. Der möchte konfiguriert werden, damit er mit dem Video-PHY-subsystem (der mit den MGTs "receiver" spielt) zusammenwuselt. Auch bei einem einfachen FPGA muss noch ein DDR-Controller eingebaut werden. Damit dürfte der TE genug zu tun haben. Stefan M. schrieb: > Das Ding ist halt, von FPGAs habe ich bisher wenig Ahnung. Null Chance! Wenn überhaupt, nimm einen fetten FPGA und einen HDMI-chip. Dann kannst du die Funktion so wie in C schreiben: Warten bis VSynch und Hsynch, Daten in die Block-RAMs und fertig. Hinten ein paar Zähler, die sich die Daten aus den Rams holen und ein Bildlein machen. Wenn du sehr geschickt bis, komsmt du ohne grosses RAM aus, wenn du die Quelle dazu bringen kannst, die Pixel zur richtigen Zeit auszuspucken. Dann ist das nur ein Ausblenden, Einblenden mit IF THEN
Stefan M. schrieb: > Ich hätte auch kein Problem damit mit der doppelten bzw vierfachen > Auflösung aus dem PC zu gehen. Genau so. Das Bild muss vom Timing her schon so gross sein, wie es später gemacht werden muss. Die Länge in X und Y also übereinstimmen. Das Display muss daher mit einem ganzzahligen Teiler der HDMI-Taktfrequenz gefahren werden.
jemand schrieb: > Die Spartan-6 Serie hat Devices mit SERDES drin: > https://www.xilinx.com/products/silicon-devices/fpga/spartan-6.html > > Selbst die kleineren (z.B. XC6SLX4-2TQG144I) haben welche, und das ist > am unteren Ende angesiedelt. Die Frage ist natürlich, ob die ausreichen, > aber ausschließlich ein Feature teurer FPGAs ist das nicht. > Einige Spartan-6 bieten auch TMDS-Receiver an, womit sich HDMI umsetzen > lässt. Uhh...das geht zwar moeglicherweise mit viel Gefrickel, aber das wuerde ich nicht mehr machen. Bis man die Timings eingehalten kriegt, das Lane-Deskewing, usw. vergeht viel, viel Zeit und man muss tief in die Wissenschaften der manuellen Plazierung einsteigen. Lattice hat Silicon Imaging unter der Haube, ergo gibt es da sehr schoene Referenzdesigns mit ECP5 und einem HDCP-freien Si irgendwas, siehe EVP-Kit. Das ist auch vernuenftig dokumentiert (im gegensatz zu den HDCP-Kaefern), und die passenden HDMI-Cores gibt es in verschiedenen Varianten. Ich hatte damals relativ schnell (ein paar Wochen) was am Laufen, allerdings ohne externes DDR. Das ist bei Lattice wiederum etwas knifflig (gewesen).
Martin S. schrieb: > Ich hatte damals relativ schnell (ein paar Wochen) was am > Laufen, allerdings ohne externes DDR. Nimm einen aktuellen größeren Baustein der 7er-Serie von Xilinx und baue es mit den MGT. Das geht binnen Tagen. Inklusive DDR-Controller. Alles fix und fertig aus der Box. Also wenigstens hat uns das der Xilinx-FAE, den wir vor Tagen im Hause hatten, es so versprochen.
Martin S. schrieb: > und einem HDCP-freien Wie verhält sich der denn, wenn eine Senke HDCP anfordert?
Tobias N. schrieb: > Martin S. schrieb: >> und einem HDCP-freien > > Wie verhält sich der denn, wenn eine Senke HDCP anfordert? Wieso sollte eine Senke sowas tun koennen? Gruss WK
Samstag abend, 2 Weißbier getrunken, man kennt das ja :-) Also nochmal: "wenn die Quelle das anfordert"?
Moin, Naja, das uebliche halt: 's dud ned. Also mit viel Glueck schaltet dann die Quelle, wenn sie merkt, dass die Senke sich nicht authentisieren kann, auf eine hundsmiserablige Aufloesung runter oder sie liefert gar kein Ausgangssignal. Gruss WK
K. L. schrieb: > Das geht binnen Tagen. Inklusive DDR-Controller. > Alles fix und fertig aus der Box. > Also wenigstens hat uns das der Xilinx-FAE, den wir vor Tagen im Hause > hatten, es so versprochen. Xilinx verspricht da sehr viel und auf den ersten Blick schaut alles schnell und einfach aus. Aber versuchst du, ein wenig vom Weg abzuweichen und deine eigene Applikation zu entwickelln, verläufst du dich schnell in den Tiefen der Strukturen aus Scripten und Cores. Es reicht, wenn irgendwo ein Pfad nicht stimmt oder ein Parameter nicht passt. Dann viel Spass beim Suchen.
K. L. schrieb: > Also wenigstens hat uns das der Xilinx-FAE, den wir vor Tagen im Hause > hatten, es so versprochen. Ha, ha :-) Sepp schrieb: > Xilinx verspricht da sehr viel und auf den ersten Blick schaut alles > schnell und einfach aus. Aber versuchst du, ein wenig vom Weg > abzuweichen und deine eigene Applikation zu entwickelln Jeder kann alles, und Xilinx kann sowieso alles, aber es artet jedesmal aus. Da lob' ich mir die 'Kleinen', die sich auf ein Thema fokussieren, und das dann auch beherrschen. Den Anlauf habe ich mal bei Altera genommen, auf die Ansage hin: "Koennen Sie als Blocks im SoC-Builder zusammenklicken - laeuft". Dass man da die getimebombten Cores aus irgendeinem Grund nicht mit eigenen kombinieren kann, sagt einem weder Tool noch FAE. Bei HDMI ist das so eine Sache: Man kann u.U. mal schnell was zum Laufen kriegen, wenn's aber ans Einhalten der Timings geht und man mal so seine 4-5 Sourcen angeschlossen hat, mit denen's dann nur sporadisch geht, muss man schnell mal ans harte Logik-Routing. Da spendiert man besser schon mal den Receiver-Chip fuer die Erstserie.
Martin S. schrieb: > Da spendiert man besser > schon mal den Receiver-Chip fuer die Erstserie. Der Vergleich ist aber nicht ganz fair, weil die HDMI-Transceiver-Chips auf den Datenstrom und die SPEC angepasst sind. Das gilt vor allem für die PLLs, Jitter und die Toleranz gegenüber dem Eingangssignal. Die integrierte CHIP PLL logged sich oft auch auf sehr schlechte und beflektionsbelastete Signale. Die Transceiver im FPGA sind Universal-Architekturen, die so gut wie es geht, auf den Standard hingetrimmt werden. Ich bin nicht mal sicher, ob die den perfekt können. HDMI arbeitet mit Signalstandards, die nicht automatisch mit FPGA-Bänken kompatibel sind. Die gleiche Rechnung lässt sich für SATA aufmachen: 2 Tage, um eine Schaltung zusammenzuklicken, 3 Tage Fehlersuche und 2 Wochen, um den PL davon zu überzeugen, die Schaltung zu redesignen und einen Chip draufzusetzen.
Martin S. schrieb: > mit denen's dann nur sporadisch geht, > muss man schnell mal ans harte Logik-Routing. Welche Möglichkeiten hat man denn da?
jemand schrieb: > Was die Kosten das IP-Cores angeht, oder die Komplexität eines > HDMI-Receivers, da fehlt mir der Einblick. Der LVDS-Teil dürfte keine > Raketenwissenschaft sein. Dafür aber der HDMI-Tansceiver. Da haben sich schon einige mit abgequält, das nachzubauen. Signalverarbeiter schrieb: > Ich plädiere daher auch eher für einen Receiver-Chip. Und auch die wollen bespasst werden. Spartan ist da schon am Limit, wenn mehrere Chips breitbandig über mehrere single ended Signale angeschlossen werden sollen und die über mehrer Banken hinweg laufen.
Hans schrieb: > Welche Möglichkeiten hat man denn da? Haengt komplett von der Architektur ab. Bei den Spartan6-Hacks muss man muehsam die Constraints erstellen, bei Lattice geht es mit dem PCS-Einheiten etwas eleganter, da kuemmert man sich dann bestenfalls nur noch um das Lane-Deskewing (also gegeneinander im Timing verschobene Kanaele). Ist halt immer so auch bisschen Glueckssache/Geschmackssache, was man am schnellsten (ohne Einsatz sehr teurer Proben) zum Zappeln kriegt. Ein Xilinx-FAE wuerde natuerlich etwas ganz anderes behaupten :-) M. W. schrieb: > Dafür aber der HDMI-Tansceiver. Da haben sich schon einige mit > abgequält, das nachzubauen. Das ist jetzt bei mit ECP3 keine schwarze Magie. Aber halt nahe am ueblen Hack, je nach Spezifikation, die man einhalten will/muss.
Warum muss das unbedingt in einem FPGA gemacht werden? Die Video-Chips, die in beamern verwendet werden, können das. Die haben einen DDR-RAM mit dran, in dem sie das ganze Bild vollständig ablegen. Daraus kann man sich jeden beliebigen Ausschnitt holen. Programmiert werden die über I2C.
Hast du für "die" auch ne Teilenummer, oder irgendeinen Anhaltspunkt? Ich hab nur die TW8844 bzw TW8846 vom Renesas gefunden für so eine cropping-Funktion.
Thread beobachten
Seitenaufteilung abschalten
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.