PHYS Ethernet oder FPGA

Wie verwendet man einen Standard-PHYS-Ethernet-Controller? Die Datenblätter enthalten keine Schaltpläne und geben hauptsächlich nur die Pin-Beschreibungen an.

Ich möchte einen TDM-Datenstrom oder einen Bitstrom durch die Ethernet-Steuerung serialisieren, um von allen Übertragungsmethoden zu profitieren, anstatt diese Methoden selbst erstellen zu müssen.

Da ich die Daten so schnell wie möglich streamen möchte, möchte ich keine Pakete verwenden. Aus den Datenblättern einiger PHYS-Ethernet-Transceiver von TI verbinden sie die Eingänge des Controllers von einem MAC und verwenden den Begriff MII.

Das Beste, was ich sagen kann, ist, dass MII ein sehr minimaler Paketwrapper der Daten ist. Bedeutet dies, dass ich Bits nicht einfach an die Ethernet-Steuerung streamen kann, sondern sie zuerst paketieren muss?

Da ich die Daten Bit-Dumping mache, anstatt Pakete zu verwenden, muss ich dem Empfänger auf irgendeine Weise mitteilen, wo der Datenrahmen beginnt (er wiederholt sich), damit er weiß, wo "Bit 0" ist. Ich wollte dafür ein separates TP verwenden, aber das scheint eine ziemliche Verschwendung zu sein. Ich denke, ich benutze das 8b/10b, um das erste Paket mit einem der Steuerwörter oder ähnlichem zu signalisieren? Aber das setzt voraus, dass ich das tatsächlich auf den Ethernet-Controller programmieren kann?

Soweit ich das beurteilen kann, wäre dies in FPGA ziemlich einfach (ich habe jedoch nicht viel Erfahrung damit)? Wäre es besser, ein FPGA zu verwenden, um den Bitstrom in 8b/10b zu codieren und Steuerwörter zu verwenden, um den Start des Stroms zu signalisieren und trotzdem in der Lage zu sein, eine Hochgeschwindigkeits-Datenübertragung zu erhalten? (Verwenden Sie offensichtlich immer noch differenzielle Signalisierung und Magnetik wie Ethernet / RJ-45)

Ein FPGA wäre ideal als Frontend für meine Anwendung geeignet und ich könnte mir vorstellen, dass man auf einem FPGA problemlos einen Ethernet-Controller implementieren könnte. Ich möchte jedoch keinen vollständigen Controller implementieren, sondern einfach das FPGA verwenden, um Daten über TP oder sogar FO zu senden. Was sind die Nachteile bei der Verwendung eines FPGA in diesem Fall zum "Emulieren" eines Ethernet-Controllers, wobei die "Programmierprobleme" ignoriert werden (ich nehme an, man kann sie wahrscheinlich herunterladen)?

Möchten Sie die Daten an einen Standard-PC oder an ein anderes System senden, dessen Hardware Sie vollständig steuern können?

Antworten (2)

Lassen Sie uns zunächst einige Begriffe klarstellen: Eine Ethernet-Schnittstelle besteht normalerweise aus zwei Teilen: einem MAC und einem PHY. Der MAC, Media Access Controller, handhabt die gesamte Paketzusammenstellung, -übertragung, -empfang und -fehlerprüfung. Ein PHY kümmert sich um alle PHYsical-Transportaufgaben wie Modulation des Signals, Verwaltung des DC-Ausgleichs, Verfolgung von Basisbandwanderung usw.

Es gibt einige Dinge, die beide Seiten bis zu einem gewissen Grad tun. Sowohl MAC als auch PHY führen ein gewisses Maß an Datenfehlererkennung durch. Dies ist keine redundante Fehlererkennung, sondern nur eine Fehlererkennung, die direkt mit den Arten von Dingen zusammenhängt, die der MAC und der PHY tun. Außerdem sind sowohl MAC als auch PHY von der Paketnatur von Ethernet abhängig. Der MAC, weil er die Paketnatur verwendet, um die Daten zu filtern, weiterzuleiten und zu verwalten. Die PHY, weil es bestimmte Signalmodulations-/-demodulationsfunktionen gibt, die Pakete (und den Abstand zwischen Paketen) benötigen, um korrekt zu funktionieren.

Der Punkt ist: Sie kommen nicht von Paketen weg, selbst wenn Sie nur den PHY verwenden. Natürlich müssen die Paket-Header keine "Standard"-Header sein. Und der CRC muss kein Standard-CRC sein. Sie sind jedoch immer noch auf die maximale Paketlänge und den Abstand zwischen Paketen beschränkt, die Standard-Ethernet erfordert. (Hinweis: Sie können möglicherweise "Jumbo"-Pakete erstellen, wenn beide PHYs dies unterstützen.)

Die Verwendung von Standard-Ethernet-Paket-Headern bietet jedoch viele Vorteile. Wir würden dies als "Layer 2"-Protokoll bezeichnen. Der Hauptvorteil besteht darin, dass Sie Standard-Ethernet-Switches verwenden können, um verschiedene Geräte miteinander zu verbinden.

Sie erwähnen, dass Sie einfach einen "TDM-Stream" direkt (mehr oder weniger) mit dem PHY verbinden. Jedes Mal, wenn jemand das zu mir gesagt hat, hat er davon gesprochen, digitales Mehrkanal-Audio über Ethernet zu betreiben. Wenn dies der Fall ist, haben Sie eine Reihe anderer Probleme, wie z. B. die Uhrzeitsynchronisierung und Fehlererkennung, die Sie daran hindern, dies auf einfache Weise zu tun. Ich werde in dieser Antwort nicht mehr auf Audio über Ethernet eingehen, aber sagen Sie mir, ob Sie das tun möchten, da ich in diesem Fall viel mehr Informationen hinzufügen kann.

