www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Daten per Ethernet übertragen


Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi @ all

Ich möchte Daten mit Hilfe von Ethernet zwischen einem FPGA und einem PC 
übertragen.

Ich habe schon mal 2 PC's über das Netzwerk verbunden. Mit Hilfe von 
Labview habe ich eine Programm erstellt, dass Daten zwischen den beiden 
PCs austauschen kann. Nun möchte ich aber nicht die Daten zwischen 2 
PC's austauschen, sondern zwischen einem FPGA und einem PC. Hierzu will 
ich ein neues FPGA Board entwerfen. Jedoch weiß ich nicht welchen 
Ethernet-Chip ich benötige. Es gibt ja Ethernettransreceiver und 
Ethernetcontroller.

1 .Welchen Chip davon benötige ich?

Ich habe schon bei Ti und Intel geschaut. Diese haben einige Chips im 
Angebot. Ich habe diese aber nicht ganz vestanden. Man kann dort Daten 
am Datenbus anlegen und dann einen Puls geben. Die Parallelen Daten 
werden dann in serielle umgewandelt und über das Kabel an den PC 
gesendet. Doch woher weiß dieser Transreceiver woher die Daten kommen 
(IP) und wohin die Daten gehen sollen (IP). Am anderen Ende der Leitung 
ist der PC. Der horcht die ganze Zeit auf einem Port ob die Daten 
ankommen. Jedoch weiß er halt nicht das die Daten für ihn sind.

Hat vielleicht jemand Links zu diesem Thema oder Diplomarbeiten?

Grüße Michael

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du IP Pakete verschicken willst, brauchst du Komponenten, die dir 
Schicht 1, 2 und 3 des OSI Schichtenmodells realiseren.

Du brauchst mindestens für Schichte 1 (physical layer) einen externen 
Chip, den sogenannten PHY. Der könnte mit dem FPGA, oder einem 
Mikrocontroller über ein MMI Interface  kommunizieren, und 
sendet/empängt daten vom netzwerkkabel.

Für Schicht 2, also das senden von Ethernet Paketn, mit fluss- und 
fehlerkontrolle, kann man einen externen Chip nehmen, nennt sich dann 
MAC. Gibts auch kombiniert mit einem PHY. Die Realtek und Microchip 
Netzwerkchips, die hier öfters in AVR Projekten verwendet werden sich 
solche.
Alternativ kann man den MAC Teil aber auch als Hardware im FPGA 
implementieren.

Naja, und dann musst du wohl noch IP und evtl TCP implementieren. Das 
geht nicht sonderlich gut in Hardware. Am besten wäre hier ein 
Microcontroller Core, der ins FPGA integriert wird, und als software ne 
tcp/ip bibliothek. Der Mikrocontroller muss dann die IP Pakete erstellen 
und den Datenstrom an den MAC Teil, der irgendwie dran angeschlossen 
ist, weiterschicken.

Jedenfalls ist das auf diese Art und Weise ne ziemlich komplizierte 
Sache.

Einfach wäre es, wenn du sowas wie den XPort Chip nimmst. Den kann man 
wohl so ähnlich wie eine serielle Schnittstelle anpsrechen, also vom 
FPGA aus die Daten seriell reinschreiben und der macht dann TCP/IP 
Pakete draus und schickt sie los. Wies genau geht weiß ich auch nicht, 
habe nicht damit gearbeitet. Die Datenrate ist hier aber im Gegensatz zu 
einer richtigen Netzwerklösung sehr begrenzt, aber vielleicht reichts ja 
für dich.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe bei TI folgenden CHIP gefunden : "TLK1521"

http://focus.ti.com/paramsearch/docs/parametricsea...

Dieser ist ein Transceiver. Er wandelt die Parallelen Daten in serielle 
um und sendet diese. Jedoch steht dort nicht wie viel Speicher er intern 
besitzt.
1. Ist dies ein PHY?

Wenn ich einen PHY benutze, kann man damit ja Daten senden. Woher weiß 
denn der Empfänger das diese Daten für Ihn bestimmt wird. Ich sende da 
ja kein Protokoll mit.

