Hallo zusammen, ich möchte eine Kamera über eine Camera Link-Schnittstelle an einen FPGA (wahrscheinlich Virtex-5 SXT- oder FXT-Reihe) anschliessen. Dafür würde ich spontan die LVDS-Ports des FPGAs nehmen? Da ich mich mit Camera Link jedoch nicht auskenne, weiß ich nicht wie kompliziert die Umsetzung des Protokolls in VHDL ist. Gibt es da bereits fertige IP-Cores? Man findet zu dem Thema im Internet leider sehr wenig. Deshalb hoffe ich, dass sich hier jemand damit auskennt. Vielen Dank schonmal. Gruß, Trebron
Hallo Trebron, das Camera-Link Protokoll ist trivial, Die Spec laesst sich fuer eine Hand voll Dollar kaufen, es finden sich aber bereits sehr viel Informationen auf den Webseiten von National und Cypress. Inoformationen ueber das Protokoll auf Bitebene lassen sich "auf der anderen" Ecke unter anderem Namen FPD, Panellink etc. finden. Das anspruchsvollere ist das Timing. Hier kann man schon mal ein paar Tage bis Woche(n) verschmeissen. Es gibt IP Anbieter, Quellen habe ich jetzt keine da, Google ist hier aber dein Freund. Je nach Anwendung ist es aber sinnvoll, die Cameralink Schnittstelle nicht direkt am FPGA abzubilden, einige Meter Kabel wie in der Spec festgelegt, bieten lange Gelegenheit den FPGA von aussen zu toasten. wenn dann ein Buffer Platz findet, so sollte wenn die Anzahl der IOs nicht das entscheidende ist, einen Serializer/Deserializer von National u. Co. einsetzen. Die kosten nicht (so viel) und man macht sich das Leben bedeutend leichter. Gruss
Hallo Vanilla, danke für die schnelle Antwort. Das mit FPD und Panellink ist ein guter Tipp. Werd gleich mal danach googeln. Mit Serializer/Deserializer meinst du wahrscheinlich so etwas wie den DS90CR287 von National? Gruß, Trebron
Hier findet man auch was: http://photonfocus.com/upload/application_notes/AN021_e_V1_0_CameraLink.pdf Gibt auch sonst sehr viele nützliche Dokumentation auf deren Seite.
Wenn man die Chips vom National benutzt dann hat man nur noch eine Frequenz von 85MHz. Das Timing ist dann für einen Virtex 5 total lächerlich. Ich habe für die Camera Link Umsetzung 3 Tage benötigt. (Allerdings ohne die RS232 Implementierung) Allerdings habe ich Daten vom ADC über Camera Link an den PC gesendet. Ich hatte damals den Full Speed verwendet da benötigt man 3 ICs von National. und insgesamt so ca. 25x3 IO-Ports am FPGA. Dafür kommen dann aber auch 680MByte pro Sekunde über die Leitung. Beim Camera Link gibt es kein CRC32 oder ähnliches wenn Daten beschädigt werden sind diese halt dauerhaft defekt und es gibt keine Möglichkeit dies zu merken (nur so als Hinweis).
> Wenn man die Chips vom National benutzt dann hat man nur noch > eine Frequenz von 85MHz. Was aber dem Datentakt entspricht. Der serielle Takt ist höher. Bei einer Implementierung im FPGA kommt man da an die 600 MHz, was nicht mehr so einfach zu realisieren ist. Du brauchst eine Kompensation der IO-Laufzeiten und eine Art Taktsychronisation. Habe das vor 2 Jahren mal gemacht.
Moin, würde auch in dem Fall eher die Transceiver/Deserializer benutzen, in der CameraLink spec sind einige mögliche Typen aufgelistet. Schon einmal bei laufenden Betrieb Kabel ein/ausstecken könnte das FPGA braten (manche Kabel haben auch nicht das beste Grounding, sind auch schon mal eben ~100V Potential zwischen den verschiedenen GNDs gesehen worden). Apropos, es gibt auch Leute, die CRC32 checksummen in der letzten Bildzeile übertragen, frei nach dem Motto "you can pimp (almost) every braindead standard" :-)
Ich würde auch auf jedenfall die Camera Link ICs verwenden die sind wirklich nicht sehr teuer benötigen aber schon Platz auf einer Platine da man 3 Stück für Full Speed benötigt. Meine Platine besitzt 8 Lagen was die Fertigung wieder etwas teurer macht aber daruch ging es sehr schnell und benötigte nur kurze Entwicklungzeit.
Hallo, ich glaube mittlerweile auch, dass ich Serializer/Deserializer einsetzen werde. Erspart einem ne Menge Ärger, wenn ich allein daran denke 600MHz intern im FPGA verarbeiten zu müssen... Der Platz ist in diesem Entwicklungsstadium noch kein Problem. Es geht erst mal nur um einen Funktionsnachweis. Am liebsten wäre mir deshalb sogar ein fertiges Board zu kaufen oder ein vorhandenes Board (ML506 von Xilinx) aufzurüsten.
Trebron schrieb: > wenn ich allein daran denke 600MHz > intern im FPGA verarbeiten zu müssen... Müsstest du ja nicht. Dafür gibts die RocketIOs, oder GTP/GTX Transceiver wie sie sich jetzt nennen. Die machen das alles für dich. Aber auch die sind nicht ganz trivial zu handhaben, da gibts hunderte Parameter. Das Argument mit dem Stecken unter Strom ist da auch was wert, so ein Virtex 5 mit GTP Transceivern kostet ja nicht gerade wenig.
Christian R. schrieb: >> wenn ich allein daran denke 600MHz >> intern im FPGA verarbeiten zu müssen... > > Müsstest du ja nicht. Dafür gibts die RocketIOs, oder GTP/GTX > Transceiver wie sie sich jetzt nennen. Die machen das alles für dich. > Aber auch die sind nicht ganz trivial zu handhaben, da gibts hunderte > Parameter. Das Argument mit dem Stecken unter Strom ist da auch was > wert, so ein Virtex 5 mit GTP Transceivern kostet ja nicht gerade wenig. Wenns nicht umbedingt 85MHz Pixeltakt sein müssen, dann kann mit den Desrialisern der Virtex5 und Spartan6 IOs schon etwas angefangen werden. Die Rocket IOs sind für den zweck eher weniger geeignet...
Ich werde auch einen ähnlichen interlink machen müssen, allerdings nicht nach dem Cameralink-Protokoll, sondern einem internen Standard. Ich brauche 10 Bits, die jeweils 8fach seriell kommen, als parallele Welt. Bislang habe ich nur mit Altera zu tun. Wieso sollen die Rocket IOs dafür nicht geeignet sein? Wegen des Programmieraufwandes oder aus technischen Gründen? - Was wäre denn sonst noch bei Xilinx vorhanden?
Ralf Kimme schrieb: > Wieso sollen die Rocket IOs dafür nicht geeignet sein? Wegen des > Programmieraufwandes oder aus technischen Gründen? - Was wäre denn sonst > noch bei Xilinx vorhanden? Ja der Programmieraufwand das Einsamplen des hier genannten LVDS Standards wäre sehr hoch. Du hast im Protokoll keine Synchroniserung der einzelnen Lanes zueinander. Genau dass musst Du aber wenn Du mehrere GTX-Tiles nutzt. Der Eingangstakt von "nur" 85MHz taugt aber nicht fuer die Rocket-IOs, den musst Du vorab durch eine normale PLL schicken. Jetzt wirds leicht spekulativ, müsste erst die Datenblätter nochmals wälzen: Da in den Daten nunmehr kein fuer die RocketIOs mehr verwertbarer Clock mehr enthalten ist, muessen die (Virtex5) RocketIOs im Oversampling Mode betrieben werden. Fuer den Parallelbetrieb mehrerer RocketIOs ist dann des Abschaltewn von FlexibleBuffer und Co notwendig. Jetzt kommen dann Probleme des internen Phaseallignement (na gut ist ja fast DC Betrieb und damit beherschbar) und der relativ stiefmuetterlich dokumentierten Betrieb im Oversampling erst einmal zu implementieren. Die Rocket-IOs sind einfach fuer anderes gemacht... Wenn einer eine Idee hat wie obiges mit den RocketIOs angenehmer zu lösen ist, bitte korregieren... Mit den "normalen" IOs vom Virtex5 lassen sich wiederum bis zu Zitat:"Up to 1.25 Gb/s LVDS (on all differential I/O pairs)" einsamplen und deserialiseren. dazu kann man mit den Dingern auch Skews korregieren. Das ganze ist auch nicht trivial und nix fuer Anfaenger, aber sicherlich einem Abenteuer mit der RocketIOs ohne Not vorzuziehen. P.S. Die Spartan6 haben ähnliche Fähigkeiten in den IOs, insgesammt etwas gemächlicher, aber in Richtung 70MHz-Cameralink kann man damit schon zielen und hätte dann eine einigermassen preisguenstige Loesung...
Naja, die 85Mhz wären ja nach dem Deserializer für die parallelen Daten, auf der CameraLink Seite ist es ja seriell und damit ein viel höherer Takt, das sollte mit den schon GTP gehen. Allerdings weiß ich nicht, wie da die Komma und K-Chars aussehen, falls überhaupt vorhanden. Ich kenn das Protokoll auch nicht, weiß auf Anhieb nicht wie die Synchrosnisierung aussieht. Mit den ISERDES ist das immer so eine Sache, die können ja maximal 4 Bit deserialisieren, oder waren es 7? Dann könnte es ja gehen, der o.g. Chip überträgt die 18 Bit auf 4 Leitungen. Dann könnte es mit den GTP wirklich eng werden, sind ja "nur" 595MBit/s.
Christian R. schrieb: > Allerdings weiß ich nicht, wie > da die Komma und K-Chars aussehen, falls überhaupt vorhanden. Ich kenn > das Protokoll auch nicht, weiß auf Anhieb nicht wie die > Synchrosnisierung aussieht. Beim Cameralink gibt es keine 8b10b Codiering. Es gibt keine K-Character. Das Allignement innerhalb des Protokolls ist fest auf den mitlaufenden Clock welcher 1/7 der Bautrate entspricht verbunden. Mit den ISERDES ist das immer so eine Sache, > die können ja maximal 4 Bit deserialisieren, oder waren es 7? Dann > könnte es ja gehen, der o.g. Chip überträgt die 18 Bit auf 4 Leitungen. > Dann könnte es mit den GTP wirklich eng werden, sind ja "nur" 595MBit/s. Die ISERDES Zellen des Virtex5 koennen von Hause aus 6Bit deserialisieren, ABER es kann einem Slave ISERDES auf 1/10 erweitert werden... Wenn man wirklich mit den GTPs arbeiten will dann kommt man nicht umhin, das ganze zu "oversampeln" und dann hinterher wieder auseinanderzunehmen. Wie gesagt das Cameralink LVDS Geraffel kennt nix von dem was die Rocket-IOs ausmachen. Keine 8b10b (oder 64/68 oder wie auch immer geartete Bitkodierung mit DC Balancing).
Achso, na dann gehts mit den GTP kaum. Die ISERDES sind allerdings auch nicht ganz ohne. Ich wollte sowas mal für einen seriall ausgebenden High Speed ADC machen. Aber die 14 Bit hab ich da nirgends unter bekommen und zu langsam war die Geschichte auch noch (Spartan 6).
>Mit den ISERDES ist das immer so eine Sache,
Habe mal nachgesehen: Laut CoreGen können die 10 Bit. (???)
Richtig. Das ist je nach Typ bissl unterschiedlich. Ich hatte da jetzt den S6 im Hinterkopf, der kann mit Kaskadierung nur 8 Bit maximal. Dann muss der Eingang aber differenziell sein.
Kaskadierung? Kann man das auch weiter treiben?
Ralf Kimme schrieb: > Kaskadierung? Kann man das auch weiter treiben? Das sind keine freie Resourcen sondern fest den IO-Zellen zu geordnet. Von daher ist eine Kaskadierung nicht möglich.
Na was denn jetzt: Kaskdierung ja oder nein? Welche maximale Deserialisation bekommt man denn damit hin?
Wieso nicht mal einfach im User Guide nachschauen? Da stehts eindeutig drin. Ich hab bzgl. der Kaskadierung oben vom Spartan 6 gesprochen.
Der User Guide ist ein wenig unklar, finde ich. Einerseits wird davon gesprochen, dass man für mehr, als 6 Bits eine Kaskadierung braucht, um auf genügend Bits zu kommen und auch der Coregen das angeblich nicht kann, andererseits liefert der CoreGen eine Implementierung für bis zu 10 Bits. Ich habe das damals mit dem CoreGen gemacht, allerdings nur eben 6 Bits x n
Aus Interesse hab ich jetzt mal für den Spartan 6 so ein Design simuliert. Ausgangspunkt ist die serielle LVDS Ausgabe des neuen LTM9010-14 ADC Modul von LT. Mithilfer der XAPP1064 versteht man besser, wie die ISERDES funktionieren. Und tatsächlich lässt sich das bei LVDS so verschalten, dass die 2 Lanes mit je 400 MHz und DDR mit dem S6 mit minimalem Ressourcen-Verbrauch einlesbar sind. Da braucht man nicht mal eine PLL, geht mit den BUFIO2 Dingern und Master/Slave ISERDES. Das Frame Signal erzeugt das BitSlip Signal, um die Datenströme an der Wortgrenze auszurichten. Sehr interessant die ganze Geschichte....
Ich kann nur dazu raten blos keine GTP/GTX zu verwendet. Man benötigt für den vollen Camera Link Standard 15 Leitungen mit je 595MHz(85MHz x 7). Demnach benötigt man auch 15 GTP/GTX. Dieser FPGA kostet dann so extrem viel das es kaum bezahlen kann. Die 3 IC kosten demnach 20€ oder weniger benötigen halt nur ein wenig Platz man kann ohne Propleme einen 30€ teuren Spartan 6 nehmen. So kostet der Virtex 5 bereits mit den ganzen GTP/GTX bereit mehr als 1000€.
Ja, das war eine Fehl-Annahme von mir mit den GTP/GTX. Mit den ISERDES scheint das ja ziemlich gut zu gehen, die sind offenbar genau für sowas gemacht.
>BitSlip Signal
Muss das vor oder zum Wortwechsel aktiv sein?
In der Appnote wird das immer mal für einen (langsamen) Takt aktiv, solange das empfangene Wort nicht der Referenz entspricht. Dann ist da ein Zähler, der eine Pause macht und dann wieder nachguckt. In der Simulation dauert es ein paar solcher Zyklen, bis der sich auf das Frame Signal synchronisiert hat. Das ist recht einfach. Am Anfang hat mich nur die verdrehte Bit-Reihenfolge etwas genarrt.
Christian R. schrieb: > Am Anfang hat mich nur > die verdrehte Bit-Reihenfolge etwas genarrt. Ja das ist nervig! Ich sass hier auch etwa eine Woche bis mir das BitSlip signal auffiel und ich endlich meinen stream synchronisieren konnte...
Man kann auch händisch auf den Takt synchronisieren, wenn man die Lage des Signals kennt. Beim Cameralink liegt der Bitwechsel je nach Protokoll anders. Daher sollte man sowas einstellbar halten.
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.