Hallo,
Es soll eine Maschine mit einem PC verbunden und Daten übertragen
werden. Die Entferneung zwischen Maschine und PC ist wohl nicht größer
als 5m. Die Netto-Datenrate muss mindestens 320MB/s (2560Mbit/s) sein
und der Datenfluss darf nicht abreißen.
Jetzt ist die Frage wie macht man so etwas am besten?
Die ersten Gedanken von meinem Kollegen waren:
1. 10Gb Lan. Hier gibt es schon fertige Lan-Karten und auch IP-Cores.
2. PCIe X4 Hier soll es auch bereits eine Steckmöglichkeit geben, an der
man an das Slotbrech ein Kabel anschließt. Entsprechende IP-Cores gibt
es auch hier. Jedoch habe ich so ein Slotblech nicht gefunden. Kann mir
da jemand einen Tip geben? Wie lang darf hier das Kabel sein?
Ich bin auch noch über Möglichkeiten gestolpert:
1. Serial RapidIO. Hier muss man allerdings dann noch eine PCIe->RapidIO
Bridge basteln oder gibt es die käuflich wo zu erwerben? Die
Geschwindigkeit kann es, aber wie lange darf hier das Kabel sein? Was
für Kabel & Stecker verwendet man hier? Man könnte ein HDMI-Kabel oder
ein Ethernetkabel verwenden... Gibt es hier ein Standard?
2. Xilinc Aurora: hier ist eigentlich die gleiche Fragestellung wie bei
Serial RapidIO.
Wie würdet ihr das Problem lösen?
Ich bedanke mich für eure Lösungsvorschläge.
Grüße
Torsten
Torsten schrieb:> Die Netto-Datenrate muss mindestens 320MB/s (2560Mbit/s) sein> und der Datenfluss darf nicht abreißen.
Was bedeutet "nicht abreißen"?
Welcher Jitter ist erlaubt?
Was passiert im Fehlerfall?
Hallo Peter II
Danke für die schnelle Antwort.
Ich habe gesehen, dass Thunderbolt extrem neu ist. Da gibt es noch nicht
viel Hardware. Aber ich habe auf die schnelle ein Karte gefunden:
ASUS ThunderboltEX PCIe-Karte
Ist das Hauptsächlich für Apple oder auch PC?
Ich habe noch etwas anderes gefunden: XAUI
Evtl. kann man auch Sata verwenden...
Hallo Lothar
Also es werden Daten vom Gerät zu PC übertragen. Wenn die Datenrate
öfter unterschritten wird, dann wird wohl ein Bufferoverflow irgendwann
passieren. Wie krittisch das ist, kann ich nicht sagen - aber
wahrscheinlich nicht zu kritisch.
Torsten schrieb:> 2. PCIe X4 Hier soll es auch bereits eine Steckmöglichkeit geben, an der> man an das Slotbrech ein Kabel anschließt. Entsprechende IP-Cores gibt> es auch hier. Jedoch habe ich so ein Slotblech nicht gefunden. Kann mir> da jemand einen Tip geben? Wie lang darf hier das Kabel sein?
nennt sich Cabled PCIe, maximal 7m.
USB 3.0 mit Cypress FX3 ist noch eine Altenative.
InfiniBand klingt auch interessant.
An USB 3.0 hätte ich auch mal denken können.
Ich glaube da habt ihr mir schon mal sehr geholfen.
Ich bedanke mich für eure hilfe und wünsche euch noch einen schönen
Abend.
Grüße
Torsten
Ich bin hier gerade am Machen mit USB-3. Bislang nur von der
Rechnerseite.
Das Protokoll ist schon so kompliziert, das möchte ich nicht im FPGA
machen wollen. Vielleicht gibt es einen USB-3 Client Core, der das kann.
Der wird aber bestimmt sehr teuer.
Ich habe nach eine USB-3 Host IP-Core geschaut, der ist noch nicht
einmal erhältlich.
Hallo Torsten
Falls du USB 3 (z.B: den Cypress FX3) verwenden möchtest, brauchst du
meiner Erfahrung nach einen genügend grossen Buffer (z.B. ein DDR-RAM)
auf der "Maschinen" Seite, um einen Stream unterbruchsfrei übertragen zu
können.
Gruss Tim
@ PittyJ
Der Chip Cypress FX3 übernimmt das ganze Protokoll.
USB 3.0 wäre - meiner meinung nach - elegant. Allerdings hatten meine
vorgänger sohl schon ihre schwirigkeite mit dem cypress fx2. Da soll
wohl irgendwie das timing extrem schwer einzuhalten sein im master-slave
mode... hab das aber noch nicht richtig verstanden, was die damit
gemeint haben.
Ich habe allerdings auch gerade erfahren, dass USB 3.0 keine Option ist.
Die wollen das nicht weil zu neu - und Kinderkrankheiten?
@Tim: Danke für den Hinweis. Großer Buffer ist gut.
@Matthias.
ggg Videothek ist gut ;-) Ich kann es dir gar nicht genau sagen, was
die Maschine für Daten aufnimmt. Ich soll mich nur wegen der
Schnittstelle informieren. Alles andere hat man nicht für nötig gehalten
mir zu erzählen.
So ich gehe jetzt in den Feierabend.
Euch auch ein schönen Feierabend!
Viele Grüße und danke für eure Hilfe nochmal!
Was auch eine Möglichkeit wäre:
Mehrere 1GBit-Ethernet benutzen.
Allerdings hast Du mit Ethernet das Problem, welche Protokolle Du
einsetzen kannst (TCP/IP oder UDP).
Meines Wissens gibt es im FPGA keine IP-Cores für TCP/IP, sondern der
TCP/IP-Stack läuft als Software auf einem CPU-Core.
1GBit mit UDP hab ich schon im FPGA realisiert, allerdings hat UDP seine
Einschränkungen.
Bronco schrieb:> Meines Wissens gibt es im FPGA keine IP-Cores für TCP/IP, sondern der> TCP/IP-Stack läuft als Software auf einem CPU-Core.
Das geht auch bei schnellen FPGAs nicht so ganz einfach, weil Du bei den
2,5GB wenigstens 3 lines brauchst und damit auch 3 PHYs+MACs. Im Virtex
gibt es hard MACs, aber ich weiss nicht, wieviele. Wenn du TCP/IP fahren
willst brauchst Du eine Bruttorate von 20%+ und damit dürftest du den 4.
PHY+MAc ankratzen, zumal Du für das handling schon mal einen kompletten
PowerPC im Virtex reservieren kannst. 4 parallele FGPGs wären wenigstens
nötig. Da gibt es bessere Lösungen.
Wenn es wirklich Videodaten sind, kannst Du ja eine Videoschnittstelle
einbauen. Camera Link über SERDES schafft pro Kabel 320MBp.s. Über 2
Kabel (full mode) hättest Du brutto 640MB/s.
http://de.wikipedia.org/wiki/CameraLink
Oder doch 10GBit-Lan?
Ich an deiner Stelle würde 10Gb Ethernet verwenden. Die PHYs sind mit
relativ geringem Aufwand auch in geringeren Stückzahlen erhältlich. Dann
könnte man auch auf eine optische Übertragung setzen was weniger
störempfindlich sein sollte. Aber das kommt auch auf den Einsatzort
darauf an.
Such mal nach SFP+ Modulen. Ein weiterer Vorteil ist dass es die
Gegenseite schon fertig zu kaufen gibt, anstopseln und "fertig".
Zu überlegen wäre jedoch ob der PC die Daten fortlaufend mit dieser
Datenrate (weiter)verarbeiten kann.
USB 3.0 ist doch mittlerweile nicht mehr neu, das ist etabliert und
funktioniert mit dem FX3 problemlos. Allerdings sind 320MB/s schon etwas
das, was der FX3 schafft. Aber die Ansteuerung ist wirklich simpel,
besser als beim FX2. Ich arbeite schon eine Weile mit dem.
Cabled PCIe wäre eine Option, ist allerdings im FPGA um Welten
aufwendiger als der popelige Parallelbus zum FX3. Alles andere wird noch
viel komplexer (Infiniband, 10GbE...).
Für PCIe x4 wäre eventuell der Gennun Controller noch was, da hast du
einen DAM IP Core dabei.
Allerdings ist PCIe für Streaming denkbar ungeeignet, da das auf Memory
Mapped aufbaut. Und die hohe Geschwindigkeit erreicht man nur, wenn man
dem Scatter Gather DMA den wahlfreien Zugriff auf den Speicher erlaubt.
Im FIFO Modus sinkt die Bandbreite rapide.
Ich würde USB 3.0 nehmen, der FX3 kostet etwa 30€ und macht alles fix
und fertig. Die Firmware gibts von Cypress dazu und die läuft out of the
box.
Christian R. schrieb:> Allerdings ist PCIe für Streaming denkbar ungeeignet, da das auf Memory> Mapped aufbaut. Und die hohe Geschwindigkeit erreicht man nur, wenn man> dem Scatter Gather DMA den wahlfreien Zugriff auf den Speicher erlaubt.
Sowas hatte ich vor Jahren mal für UMTS mit einem SOPC-System gebaut.
Allein an der FIFO-Steuerung und Anlopplung an den PLDA-PCIe Core sitzt
man 3 Monate, bis es läuft.
Franz schrieb:> Die PHYs sind mit>> relativ geringem Aufwand auch in geringeren Stückzahlen erhältlich.
Hast Du das bereits eingesetzt? Wie hast Du das mit der
MAC-Funktionalität gelöst?
Christian R. schrieb:> USB 3.0 ist doch mittlerweile nicht mehr neu, das ist etabliert und>> funktioniert mit dem FX3 problemlos.
Da würde mich mal die Störsicherheit interessieren. Was für eine Art von
Machine ist das? EMV?
Christian R. schrieb:> Allerdings ist PCIe für Streaming denkbar ungeeignet, da das auf Memory> Mapped aufbaut. Und die hohe Geschwindigkeit erreicht man nur, wenn man> dem Scatter Gather DMA den wahlfreien Zugriff auf den Speicher erlaubt.> Im FIFO Modus sinkt die Bandbreite rapide.
Das kann ich so nicht stehen lassen. Selbstverständlich ist PCIe
herrvorragend für Streaming geeignet, das beweisen unzählige auf dem
Markt befindliche Produkte einschliesslich USB 3.0 Controller :-). Die
Lernkurve ist nur steiler als mit einer fertigen USB 3.0 Lösung.
Beliebter Einsteigerfehler ist die Annahme dass man mit Memory Mapped IO
die PCIe mehr als ein paar MByte/s erreichen kann, dass Problem gab es
aber auch schon beim altem PCI.
D.h, zum Streamen braucht man Busmaster DMA, aber ein overdesigned
Scatter/Gather DMA Core ist nicht nötig, ein grosser fest allozierter
Ringbuffer tut es auch und ist sogar ca 10% performanter. Das dafür
nötige zusätzliche Memorycopy fällt erst bei sehr viel höheren
Geschwindigkeiten ins Gewicht.
Auch hat man bei PCIe gegenüber USB den Nachteil dass man sich die
Kerneltreiber mehr oder weniger selber schreiben muss. Bei USB kann man
auf WinUSB oder libusb aufsetzen.
Wenn man mir die Aufgabe stellen würde, würde ich PCIe wählen. Einfach
weil ich es schon kann, den FX3 müsste ich erst lernen.
J. S. schrieb:> Da würde mich mal die Störsicherheit interessieren. Was für eine Art von> Machine ist das? EMV?
USb 3.0 setzen wir zwar bisher noch nicht in industriellem Umfeld ein,
ich sehe da aber sogar weniger Schwierigkeiten als bei 2.0, da die
Übertragung über die Super Speed Lanes robuster ist als die
pseudo-differenzielle bei 2.0
2.0 HighSpeed mit dem FX2 setzen wir allerdings weltweit im
industriellen Umfeld (Bahn) ein, bisher ist da noch nicht ein Byte
weggekommen. Ordentliche Kabel und Schaltungsdesign sind da natürlich
Voraussetzung.
Es ist ein weit verbreiteter Irrtum, dass USB nicht industrietauglich
sei, selbst beim Surge Test beim CE ist das nicht abgeschmiert.
Zu PCIe: Klar, Streaming ist natürlich immer möglich, aber man erreicht
nicht die vollen Datenraten, soweit ich weiß. Wir wollten das auch mal
weiter ausbauen, aber gerade PLDA hat uns da zu Verstehen gegeben, dass
man schon den o.g. Ringpuffer aus mehreren DMA zusammen bauen muss,
deren FIFO Modus liefert wohl nur etwa 20% Bandbreite.
Die Lernkurve ist da deutlich steiler, auch die Usebility auf Host Seite
ist nicht so doll, die Kosten gerade bei der Kabellösung höher als USB
3. Alleine das x1 Kabel kostet in 3m schon soviel wie der FX3 Chip.
Hat allerdings auch seine Berechtigung.
Wow ... Hey Leute... da hat sich ja hier nochmal richtig viel getan...
Ich seh schon, ich bin da noch recht am Anfang... Einige Sachen verstehe
ich noch nicht ganz... aber da muss ich mich erst wohl noch ein bisschen
einlesen.
Ihr hab mir echt viel weiter geholfen. Vielen dank dafür!
Ist auch mal sehr Interessant, wie das erfahrene ... Profis das sehen.
Ich habe leider auf Arbeit niemanden mit dem ich mich austauschen kann.
Christian R. schrieb:> Zu PCIe: Klar, Streaming ist natürlich immer möglich, aber man erreicht> nicht die vollen Datenraten, soweit ich weiß.
Vom Device (FPGA) in den PC ist es relativ leicht die volle Datenrate zu
erreichen (d.h. die mögliche Datenrate nach Abzug des
Protocoloverheads).
(ca 200 MB/s bei Gen1 x1, bei Gen2 das doppelte). Da darf dann natürlich
kein anderer Traffic sein, wie z.B. Registerzugriffe.
Die andere Richtung ist komplexer. Man braucht ca 3 ausstehende
DMA-Readrequests um auf volle Geschwindigkeit zu kommen, die aber leider
in beliebiger Reihenfolge beantwortet werden dürfen. D.h. man braucht
zwischen Fifo und PCIe Core einen Reorderbuffer, falls der Core keinen
hat. Mit nur einem ausstehenden Request sind maximal 60 MB/s bei Gen1 x1
machbar.
Christian R. schrieb:> 3. Alleine das x1 Kabel kostet in 3m schon soviel wie der FX3 Chip.> Hat allerdings auch seine Berechtigung.
Mit etwas Unterstützung von Pericom tuts auch ein Cat6 Kabel (max 7m).
Mir fällt zu dem Thema noch Fibre Channel ein. Das existiert seit vielen
Jahren, gibts als Kupfer- und Glasfaserversion mit 1 bis 20 GBit/s. Für
PCs gibts fertige HBAs. Auf der Geräteseite sollte es auch fertige
Lösungen geben - die Hersteller von Storagesystemen entwickeln ihre
Chipsätze ja auch nicht selber.
fchk
A.S. schrieb:> Bronco schrieb:>> Meines Wissens gibt es im FPGA keine IP-Cores für TCP/IP, sondern der>> TCP/IP-Stack läuft als Software auf einem CPU-Core.>> Das geht auch bei schnellen FPGAs nicht so ganz einfach, weil Du bei den> 2,5GB wenigstens 3 lines brauchst und damit auch 3 PHYs+MACs. Im Virtex> gibt es hard MACs, aber ich weiss nicht, wieviele. Wenn du TCP/IP fahren> willst brauchst Du eine Bruttorate von 20%+ und damit dürftest du den 4.> PHY+MAc ankratzen, zumal Du für das handling schon mal einen kompletten> PowerPC im Virtex reservieren kannst. 4 parallele FGPGs wären wenigstens> nötig. Da gibt es bessere Lösungen.>> Wenn es wirklich Videodaten sind, kannst Du ja eine Videoschnittstelle> einbauen. Camera Link über SERDES schafft pro Kabel 320MBp.s. Über 2> Kabel (full mode) hättest Du brutto 640MB/s.>> http://de.wikipedia.org/wiki/CameraLink>> Oder doch 10GBit-Lan?
Wir verwenden ein zugekauftes UDP Streaming Core, das triple speed (also
10/100/1000Base-T) unterstützt. Das Core ist reines VHDL (keine MCU) und
unterstützt halt UDP und ARP komplett sowie TCP-Erkennung (dann muss ein
nachgeschaltetes Core allerdings die Verarbeitung machen). Ich habe dann
noch RTP und RTCP, sowie IGMP drangebastelt. Zusammen liegt man da (für
unsere Bedürfnisse angepasst) bei 6k LE in einem Cyclone. TCP ist aber
eigentlich für reines Streaming auch unüblich (abgesehen von Shoutcast).
Wenn ich Deine Bruttodatenrate an einen PC pusten müsste würde ich für
einen Schnellschuss 4 Cores parallel schalten, 4 PHYs dahinter knallen
und 4 crossover links an einen PC mit 4 Netzwerkkarten machen. Dann
braucht man nur noch eine App auf dem PC die die Daten wieder
reassembled. Durch die RTP Header hast Du eine Sequenznummer (es gibt
allerdings keine Notwendigkeit für Reordering bei Crossover oder LAN, da
es selten mehr als eine Route gibt). Die Daten verschickt man halt
interleaved über die 4 Cores an den PC.
Vorteil der IP Lösung ist, dass Du keine spezialisierte Hardware im PC
benötigst und prinzipiell mit jedem Rechner arbeiten kannst. Nur für das
Streaming müsste z.B. ein EP4CE30 komplett ausreichen (man braucht für
das Core halt 8kB RAM minimum pro Core).
Mit 10GBase-T kenn ich mich leider nicht aus, aber dafür braucht man
dann wohl auch einen GX Baustein mit 3,25Gbs Transceivern. Ist halt die
Frage wofür man sich entscheiden will, Stand der Technik oder Zukunft.
Meistens hinken die Kunden aber in der Technik ein paar Jahre hinterher,
1000Base-T ist zum Beispiel im Broadcastbereich (SAT, FM, etc.) für
Endgeräte immer noch eine Seltenheit.
Joost S. schrieb:> Wenn ich Deine Bruttodatenrate an einen PC pusten müsste würde ich für> einen Schnellschuss 4 Cores parallel schalten, 4 PHYs dahinter knallen> und 4 crossover links an einen PC mit 4 Netzwerkkarten machen.
Da wäre mir die USB-Geschichte aber symphatischer.
Christian R. schrieb:> 2.0 HighSpeed mit dem FX2 setzen wir allerdings weltweit im> industriellen Umfeld (Bahn) ein, bisher ist da noch nicht ein Byte> weggekommen. Ordentliche Kabel und Schaltungsdesign sind da natürlich> Voraussetzung.
Interessant. Darf ich fragen, wie lange Eure Kabel maximal sind?
Bronco schrieb:> Interessant. Darf ich fragen, wie lange Eure Kabel maximal sind?
Natürlich immer < 5m zwischen Hub/Device oder Hub/Hub. Zwischen PC und
Device ist da immer eine USB Aktiv-Verlängerung, also Hub, weil es
insgesamt mehr als 5m sind. Wenn man sich an die App-Note von Würth
hält, was EMV Schutz des USB angeht, dann ist man da quasi schon auf der
sicheren Seite.
Christian R. schrieb:> Natürlich immer < 5m zwischen Hub/Device oder Hub/Hub.
Wir gehen derzeit von USB2.0 auf 1GBit-Ethernet über, weil unsere Kunden
ein Problem mit der begrenzten Kabellänge von USB haben. Wir setzen
standardmäßig sehr hochwertige USB-Kabel ein, die dann oft durch längere
Billigkabel oder Verlängerungen zunichte gemacht werden. Und dann heißt
es, USB wäre zu störanfällig für Industrieanwendungen... :-O
Persönlich würde ich lieber in Richtung USB3.0 gehen und einen Cypress
o.ä. an den FPGA anbinden, als Ethernet in VHDL zu implementieren.
Bronco schrieb:> als Ethernet in VHDL zu implementieren.
Für einfaches framing ist das gar kein Problem. Brauchst Du nicht mal
einen MAC. Für UDP gibt es Lösungen, die direkt auf dem Phy arbeiten und
rucki zucki zu implementieren sind. Das einzige, was Aufwand ist, ist
das technische rund um die Ports im FPGA in Sachen Serializing und
Timing. Mit einem Stratix ist das gar kein Problem und auch die dickeren
Cyclone packen das locker wech. Mehr weiss das Datenblatt.
Ist halt alles eine Frage, was man will. Datensicherheit, mehrere
Teilnehmer, Redundanz, Verbindungshopping und das Aushandeln jeweils,
können im FPGA schon etwas mühsam werden.
Ein richtiges TCP/IP Protokoll mit allem pipapo nach Standard baust Du
in 2 Jahren nicht komplett auf. Da lohnt sich der Kauf eines MAC. Auf
die opencore MACs würde ich mich nicht verlassen, wenn man kein Fachmann
ist. Zu buggy! Der Altera-MAC ist recht billig und leicht zu erlernen,
allerdings dauert es ein wenig, bis man alles am Laufen hat. Der
Xilinx-MAC dauert länger.
Wenn man richtig Datendurchsatz haben will, wird es aber irgendwann
kritisch: Die Anbindung und Verwaltung des MAC und vor allem der Daten
wird wiederum recht konfus, wenn es um komplexe Aufgaben geht und dann
lohnt sich die Implementierung eines CPU-Cores. NIOS geht da aber nur,
wenn er auch einem Stratix läuft. Auf den kleinen Viechern ist das alle
zu langsam. Dann würde ich eher zu einem Xilinx mit Power-PC raten. Wäre
mal interessant zu wissen, was die neuen Altera-FPGAs mit ARM so können.
Für einfache, lineare Operationen auf der Datenbasis würde ich es, wann
immer möglich, in VHDL machen. Hat den Vorteil, dass man es bei neuen
Technologien leicht hochskalieren kann. Was in Software auf einer MCU
läuft braucht im Gegensatz dazu immer wieder eine soft CPU.
Christian R. schrieb:> Für lange Strecken nehmen wir Icron. Erspart den zusätzlichen> Entwicklungsaufwand. Und geht sogar optisch bei einer Anwendung hier> über 300 Meter.
Kannte ich noch gar nicht, danke!
Leider ist USB2 recht lahm im vergleich zur geforderten Datenrate von
320MB/s (2560Mbit/s).
LWL ist auch nur das Medium auf dem das transportiert wird - was man
darauf macht ist wieder was Anderes.
Ich würde eine fertige Technik verwenden wie Infiniband, Fibre Channel
oder 10GBit Ethernet. PCIe hat wie auch SATA vermutlich das Problem mit
der Reichweite, 5m ist halt doch eher länger wie das wofür diese
Standards entwickelt wurden.
Gustl Buheitel schrieb:> Leider ist USB2 recht lahm im vergleich zur geforderten Datenrate von> 320MB/s (2560Mbit/s).
Deshalb haben wir ja USB 3.0 mit dem Cypress FX3 vorgeschlagen. Dafür
gibts notfalls auch optische Repeater.
Habe mit die Tage einem Kollegen gesprochen: Die haben wohl jahrelang
mit Ehtercat rumgeeiert und sind immer an Bandbreitengrenzen gestossen.
Jetzt sind sie auf USB3.0 umgestiegen und schirmen die Leitung noch
aktiv ab, indem sie symmetrische Übertragung betreiben und das
bufferpotential der Treiber passend anheben. Damit werden die Augen des
USB-Signals dynamischer und die Übertragungslänge wächst auf über 20m,
wobei sie nur 15 brauchen.
Ich werde mich ganz klar USB 3.0 zuwenden. Das ist die Zukunft. Zumal
die chips billig und einfach zu betreiben sind.
>Es soll eine Maschine mit einem PC verbunden und Daten übertragen>werden. Die Entferneung zwischen Maschine und PC ist wohl nicht größer>als 5m. Die Netto-Datenrate muss mindestens 320MB/s (2560Mbit/s) sein
Vielleicht selber machen mit 10/8-Bit-Protokoll, und den Transceivern v.
FPGA.
Dann brauchst Du wieder etwas im PC, als einen FPGA mit Anbindung an
PCIe z.B. Warum selber bauen, wenn es da schon was gibt? Solange es mit
1GB geht würde ich das Ethent nehmen, weil das jeder PC schon drinne
hat.
GbE ist ja schön und gut, aber wie schon oben mehrfach ermittelt, bei
Weitem nicht schnell genug, um 320MB/s rüber zu ziehen. Eigentlich
bleibt nur 10GbE, PCIe oder USB 3.0 übrig. Jeder vernünftige
Projektleiter wird sich für USB 3.0 entscheiden, das hat nun mal
inzwischen jeder PC und ist dank integrierter Chips und fertiger Treiber
billig und schnell entwickelt, wenn man bei 0 anfangen muss.
Mal 'ne andere Frage, wie willst Du denn 320 MB pro Sekunde an Daten
verarbeiten? Auf die Platte speichern kannst Du das in dem Tempo
jedenfalls nicht, und ein Algorithmus, der auf der CPU läuft müsste auch
ziemlich flott sein, dass das noch hinhaut.
>Die haben wohl jahrelang mit Ehtercat rumgeeiert und sind immer an >Bandbreitengrenzen gestossen.
LOL. Ja, das EtherCAT... Die eierlegende Wollmilchsau unter den
Feldbussen ;-)
>das hat nun mal>inzwischen jeder PC und ist dank integrierter Chips und fertiger Treiber>billig und schnell entwickelt
Das ist in Firmen ein Grund, es nicht zu benützen...
Jürgen S. schrieb:> Matthias Lipinsky schrieb:>> Das ist in Firmen ein Grund, es nicht zu benützen...> Wieso?
Kostet ja nicht extra, kann also nix sein ;)
Ist aber tatsächlich ein Effekt, den ich bei vielen "Profis" auch zu
beobachten glaube.
Ja, besonders eifrige Projektleiter mit zu wenig Ingenieur-Hintergrund
neigen dazu, proprietäre, aufwendige Speziallösungen zu bevorzugen. Was
nicht viel kostet, kann ja nicht viel wert sein.
Naja, jedem das seine, wir setzen auf etablierte Standard-Interfaces.
Sven B. schrieb:> Kostet ja nicht extra, kann also nix sein ;)> Ist aber tatsächlich ein Effekt, den ich bei vielen "Profis" auch zu> beobachten glaube.
Das ist nicht von der Hand zu weisen, sicher, aber sowas beobachte ich
eher beim unerfahrenen Nutzer, der sich Glanz des Neuen blenden lässt.
Bisher wurde noch nicht beantwortet was das Ganze soll, resp ob 's denn
Alternativen gibt. 320MByte /s sind bescheuert. sowas macht man
allenfalls am Cern, mit dem passenden Budget. Ich wuerd mir mal
ueberlegen welche Verarbeitung mir die Datnrate signifikannt reduzieren
wuerde.
Wie willst Du die Datenrate reduzieren? und warum?
Es wird seinen Grund haben, warum die Daten breutbandig in den PC
sollen. Die werden wohl dort verarbeitet werden müssen. Meistens ist es
eine Art von Bildauswertung, die
a) so kompliziert ist, dass man sie nicht mehr auf einem embedded-System
rechnen kann
b) die soviel Platz braucht, dass man sie nicht kostengünstig in der
Subkomponente lösen kann,
c) es offline gerechnet werden kann, weil die Datenrate nur punktuell
hoch ist und die Software ansonsten brach liegt, oder andere Anlagen
abfertig
d) die Daten sternförmig verglichen werden müssen und die Subkomponenten
sich gegenseitig nicht sehen
f) die Rechnerei auf dem PC billiger ist
> sowas macht man allenfalls am Cern, mit dem passenden Budget
Da täuschst Du Dich gewaltig! Solche Banbreiten zu PC-Systemen brauchen
u.a.
* nahezu jede Radarapplikation,
* die meisten SDR-Funksysteme
* Suchköpfe in Zielfindesystemen (MIL), z.B. AVAX
* IR-Leitsysteme in Hubschraubern
* kompakte Partikelbeschleuniger für Medizingeäte
* Bildverarbeitungsysteme wie CBT, MRT oder DVT
* Lidar-Systeme
Ich weiss das zufällig so genau, weil ich an all solchen Systemen
bereits mitentwickelt habe.
Cern braucht das genau zufällig nicht, denn dort hat man passende TDCs
auf der Basis selbstentwickelter Converter-Asics und geht mehrkanalig
über PCI-lanes in die Rechner. Das ist also aus der einen Sicht eine
Nummer kleiner, aus der Systemsicht 2 Grössenordnunge grösser.
Und, ja - auch an TDCs für Cern habe ich schon mitentwickelt.
320MB/s sind überhaupt nicht bescheuert. Gerade im Mess- und Prüfbereich
mit ständig steigenden Anforderungen an Auflösung und Geschwindigkeit
bei gleichzeitiger lückenloser Dokumentation incl. Rohdatenspeicherung
ist das keine absurde Forderung.