2. Würde die ein PHY ausreichen um zwischen FPGA und PC Daten 
auszutauschen"
3. Muss ich dafür TCP oder UDM benutzen?
4. Hat der PHY keine Fehlerkontrolle (bekomme ich es mit wenn die Daten 
nicht richtig angekommen sind oder muss ich den CRC check selber 
machen?)

Eigentlich brauche ich schon 1000MBit. Dies wäre toll, da ich eine 
Alternative zu USB 2.0 suche

Autor: guelcki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meinst du nicht, dass du dich erstmal ein bißchen mit der Theorie von 
Ethernet (z.B. OSI Schichten) beschäftigen solltest? Ich bezweifle, dass 
du mit deinem Wissensstand das Projekt bewältigst. Vor allem wenn ich 
lese, dass du Gbit Ethernet realisieren willst. Das erfordert schon 
einiges an Know How, auch im Harwdware Bereich.

Autor: Ronny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als Einstieg:

Über das Kabel geht seriell ein sogenanntes Ethernetframe (1.Suchbegriff 
Wikipedia: Ethernet bzw Ethernetframe).Darin stehen im wesentlichen nur 
die MAC-Adresse (2.Fachbegriff zum einlesen!) von Sender und Empfänger 
sowie eine Kennung des Typs.Der Rest besteht aus den in das 
Ethernetpaket gekapselten Daten.Diese können vom Typ her z.B ARP (Adress 
Resolution Protocol,Punkt 3) oder IP sein.In letzterem steht dann schon 
die IP-Adresse von Sender und Empfänger sowie wieder einige 
Informationen zu den gekapselten Daten.Diese können dann wiederum TCP 
oder UDP Pakete darstellen.

Du siehst,es sind eine ganze Reihe von Protokollen bzw Protokollheader 
zu interpretieren/zu parsen.Bei Ethereal kannst du ja mal in einige 
Pakete reinschnubern,ohne das Wissen was Abkürzungen wie 
TCP,IP,UDP,IMCP,ARP usw. bedeuten wird dir das aber nicht viel bringen.

Wenn man das Prinzip erstmal verstanden hat (Paket in Paket in 
Paket...),ist die Implementation dann eine 
Fleissaufgabe.Verbindungsorientierte Verbindungen (TCP) sind allerdings 
richtig unschön zu debuggen (u.a. Timeouts,...).Zum Glück gibts da schon 
fertige Protokollstapel,die man einsetzen kann,sobald man die Grundlagen 
verstanden hat.Ich denke mal,du hast jetzt einige Begriffe zum 
googlen.Um tiefer in die Materie einzutauchen ist ein altmodisches Buch 
allerdings dennoch empfehlenswert.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das habe ich schon mal gelesen. Ich dachte immer ich brauche nur einen 
PHY den es von TI gibt. Der sendet dann die Daten an dem PC. Jedoch habe 
ich gemerkt das der PHY kein Protokoll erzeugt sondern nur die Daten von 
Parallel in seriell wandelt. Also brauche ich noch einen MAC zwischen 
FPGA und PHY. Der MAC erzeugt dann ein Protokoll.

1.Reicht denn das MAC Protokoll aus, um mit dem PC sicher zu 
kommunizieren?

2.Gibt es denn keine weiteren ICs, die das TCP/IP-Protokoll mit 
integrieren?

Das ganze kann doch nicht so schwer sein, denn jedes neue Mainboard hat 
doch einen Gigabit-Anschluss auf dem Board.

Wie lösen die denn das Problem?



Autor: Cheffe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie ist das eigentlich auf dem Xilinx-Eval Board gelöst? Kann das nicht 
sowas?

Autor: Feadi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht hiermit anfangen: http://www.fpga4fun.com/10BASE-T.html ?

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
10 MBit sind viel zu langsam. Wie machen die es denn auf den Mainboards. 
Dort kann doch nicht nur die CPU das TCP/IP Protokoll erzeugen. Dann 
würde die CPU-Last doch viel zu hoch sein.

