mikrocontroller.net

Forum: FPGA, VHDL & Co. 20MP Sony Sensor (6Gb/s) auf 10G Ethernet


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Arthur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Blechbieger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS: Ich hätte gerne einen Link zu Deinem Kameramodul. Interessiert mich.

fchk

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arthur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Arthur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: -gb- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: -gb- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arthur schrieb:
>>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?

Ja. Nennt sich PCI Express External Cabling.

Das ist so eine Karte, nur mit Redriver drauf:
http://www.ioi.com.tw/products/proddetail.aspx?CatID=106&DeviceID=3035&HostID=2046&ProdID=1060128

Es gibt auch weilche mit zwei Ports und PCIe Bridge.

So sehen die zugehörige Kupferkabel aus:
http://www.ioi.com.tw/products/proddetail.aspx?CatID=102&HostID=2046&Cable_HostID=4030&ProdID=1020099

Über Glasfaser geht das 100m weit.

Das sind die Buchsen und Einzelteile:

https://www.molex.com/molex/products/family?key=ipass&channel=PRODUCTS&chanName=family&pageTitle=Introduction

Dieses System gibts für 4, 8 und 16 Lanes und ist von der PCI-SIG 
standardisiert. Wie gesagt, es gibt keine schnellere, direktere und 
latenzärmere Schnittstelle.

fchk

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-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

Autor: -gb- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mag ja sein, aber funktioniert. Mit PCIe 4 sind das auch über 10 GBit/s. 
Noch besser wäre wenn der die Hardware direkt in einen PC steckt.

Autor: Arthur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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!

Autor: Fitzebutze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Arthur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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!

Autor: Arthur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Arthur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LabVIEW
http://www.ni.com/tutorial/5750/en/

Matlab
https://www.mathworks.com/help/imaq/acquire-images-from-gige-vision-cameras.html

Von dieser Seite betrachtet hat der Standard also hinten raus vielleicht 
doch einige Vorteile?

Autor: Fitzebutze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: PittyJ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Fitzebutze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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").

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Zitronen F. (jetztnicht)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.