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
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.
Ich habe bei TI folgenden CHIP gefunden : "TLK1521"
http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=analog&familyId=553&uiTemplateId=NODE_STRY_PGE_T¶mCriteria=no
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
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.
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.
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?
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?
@ 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
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
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
@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.
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
> "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...
@ 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.
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.
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
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!
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?
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
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.
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
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.
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.
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!
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?
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.
@ 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?
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!
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.