Was würde denn passieren wenn ich einfach mit einem PHY Daten an den PC 
übertragen würde, und nur die Leitung abhören würde. (Ohne Protokoll)

Geht das überhaupt, oder würden zu viele Fehler entstehen?

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Michael

> 10 MBit sind viel zu langsam. Wie machen die es denn auf den Mainboards.

Für wen zu langsam? Für dich?

> Dort kann doch nicht nur die CPU das TCP/IP Protokoll erzeugen. Dann

Warum nicht. So ein P4, Athlon und Co haben Power ohne Ende. Das einzige 
was der Ethernetcontroler macht ist die Prüfsumme ausrechenen. Alle 
anderen Daten (Adresse, Typ, etc.) schreibt die CPU. Und wenn er ein 
Paket empfangenhat das gleiche. Er prüft die CRC uns sagt der CPU per 
interrupt Bescheid, dass ein neues Paket angekommen ist.

> würde die CPU-Last doch viel zu hoch sein.

[ ] Du hast ein Vorstellung von der Rechenpower einer CPU.

> Was würde denn passieren wenn ich einfach mit einem PHY Daten an den PC
> übertragen würde, und nur die Leitung abhören würde. (Ohne Protokoll)

> Geht das überhaupt, oder würden zu viele Fehler entstehen?

Ohne Protokoll geht gar nix. Selbst reines RS232 hat ein "Protokoll", 
wenn gleich nur auf Byte-Ebene. Bei Ethernet brauchst du mindestens das 
Protokoll bis auf OSI-2, sprich Ethernet-Paket-Ebene.

