Hallo zusammen,
ich bin auf der Suche nach einer schlanken Lösung, um Bilddaten vom 20MP
Sony Sensor über 10GEthernet zu übertragen.
Das Sensor Interface ist MIPI und soweit klar.
Bauchschmerzen macht mir die hohe Datenrate und das 10G Interface.
6Gb/s sind mit USB und Konsorten nicht mehr zu machen, also habe ich mir
10G auserwählt und recherchiere nun.
Gibt es vielleicht ein kompaktes FPGA Eval Board mit 10G PHY, so dass
ich hier nur noch das MIPI Interface "dranbauen" muss?
Was denkt ihr ist bei einer Eigenentwicklung ein realistischer Foodprint
des Boards?
Stromversorgung, FPGA (sollte ja nicht der kleinste sein), DDR3-4
Speicher, 10G PHY, Steckverbinder usw brauchen schon Platz, so dass ich
mal sehr optimistisch von 80x80mm, eher 100x100 ausgehen muss?
Mit Xilinx habe ich schon einmal einen 4MP Sensor betrieben, hier aber
noch CCD mit externen ADCs und das Interface war Parallel zu einem
externen uC, der dann die 1 GigE gemacht hat. Nun möchte ich einen
Schritt weiter gehen und das ganze komplett im FPGA abhandeln und eben
einen zeitgemäßen Sensor verwenden.
Wenn ich nun Bilddaten übertragen möchte, geht das nativ über 10G, oder
muss ich mich dann noch mit der korrekten Implementierung von 10 GigE
Vision beschäftigen?
Vielen Dank!
Arthur
Moin,
Arthur schrieb:> Stromversorgung, FPGA (sollte ja nicht der kleinste sein),
OK.
> DDR3-4 Speicher,
Wozu zwischenspeichern? Willst du auch noch ne Verarbeitung machen, oder
nur die Pixel moeglichst hurtig paketieren und durchschaufeln?
> 10G PHY,
Je nachdem welche Geschmacksrichtung von 10G Ethernet du haben willst,
geht's vielleicht auch mit den im FPGA eingebauten Transceivern (und
z.B. SFP+).
Arthur schrieb:> Wenn ich nun Bilddaten übertragen möchte, geht das nativ über 10G, oder> muss ich mich dann noch mit der korrekten Implementierung von 10 GigE> Vision beschäftigen?
Naja, was du halt haben willst: Wenn du GigE Vision haben willst, wirst
du's einbauen muessen. Willst du SMPTE 2022-6, musst du das einbauen.
Willst du was anderes, dann halt was anderes...Oder eben jemandem Geld
zahlen, der weiss, wie das geht und was du brauchst.
Gruss
WK
Arthur schrieb:> ich bin auf der Suche nach einer schlanken Lösung, um Bilddaten vom 20MP> Sony Sensor über 10GEthernet zu übertragen.>> Das Sensor Interface ist MIPI und soweit klar.>> Bauchschmerzen macht mir die hohe Datenrate und das 10G Interface.> 6Gb/s sind mit USB und Konsorten nicht mehr zu machen, also habe ich mir> 10G auserwählt und recherchiere nun.
Wie lang ist die Übertragungsstrecke? Was ist am anderen Ende der
Leitung dran?
Wie viele CSI-2 Lanes hast Du?
Weswegen ich frage:
Du solltest bei Deinem Problem eher über ein PCIe-Interface nachdenken.
PCIe ist nicht nur auf Mainboards beschränkt, sondern kann auch extern
nach außen geführt werden - mit bis zu 16 Lanes, wenn Du das mal
brauchen solltest. Eigentlich sollten 4 PCIe-Lanes ausreichen.
Vorteil von PCIe: minimale Latenz. Es gibt keine direktere Anbindung an
den Prozessor. Deswegen sind alle schnellen SSDs PCIe NVMe SSDs. PCIe in
FPGAs ist kein Problem, da gibts fertige Cores dafür, und die
Transceiver sind direkt im FPGA drin. Heißt also auch: Der
Hardware-Aufwand ist minimal.
IPass oder MiniSAS-Stecker dran, ESD-Schutz nicht vergessen, und das
wars.
Beim RAM sollte das BlockRAM im FPGA reichen. Die Daten gehen dann ja eh
direkt per PCIe ins PC-RAM.
Für PCs gibts fertige Karten mit PCI-e Bridges drin, die auch Hotplug
können.
Und wenn Du wissen willst, wie andere Leute das machen:
https://www.ximea.com/en/products/application-specific-oem-and-custom/pci-express-high-speed-cameras-xib/cb200cu-cm
20 MPixel, CMOSIS CMV20000 Sensor, PCIe x4 Interface, wahlweise als
reine sw-Kamera oder mit Bayer-Filter.
fchk
Dergute W. schrieb:> Je nachdem welche Geschmacksrichtung von 10G Ethernet du haben willst,> geht's vielleicht auch mit den im FPGA eingebauten Transceivern (und> z.B. SFP+).
Es gibt eigentlich für alle 10G Varianten SFP+ Module, auch für
10GBASE-T. Das von fs.com habe ich schon verwendet. Fertige FPGA-Boards
direkt mit 10GBASE-T gibt es wahrscheinlich gar nicht.
Arthur schrieb:> Bauchschmerzen macht mir die hohe Datenrate und das 10G Interface.> 6Gb/s sind mit USB und Konsorten nicht mehr zu machen,
Nur so aus Interesse: Warum geht USB nicht? USB 3.1 macht 10GBit/s und
USB 3.2 20GBit/s. Laut
https://www.elektronik-kompendium.de/sites/com/1310061.htm kommen da
dann real 800MB/s (=6.4Gb/s) bzw. 1600MB/s (=12.8Gb/s) raus.
Hallo zusammen und danke für das ausführliche Feedback!
>Wozu zwischenspeichern? Willst du auch noch ne Verarbeitung machen, oder>nur die Pixel moeglichst hurtig paketieren und durchschaufeln?
Für den Beginn ist eigentlich nur durchschaufeln angesagt, aber wenn ich
ein Board baue, möchte ich mir später ein paar Freiheiten offen halten.
Ich denke auch darüber nach, zwei Sensoren anzusprechen, also zwei MIPI
Interface zu haben. Dann bräuchte ich sicher den DDR zum Speichern.
>Naja, was du halt haben willst: Wenn du GigE Vision haben willst, wirst>du's einbauen muessen. Willst du SMPTE 2022-6, musst du das einbauen.>Willst du was anderes, dann halt was anderes...Oder eben jemandem Geld>zahlen, der weiss, wie das geht und was du brauchst.
Mit GigE habe ich bisher schon etwas gemacht. Da weiß ich, dass es ein
Standard ist und man relativ problemlos die Daten übertragen bekommt
incl. Paramtrierung der Kamera, ihrer Parameter, Framerate, Auflösung
usw. Da habe ich das gen-i-cam XML und los gehts. Da kann ich dann auch
easy ein anderes Sensor Modul verwenden. Wenn ich über 10G etwas anderes
baue, muss ich mich um alles selber kümmern.
Was die 10G Standards angeht, bin ich aber noch nicht sonderlich
sattelfest. Es könnte also sein, dass es noch Alternativen gibt, die
noch nicht auf dem Schirm habe.
>Wie lang ist die Übertragungsstrecke? Was ist am anderen Ende der>Leitung dran?
Die Strecke ist ca. 4-5m lang, also von der Kamera zum PC.
>Wie viele CSI-2 Lanes hast Du?
Im best case würde ich gerne zwei Sensoren ansteuern bzw. mir zumindest
diese Möglichkeit seitens der Hardware offen halten.
Damit hätte ich 2x4 MIPI Lanes.
>Nur so aus Interesse: Warum geht USB nicht? USB 3.1 macht 10GBit/s und>USB 3.2 20GBit/s. Laut
Mit USB habe ich in der Vergangen schlechte Erfahrungen gemacht. Das war
irgendwie nie stabil. Mit USB3.0 ist es wohl jetzt besser geworden, wenn
man die Cypress Chips verwendet.
Wie es mit 3.1 oder gar 3.2 aussieht, weiß ich noch nicht.
Gefühlt ist 10G ausgereifter und man findet mehr Infos dazu im Netz.
Daher aus dem Bauch heraus die Entscheidung zu 10G.
Ich kann aber auch gerne noch einmal Richtung USB3.1/2 recherchieren.
Vielleicht liege ich da komplett falsch?
Ich habe ja bei 20.1 MP so um die 6Mb/s... das muss das Interface
hergeben zzgl. Wasserkopf.
>PS: Ich hätte gerne einen Link zu Deinem Kameramodul. Interessiert mich.
Das habe ich noch nicht in der Hand. Mir wurde bisher nur gesagt, dass
dieser Sensor IMX214 unter anderen mit im Rennen ist. Es könnte also
auch noch ein anderer werden.
Meine Arbeit in meinem Praktikum wird sich nicht mit dem Sensormodul
beschäftigen, sondern mit dem Konzept der Hardware zwischen MIPI und PC.
Vielen Dank!
Arthur
Wenn Du es einfach haben willst und 10G Ethernet verwendetn willst, dann
schau Dir die NVidia Jetson Prozessormodule an. Die haben genügend MIPI
CSI-2 Lanes für entweder 6 2-Lane-Kameras oder 3 4-Lane Kameras) plus
Hardware für Debayering usw plus eine orgendtliche GPU drin. 10 Ethernet
ist so erstmal nicht dabei, das müsstest Du per PCIe x4 anklemmen.
Zum GigE-Standard: Hast Du den zugriffsbereit? Das ist ein
kostenpflichtiger Standard, für den man Mitglied im Genicam-Konsortiom
sein muss. Ohne Standarddokumente wirst Du kein standardkonformes GigE
hinbekommen. Vergiss es einfach.
Ansonsten steht mein Vorschlag, direkt mit PCIe in den PC reinzugehen,
immer noch. 5m sind kein Problem, da gibts Lösungen für.
Und: Du kannst direkt in den PC-Hauptspeicher reinschreiben, externes
Puffer-RAM ist unnötig.
fchk
>Ansonsten steht mein Vorschlag, direkt mit PCIe in den PC reinzugehen,>immer noch. 5m sind kein Problem, da gibts Lösungen für.
Ich habe versucht zu finden, wie man direkt mit PCIe in den Rechner
reinkommt bzw. welche Schnittstelle man dazu braucht.
Gefunden habe ich als Ansatz Thunderbolt, oder habe ich etwas übersehen?
Die ganzen anderen PCIe Anbindungen im Rechner sind ja nicht nach außen
geführt (NVME, PCIe Stecker usw.).
Ich möchte ungern eine Bastellösung, sondern eine üblich verfügabare
Schnittstelle. So eine LAN Buchse für GigE Vision hat jeder Laptop und
es ist bei geringerer Datenrate bei kleineren Sensoren abwärtskompatibel
zu 1GigE.
Wenn sich der GigE Standard als tauglich erweist, ist das Gen-I-Cam
hoffentlich kein Showstopper und ich habe auch gesehen, dass es fertige
GigE IPs gibt. Alles eine Kostenfrage... aber das muss dann der
Arbeitgeber entscheiden.
Bei diesen ganzen Bitcoin Minern wird das PCIe über normales USB Kabel
nach aussen geführt. Da gibt es auch direkt Platinen die rein passiv
PCIe auf einen USB Stecker legen.
Du brauchst ja auch nur das PCIe, also die paar Signale. Thunderbolt
macht da viel mehr, das ist unnötig, USB macht auch mehr und unnötig.
So was meine ich:
https://img.dxcdn.com/productimages/sku_452346_1.jpg
Die kleine Karte kommt in den PC und extern hast du dann den 16x Slot.
Wenn du den nicht brauchst kannst du natürlich auch eine USB Buchse auf
deine Platine löten und dort das PCIe abgreifen.
-gb- schrieb:> So was meine ich:> https://img.dxcdn.com/productimages/sku_452346_1.jpg>> Die kleine Karte kommt in den PC und extern hast du dann den 16x Slot.> Wenn du den nicht brauchst kannst du natürlich auch eine USB Buchse auf> deine Platine löten und dort das PCIe abgreifen.
Falsch. Damit hast Du nur PCIe x1, und es wird USB3 Kabelage
missbraucht. Dieses Zeugs wird für Renderfarmen benutzt, ist aber in
keiner Weise ein offizieller Standard oder zur Nachahmung empfohlen. Die
richtigen, industrietauglichen Lösungen hab ich ein Posting vorher
aufgezeigt.
fchk
> Ja. Nennt sich PCI Express External Cabling.
Vielen Dank für den Input. Diese Kabel habe ich tatsächlich noch nicht
gefunden gehabt.
Somit bekommt man zumindest den PCIe eines Desktop-Rechners nach außen
gelegt. Laptops sehen da schon weider schwerer aus, aber da kann ich ja
nochmal nach einer Lösung suchen und ist auch nur ein Nice-to-have.
Mal schauen, wie man geschickt z.B. die Daten für das I2C/CCI durch PCIe
tunneln kann, das wäre bei GigE Vision ja schon fertig.
Aber großartige Infos!
Danke!
> Wenn sich der GigE Standard als tauglich erweist, ist das Gen-I-Cam> hoffentlich kein Showstopper und ich habe auch gesehen, dass es fertige> GigE IPs gibt. Alles eine Kostenfrage... aber das muss dann der> Arbeitgeber entscheiden.
GenIcam ist, wie böse Zungen manchmal sagen, per se ein Showstopper.
Auch mit Zugang zu allen Specs.
Ich würde dazu raten, sofern es nicht die zigste IBV-Kamera werden soll,
die Bilder per RTP-Standard zu übertragen und allenfalls zu
komprimieren. Kommt oft vor, daß an einem 1G-Laptop-Ethernet alles nicht
so tut wie gedacht und die Bandbreite mies ausfällt.
Allerdings ist auch da ein vernünftiger 1G-IPcore inkl. Rtpstack nötig,
da gibt es aber genügend kommerzielle Lösungen.
>Ich würde dazu raten, sofern es nicht die zigste IBV-Kamera werden soll,>die Bilder per RTP-Standard zu übertragen und allenfalls zu>komprimieren.
Das Problem an einem, wie auch immer gearteten RTP protokoll ist, dass
man alles selber bauen muss incl. dem I2C Transfer zur Kamera hin. Da
wollte ich naiver Weise auf bereits existierende Lösungen zurückgreifen,
wo man z.B. mit dem GigE Control Protokoll in der Kamera selber
definierte Register beschreiben kann. Die Register mappe ich dann
einfach auf I2C und kann damit den Sensor beschreiben.
So habe ich es schon mal gemacht... andere/eigene Protokolle kenne ich
noch nicht.
Hast Du da zufällig einen guten Einstiegspunkt zur Recherche, wie ein
solches RTP Protokoll via 10GE aussehen kann?
Vielen Dank!
>Zum GigE-Standard: Hast Du den zugriffsbereit? Das ist ein>kostenpflichtiger Standard, für den man Mitglied im Genicam-Konsortiom>sein muss. Ohne Standarddokumente wirst Du kein standardkonformes GigE>hinbekommen. Vergiss es einfach.>Auch mit Zugang zu allen Specs.
Die Specs sind übrigens kostenlos verfügbar nach Anfrage.
Man muss nur Gebühren zahlen, wenn man Mitglied der AIA sein möchte, ein
Produkt vermarkten möchte, was GigE zertifiziert ist und sein Produkt
bei denen gelistet haben möchte.
Zur Entwicklung "for internal use only" bekommt man die Specs auch so,
wenn man also nur vom Standard an sich und dessen Funktionalität
profitieren möchte und z.B. Standardsoftware verwenden will bzw. mittels
Matlab/LabVIEW, die ja GigE unterstützten, an die Daten kommen möchte.
Arthur schrieb:> Das Problem an einem, wie auch immer gearteten RTP protokoll ist, dass> man alles selber bauen muss incl. dem I2C Transfer zur Kamera hin. Da> wollte ich naiver Weise auf bereits existierende Lösungen zurückgreifen,> wo man z.B. mit dem GigE Control Protokoll in der Kamera selber> definierte Register beschreiben kann. Die Register mappe ich dann> einfach auf I2C und kann damit den Sensor beschreiben.> So habe ich es schon mal gemacht... andere/eigene Protokolle kenne ich> noch nicht.>
Der gemeinsame Nenner von GigE (sprich dem Pleora-Standard) und dem
Realtime Protocol (RTP) ist sowieso schon mal UDP, daran kommst du nicht
vorbei.
D.h. so oder so brauchst du da einen aufwendigeren Core, entweder eine
harte State-Machine wie es Pleora macht, oder eine gut programmierbare
Software-Lösung mit schlauer DMA-Engine, um die Bandbreite zu schaffen.
Du hast schon mal zwei Datenkanäle: Eine für Konfiguration (GenICam oder
was anderes) und den Video-Stream. Den Wrapper von GenICam nach i2c
musst du dir bauen, oder von wem holen. Zum genannten IMX214 habe ich da
bereits was fertig, das ist auch im Rahmen einer Dienstleistung im
Source kriegen.
> Hast Du da zufällig einen guten Einstiegspunkt zur Recherche, wie ein> solches RTP Protokoll via 10GE aussehen kann?
Da gibt es unzählige RFCs zu, z.B. https://tools.ietf.org/html/rfc4175,
Das dann nach 10G hochzuskalieren ist eine Frage des effizienten
Datenschaufelns.
GigE ist einfach das Gleiche in 'grün' und wurde auf Biegen und Brechen
von der AIA zum Standard definiert, warum man da das Rad nochmal
erfunden hat, hat politische Gründe :-)
Die Frage ist halt, an welcher Ecke du drehen musst/willst. Die
RFC-konformen Formate werden zum grossen Teil von der hocheffizienten
gstreamer-Bibliothek verstanden, für GigE brauchst du die entsprechenden
Libraries oder Viewer von deinem Kamerahersteller.
Für mich als RFC-gewohnten Veteranen ist GigE/GenIcam ein bedingt guter
Standard, wenn deine Front-End-Software es aber nun mal so unterstützt,
ist das bei der Auswahl zweitrangig, solange es funktioniert.
Wenn du allerdings mit LabVIEW bei 10G auffährst: Stirnrunzeln. Mit LV
würdest du die Bandbreite nie ausnutzen. Da kann man gleich
Kompression bei 1G fahren.
Ich hatte mal High-Speed Kameras mit USB-3. Die machten aber mehr
Probleme, weil die Verbindung doch sehr empfindlich ist. Insbesondere
über längere Zeit die hohen Datenraten zu halten, klappt nicht immer.
Irgendwas hat sich dann doch weg gehängt.
Ein Sony-Chip mit FPGA und SFP+ liegt gerade auf meinem Tisch. Da gibt
es Kamerahersteller in Ostdeutschland, die bauen das für einen. Selber
möchte ich das nicht machen.
Apropos PCIe: Finde ich eigentlich auch einen sehr eleganten 'hack'. Ein
Kollege hat mal high speed Video über SATA-Stecker getunnelt.
Aber das Problem dabei ist immer, dass man sich das Front-End eben mit
bauen muss, und keine goldene Referenz hat. Das könnte dann doch mehr
Arbeit kosten als eine standardisierte Ethernet-Lösung - und man hat am
Schluss eben doch eine Insellösung, die man zu einem Tool kompatibel
machen muss ("wrappen").
Mein Arbytegeber verwendet Ximea-Kameras in seinen Produkten. Die gibt
es entweder mit USB3 oder mit PCIe. Nach unserer Erfahrung funktionieren
die PCIe-Kameras deutlich besser, weil die CPU-Last und die Latenz
einfach deutlich geringer sind und PCIe Gen2 x2 ist einfach schneller
als USB 3.0.
Die großen Kameras mit 20 oder 50 MPixel werden nur noch mit PCIe Gen2
x4 angeboten. Wenn Du davon 6 Stück an einem PC hast, weißt Du erst, was
Bandbreite heißt und warum NUMA bei einem Multiprozessorsystem wichtig
ist. Jede andere Schnittstelle würde bei solch einer Konfiguration in
die Knie gehen, sei es wegen Bandbreite oder wegen CPU-Last. Daher auch
meine Empfehlung. Die kommt nämlich aus der Praxis.
Die Sensoren dieser Kameras haben übrigens normales Kleinbild-Format, im
Gegensatz zu den Winz-Sensoren bei IMX214 und Konsorten.
fchk
PS: Vergiss Debayering und Weißabgleich nicht. Das willst Du bei diesen
Bandbreiten nicht auf der CPU rechnen. Wirklich nicht. Also pack
passende Hardware ins FPGA oder eine ordentliche GPU ins System.
Hi,
Du brauchst:
GigE-Vision Standard <- RJ45/SFP+ <- 10G Phy <- Xilinx Zynq FPGA
Richtig?
GigE-Vision im FPGA ist nicht besonders kompliziert, da eh UDP-Stack.
Ich durfte keine (kauf) IP-Cores verwenden, deshalb habe ich alles in
VHDL implementiert.
Für vom FPGA (Zynq) zum SFP+/Phy ist ein kostenloses IP-Core notwendig.
Dabei ist nur zu beachten, dass Zynq 7er Serie den richtigen Speedgrade
hat, sonst ist maximal 6 Gbs möglich. Sobald du die serielle Verbindung
am Laufen hast, musst Du "nur" Eth-Frames zusammensetzen. Es ist nicht
trivial, aber auch nicht besonders kompliziert (aber aufwendig).
Aus Ethernet-Frames baust Du UDP-Pakete. Und da ist auch GigE-Vision
nicht mehr weit ;-)
Wenn Du 20kEuro übrig hast, dann kannst Du "Xilinx 10G/25G Ethernet
Subsystem" (?) kaufen, daran schließt Du über AXI den DMA-controller an.
Dann ist der Zusammenbau der GigE-Vision Pakete nur "Software".
Grüße
Kest
Allenfalls sollte man einen Teil der Verarbeitung, inkl Komprimierung am
Frontend machen. Weil die ganzen Daten am PC nichts bringen. Ganz
einfach nichts. Beim ersten mal Seek & Retry geraet's ins Stocken.
Wer kann denn schon 20 Megapixel unkomprimiert in Echtzeit schauen.
Womit denn ? Mein Screen hat fast 12M Pixel. Ich schau mir da
Drohnenvideos an. Die kommen aber nur mit 20 Frames, oder so. Weil die
Speicherkarte auch nicht schneller ist. Man kann's aber nur anschauen
wenn sich hinreichend wenig aendert.
Und die komprimieren schon, die SD Karte ist mit 100MByte/s
spezifiziert. Das waere dann 1GBit.
Also vergiss die 20Megapixel unkomprimiert in Echtzeit. Das ist dummes
Zeug. Nimm eine realistische Datenrate, die du auch wegspeichern kannst.
zB was eine Disk bringt. Da ist dann bei 200MByte/s langsam Schluss.
Zitronen F. schrieb:> Allenfalls sollte man einen Teil der Verarbeitung, inkl Komprimierung am> Frontend machen. Weil die ganzen Daten am PC nichts bringen. Ganz> einfach nichts. Beim ersten mal Seek & Retry geraet's ins Stocken.
Es gibt mittlerweile auch SSDs. Die können Daten viel schneller
speichern. So 2GB/s machen auch die besseren Consumer-SSDs.
> Wer kann denn schon 20 Megapixel unkomprimiert in Echtzeit schauen.
Er hat nichts von der Anwendung geschrieben. Bei GigEVision fällt mir
u.a. auch industrielle Bildverarbeitung ein.
> Womit denn ?
z.B. mit einem DELL UP3218K, der hat 33MP.
> Mein Screen hat fast 12M Pixel. Ich schau mir da> Drohnenvideos an. Die kommen aber nur mit 20 Frames, oder so. Weil die> Speicherkarte auch nicht schneller ist. Man kann's aber nur anschauen> wenn sich hinreichend wenig aendert.> Und die komprimieren schon, die SD Karte ist mit 100MByte/s> spezifiziert. Das waere dann 1GBit.
Diese SD-Karte ist das beste, was die Technik heutzutage schafft?
Bei den professionellen Videokameras (z.B. Aria DSMC2) geht das auch bis
300MB/s. Aber wahrscheinlich nicht auf eine SD-Karte.
