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
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).
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.
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.
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.
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.