MfG
Falk

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wirf mal einen Blick auf Wiznet (http://www.iinchip.com/)
Die haben einen 10/100 Mb Ethernet-Controller mit integriertem 
TCP/IP-Stack.
Dies ist ev. das was Du suchst.

MfG.
Andreas

Autor: Schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es kommt drauf an, WAS du über Ethernet übertragen willst.
Ethernet legt lediglich den Frame fest:

Präamble, SFD, Destination, Source, DATA, FCS.

Das muss bei allen Netzwerkkomponenten gleich sein, sonst funzt es 
nicht.

Dass in dem Datenfeld TCP/IP gesprochen wird, das ist eine Sache, die 
zwischen zwei Teilnehmern ausgehandlt werden muss.

Darum ist der TCP/IP-Stack in deinem PC auch ein Stück Software. DU 
kannst es locker deinstallieren.

Ergo: Du könntest dir auch ein ganz eigenes Protokoll ausdenken, was 
dann eben beide Teilnehmer sprechen müssen.

Ergo: Du musst lediglich nen PHY kaufen. Den Rest kannst du in nem FPGA 
realisieren (auch die FCS Berechnung etc) Das ist aber alles n icht so 
ganz trivial, da du Aufgrund der unterschiedlichen Takte von PHY und 
FPGA dir ein wenig Gedanken machen musst, wie du die Daten ohne 
Setup-Verletzungen in das FPGA bekommst.

Ich hab sowas mal für 100 Mbit gemacht (eigener MAC und eigenes 
Protokoll)

Am PC musst du dann natürlich direkt auf die Netzwerkkarte zugreifen und 
NICHT über den TCP-IP-Stack

Autor: Pete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael:

Was willst Du denn mit 1000Mbit/s übertragen ? Das könnte mit einer CPU 
sehr schwierig werden zu verschicken.

1000Mbit/s sind ungefähr 100MByte/s. Schafft das überhaupt Deine 
Festplatte ?

Ansonsten kann ich auch nur zum Lesen eines Buches raten. Es ist ratsam, 
sich erst einmal mit den Begriffsdefinitionen vertraut zu machen.

Google auch mal nach OSI-Schichtenmodell. Das zu Verstehen ist ein 
wichtiger Schritt in die Welt der Netzwerke.

Autor: Schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du musst natürlich davon ausgehen, dass du nicht einen Frame nach dem 
andern rausschreibst.

Ethernet ist für Netzwerke gedacht (wie der Name schon sagt). Da 
schwatzen ja noch andere Teilnehmer. Das heisst, nicht alle Teilnehmer 
senden ununterbrochen Frames. Trotzem muss die hohe Bandbreite her, dass 
bei vielen Teilnehmern das Netz nicht irgendwann "zu" ist.

Der Prozessor schreibt seinen Frame komplett in den MAC (das kann er 
auch ganz gemütlich machen) Und wenn der Frame fertig geschrieben ist, 
dann versucht der MAC diesen zu versenden (Mit z.B 1 GB/s). So wird die 
Leitung schnell wieder frei für andere.

Wie du siehst, dein Controller kann beliebig langsam sein und es 
funktioniert trotzdem noch.

Das Empfangen geht genauso:
MAC-Controller erkennt anhand der MAC Adresse, oder Frame für ihn ist. 
Empfängt mit 1 GB/s und schreibt das alles in einen Speicher. Dort kann 
der Prozessor das dann ganz gemütlich abholen

Klaro, der Speicher ist beschränkt und wenn du einen Frame nach dem 
anderen immer an den gleichen Teilnehmer schickst, dein Prozessor 
langsam ist, dann wird irgendwann der Empfangsbuffer des MAC voll sein 
und Frames gehen verloren.
Das passiert ständig auf dem Ethernet udn darum gibt es z.B. im 
TCP-IP-Stack mechanismen, die das erkennen und den Frame dann erneut 
senden. Das ist aber Protokollsache und hat mit Ethernet NIX zu tun. Du 
kannst theoretisch auch TCP/IP über deine serielle Schnittstelle 
sprechen

Autor: Ronny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> "Du kannst theoretisch auch TCP/IP über deine serielle Schnittstelle
> sprechen"

@Schlumpf:
Weisst du ob es eine Software gibt,mit der man sowas zum debuggen nutzen 
kann?Also irgendein Tool/Treiber das/der ein TCP/IP-Paket (oder 
vielleicht ein komplettes Ethernetframe) am PC auf einer seriellen 
Schnittstelle ausgibt.Vielleicht als virtuelle Netzwerkkarte oder so...

Autor: Schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Ronny:

Glaub nicht, dass es sowas gibt, bzw. was man damit anfangen sollte.

Du müsstest ja ein ganzes Paket an Daten rausschiscken, da deine RS232 
immer nur 8 Bit sendet. Also Startbit, 8 Datenbits, Parity usw...

Das heisst, du bekommst keinen durchgängingen "Datenstrom" wie bei einem 
Ethernetframe hin. Was aber nicht heisst, dass du nicht TCP-IP sprechen 
kannst.
Du müsstest dein Protokoll halt in viele kleine RS232-Paketchen 
zerhacken udn übertragen.


Autor: Schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab noch was auf Wikipedia gefunden:

http://de.wikipedia.org/wiki/MAC-Adresse

Da sieht man es recht gut:
Ethernet ist ein Transportmedium! Im Typenfeld steht, was für eine 
"Sprache" gesprochen wird (z.B. TCP). Im datenfeld steht dann die 
eigentliche Information, die z.B. bei TCP nochmals mit jeder Menge 
Overhead versehen ist, die die Verbindungen aufbauen, die Daten sichern 
und die IP-Adressen (source und Destination) beinhalten.

http://de.wikipedia.org/wiki/Transmission_Control_Protocol (das ist das, 
was im Datenfeld eines Ethernetframes steht, wenn TCP gesprochen wird)

Man sieht schon, dass die MAC Adresse nichts mit der TCP-Adresse zu tun 
hat und beide in einem Frame vorkommen.

Ergo: du kannst dir nen eigenen Typ überlegen und dann in´s Datenfeld 
reinschreiben was du willst, du musst lediglich sicherstellen, dass der 
Empfänger anhand des Typenfeldes erkennt, wie er die Daten zu 
interpretieren hat.




Autor: Roger Steiner (edge)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Schlumpf & Ronny

http://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol
http://en.wikipedia.org/wiki/Point-to-Point_Protocol

Ist bei Windows, Linux und auch anderen Betriebssytemen mit dabei.

Cheers, Roger

