Hallo zusammen, ich bin FPGA- und VHDL-"Frischling" und arbeite an einem ersten etwas größeren Projekt. Vielleicht kann mir jemand bei der einen oder anderen Frage helfen bzw Denkanstöße geben? Die Hardware: - Trenz TE0720 GigaZee, also ein Xilinx Zynq-7000 (XC7Z020) - Carrier Board: Trenz TE0701 - Kamera: JAI CV-M4+CL Ich arbeite mit Vivado 2015.4 Es gibt bereits einen IP-Core von Xilinx, der im Grunde genau das tut, was ich brauche: den SelectIO Interface Wizard mit dem Interface Template "Camera Link Receiver". Meine ersten Versuche waren intuitiv (und falsch): Ab mit dem Wizard ins Block Design, Kamera an den Mini-CamLink-Stecker des Boards, differentielle Ports im Block Design erstellt und in den Constraints entsprechend zugewiesen und dann bietet einem der Block ja differentielle Eingänge für einen Clock und für die Datenkanäle. Das konnte nicht funktionieren, wie ich inzwischen weiß, weil das Herzstück des CamLink-Receiver-Blocks ein ISERDES ist, der als Eingangsclock einen sieben mal schnelleren Clock benötigt als von der Kamera übertragen (In einem Takt kommen ja 7 Bit seriell an, Datenwortbeginn in der Mitte der High-Phase, Duty Cycle 4:3. Der Deserializer braucht aber einen Takt pro Bit). Also verwende ich einen weiteren Block, den Clocking Wizard (im Grunde ein MMCM), der den differentiellen Eingangsclock für den IO-Wizard multipliziert. Mir ist klar, dass ich damit das Signal puffere und sich ggf der Beginn eines Datenworts verschiebt. Nun zu meinen Fragen: 1. Die Auswirkungen des vermutlich phasenverschobenen Clocks müssten mit der Bitslip-Funktion auszugleichen sein, oder? Ich habe zwar verstanden, auf welchem Prinzip diese Funktion basiert, aber mir ist nicht klar, was der "bitslip"-Eingang des IO-Wizards bewirkt - ist das eine Konstante, die beschreibt, um wieviel Bit ein Datenwort verschoben ist? Oder ein Takt zum Abgleichen...? 2. Ich überprüfe die Signale mit einem Oszi. Ich sehe, dass die Clocks in Phase und der eine tatsächlich 7mal schneller als der andere ist - so weit, so gut - aber es finden sich nur 7 statt 10 erwarteter Datensignale (die sichtbar auf unterschiedliche Lichtverhältnisse reagieren) und data valid, frame sync und line sync fehlen komplett. Ideen, woran das liegen könnte? (jedenfalls ist es ohne diese Signale kein Wunder, wenn nichts funktioniert...) Ich danke euch fürs "Zuhören" und freue mich auf eure Unterstützung! Jana
Das ganze hört sich durchaus so an, als würdest Du den schnellen Takt herunterteilen und als neuen Takt verwenden. Das ganze sieht zwar auf dem Oszilloskop schön phasensynchron aus, bereitet aber im FPGA erhebliche Probleme, da der durch die Frequenzteilung oder -vervielfachung erzeugte Phasenversatz doch zu einer separaten Clock-Domain führt. Folglich müsstest Du entweder beim Wechsel zwischen den Domains neu einsychronisieren (hmmm...) oder (besser!) durchgängig der ursprünglichen hohen Takt verwenden und mit niederfrequenten Clock-Enables arbeiten.
:
Bearbeitet durch User
Hallo Andreas, danke für deine Antwort! Andreas S. schrieb: > Das ganze hört sich durchaus so an, als würdest Du den schnellen Takt > herunterteilen und als neuen Takt verwenden. Nein, anders herum - die Kamera liefert einen langsamen Takt, den ich mit 7 multipliziere. > Folglich müsstest Du entweder beim Wechsel zwischen > den Domains neu einsychronisieren (hmmm...) oder (besser!) durchgängig > der ursprünglichen hohen Takt verwenden und mit niederfrequenten > Clock-Enables arbeiten. Das klingt gut, um den Takt herunterzuteilen, aber zum Beschleunigen...?
Jana B. schrieb: > Das klingt gut, um den Takt herunterzuteilen, aber zum Beschleunigen...? Da dein "schneller" Takt der Pixeltakt von 40,49 MHz ist (wenn das das richtige Datenblatt gerade ist), müsste dein Clock ja bei etwa 5,78 MHz.. liegen. Schnapp dir den Clock oder irgendeinen und erzeug z.B. 40,49 x4 -> 161,96MHz. Damit hast du einen viel größeren Takt zum Abtasten.
Ich habe Cameralink sowohl auf dem Spartan6 als auch dem Virtex6 realisiert. Der XI-Core alleine wird Dir da nicht viel weiterhelfen, weil das Eigentliche in eben der Steuerung der SERDES, deren Beschaltung und dem Eintrainieren der Eingänge aud die lanes besteht, was der Core nicht leistet - nach wie vor im Übirgen nicht, darf ich sagen (wir hatten den damals auch probiert, kam mit 13.2 raus, meine ich). Dazu braucht es einiges an constraints, also elektrische Themen. Wäre als Core für den Artix 7 rechtefrei verfügbar. Kann 560/640MHz auf bis zu 4 lanes und cables mit combined transmission, also 10,8Gbit. Preis VHS. Allerdings braucht es da noch ein paar Infos besonders zu dem Timing eines eventuellen Buffers / CL-Receivers. Zu Deinen Überlegungen: Sieh Dir erst nochmal an, mit welchen Takten CL überhaupt kommt, welchen Jitter Du Dir erlauben kannst / tolerieren musst und wie das Einsynchen auf den Mastertakt bei CL überhaupt gedacht ist, d.h. wie die Bits kommen und wann ein slip kommen darf /muss und wann nicht. In Deinen Darstellungen erkenne ich so einige Missverständnisse. Die 40,49 sind schon mal definitiv nicht richtig und auch die 4/3 Thematik verdient einige Beachtung.
Klakx schrieb: > Da dein "schneller" Takt der Pixeltakt von 40,49 MHz ist (wenn das das > richtige Datenblatt gerade ist), müsste dein Clock ja bei etwa 5,78 > MHz.. liegen. Nein, die 40 MHz ist der langsame Takt, der von der Kamera generiert wird. Klakx schrieb: > Schnapp dir den Clock oder irgendeinen und erzeug Du meinst, ich sollte mit der Frequenz höher gehen als die Geschwindigkeit, mit der die Bit eintreffen, und damit jedes Bit mehrfach abtasten? Dann hilft mir aber vermutlich der ISERDES nichts mehr, und ich muss selbst was schreiben, oder seh ich das falsch? ... oder nachher doppelte Datenworte aussortieren... Videoprozessierer schrieb: > Der XI-Core alleine wird Dir da nicht viel weiterhelfen, > weil das Eigentliche in eben der Steuerung der SERDES, deren Beschaltung > und dem Eintrainieren der Eingänge aud die lanes besteht, was der Core > nicht leistet Die Befürchtung hab ich inzwischen auch - aber ist es dann nicht absurd, dass es nicht etwa nur den Block gibt, sondern explizit eine vorgefertigte Camlink-Konfiguration? Videoprozessierer schrieb: > Preis VHS. Ich wills ja selbst lernen ;) Videoprozessierer schrieb: > Timing > eines eventuellen Buffers / CL-Receivers Ou, gutes Stichwort! Diesbezüglich sollte ich mich dringend schlau machen. Videoprozessierer schrieb: > In Deinen Darstellungen erkenne ich so einige > Missverständnisse. Oje. Ich dachte, da hätte ich schon ein bisschen was ausfiltern können. Danke, dann werde ich nochmal alles von vorn aufrollen und versuchen, meine Fehler zu finden. Hast du ein Beispiel für besagte Missverständnisse?
Moin, in der Annahme, dass das ein Lernprojekt bzgl. CL ist und zu keinem Produkt führen soll, würde ich mir mal zum Thema "Clock Recovery" etwas Literatur reinziehen. Es gibt auch eine Menge Appnotes zu "7:1 lvds video" und den beliebten Gearboxen. Auf den Spartanern ist das zwar alles etwas mühsamer zu handhaben, sollte aber bei 40 MHz noch locker ohne Handoptimierung gehen, also wird's auf dem Zynq ähnlich sein (kann ich aber nicht wirklich mitreden, auch was die dortigen Coregens angeht nicht). D.h. eigentlich solltest du nur das Problem lösen müssen, einen sauberen Clock rauszubekommen (PLL) und mit minimalem Phasen-Jitter die Channel-Bits abzutasten. Da sollte dich die XAPP1064 eigentlich weiterbringen. Die bitslip-Geschichte brauchst du bei CL nicht, das ist eher bei HDMI relevant (wo ein Anfang eines Datenworts per Patternmarke detektiert werden muss). Wichtig ist natürlich auch, dass die HW richtig verkabelt ist (Edge-Clocks), aber davon gehe ich jetzt mal aus. Abgesehen davon ist die Aufgabe für FPGA-Rookies noch recht knackig. Viel Glück... - Strubi
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.