Hallo liebes Forum, ich muss demnächst einen 2D-CMOS-sensor in Betrieb nehmen welcher schon digitalisierte Pixeldaten in Form von LVDS liefert. Kurz die Eckdaten: Resolution: 1902 x 360 pixel Framerate: 300Hz ADCs: 4x12bit LVDS outputs: 4 x 2 data channels Digital system clock input frequency: up to 150 MHz Da ich noch nie mit LVDS+FPGA gearbeitet habe, hier ein paar Fragen an euch: 1) Gibt es gute Tutorials im Netz. Links? (ja ich hab im WWW auch schon gesucht, aber eventuell habt ihr ja noch gute Links). 2) Ich habe ein Spartan3A-Board. Ist dieses überhaupt in der Lage LVDS-Signale zu verarbeiten? 3) Benötigt man einen vorgeschalteten LVDS-Receiver oder kann das der FPGA auch alleine? 4) Gibt es eventuell Xilinx-Demoboards mit implementierter LVDS-IP bei der man sich LVDS-Datencapturing einmal im Detail angucken kann? Danke für eure RE's :) MfG fwc
Du musst 3 Themen trennen: 1) LVDS Eingänge. Das sind dif-eingänge, die das FPGA haben muss. Ferner muss dein Board passend layoutet sein. Nach diesen Buffern bist Du eindimensional 2) Taktfrequenz: Das board muss das können und gfs gematcht Leitebahnen haben, speziell bei der Freuqenz! Spartan 3A sind langsam. Bei 150MHz wirsr Du Probleme bekommen. 3) Synchronisation: Dein VHDl Design muss u.U. mehrere Inputs auf einen Takt synchronisieren, d.h. IODELAYs einstellen. Das wiederum muss der FPGA Eingang können. Spartan 3 A hat sowas nicht, soweit ich weiss. Ferner kann es sein, dass du den Takt einsampeln muss. Dazu muss deines Sytemtaktfrequenz >2 der Datenfrequenz sein. Das scheint mir schon mal susgeschlossen.
Habe gerade nochmal nachgerechnet: Die Bruttorate sind wenigesten 600 MBit je Kanal x 4 x 12Bit für 300 fps und der Auflösung. Welche Taktfrequnez ist geplant? 300 fps lassen sich mit 150MHz nicht machen! I.d.R haben solche Sensoren auch noch ein nichtkontinuierliches Timing wegen der Belichtung und Leerzeilen / Markerzellen. Daher wird es noch schwerer, solche eine Framrate rauszuholen. Machen wir es mal moderat: X 1902 Y 360 pixel 684.720 fps 60 pixl/sec 41.083.200 channels 4 pixl/sec 10.270.800 bits 12 clock 123.249.600 Damit wäre Reserve für den ADC Strom, der nicht in 12 Takten auch 12 Bits ausgeben kann. Sensoren, die ich zuletzt verwendet habe, hatten 640x480 und 72 fps und kamen auf einem Kanal mit ddr: X 640 Y 480 pixel 307.200 fps 72 pixl/sec 22.118.400 bits 14 clock 309.657.600 ddr 2 clk ddr 154.828.800 (theoretisch) real war das hys/vsyn timing aber so, scheinbare 688 x 512 pixel ausgeben wurden. Mit 200 MHz DDR habe ich dann gut 70 fps hinbekommen. Macht Dein Sensor das Timing selber oder gibts du den Takt vor?
Hi, bei dem knackigen Clock würde ich mir die Option Deserializer (gibt da fertige Chips, glaube von National Semi) und Spartan6 offenhalten. Zu ersterem gab's irgendwo hier mal einen Thread.. Grüsse, - Strubi
Strubi schrieb: > und Spartan6 Dann eher oder. Der Spartan 6 hat Deserielizer an jedem I/O Pin eingebaut, die bis zu 1080MBit/s gehen.
Die Deserializer, die 14 Bit verarbeiten, musst Du mir mal zeigen. Das geht dann nur wieder mit Trickserei und variablem bitslip und das Problem der grundsätzlichen Taktfequenz wird ja nicht gelöst. Die Bandbreite der Sensoren ist mit 150MHz nicht auszureitzen, auch wenn der FPGA mehr könnte.
hey Leute, danke erstmal für die Antworten, bin noch nicht dazugekommen sie richtig zu lesen, das wird erst morgen etwas....
Wie lange brauchst du, um 5 Beiträge zu lesen (?)
Robert schrieb: > Die Deserializer, die 14 Bit verarbeiten, musst Du mir mal zeigen Stimmt, die können erst mal nur 8 Bit pro Lane. Aber mit Tricksen geht auch mehr, die XAPP1064 ist zwar ziemlich kryptisch, aber es soll wohl gehen. Löst aber nicht das 150MHz Problem, das ist auch wahr. Mit dem S3A ist das aber dann gänzlich unmöglich. Jedenfalls ohne externen Deserializer.
Nahmd, deswegen der Vorschlag, fertige Deserializer (einige schaffen bis 18 Bit) zu nehmen, für ein Evalboard lohnt es ev. nicht, sich mit den Xilinx-Refdesigns rumzuschlagen und die Clockpfade debuggen zu müssen, da kann genug schiefgehen.
Christian R. schrieb: > Stimmt, die können erst mal nur 8 Bit pro Lane. Aber mit Tricksen geht > auch mehr, Die können aber auch 7 Bit pro Lane. Und daraus dann mit einem Demultiplexer 14 machen ist doch eher trivial. Davon abgesehen braucht der TE nur 12 bit. Christian R. schrieb: > Löst aber nicht das 150MHz Problem, das ist auch wahr. Das existiert IMO nicht. bei 150 MHz DDR hat er bei 8 Lanes (4 ADCs a 2 Lanes) 2.4 GBit/s. Für seine angestrebte Auflösung und Bildrate braucht er 2.465 GBit/s. Das passt doch.
Ich hatte die 4x2 channels als LVDS interpretiert. Wenn es wirklich 8 sind, wieso nennt man sie nicht so? Es bliebe dann aber noch die Unsicherheit mit der Netto/Bruttopixelzahl, sowie die Frage, ob wirklich 12Bit-Pakete non stop daher kommen und nirgendwo eine Sende-/Reset-/oder Belichtungspause besteht. Und sind es auch wirklich 1902 und nicht etwa doch 1920? Vielleicht kann der TE mal ein Datenblatt posten.
Lattice User schrieb: > bei 150 MHz DDR hat er bei 8 Lanes (4 ADCs a 2 Lanes) 2.4 GBit/s. > Für seine angestrebte Auflösung und Bildrate braucht er 2.465 GBit/s. > Das passt doch. Wenn das so ist ja, aber niemand weiß, ob es wirklich 2 Lanes pro Kanal sind und ob die DDR betrieben werden....an sich gehen die ISERDES am S6 ziemlich gut, ich betreibe hier einen LTC2175 zum Testen damit, erzeugt bei 125MS/s 1GBit/s Datenstrom pro LVDS Paar, das kommt fehlerfrei rüber.
Hallo, also für das Datenblatt musste ich eine NDA unterschreiben, deswegen kann ich es hier nicht posten. Robert schrieb: > 1) LVDS Eingänge. Das sind dif-eingänge, die das FPGA haben muss. Ferner > muss dein Board passend layoutet sein. Nach diesen Buffern bist Du > eindimensional OK, also der FPGA ist direkt der Receiver. Mir war nicht ganz klar ob ich hier noch einen Receiver vorschalten muss um die Signale wieder "zusammen zu basteln". Robert schrieb: > 3) Synchronisation: Dein VHDl Design muss u.U. mehrere Inputs auf einen > Takt synchronisieren, d.h. IODELAYs einstellen. Das wiederum muss der > FPGA Eingang können. Spartan 3 A hat sowas nicht, soweit ich weiss. OK Spartan3A is also kein gute Idee. > Ferner kann es sein, dass du den Takt einsampeln muss. Dazu muss deines > Sytemtaktfrequenz >2 der Datenfrequenz sein. Das scheint mir schon mal > susgeschlossen. Wann kann das der Fall sein? Mein Spartan3A_Board ist von TRENZ Elektronik. Da sind 100 MHz und 24 MHz Oszillatoren drauf. Allerding hatte ich es beim studieren von LVDS so verstanden, das ich zum Einlesen der Daten direkt den LVDS-Takt nutze . Ich bin also davon ausgegangen das der LVDS-clock erst einmal unabhängig von dem Systemclock des FPGA's ist. Robert schrieb: > Ich hatte die 4x2 channels als LVDS interpretiert. Wenn es wirklich 8 > sind, wieso nennt man sie nicht so? Weil ich es nicht besser weiss :) Wie gesagt, alles noch nie gemacht, also bitte habt etwas Gedult mit mir. Im Datenblatt steht: This block consists of a programmable delay block, an embedder block, and a LVDS transmitter with 2 data output channels. In total 4 LVDS modules are implemented. So, in total up to 8 LVDS channels are available for data transmission. A total of four LVDS transmitter blocks are implemented. Every LVDS transmitter block uses up to four high-speed LVDS data channels in order to transmit sensor data. The LVDS data channels are optionally accompanied by a clock signal that is output from the internal LVDS serializer PLL. LVDS data signal is composed of the 12-bit sampled video signal as well as control signals that can be used for video frame processing at the receiver side. It is generated in the LVDS embedder module. So, the LVDS embedder module is a digital data processing block that processes an incoming data stream originating from the A/D converter (ADC) via the delay block and outputs it to the LVDS serializer. Robert schrieb: > Und sind es auch wirklich 1902 und nicht etwa doch 1920? Richtig, war ein Zahlendreher, sorry! Also: 1920x360 Pixel Robert schrieb: > Machen wir es mal moderat: > > X 1902 > Y 360 > pixel 684.720 > fps 60 > pixl/sec 41.083.200 > channels 4 > pixl/sec 10.270.800 > bits 12 > clock 123.249.600 > > Damit wäre Reserve für den ADC Strom, der nicht in 12 Takten auch 12 > Bits ausgeben kann. Ich hatte bisher in der Annahme das das korrekt ist, so gerechnet: X 1920 Y 360 clock 150 MHz 4 ADCs => Datarate = 4x150 Mhz = 600 MSamples/s => @12bit=600 MSamples/s * 12bit= 7.2 Gbit/s Ich hatte allerdings noch unterschlagen, bzw. ist mir das jetzt erst aufgefallen, das die Datenrate am Ausgang des Sensors durch das Binning (der Sensor hat eig. 1920x1080 Pixel und wird durch ein 3x1-Binning auf 1920x360 getrimmt) um den Faktor 12 reduziert ist. Es ergibt sich also eine Datenrate von 7.2 Gbit/s / 12 = 600 Mbit/s. Falls das korrekt ist, stellte sich eben die Frage ob ich das mit meinem Spartan3A noch gehandlet bekomme. Aber Spartan3A ist ja eh gecancelt... Robert schrieb: > Macht Dein Sensor das Timing selber oder gibts du den Takt vor? Macht er alles selbst, über ne SPI wird "einfach" Framerate und Exposure time eingehackt. Robert schrieb: > Welche Taktfrequnez ist geplant? 300 fps lassen sich mit 150MHz nicht > machen! Wenn ich in die Formeln in der AppNote des Sensors meine Wunschparameter einhacke komme ich auf knapp 348Hz bei einer Systemclock von 150MHz. Laut Hersteller stimmt das auch, ahbs nochmal gegen checken lassen. Also ertsmal mein Mini-Resumee: Spartan6-Board und Einarbeitn in LVDS-Datenaufnahme mittels FPGA :)
full well schrieb: > Ich hatte bisher in der Annahme das das korrekt ist, so gerechnet: > X 1920 > Y 360 > clock 150 MHz > 4 ADCs > => Datarate = 4x150 Mhz = 600 MSamples/s > => @12bit=600 MSamples/s * 12bit= 7.2 Gbit/s > > Ich hatte allerdings noch unterschlagen, bzw. ist mir das jetzt erst > aufgefallen, das die Datenrate am Ausgang des Sensors durch das Binning > (der Sensor hat eig. 1920x1080 Pixel und wird durch ein 3x1-Binning auf > 1920x360 getrimmt) um den Faktor 12 reduziert ist. > Es ergibt sich also eine Datenrate von 7.2 Gbit/s / 12 = 600 Mbit/s. das stimmt vorne und hinten nicht. Also nochmal ganz von vorne alles genau anschauen und verstehen.
Lattice User schrieb: > das stimmt vorne und hinten nicht. > Also nochmal ganz von vorne alles genau anschauen und verstehen. Hm, wenn ichs mir genau anschaue stimmt das mit dem 3x1-Binning schonmal nicht. Es ist ein 1x3-Binning. Wäre nett, wenn du mir zmd. nen Tipp gibst was da nicht stimmt :)
Die 1920 x 320 sind bereits die gebinnte Pixelzahl? Die 360 sehen mir verdächtig nach 1080/3 aus! Hast Du dann vorne auch 1920/3 ? 640 pixel? Kommen die Daten überhaupt seriell oder doch parallel? So wie du das schreibst, hast Du 8 Kanale + Takt auf denen neben den Videobits noch Kontrollsignale kommen. Was Du zu allererst mal machen solltes: Rechnen! Wenn du das nicht hinbekommst, sehe ich schwarz. Ich sehe hier (1920 + x) / 150 MHz = 13,3 us pro Zeile und wenigstens 5ms je Bild. Wenn man das über 8 Kanäle DDR liest, sind das 3ms. Damit kämen die 300 Hz hin. Die Frage ist, wie die 8 Datenkanäle die Zeilen auswerfen und ob das lücken/pausenlos geschieht. SERDES sind hier vollkommen überflüssig. Du übernimmst einfach mit den abkommenden Takt des Sensors und pufferst. Danach hast Du irgendwann 150MHz parallel 12 Bit Registerdaten, wie auch immer die ankommen mögen. Da muss gfs etwas sortiert werden. Das Ganze ist aber IMO ein rein funktionslogisches Problem. Das kann ein S6 locker, wenn man ihm genug Register verpasst, allerdings hat der einige Macken und Beschränkungen bei den Takten. Du solltest ERST das VHDL design fertig haben, bevor du ins Layout gehst.
full well schrieb: > and outputs it to the LVDS serializer. Empfehler schrieb: > SERDES sind hier vollkommen überflüssig. Ich weiß nicht so recht, irgendwie ist die Beschreibung des Interfaces eher dürftig. Irgendwas wird offenbar doch serialisiert....aber "up to 8 LVDS channels" ist ja auch eine schwammige Angabe. Vielleicht lässt sich das per SPI einstellen?
Empfehler schrieb: > Die 1920 x 320 sind bereits die gebinnte Pixelzahl? > > Die 360 sehen mir verdächtig nach 1080/3 aus! > > Hast Du dann vorne auch 1920/3 ? 640 pixel? Der Sensor hat 1920x1080 Pixel, hatte ich schon geschrieben. Nein die 1920 werden nicht gebinnt, es ist nur zeilenweises Binning möglich (max 1x3). Also 1920 x 360. Empfehler schrieb: > Was Du zu allererst mal machen solltes: Rechnen! Wenn du das nicht > hinbekommst, sehe ich schwarz. Sehe ich auch so^^ Datenblatt muss ich mir jetzt doch nochmal gaaaanz genau reinziehen... Empfehler schrieb: > Ich sehe hier (1920 + x) / 150 MHz = 13,3 us pro Zeile und wenigstens > 5ms je Bild. Wenn man das über 8 Kanäle DDR liest, sind das 3ms. Damit > kämen die 300 Hz hin. Wenn ich das Datenblatt zu Hilfe nehme komme ich auf ca. 348fps (per Formel) Empfehler schrieb: > Die Frage ist, wie die 8 Datenkanäle die Zeilen auswerfen und ob das > lücken/pausenlos geschieht. Gute Frage, das Datenblatt ist mein Freund und Helfer. Empfehler schrieb: > SERDES sind hier vollkommen überflüssig. Du übernimmst einfach mit den > abkommenden Takt des Sensors und pufferst. Danach hast Du irgendwann > 150MHz parallel 12 Bit Registerdaten, wie auch immer die ankommen mögen. > Da muss gfs etwas sortiert werden. Das Ganze ist aber IMO ein rein > funktionslogisches Problem. Das wäre meine Wunschlösung :) Mit SERDES meinst du Serializer/Deserializer? Empfehler schrieb: > Das kann ein S6 locker, wenn man ihm genug Register verpasst, allerdings > hat der einige Macken und Beschränkungen bei den Takten. Hast du einen anderen Vorschlag für nen geeigneten FPGA? Ich frage das, weil ich bisher nur mit Spartan3A gearbeitet habe...hat bisher gereicht und die Projekte waren noch relativ simpel. Ist aber auch der Grund warum ich mir nicht zutraue jetzt z.B. auf Altera umzusteigen.
>Altera Ein Cylcone III kann das ohne Probleme. Mit dem C3 habe ich schon Video mit 192MHz gebaut. Ist das ein Privatprojekt? Dann nimm Altera. Sobald Du externe Signale bekommst, bei denen das Timing kritisch ist, ist ein interner LogicAnalyzer sehr hilfreich und der ist nur bei Altera kostenlos dabei. Zu empfehlen ist momentan das Cyclone 4 academic mit dem grossen 115k chip. Der reicht vom Tempo zweimal. full well schrieb: > Wenn ich das Datenblatt zu Hilfe nehme komme ich auf ca. 348fps (per > Formel) D.h. Du kannst den Sensor selber takten und er liefert Dir den frame? Sind die 150MHz ein Fixum? Solche Sensoren lassen sich bei einem engeren Temperaturfenster und Sicherstellung der Spannung oft um einiges Übertakten, wobei dann die LVDS Signale schlechter werden und sich das Timing verschiebt, was man aber im FPGA mit entsprechenden Massnahmen anfangen kann, solange die einzelnen Augen jeweils gross genug sind und die Verkabelung / Verdrahtung zum Sensor das hergibt. Z.B. kann man einen high speed Sensor auf diese Weise gepulst auslesen und die Zeitdauer zwischen den Zeilenresets und der Belichtung vergrössern. Damit ergibt sich ein zeitlich engerer Zusammenhang zwischen erstem und letztem Pixel. Falls Du binning benutzt, versuche, es ausserhalb des Sensors im FPGA zu machen, soweit als möglich. Da hast du mehr Möglichkeiten der Filterung.
Hallo, ich habe vor einiger Zeit mit einem Spartan 3A DSP ebenfalls LVDS verarbeitet. 160MHz DDR, also 320MHz effektiv auf 4 Kanälen. Ich hatte aber einen CCD Sensor und dazu ein FrontEnd von Analog Devices, in dem auch die zwei ADCs integriert waren. Der Ausgang dort waren dann serialisierte LVDS Daten (16bit pro ADC). Pixeltakt waren 40MHz bei 2048x2048 effektiven Pixeln. Den Deserializer habe ich mir selber mit einem Schieberegister im FPGA gebaut, die beiden Kanäle zusammengesetzt und dann mit einem EN in ein Fifo geschrieben. Ob gerade gültige Pixel kommen oder nicht, wurde mir vom FrontEnd mit HSync und VSync Signalen gesagt. Nach den Fifos ging es dann mit niedrigerem Takt weiter und die Daten wurden parallel aus dem Fifo wieder ausgelesen. Der Fifo war quasi mein Buffer und der Übergang zwischen der Taktdomain von Schreiben und Lesen. Alles lief aber auf drei eigenen Boards, die via Samtec (QSH/QTH) verbunden waren. Die LVDS Leiterbahnen waren in der Länge ausgeglichen, liefen aber auch über einen Steckverbinder. Das Ganze war ziemlich robust und funktioniert tadellos :) Viele Grüße, Andi
Mit dem S3A DSP geht etwas mehr, das ist richtig. Mit dem S3E sind 150 MHz aber ein Kampf. Andreas B. schrieb: > Pixeltakt waren 40MHz Gleichstrom :-)
Andreas B. schrieb: > J. S. schrieb: > >>> Pixeltakt waren 40MHz > >> Gleichstrom :-) > > Nicht für einen CCD Sensor ;) Aber für den FPGA und um den geht es euch ja wohl. Die 150MHz sind Kleinkram für einen FPGA, die Schwierigkeit ist eher, die 150MHz Daten sauber über das PCB zu führen.
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.