Autor: Schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Roger: Danke, man lernt nie aus ;-)

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich brauche halt 1000Mbit, da ich so schnell sein will wie USB2.0 High 
Speed (480MBit) oder Firewire. Zudem will ich nicht die 100MByt/s auf 
die Festplatte schreiben. Dafür gibt es ja Arbeitsspeicher.

Mein Task ist die Datenaufnahme, Datenübertragung und Visualisierung der 
Daten. Bei der Visualisierung benutze ich einen großen Ringspeicher, da 
1 Datensatz ein Bild ergibt. Kommt ein neues Bild, dann wird das alte 
Bild überschrieben. Daher brauche ich auch eine schnelle 
Übertragungsmethode. USB 2.0 Highspeed ist auch nicht so toll, da man 
dort die richtungen Treiber kaufen muss. (erst mal die richtigen finden, 
denn Treiber ist bei USB nicht Treiber, denn einige schaffen nur 
10MByte/s)

Da auch andere Programme auf Ethernet zugreifen, dachte ich 1000MBit 
sollte es schon sein, zudem muss ich meine Daten auch schnell genug 
übertragen können.

Jetzt frag bitte nicht wie viele Daten es genau sind. Zudem habe ich das 
Schichtmodell schon durchgelesen.

Wo findet man denn ein TCO/IC Protokoll im Datail beschriebn, damit ich 
es auf dem FPGA nachbilden kann? Bei Wiki ist nur eine allgemeine 
Beschreibung, aber für das Timing benötigt man schon mehr Angaben

