El cable de ethernet "engañando" está desconectado

He estado buscando una solución para "desconectar" un cable ethernet de un puerto sin desconectarlo físicamente.

Estoy haciendo esto porque quiero reducir el consumo de energía en un proyecto en el que estoy trabajando que incluye un FPGA con un puerto ethernet. Desconectar físicamente el cable de ethernet es la única forma de apagar el puerto de ethernet en el FPGA, lo que consume una gran cantidad de energía.

No he encontrado a nadie haciendo algo similar al buscar una respuesta. Podría tener una solución y me preguntaba si es viable o si alguien tiene una mejor.

ingrese la descripción de la imagen aquí

¿Cuál es el inconveniente de simplemente dejar que el cable ethernet pase por un transistor? Si la actividad del interruptor es baja, los parásitos del MOSFET no deberían ser un problema, ¿o me equivoco aquí?

Preferiría usar relés para eso, el diodo en los fetos y quitar el aislamiento galvánico no suena como una buena idea.
¿No debería estar aislado ethernet? Su MOSFET rompe este aislamiento. Tampoco sé qué impacto tendrá en las impedancias.
Además, existen estas cosas llamadas "interruptores de retardo" que algunos jugadores usan (pero generalmente se consideran trampas). Tal vez esto podría usarse aquí también.
Si ya está utilizando un FPGA, seguramente puede reiniciar el controlador Ethernet.
El ethernet no se puede poner en reposo o restablecer ya que está controlado por un ASIC que no está bajo mi control. El interruptor debe poder encenderse cuando se encuentra, por ejemplo, en un determinado estado en un diagrama de estado.
Así que esto no es un FPGA con un puerto ethernet. Es un ASIC que contiene muchas cosas, por ejemplo, un FPGA y un controlador Ethernet. Esta parte de la pregunta es un poco confusa.
¿Por qué no pones un interruptor administrado en el medio? La mayoría de los tipos pueden apagar los puertos individualmente.
@pipe Sí, lo sé, por eso no era importante qué dispositivo era y el foco debería estar en el cable de ethernet.
@Turbo La razón por la que hago esto es para reducir el consumo de energía y no quiero agregar dispositivos grandes

Respuestas (1)

Desafío de marco, estás partiendo de una premisa equivocada:

Desconectar físicamente el cable de ethernet es la única forma de apagar el puerto de ethernet en el FPGA, lo que consume una gran cantidad de energía.

no es verdad. Si sabe que estaría bien desconectar el cable, también puede:

  • forzar el reinicio del núcleo
  • dejar de cronometrar el núcleo usando la activación del reloj
  • Innumerables otras cosas, dependiendo de cómo implementó/copió el núcleo de ethernet

Jugar con la capa física de las señales debería ser su último recurso. Verse obligado a tomar esta ruta grita que arruinó sus decisiones de diseño anteriores y que es mejor volver para resolverlas.

Como mencionó Peufeu: si su PHY es un controlador separado, simplemente reinícielo. Supuse que no lo era, pero no está completamente claro en su diagrama que necesariamente no lo sea.

también considere apagar el PHY si es un componente separado
Sí, por supuesto, lo primero que intenté fue deshabilitar el conector ethernet del FPGA. Sin embargo, he estado en contacto con la empresa que fabrica el FPGA (Orange Tree Tech) y sé que actualmente no existe una forma de controlar el PHY de ethernet ya que está controlado por un ASIC personalizado. El FPGA utilizado es: orangetreetech.com/products/gigabit-ethernet-boards/zestet2-nj
@ user2876482 Te refieres a toda la placa como un "FPGA" cuando, de hecho, el FPGA es solo el Artix-7. El fabricante parece referirse a esto como un " módulo FPGA ". Le sugiero encarecidamente que edite su pregunta original para identificar el tablero que está utilizando, e incluso pegue su diagrama de bloques en la parte superior de su publicación. El hecho de que su ASIC controle el PHY parece ser la parte problemática.
Sí, sé que el ASIC era el problema, por eso no entré en detalles sobre el FPGA, por eso estaba buscando una solución fuera del FPGA.
@user2876482 Dado que ya está en contacto con el fabricante, puede preguntar si la CPU del usuario de ASIC tiene control sobre la descarga principal de CPU/IPv4. Tal vez podrías ir desde allí. De lo contrario, probablemente sea mejor cambiar las placas a un fabricante más sensato.