In der Vergangenheit gab es viele Produkte, die eine Art Datenstrom nahmen und ihn mit Ethernet-PHYs und FPGAs über Cat-5 liefen, jedoch ohne herkömmliche MACs. Einige von ihnen haben die richtigen Ethernet-Layer-2- oder Layer-3-Pakete verwendet, andere nicht. Einige haben auch Nicht-Ethernet-Technologien wie ATM oder FDDI verwendet. Einige von ihnen haben FPGAs verwendet, aber innerhalb des FPGAs befinden sich eine traditionellere CPU und ein MAC.

Ich hoffe, dass Sie an dieser Stelle erkannt haben, dass das, was Sie tun möchten (einen FPGA und PHY verwenden, um einen Datenstrom über Cat-5 zu übertragen), schwierig ist. Nicht unmöglich, aber schwierig. Lassen Sie mich versuchen zu erklären, wie schwierig.

Zunächst müssen Sie das FPGA-Logikdesign beherrschen. Von allen professionellen FPGA-Logikdesignern, die ich kenne, übersteigt dieses Projekt die Fähigkeiten von vielleicht 95 % von ihnen. Das sind Leute, die seit mehreren Jahren oder sogar mehreren Jahrzehnten FPGAs entwerfen. Sie werden lange brauchen, um FPGAs genug zu lernen, um diese Logik zu entwerfen. Wahrscheinlich Jahre, wenn Sie dies als Hobby tun.

Als nächstes müssen Sie genau lernen, was ein MAC und ein PHY tun und wie sie sich verbinden. Das ist nicht so schwer wie das Erlernen von FPGAs, aber auch nicht einfach. Es gibt viele grundlegende Konzepte, die wichtig, aber nicht leicht zu erlernen sind.

Jetzt müssen Sie eine Leiterplatte entwerfen, um all dies zu tun. Das Entwerfen einer zuverlässigen Leiterplatte, die FPGAs und PHYs verwendet und alle erforderlichen Ethernet-Signalintegritätsfunktionen erfüllt, ist ebenfalls nicht einfach. Auch nicht superhart. Aber auf einer Skala von 1-10, wobei 1 super einfach ist, wäre dieses PCB ungefähr eine 6. Nicht schwer für einen erfahrenen Profi, aber definitiv schwer für einen Laien-EE.

An dieser Stelle ist Ihnen wahrscheinlich aufgefallen, dass ich Ihre Fragen nicht direkt beantwortet habe. Dies war Absicht. Ich könnte deine Fragen beantworten, aber ehrlich gesagt würde dir das nicht helfen. Es wäre, als würde man Ihnen sagen, wie man die zweite Etage eines Hauses baut, wenn Sie nicht herausgefunden haben, wie man die erste Etage oder sogar das Fundament baut.

Beginnen Sie, indem Sie alles über das Entwerfen von FPGAs lernen, was Sie können. Lernen Sie auch alles über Ethernet, was Sie können. Es gibt viele Online-Ressourcen von App-Notizen, Datenblättern und Anleitungen. Gehen Sie zu opencores.org und studieren Sie ihre Ethernet-MAC-Kerne. Tun Sie dies fleißig und in einem Jahr sind Sie vielleicht bereit. Und wenn Sie bereit sind, werden Sie wahrscheinlich die Antworten auf 75 % Ihrer Fragen kennen – und Sie werden in der Lage sein, die anderen 25 % in den richtigen Zusammenhang zu stellen, sodass es für Sie tatsächlich nützlich sein wird, wenn Ihnen jemand eine Antwort gibt.

Sie können Ethernet MAC+PHY natürlich verwenden, um jede Art von Daten zu übertragen, die Sie wollen, wohlgemerkt, ohne sich um TCP/IP- oder UDP-Stacks kümmern zu müssen. Die Lösung, die vorhandene IP und Chips am meisten nutzt und dennoch sehr effizient ist, besteht darin, Ihre Daten in Ethernet-Frames zu verpacken. Haben Sie keine Angst davor, der Header ist sehr einfach und relativ wenig Overhead, besonders wenn Sie Jumbo-Frames verwenden, und das MAC-Modul kümmert sich um die Schnittstelle zum PHY (MII/GMII/RGMII) und Dinge wie die CRC-Berechnung.

Sie streamen grundsätzlich Daten zum MAC und respektieren alle Warteanforderungen, die Sie möglicherweise von ihm erhalten.

Auf der Empfangsseite (die identisch ist) streamt der MAC in Form von Ethernet-Frames an Ihre App, wiederum sehr einfach zu decodieren. Normalerweise hat der MAC die Möglichkeit, Frames mit falschem CRC zu verwerfen.

Verwenden Sie Gigabit-Ethernet für relativ hohe Geschwindigkeiten.

Einfach gesagt:

app(fpga) <-> MAC(fpga) <-> PHY(ext. chip) <-> Magnetics (ext. pkg) <-> connector

Sie müssen die MAC-IP nicht schreiben, so viele haben es schon einmal getan, jeder große FPGA-Anbieter hat ein Angebot und opencores.org hat ein kostenloses (dreifache Geschwindigkeit, als stabil gekennzeichnet).

Sie können mit einem Entwicklungskit beginnen, bevor Sie mit Ihrer eigenen Leiterplatte beginnen. Es hilft Ihnen, Ihr Design mit minimalen Kosten zu validieren.

Sie könnten sogar damit beginnen, die Idee nur mit Ihrem Computer zu validieren, indem Sie rohe Ethernet-Frames senden (googlen Sie es, sogar Python bietet eine API dafür), und später hilft Ihnen dies zu überprüfen, was Sie vom FPGA übertragen.