Autor: sepp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du mit TCO/IC TCP/IP meinst, dann findest du alle Informationen in 
dem Dokument rfc793 (http://tools.ietf.org/html/rfc793). Der Link ist 
auch bei Wikipedia angegeben! Es gibt schon einige Links zu dem Thema im 
Forum, ich würde dir empfehlen diese durchzulesen.

Ist das ganze ein Hobbyprojekt? Was für einen Fpga verwendest du?
Der Ti Chip den du oben genannt hast, ist nicht für Ethernet gedacht!

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist kein Hobbyprojekt. Diese sind aber unter Gigabit Etherner 
aufgeführt. Es ist ein PHY. Jedoch besitzt dieser Chip keinen MAC.

Kennt jemand Gigabit MACs + PHY?

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich verwende einen Spartan 3 mit 400k Systemgates. Mal angenommen ich 
schaffe es mit 30 MHz 16 Bit and den MAC zu senden, dann schaffe ich 
480MBit. Wenn die Schaltung mit 120 MHZ läuft dann habe ich 4 Takte um 
das Protokoll zu realosieren. Das ist nicht besonders viel. :-(

Ich schätze mal, das man 8 Takte benötigt, um die Daten aus dem 
Block-Ram zu laden, und das Protokoll mit einzubinden.

AH

Ich werde einfach während ich die Daten digitalisiere in die ersten 
Speicherzellen schon den Header schreiben. Ist dann ein Bild im 
Block-Ram, kann ich mit der Ausgabe beginnen und volle Socke die Daten 
aus dem RAM übertragen :-) So sollte es dann noch schneller gehen.

Nun brauche ich nur noch einen MAC und einen PHY für Gigabit

Autor: Feadi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du einen MAC und einen PHY habe möchtest solltest Du vielleicht 
gleich eine Netzwerkkarte benutzen.

Aber: Warum nicht hiermit anfangen: 
http://www.fpga4fun.com/10BASE-T.html ?
Dabei lernst Du auch alles was Du für 1000 Mbit brauchst, und dann von 
10 zu (100 zu) 1000, ist einfacher als gleich mit 1000 zu beginnen. 
Dabei ändert sich schliesslich nur die Geschwindigkeit.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe da was bei Intel gefunden. Hört sich sehr interessant an

http://download.intel.com/design/network/datashts/...

Ich werde mir mal das Datenblatt genau durchlesen. Ist allerdings mit 
PCI.

Autor: Klaus Falser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da ich mich selber gerade in meinem Job mit einer ähnlichen Problematik 
beschäftige und mir deshalb das Referenz-Design von Xilinx genauer 
angeschaut habe, glaube ich, daß Du mit einem Spartan keine Chance hast 
das mit TCP/IP zu realisieren.
Das Protokoll ist zu kompliziert, ich habe jedenfalls keine 
Implementierung gefunden welche es komplett in HW realisiert.
Du mußt nämlich beim Verbindungsaufbau Pakete empfangen und analysieren. 
Weiters brauchst Du eine Art ARP für die Bestimmung der Ethernet 
Addresse Deiner Empfangsseite.

Das Referenz Design verwendet den PowerPC des Virtex und muß dort 
tricksen, weil man bei einer Framelänge von ca. 1500 Bytes theoretisch 
alle 12 us einen  Interrupt zum Behandeln des Frames.

Das einzige das vielleicht ginge ist UDP, bei dem die Pakete vom FPGA 
einfach nur gesendet werden, ohne Antwort und nichts. Bleibt immer noch 
die MAC Adresse deiner Empfangsseite, die Du fest ins FPGA verdrahten 
müßtest.

Grüße
Klaus

Autor: Schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde, wenn es nur eine Peer-to-Peer verbindung ist, und du eh nur 
Bilder überträgst, auf ein eigenes Protokoll gehen.

Wenn deine zusammengehörende Datenmenge (1 Bild) nicht größer als 1500 
Byte ist, dann kannst du die Bilddaten einfach direkt in das Datenfeld 
eines Frames packen und verschicken. Du brauchst dann gar kein Protokoll 
und nutzt die Bandbreite ideal aus.

Bei größeren Datenmengen könntest du dir einen eigenen kleinen Header 
erfinden. Also wenn du weisst, dass ein Datensatz immer in 4 Frames 
passt, dann könntest du ein Byte spendieren um anzuzeigen, um welchen 
Teil des Datensatzes es sich handelt. Dann brauchst das am PC nur noch 
zusammenbauen.

Bei Übertragungsfehlern stimmt die FCS nicht und du musst dann eben 
diesen Datensatz verwerfen.

Ich denke, dass sowas komplett ohne TCP/IP zu machen ist.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber wie kommt man dann von PC-Seite an die Daten?

Mein Bild ist 4000 Byte groß.

Bis jetzt habe ich immer ein Trennzeichen zum Schluss gesendet. z.B. 
"0xFF" Die digitalisierten Daten konnten diesen Zustand nie erreichen, 
somit war das Trennzeichen eindeutig.

Jedoch gibt es 1 Problem. Der PC sendet auch noch DATEN (z.B. 
automatische Update-Sucher) Diese muss ich ja von den Daten auseinander, 
die meine PC Programm an den FPGA sendet. Daher denke ich ist es nicht 
Klug auf das TCP/IP Protokoll zu versichten.

Außerdem kann ich momentan mit Labview sehr einfach auf das TCP/IP 
Protokoll zugreifen und Daten lesen und senden. Wenn ich jetzt noch ein 
eigenes Protokoll entwerfe, dann muss ich auch noch die PC-Software 
aufwendig schreiben. Und dies würde ich alleine im Zeitrahmen nicht 
schaffen.

Autor: guelcki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei deinen Fragen erkennt man wenig Entwicklung von Frage zu Frage!

Das Design eines Motherboards ist SEHR aufwendig! Die Taktraten die da 
auf den Leitungen gefahren werden, sind schon weit im HF Bereich und 
dann auch häufig noch parallel. Einfach zu sagen: Die können das doch 
auch irgendwie, dass muss ich auch können, ist SEHR SEHR mutig! Das 
Team, das so etwas realisiert, ist deutlich größer als eine Person und 
hat DEUTLICH mehr Erfahrung.

Zum Thema eigenes Protokoll über die Ethernet Schnittstelle:

Wie wäre es denn, wenn du einfach im PC eine zweite Netzwerkkarte nutzt? 
Dann musst du dir keine Gedanken über andere Anwendungen, die darauf 
zugreifen machen.

Aber ich behaupte nach wie vor, du müsstest deutlich mehr Zeit in die 
Einarbeitung in das Thema investieren. Keine Antwort, die dir hier 
gegeben wird, wird dir dabei groß helfen können. Und da du das ja nicht 
als Hobby machst, sollte das ja auch möglich sein. Ansonsten hast du ein 
Problem!

Autor: Nobody (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hätte da noch ne Idee:

Nimm doch ein fertiges Board mit Embedded Controller, die gibts 
mittlerweile auch mit GBit-Ethernet und teilweise sogar mit FPGA drauf 
bzw. mit FPGA-Scnittstelle, schau mal z.B. bei MEN oder Microsys oder 
so.

Die Daten schickst Du über einen 32 bit Bus an den Controller, das 
könnte relativ sportlich werden bei 480 MBits, sollte aber machbar sein.

Dann musst Du Dich erstmal um das Interface zum Controller kümmern, auf 
dem Controller läuft dann ein Linux oder so und Du brauchst jemanden der 
Dir einen Treiber schreibt und eine kleine Applikation, die die Daten 
hin und herschaufelt (oder nur hin?).

Vorteile: Simples Debugging, die ganze TCP/IP Geschichte kann ohne FPGA 
in Betrieb genommen werden,
Im FPGA ist nur die Interface-Logik zum Controller nötig.

Wäre das was?

Autor: Schlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fragt sich, ob es einfacher ist, TCP/IP in Hardware zu giessen, oder 
einen kleinen Treiber für den PC zu schreiben der die Daten von der 
Netzwerkkarte abholt udn wieder zusammenflickt.

Ich versteh allerdings nicht, wie du mit LABVIEW diese Datenraten 
bewältigen kannst...

Na ja, ich hab mal 100MBit Ethernet in ein FPGA implementiert also MAC 
funktionalität und das war kein großes Ding.

Aber wenn du nicht auf TCP/IP verzichten willst und das ganze in ein 
FPGA giessen musst, dann kannst über die ganzen Treiberschickten im PC 
drauf zugreigfen.
Ich denke, dass du dir aber darüber im klaren bist, dass du auf der 
einen Seite Gas geben willst, die Daten mit Höchstgeschwindigkeit 
rausschieben musst um sie dann am anderen Ende über einen völlig lahmen 
Windows Treiber durchzunudeln...

Du kannst natürlich auch für das Senden vom PC zum PFGA ein eigenes 
einfaches Protokoll verwenden.

Na ja, vielleicht findest ja noch ne Lösung. Ich werd mich an dieser 
Stelle ausklinken. Hab alles gesagt, was ich dazu beitragen konnte. Du 
bist der Überzeugung, dass TCP/IP das Richtige für dich ist, dann mach 
an diesem Ansatz weiter.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Schlumpf

Auf jedenfall vielen Dank für Deine Meinungen.


@guelcki
Ich weiß nicht wo das Problem beim eigenem Board sein soll. Heute gibt 
es Layout Programme die extra Bussysteme Routen. Die sind dann exakt 
gleich lang.

Eine zweite Netzwerkarte kommt nicht in Frage, da es ein sehr kleines 
System werden soll.

Hat denn schon mal einer mit dem weiter oben verlinkten Intel 
gearbeitet?

Autor: guelcki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay, wenn du meinst, dass man einfach nur ein passendes Tool braucht, 
ohne irgendwelche großen Erfahrungen, um ein PC Motherboard zu designen, 
dann wünsche ich dir noch frohes gelingen bei deinem Projekt!

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich will ja kein ganzes Mainboard erzeugen, sondern nur der FPGA mit dem 
MAC verbinden.

Autor: guelcki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mich da auch nur auf deine Ausssage bezogen:

>Das ganze kann doch nicht so schwer sein, denn jedes neue Mainboard
>hat doch einen Gigabit-Anschluss auf dem Board.

Und ich sage dir nochmal, du musst dich weiter in die Theorie von 
Ethernet einlesen, wenn du wirklich TCP/IP über Gbit Ethernet nutzen 
willst. Du wirst keinen Chip finden, den du einfach anschließen und eine 
IP einstellen musst und es läuft wie du es dir vorstellst.

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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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