"Tricking" Ethernet-Kabel, es ist getrennt

Ich habe nach einer Lösung gesucht, um ein Ethernet-Kabel von einem Port zu "trennen", ohne es physisch zu trennen.

Ich mache das, weil ich den Stromverbrauch in einem Projekt reduzieren möchte, an dem ich arbeite und das ein FPGA mit einem Ethernet-Port enthält. Das physische Trennen des Ethernet-Kabels ist die einzige Möglichkeit, den Ethernet-Port am FPGA auszuschalten, der ziemlich viel Strom verbraucht.

Ich habe niemanden gefunden, der etwas Ähnliches tut, wenn ich nach einer Antwort suche. Ich könnte eine Lösung haben und habe mich nur gefragt, ob es praktikabel ist oder ob jemand eine bessere hat.

Geben Sie hier die Bildbeschreibung ein

Was ist der Nachteil, wenn man das Ethernet-Kabel einfach durch einen Transistor führt? Wenn die Schalteraktivität niedrig ist, sollten die Parasiten des MOSFET kein Problem sein, oder irre ich mich hier?

Ich würde dafür lieber Relais verwenden, die Diode in den Fets und das Entfernen der galvanischen Trennung klingt nicht nach einer guten Idee
Sollte Ethernet nicht isoliert werden? Ihr MOSFET unterbricht diese Isolierung. Ich weiß auch nicht, wie sich das auf die Impedanzen auswirkt.
Darüber hinaus gibt es diese Dinge, die als "Lag Switches" bezeichnet werden und von einigen Spielern verwendet werden (aber allgemein als Betrug angesehen werden). Vielleicht könnte man das hier auch verwenden.
Wenn Sie bereits ein FPGA verwenden, können Sie den Ethernet-Controller sicherlich einfach zurücksetzen.
Das Ethernet kann nicht in den Leerlauf versetzt oder zurückgesetzt werden, da es von einem ASIC gesteuert wird, der nicht unter meiner Kontrolle steht. Der Schalter muss beispielsweise in einem bestimmten Zustand in einem Zustandsdiagramm eingeschaltet werden können.
Dies ist also kein FPGA mit einem Ethernet-Port. Es ist ein ASIC, der viele Dinge enthält, zum Beispiel ein FPGA und einen Ethernet-Controller. Dieser Teil der Frage ist etwas verwirrend.
Warum stellst du nicht einfach einen Managed Switch dazwischen? Die meisten Typen können Ports einzeln abschalten.
@pipe Ja ich weiß, deswegen war es egal um welches Gerät es sich handelt und der Fokus sollte auf dem Ethernetkabel liegen.
@Turbo Der Grund, warum ich das tue, ist, den Stromverbrauch zu reduzieren, und ich möchte keine großen Geräte hinzufügen

Antworten (1)

Frame-Herausforderung, Sie gehen von einer falschen Prämisse aus:

Das physische Trennen des Ethernet-Kabels ist die einzige Möglichkeit, den Ethernet-Port am FPGA auszuschalten, der ziemlich viel Strom verbraucht.

ist nicht wahr. Wenn Sie wissen, dass Sie das Kabel trennen können, können Sie auch:

  • zwingen Sie den Kern zum Zurücksetzen
  • Hören Sie auf, den Kern mit Clock-Gating zu takten
  • Unzählige andere Dinge, je nachdem, wie Sie den Ethernet-Kern implementiert / kopiert haben

Das Herumspielen mit der physikalischen Schicht der Signale sollte Ihr letzter Ausweg sein. Gezwungen zu sein, diesen Weg zu gehen, schreit, dass Sie Ihre früheren Designentscheidungen durcheinander gebracht haben und besser dran sind, diese zu lösen.

Wie von Peufeu erwähnt: Wenn Ihr PHY ein separater Controller ist, setzen Sie diesen einfach zurück. Ich bin davon ausgegangen, dass dies nicht der Fall ist, aber aus Ihrem Diagramm geht nicht ganz klar hervor, dass dies nicht unbedingt der Fall ist.

Erwägen Sie auch, den PHY auszuschalten, wenn es sich um eine separate Komponente handelt
Ja, natürlich habe ich als erstes versucht, die Ethernet-Buchse vom FPGA zu deaktivieren. Ich stand jedoch in Kontakt mit der Firma, die das FPGA (Orange Tree Tech) herstellt, und weiß, dass es derzeit keine Möglichkeit gibt, das Ethernet-PHY zu steuern, da es von einem benutzerdefinierten ASIC gesteuert wird. Das verwendete FPGA ist: orangetreetech.com/products/gigabit-ethernet-boards/zestet2-nj
@ user2876482 Sie bezeichnen das gesamte Board als "FPGA", obwohl das FPGA tatsächlich nur das Artix-7 ist. Der Hersteller scheint dies als "FPGA -Modul " zu bezeichnen. Ich empfehle dringend , dass Sie Ihre ursprüngliche Frage bearbeiten, um das von Ihnen verwendete Board zu identifizieren, und sogar das Blockdiagramm oben in Ihrem Beitrag einfügen. Die Tatsache, dass ihr ASIC den PHY steuert, scheint der problematische Teil zu sein.
Ja, ich weiß, dass der ASIC das Problem war, weshalb ich nicht näher auf das FPGA eingegangen bin, weshalb ich nach einer Lösung außerhalb des FPGA gesucht habe.
@ user2876482 Da Sie bereits mit dem Hersteller in Kontakt stehen, könnten Sie fragen, ob die Benutzer-CPU des ASIC die Kontrolle über das Haupt-CPU/IPv4-Offloading hat. Vielleicht könntest du von dort aus gehen. Ansonsten solltest du wohl besser auf einen vernünftigeren Hersteller umsteigen.