Hallo,
da ich als stiller Mitleser hier in Forum schon einige hilfreiche Tipps
entdeckt habe, möchte ich mich heute erstmals mit einer Frage an Euch
wenden.
Und zwar geht es mir darum einen geeignetes FPGA-Chip oder
Entwicklungsboard für mein Projekt zu finden:
Hierbei geht es um verschiedene Sensoren welche über SPI kommunizieren
und später mit einem eigenen FPGA in ein Gehäuse eingebaut werden
sollen. Diese Module sollen später wie ein TAP ihre Daten über Ethernet
an einen PC senden. Jedoch möchte ich nicht jedes Modul direkt mit dem
PC verbinden sondern nur eine Verbindung zum PC haben und dafür die
Module aneinander reihen. Das ganze ist bewusst dezentral gehalten und
nicht alle Sensoren an einem FPGA angebunden um eine gewisse Modularität
zu erreichen. Wichtig wäre mir noch ein RTC bzw. Zeitstempel, damit ich
die Daten aus verschiedenen Quellen über eine gemeinsamem Zeit
darstellen kann. Die Hardware bis zum SPI steht bereits, nur leider bin
ich in Sachen FPGA ein absoluter Neuling. Ich würde mich daher Freuen
wenn mir jemand ein Entwicklungsboard (Später soll das Modul ein eigenes
Layout bekommen) empfehlen könnte um erste Erfahrungen zu sammeln, oder
auch wenn mein Vorhaben so nicht umsetzbar ist.
Danke und Gruß
Warum willst Du FPGAs nehmen? Welche Datenrate haben Deine Sensoren.
Zur Ankopplung an Ethernet würd ich lieber ein fertigs Board nehmen,
z.B. RaspberryPi.
Hallo Martin,
das hätte ich wohl noch dazu schreiben sollen. Es sind 18bit bei 1MHz
Abtastrate pro Modul also doch einiges an Daten. Ist dies mit einem
RaspberryPi noch machbar? Prinzipiell bin ich auch keinem µC abgeneigt
aber hatte irgendwie schon FPGA im Kopf ohne das jetzt zu begründen.
Ich sehe keinen Grund einen FPGA zu nehmen. Ich würde einen Cortex-M mit
Etherenet nehmen und für das "durchschleifen" ein Ethernet-Switch-IC mit
drauf packen...
Im Messbetrieb kann das durchaus vorkommen das alle senden. Die genaue
Modulanzahl habe ich mir noch nicht überlegt aber ich hoffe das es mit
bis zu 10 Stück funktioniert.
Dann würd ich Auschau halten nach einem FPGA-Board, das nen
Gigabit-Ethernet Interface unterstützt. Die Messmodule selbst können
vermutlich relativ kleine FPGAs besitzen.
Cortex-M schau ich mir mal an :)
@Martin, ok also kein interen sondern ein zweikanal Interface extra
dazuhängen. Die Aufgabe des FPGA ist eigentlich "nur" die umsetzung der
Daten von SPI in einen Frame plus Zeitstempel anbringen. Wie meinst Du
das mit "kleinen FPGA"? Es soll ja keine Zentrale Steuerung geben sonder
das Entwicklungsboard nur für den Anfang genutzt werden uns später alles
ins Modul integriert werden.
Ein Pi ist bei datenintensiven Anwendungen so ziemlich das dümmste, was
man nehmen kann, weil das Ethernet dort über USB läuft. Wenn, dann wäre
ein BeagleBone sinniger.
18 MBit/s sind einzeln nicht besonders viel. Dafür reicht etwas in der
Größenordnung MSP432 bzw Tiva TM4C129. Da sind MAC und PHY schon im Chip
eingebaut.
Für Timing gibts mit IEEE 1588 eine Standardlösung, die bis hinab in den
µs Bereich geht. Das erfordert spezielle Hardwareunterstützung in den
beteiligten Netzwerkteilnehmern. Die oben erwähnten MSP432 bzw TM4C129
haben diesen Hardwaresupport. Der zu verwendende PC braucht auf dem
Interface auch den passenden Hardwaresupport und passende
Treiberunterstützung.
Mit dem Hintereinanderschalten der einzelnen Geräte handelst Du Dir nur
Probleme ein. Jeder Tap verursacht eine Verzögerung, und jeder Tap
braucht plötzlich mindenstens Gigabit Ethernet, was dann wieder den Rest
der Hardware komplexer macht. Mit einem vernünftigen Switch skaliert das
alles besser - da ist einzige Flaschenhals der Link zum PC, und wenn Du
dort und nur dort eine 10GBit Karte einbaust und einen Switch mit ein
oder zwei 10GBit-Uplinkports nimmst, dann hat sich das Thema auch
erledigt, dann sind auch 100 Module kein Problem.
fchk
Moin Ernst,
wenn Du das Rad nicht neu drechseln willst, hätte ich allenfalls eine
Lösung für Dich. Müsste man allerdings die SPI-Seite (Master oder Slave?
DMA?) abklären. Gibt dazu ein Evalkit und etwas Doku:
http://section5.ch/index.php/product/netpp-node-v0-1/
Ich habe bisher nur 200kS/s ausprobiert, aber mit demselben System
kommst du im Prinzip an die volle Bandbreite des Ethernet mit UDP/RTP
(Real-Time-Protokoll). Modul macht 100 MBit, also kriegst du von zehn
davon die Daten über einen passenden GBit-Hub weg, aber nur im
einigermassen "sandboxed" UDP-Betrieb.
Von RPi, Beagleboard und Konsorten kann ich in dem Kontext auch nur
abraten. Die sind nur mit TCP/IP einigermassen zu brauchen, ansonsten
ist die USB-Tunnelei ein echter Murks.
Super das hört sich grade schon nach einer ganz guten Basis an.
Ich überarbeite grade mein Konzept noch einmal Richtung Stern aus Switch
und Modulen und was mit IEEE 1588 möglich wäre.
Neu drechseln möchte ich natürlich nicht. sondern möglichst schnell auf
eine umsetzbare Lösung kommen. Ob es ein Spartan6 FPGA sein muss, der
ist ja im Vergleich zu den anderen beiden nicht Frank vorgeschlagenen
nicht ganz günstig.
Die Datenmenge an sich ist eigentlich nicht so viel es ist nur wichtig,
dass keine Messpunkte verloren gehen und der Chip gängige Ethernet
Mechanismen wie wiederholtes senden unterstützt.
Danke und Gruß
Hier ist von ein Board mit 2xETH von Intel/Altera:
https://www.altera.com/products/boards_and_kits/dev-kits/altera/max-10-fpga-development-kit.html
Du brauchst "nur" einen MAC (gibts bei OpenCores oder sonst was zu
finden). Es ist nicht sooo trivial, besonders für einen Anfänger, Daten
über Ethernet zu schicken. Du (oder Dein MAC-Core) muss sich um
Konfiguration, Arp-Packete/Antworten kümmern. Aber UDP-Protokoll (damit
es einfach ist), ist nicht besonders kompliziert und übersichtlich.
oder Du nimmst, NIOS auf dem Board und implementierts den MAC im NIOS
(Gibts auch als IP-Core und ich glaube sogar frei?)
Kest
Ernst schrieb:> Die Datenmenge an sich ist eigentlich nicht so viel es ist nur wichtig,> dass keine Messpunkte verloren gehen und der Chip gängige Ethernet> Mechanismen wie wiederholtes senden unterstützt.
Dann würde ich tatsächlich auch einzelne kleine Ethernet Teilnehmer mit
einem soliden TCP/IP Stack einsetzen.
Beim "durchschleifen" hast du sonst auch Probleme mit der
Zuverlässigkeit.
Vka schrieb:> Dann würde ich tatsächlich auch einzelne kleine Ethernet Teilnehmer mit> einem soliden TCP/IP Stack einsetzen.
Nur so am Rande: Das hat bisher bei mir mehr Probleme geschaffen als
gelöst. Bei Echtzeitanwendungen kann man sich allzuviel Datenpuffern
nicht leisten, wenn die TCP-Verbindung hängt (und das kann sie lange).
Lieber setzt man eine separate Box ein, die keine UDP-Pakete wegwirft
oder reordert, und daraus einen TCP-Stream irgendwohin tunnelt.
Wenn die 90 kHz von RTP reichen, braucht man auch keinen 1588-fähigen
MAC-Layer.
