Hallo Zusammen! Ich sammle gerade Informationen, ob/wie ich ein neues Projekt angehen könnte. Im Prinzip geht es darum, von einer 4k HDMI (3840 × 2160p 30FPS aktueller Stand kein HDCP und kein Ton) Videoquelle in einen Framebuffer in einem Zynq 7000 zu schreiben. Auflösung und Framerate sind konstant - es muss nichts anderes unterstützt werden. Während 1080p auf den ersten Blick ziemlich entspannt zu sein scheint und über die SelectIOs laufen könnte, scheint 4k keinen Spaß zu machen. Selbst wenn man die Daten über die GTX Transceiver reinholt, muss die Logik mit >200MHz laufen, was das Timing zumindest knifflig macht. Hat einer von euch sowas in die Richtung schon gemacht und kann mir vielleicht schon jetzt sagen, worauf man dringend zu achten hat? Welchen Entwicklungszeitraum würdet ihr für einen erfahrenen Entwickler anpeilen? Bei mehr als 2-3 Monaten würde es vermutlich Sinn machen, die 15k€ in die Hand zu nehmen, um den Xilinx IP-Core zu kaufen, auch wenn mir die Lizenzbedingungen noch nicht klar sind. Stand heute würde ich mir irgendwie versuchen die HDMI 1.4b Spec zu besorgen, ein kleines Mainbord stricken, auf das ich weitgehend die HDMI Beschaltung der Kintex Eval Boards übernehme, ein Zynq SOM darauf setzen, den HDMI Clock auf die QPLL und Daten auf die GTX legen und einfach "loslegen". Das scheint selbst mir etwas naiv - daher die Frage nach Fallstricken oder anderen/besseren vorgehensweisen. Vielen Dank! Achim
Bei uns in der Firma wurden Bridge-Chips genutzt, die HDMI auf DSI/CSI wandeln; die wurden dann an das MIPI-CSI (Kamerainterface) des SoCs angeschlossen. Der eine Chip hatte für 3840x2160 bei 30 fps zwei CSI-Interfaces (zweimal 1920x2160, links/rechts), der andere kam mit einem aus. Beide hatten aber mehrere Lanes für CSI-Schnittstelle, daher geringere Bandbreite. Vielleicht ist das eine Überlegung wert, wenn bei euch schon CSI/DSI-Erfahrung vorhanden ist?
:
Bearbeitet durch User
Du kannst auch erstmal mit einer passenden HDMI FMC Karte anfangen: https://www.digikey.de/product-detail/de/terasic-inc/P0431/P0431-ND/7044109 und die HDMI Cores evaluieren. Die 15000€ fuer den Core koennten sich evtl. mit 2 Fragen ziemlich schnell relativieren: 1.) Wie gross sit meine Stueckzahl? 2.) Ist es absehbar in Zukunft den Core in einem anderen Projekt wiederzuverwenden? Den Core kannst du naemlich jeweils in einer Project License und einer Site Lciense beziehen. Bei ersterem darfst du den Core innerhalb der ganzen Firma (innerhalb eines 5 Milen Radius vom Standort) verwenden, bei letzterem nur fuer ein einzelnen Projekt. Die Preise unterscheiden sich in der Regel allerdings nicht besonders, daher lohnt sich eine Site License in der Regel immer. Weitere Infos siehe auch hier: https://www.xilinx.com/support/answers/45589.html Zu den technischen Fragen: Ich habe den Core nie in einem Zynq 7000 verwendet, daher kann ic nicht sagen ob es da zu erwartbaren Problemen kommt. Du kannst den Core so konfigurieren, das es 1, 2 oder 4 Pixel gleichzeitig ausgibt. UHD bei 30 Hz waeren eine Pixelclock von ca. 300 MHz. D.h. bei 2 Pixel parallel sind es nur noch 150 MHz (das schafft der Zynq relativ locker) und bei 4 dann nur noch 75 MHz. Wichtig ist das du die Speicherbandbreite nicht zu klein bemessen tust, vorallem wenn sich Zynq und PL einen Speicher teilen. Ob du mehrere Pixel parallel verabreiten kannst, haengt im wesentlichen davon ab was du noch an Processing Schritten hast. Wenn du nur buffern willst, dann sollte das allerdings kein Problem sein.
:
Bearbeitet durch User
Tobias B. schrieb: > Zu den technischen Fragen: > > Ich habe den Core nie in einem Zynq 7000 verwendet, daher kann ic nicht > sagen ob es da zu erwartbaren Problemen kommt. Du kannst den Core so > konfigurieren, das es 1, 2 oder 4 Pixel gleichzeitig ausgibt. UHD bei 30 > Hz waeren eine Pixelclock von ca. 300 MHz. D.h. bei 2 Pixel parallel > sind es nur noch 150 MHz (das schafft der Zynq relativ locker) und bei 4 > dann nur noch 75 MHz. Wichtig ist das du die Speicherbandbreite nicht zu > klein bemessen tust, vorallem wenn sich Zynq und PL einen Speicher > teilen. > > Ob du mehrere Pixel parallel verabreiten kannst, haengt im wesentlichen > davon ab was du noch an Processing Schritten hast. Wenn du nur buffern > willst, dann sollte das allerdings kein Problem sein. Ist schon so richtig. Hier noch mein Senf/Erfahrung: In einem vergangenen Projekt durfte ich an der Processing Pipeline arbeiten und wir haben da mit 3 Pixeln parallel gearbeitet, weil 3x24 bit = 72 bit, und wir haben versucht die BRAMs geschickt auszunutzen. BRAM können 72-bit breite Ports haben und die neueren URAM haben nur mehr 72-bit breite Ports. UHD-1 hat einen Pixeltakt von 340 MHz und mit 3 Pixeln parallel kann man seine Pipeline auf 120 MHz reduzieren. Die Pipeline hat nichts aufregendes gemacht, wie Bildverbesserung, Skalierung und Overlay, hat aber 2-3 Personenmonate gebraucht. Wir mussten auch sparsam mit den BRAMs umgehen, weil der AI-Core fast alle BRAMs braucht. Wie die Bilder in und aus dem FPGA gekommen sind, kann ich nicht sagen, weil das ein anderes Team gemacht hat.
Vielen Dank für eure Rückmeldungen! S. R. schrieb: > Bei uns in der Firma wurden Bridge-Chips genutzt Die Idee, über eine "einfachere" Schnittstelle in den FPGA zu gehen finde ich gar nicht schlecht, aber ich glaube genau da hakt es beim csi-2 - an Board hat er die Schnittstelle nicht, sodass es die Aufgabe nur anders, aber nicht leichter macht. Tobias B. schrieb: > Ich habe den Core nie in einem Zynq 7000 verwendet, daher kann ic nicht > sagen ob es da zu erwartbaren Problemen kommt. Du kannst den Core so > konfigurieren, das es 1, 2 oder 4 Pixel gleichzeitig ausgibt. UHD bei 30 > Hz waeren eine Pixelclock von ca. 300 MHz. D.h. bei 2 Pixel parallel > sind es nur noch 150 MHz (das schafft der Zynq relativ locker) und bei 4 > dann nur noch 75 MHz. Wichtig ist das du die Speicherbandbreite nicht zu > klein bemessen tust, vorallem wenn sich Zynq und PL einen Speicher > teilen. Ah, okay - ich habe mir die Doku zu dem IP-Core noch nicht genau angeschaut: 150MHz sind in der Tat vergleichsweise entspannt. Wie so oft sind die Informationen, die ich bisher von meinem Auftraggeber bekommen habe, auf ein Minimum beschränkt. Ich weiß also weder von der zu erwartenden Stückzahl (ich schätze maximal im einstelligen 1000er Bereich, eher weniger) noch, was er sich ggf. im Nachgang noch so alles vorstellt. Evtl kommt noch Downscaling dazu, aber dabei mache ich mir nicht so große Sorgen. Den IP-Core würde ich im Zweifel nicht selbst bezahlen, sondern bezahlen lassen. Da ich aber nicht davon ausgehe, dass der Core noch einmal in einem anderen Produkt Anwendung finden wird, will ich zumindest die günstigste Variante anbieten - daher meine Überlegung, das Ganze von scratch zu entwickeln. Das Eval Bord, das du genannt hast, finde ich aber auch interessant: der ADV7619 könnte sich um das HDMI Geraffel kümmern und die Weiterverarbeitung ist nicht aufwändig. Ich weiß aber noch nicht, ob so viele Pins frei sind... Grano U. schrieb: > In einem vergangenen Projekt durfte ich an der Processing Pipeline > arbeiten und wir haben da mit 3 Pixeln parallel gearbeitet, weil 3x24 > bit = 72 bit, und wir haben versucht die BRAMs geschickt auszunutzen. > BRAM können 72-bit breite Ports haben und die neueren URAM haben nur > mehr 72-bit breite Ports. UHD-1 hat einen Pixeltakt von 340 MHz und mit > 3 Pixeln parallel kann man seine Pipeline auf 120 MHz reduzieren. Die > Pipeline hat nichts aufregendes gemacht, wie Bildverbesserung, > Skalierung und Overlay, hat aber 2-3 Personenmonate gebraucht. Danke für den Input! Viele Grüße Achim
Joachim S. schrieb: > Die Idee, über eine "einfachere" Schnittstelle in den FPGA zu > gehen finde ich gar nicht schlecht, aber ich glaube genau da > hakt es beim csi-2 - an Board hat er die Schnittstelle nicht, > sodass es die Aufgabe nur anders, aber nicht leichter macht. Hängt davon ab, welche Expertise bei euch vorhanden ist. Wir haben z.B. keine Ahnung von HDMI, dafür aber einen SoC mit genug CSI-Schnittstellen und Erfahrung mit Kamerasensoren - da ist die Entscheidung einfacher. Die Chips sind eigentlich DSI-Chips (z.B. für Panels in Fernsehern), aber der physical Layer ist kompatibel genug. Es gibt aber auch Chips, die auf ein paralleles Interface wandeln.
Joachim S. schrieb: > Ich sammle gerade Informationen Embedded Vision Development Kit Modular Platform for Embedded Vision Processing at the Edge http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/EmbeddedVisionDevelopmentKit Dual Camera Demo Using Lattice Embedded Vision Kit The dual camera demo showcases how Lattice's Embedded Vision Kit can merge the images of two sensors and display video output through HDMI. This is a great demo for designers who are considering implementing embedded vision applications. RefDesign und IDE ect.pp bitte ganz nach unten scollen. Gruss Holger. In wie weit das auf mehr als zwei Bildauschnitte auf dem HDMI Monitor geht suche ich noch. ------------------------------------------------------------------------ ----------------- ECP5 VIP Processor Board CrossLink VIP Input Bridge Board HDMI VIP Output Bridge Board Power Supply 12V Quick Start Guide Embedded Vision Development Kit Diamond License Information If you currently do not have access to the award-winning Lattice Diamond design software, Lattice would like to offer you a special 1-year license, that enables design for the ECP5UM-85F FPGA featured on the ECP5 VIP Processor Board in the Embedded Vision Development Kit. To request this license, please follow instructions included with your Embedded Vision Development Kit. Please note that this license is valid for Diamond design software and can be used only with the Embedded Vision Development Kit. This is a limited-time offer.
Holger schrieb: > In wie weit das auf mehr als zwei Bildauschnitte auf dem HDMI Monitor > geht suche ich noch. BlockSchaltbild https://training.ti.com/sites/default/files/docs/multi_camera_systems_aggregation_replication_0.pdf ------------------------------------------------------------------------ --- 4 to 1 Image Aggregation with CrossLink-NX Connect Dissimilar Image Sensor Sources with Minimal Latency RefDesign bis 15Ghz kann der Crosslink http://www.latticesemi.com/products/designsoftwareandip/intellectualproperty/referencedesigns/referencedesign04/4to1 Also 4 Rohe Bilder auf dem HDMI Gerät. ()()()() Jetz ist aber kein RefDesign für ein Text dem ich da auf dem Frame einblenden kann. Datum und Uhrzeit via Font einblenden (Text links oben im Bild)()()(). Overlay Text über dem Camera Rohbild via PostProcessing.... ------------------------------------------------------------------------ -- Zu der HDMI Dynamischen Therminierung via Kabel ... Augendiagramm für 20 Meter Kabel. Bei der hohen Bitrate ... wenn da was nicht stimmt ist der HDMI Bildschirm duster. Analog Devices macht da aktiv Thermnierung via 10mA Stromschnittstelle ... Bild poste ich noch. Gruss Holger.
Holger schrieb: > Augendiagramm und AXI4 Stream MIPI CSI Controller Subsystems https://www.xilinx.com/products/intellectual-property/ef-di-mipi-csi-rx.html MIPI Reference Design (2016.3) suche ich noch. Gruss Holger.
Joachim S. schrieb: > Selbst wenn man die Daten über die GTX Transceiver reinholt, muss die > Logik mit >200MHz laufen, was das Timing zumindest knifflig macht Die Logik muss sogar mit annähernd 300Mhz laufen, weil die bei 60Hz 2 Punkte mit 297 und bei 30Hz 1 Punkt mit 297 packen muss. Ab AXI kannst du es jeweils mehrfach halbieren. Ob das der Einfachheit der Bearbeitung gut tut, steht auf einem anderen Platt.
Auf dem EVDK hat man zwar sehr schnell was am Laufen und die CrossLink-Chips sind oft erste Wahl wenn's um MIPI geht, aber: Was soll MIPI hier bringen? Das bringt aus meiner Sicht gegenueber direktem HDMI-Eingang nur mehr Komplexitaet rein und ist dann kaum noch guenstig zu debuggen. Zudem: 4k@30 ist per HDMI wohl kaum zu schaffen, zumindest nicht mit dem SiI 1127 auf dem EVDK. TMDS direkt auf die PCSD legen habe ich mal beim ECP3 probiert, geht bis zu einem gewissen Punkt auch, aber schon bei 1080p wird's kritisch. Das 'lane deskewing' (was man zwingend machen muss, denn mit jedem PnR ist die Logik mal hier, mal da alloziert) duerfte bei 300MHz nahezu unmoeglich werden.
Martin S. schrieb: > Was soll MIPI hier bringen? Für uns war es die vorhandene Erfahrung sowie die vorhandenen MIPI-CSI Eingänge. Martin S. schrieb: > Zudem: 4k@30 ist per HDMI wohl kaum zu schaffen, > zumindest nicht mit dem SiI 1127 auf dem EVDK. Ein von uns verwendete HDMI-Chip hat bei 4k@30 zwei multi-lane MIPI-CSI-Ports benutzt (jeweils mit 1920x2160), um die Bandbreite zu ertragen; ein anderer brauchte das nur für 4k@60.
Implements a CSI-2 receive interface according to the MIPI CSI-2 standard, v2.0. The subsystem captures raw images from MIPI CSI-2 camera sensors and outputs AXI4-based sensor data ready for image sensor processing. https://www.xilinx.com/support/documentation-navigation/see-all-versions.html?xlnxproducttypes=IP%20Cores&xlnxipcoresname=mipi-cs12-subsystem%2Cmipi Trenz Electronic ZynqBerry TE0726 SoC module (directly with 15pin FPC cable) https://wiki.trenz-electronic.de/display/PD/TE0726+Zynqberry+Demo1#TE0726ZynqberryDemo1-rpicam https://www.analog.com/media/en/technical-documentation/data-sheets/ADV7533.pdf Gruss Holger. ADV7535 ADV7533 The ADV7535 provides a MIPI® display serial interface (MIPI/ DSI) input receiver and a High-Definition Multimedia Interface (HDMI®) transmitter output. The DSI receiver input supports DSI video mode operation only, and specifically, only supports nonburst mode with sync pulses. The DSI receiver provides up to four lanes of MIPI/DSI data, each running up to 891 Mbps. The HDMI transmitter supports video resolutions up to a maximum TMDS clock frequency of 148.5 MHz. The ADV7535 also provides an audio input port, which supports the insertion of audio into the HDMI stream.
Holger schrieb: > The ADV7535 provides a MIPI® display serial interface (MIPI/ > DSI) input receiver and a High-Definition Multimedia Interface > (HDMI®) transmitter output. Das Teil empfängt MIPI-DSI und sendet HDMI. Du wolltest das andersrum, oder?
S. R. schrieb: > Das Teil empfängt MIPI-DSI und sendet HDMI. Ja genau so soll es sein. Hier noch was für Xilinx Streaming ..... https://www.xilinx.com/support/documentation/ip_documentation/v_axi4s_vid_out/v4_0/pg044_v_axis_vid_out.pdf Clocking There are two clocking modes used by the AXI4-Stream to Video Out bridge, either common (synchronous) or independent (asynchronous). The common clocking mode is used when the native and AXI4-Stream sides of the bridge are running from a common synchronous clock. The common clocking mode disables the clock domain crossing logic in the internal FIFO, therefore saving resources. The independent clocking mode is used when the bridge requires asynchronous and independent clocks for the native and AXI4-Stream sides of the bridge. The video output clock corresponds to the video line standard used on the input. It is part of the video line standard and is used by both the AXI4-Stream to Video Out core and by the corresponding Video Timing Controller core that is used to detect video timing. The AXI4-Stream clock (aclk) is part of the AXI4-Stream bus. To minimize buffering requirements, this clock should be of equal or higher frequency than the video input clock. This clock can be slower than the video input clock, in which case, additional buffering is required to store pixels so that lines can be input at the burst rate of the video clock. This is discussed in the Buffer Requirements section. At a minimum, the aclk frequency must be higher than the average pixel rate. ......... ################################## HDMI with ADV7511 https://wiki.trenz-electronic.de/display/PD/HDMI+with+ADV7511
Holger schrieb: >> Das Teil empfängt MIPI-DSI und sendet HDMI. > Ja genau so soll es sein. Also im Ursprungspost hieß es andersrum: Joachim S. schrieb: > Im Prinzip geht es darum, von einer 4k HDMI (3840 × 2160p 30FPS > aktueller Stand kein HDCP und kein Ton) Videoquelle in einen > Framebuffer in einem Zynq 7000 zu schreiben. Da wolltest du noch HDMI empfangen.
S. R. schrieb: > Da wolltest du noch HDMI empfangen. Achtung, Holger und ich sind zwei verschiedene Personen ;) Mittlerweile hat sich die Plattform etwas geändert - es soll kein Zynq 7000, sondern ein Zynq US+ werden. Ich habe mich dazu entschlossen, die Retimer Schaltung vom ZCU106 zu übernehmen und mit ein bisschen anderem Geraffel an ein Trenz SOM zu stricken. Der Xilinx Video Phy Core ist (bzw. war - da bin ich mir nicht sicher) frei und für den HDMI Core gibt es eine 3 Monatige Eval Lizenz - wenn das läuft, wird die Lizenz gekauft. Ich bin mir noch nicht sicher, ob der ganze HDMI Core wirklich notwendig bzw mit Kanonen auf Spatzen geschossen ist, weil ich ja nur eine Auflösung und Framerate brauche und diese ggf. auch selbst implementieren kann. Was zb der Video Phy (an den ich andocken würde) wirklich treibt wird in der Doku aber leider nicht klar. Ich würde erwarten, dass er Lane Deskewing, Comma Alignment etc macht - ggf. wird all das aber vom Treiber über die DRU gesteuert. Wenn ich ein grobes Gerüst vom ganzen habe, werde ich das mal erforschen. Viele Grüße und schönes Wochenende! Achim
Damit hast du dir auf jedenfall das sorglos Paket besorgt. Ich moechte an der Stelle nur nochmal kurz an die Lizenzhinweise aus dem ersten Posting erinnern: Beitrag "Re: 4k HDMI in auf Xilinx Framebuffer" Viel Erfolg, das Groebste ist schon ueberstanden. ;-)
Joachim S. schrieb: >> Da wolltest du noch HDMI empfangen. > Achtung, Holger und ich sind zwei verschiedene Personen ;) Da hast du Recht. Asche auf mein Haupt.
Joachim S. schrieb: > Was zb der Video Phy (an den ich andocken würde) > wirklich treibt wird in der Doku aber leider nicht klar. Ich würde > erwarten, dass er Lane Deskewing, Comma Alignment etc macht - ggf. wird > all das aber vom Treiber über die DRU gesteuert. Wenn ich ein grobes > Gerüst vom ganzen habe, werde ich das mal erforschen. Und, was hat die Forschung ergeben? Lohnt sich der Erwerb des Video-Cores? Kann man den Video-PHY auch ohne AXI betreiben?
Michel schrieb: > Lohnt sich der Erwerb des Video-Cores? Wenn man Geld hat, schnell fertig werden will und mit aller Gewalt mit AXI bauen will oder muss, dann ja. > Kann man den Video-PHY auch ohne AXI betreiben? Ja, kann man. AXI ist gut und schön, wenn du viele Komponenten im Systen hast und nicht weiss, wann wer zugreifen will. Leider produziert AXI unvorhersehbare Latenzen, sobald man mehr, als 2 Teilnehmer auf eine Komponenten arbeiten lässt und die bremsen sich dann gegenseitig aus. Ohne eine Zugriffssteuerung über die AXI Master ist da wenig zu optmieren. Und wenn du diese Steuerung auferlegst, dann kommst du automatisch in Richtung massives System. AXI verbraucht auch mehr Respurcen für die Verschalterei von Teilnehmern, weil alle mögliche Konstellationen bedacht werden müssen und man aber real nur eine oder wenige hat. Nimmt man die vorweg und baut einen MUX ein, dann fallen viele Puffer und Synchronizer weg, weil es die vorausgeahnten Cross domain clockings, die es geben könnte, nicht gibt. Das spart Routingsresourcen in den clock Taktenleitung und auch RAM. Solche Bussysteme sollte man auch generell nur bauen, wo sie erforderlich sind.
Joachim S. schrieb: > Ich bin mir noch nicht sicher, ob der ganze HDMI Core wirklich > notwendig bzw mit Kanonen auf Spatzen geschossen ist, weil ich ja nur > eine Auflösung und Framerate brauche und diese ggf. auch selbst > implementieren kann. Es sollte eigentlich egal sein, welche Auflösung man nutzt. Die Arbeitsersparnis bei der Verwendung des Cores gegenüber Selberbau sollte dieselbe sein. Was kostet der Core denn eigentlich?
Videomann schrieb: > Solche Bussysteme sollte man auch generell nur bauen, wo sie > erforderlich sind. und sind bei einigen Anwendungen reichlich kontraproduktiv, besonders bei sonst nicht zum System passenden Takten. Wenn man das System vollständig überschaut, ist ein angepasstes timing immer besser, weil man keine Bandbreite durch handshaking verliert und dieses auch nicht ein zyklisches pipelining ruinieren kann. Solche dynamischen Zugriffe sind für Anwendungen geeignet, bei denen mehr als ein Prozess sehr unregelmässig zugreifen möchte und das zu puffern ist. Dann kann man write und read-Anfragen in FIFos puffern und abarbeiten, wenn Zeit ist, z.B. nach einem kompletten Durchlauf einer Rechenroutine, für z.B. eine Regelung. Kommt es dabei aber zu Parameteränderungen, wird es auch schon wieder schwierig, ein freies timing zuzulassen. Auch beim streaming ist das Verknpüfen über AXI auf den ersten Blick bequem, hat aber seine Nachteile, weil der kontinuierliche Datenfluss verloren geht. Bei Video ist das z.B. ein Problem, dass weder der Systemtakt noch der Datentakt konservativ durch das System transportiert wird. Dann braucht es immer eine Art von Taktrekonstruktion und Pufferung und die fordert wieder mehr resourcen. Ehrlich gesagt, mag ich kein AXI.
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.