¿Cómo se usa un controlador PHYS Ethernet estándar? Las hojas de datos no brindan ningún esquema y, principalmente, solo brindan las descripciones de los pines.
Me gustaría serializar un flujo de datos TDM, o un flujo de bits, a través del control de Ethernet para beneficiarme de todos sus métodos de transmisión en lugar de tener que crear estos métodos yo mismo.
Como quiero transmitir los datos lo más rápido posible, no quiero usar paquetes. De las hojas de datos de algunos transceptores PHYS Ethernet de TI, conectan las entradas del controlador desde un MAC y dicen que usan el término MII.
Lo mejor que puedo decir es que MII es un contenedor de paquetes mínimo de los datos. ¿Significa esto que no puedo simplemente transmitir bits al control de Ethernet, sino que debo empaquetarlos primero?
Además, dado que estoy volcando los datos en lugar de usar paquetes, necesito decirle al receptor de alguna manera dónde comienza el marco de datos (es repetitivo) para que sepa dónde está el "bit 0". Iba a usar un TP separado para esto, pero parece un desperdicio. Creo que uso el 8b/10b para señalar el primer paquete usando una de las palabras de control o algo similar. ¿Pero esto supone que realmente puedo programar esto en el controlador Ethernet?
¿Esto sería bastante fácil de hacer en FPGA por lo que puedo decir (aunque no tengo mucha experiencia con eso)? ¿Sería mejor usar un FPGA para codificar el flujo de bits en 8b/10b y usar palabras de control para señalar el inicio del flujo y aún poder obtener una transmisión de datos de alta velocidad? (obviamente, todavía usa señalización diferencial y magnetismo como ethernet/RJ-45)
Un FPGA sería ideal como interfaz para mi aplicación e imagino que uno podría implementar fácilmente un controlador de ethernet en un FPGA. Sin embargo, no quiero implementar un controlador completo, sino simplemente usar el FPGA para enviar datos por TP o incluso FO. ¿Cuáles son los inconvenientes de usar un FPGA en este caso para "emular" un controlador de ethernet ignorando los problemas de "programación" (supongo que uno probablemente pueda descargarlos)?
Primero aclaremos algunos términos: una interfaz Ethernet generalmente se compone de dos partes: una MAC y una PHY. El MAC, Media Access Controller, maneja todo el ensamblaje de paquetes, transmisión, recepción y verificación de errores. Un PHY maneja todo el material de transporte FÍSICO, como modular la señal, administrar el equilibrio de CC, rastrear la desviación de la banda base, etc.
Hay algunas cosas que ambos lados hacen, hasta cierto punto. Tanto MAC como PHY realizan algún nivel de detección de errores de datos. No se trata de una detección de errores redundante, sino de una detección de errores relacionada directamente con los tipos de cosas que hacen MAC y PHY. Además, tanto MAC como PHY dependen de la naturaleza del paquete de Ethernet. El MAC porque está utilizando la naturaleza del paquete para filtrar, enrutar y administrar los datos. El PHY porque hay ciertas funciones de modulación/demodulación de señal que requieren paquetes (y el espacio entre paquetes) para funcionar correctamente.
El punto es: no puede escapar de los paquetes incluso si solo usa el PHY. Por supuesto, los encabezados de los paquetes no tienen que ser encabezados "estándar". Y el CRC no tiene que ser un CRC estándar. Pero aún está limitado a la longitud máxima del paquete y la brecha entre paquetes que requiere Ethernet estándar. (Nota: es posible que pueda hacer paquetes "jumbo" si ambos PHY lo admiten).
Sin embargo, hay muchas ventajas en el uso de encabezados de paquetes Ethernet estándar. Nos referiríamos a esto como un protocolo de "Capa 2". El principal beneficio es que puede usar conmutadores Ethernet estándar para ayudar a conectar diferentes dispositivos.
Usted menciona simplemente conectar un "flujo TDM" directamente (más o menos) al PHY. Cada vez que alguien me ha dicho eso, ha estado hablando de ejecutar audio digital multicanal a través de Ethernet. Si ese es el caso, entonces tiene muchos otros problemas, como la sincronización del reloj y la detección de errores que le impedirán hacerlo de la manera más fácil. No cubriré más el audio a través de Ethernet en esta respuesta, pero dígame si eso es lo que quiere hacer porque puedo agregar mucha más información en ese caso.
Históricamente ha habido muchos productos que han tomado algún tipo de flujo de datos y lo han ejecutado a través de Cat-5 utilizando Ethernet PHY y FPGA, pero sin MAC tradicionales. Algunos de ellos han utilizado los paquetes adecuados de Capa 2 o Capa 3 de Ethernet, y otros no. Algunos también han utilizado tecnología que no es Ethernet, como ATM o FDDI. Algunos de ellos han usado FPGA, pero dentro del FPGA hay una CPU y una MAC más tradicionales.
Espero que en este punto se haya dado cuenta de que lo que quiere hacer (usar un FPGA y PHY para transferir un flujo de datos a través de Cat-5) es difícil. No imposible, pero difícil. Permítanme tratar de explicar lo difícil.
Primero, deberá dominar el diseño lógico de FPGA. De todos los diseñadores lógicos de FPGA profesionales que conozco, este proyecto está más allá de la capacidad de quizás el 95% de ellos. Estas son personas que han estado diseñando FPGA durante varios años o incluso varias décadas. Le llevará mucho tiempo aprender lo suficiente sobre FPGA para diseñar esta lógica. Probablemente años si estás haciendo esto como un pasatiempo.
A continuación, debe aprender exactamente qué hacen un MAC y un PHY, y cómo interactúan. Esto no es tan difícil como aprender FPGA, pero tampoco es fácil. Hay muchos conceptos básicos que son importantes, pero que no se aprenden fácilmente.
Ahora tendrás que diseñar una PCB para hacer todo esto. Diseñar una PCB confiable que use FPGA, PHY y haga todo lo necesario para la integridad de la señal de Ethernet tampoco es fácil. Tampoco súper duro. Pero en una escala del 1 al 10, siendo 1 súper fácil, esta PCB sería aproximadamente un 6. No es difícil para un profesional experimentado, pero definitivamente difícil para un EE no profesional.
En este punto, probablemente haya notado que no respondí directamente a sus preguntas. Esto fue a propósito. Podría responder a tus preguntas, pero sinceramente eso no te ayudaría. Sería como decirle cómo construir el segundo piso de una casa cuando no sabe cómo construir el primer piso o incluso los cimientos.
Comience aprendiendo todo lo que pueda sobre el diseño de FPGA. También aprenda todo lo que pueda sobre Ethernet. Hay muchos recursos en línea de notas de aplicaciones, hojas de datos y procedimientos. Vaya a opencores.org y estudie sus núcleos Ethernet MAC. Haz esto diligentemente y en un año podrías estar listo. Y cuando esté listo, probablemente sabrá las respuestas al 75 % de sus preguntas, y podrá poner el otro 25 % en el contexto adecuado, de modo que cuando alguien le dé una respuesta, en realidad le sea útil.
Ciertamente puede usar ethernet MAC+PHY para transmitir cualquier tipo de datos que desee, eso sí, sin tener que preocuparse por las pilas tcp/ip o udp. La solución que aprovecha al máximo las IP y los chips existentes y sigue siendo muy eficiente sería empaquetar sus datos en marcos de ethernet. No tenga miedo de esto, el encabezado es muy simple y tiene una sobrecarga relativamente baja, especialmente si usa tramas gigantes, y el módulo MAC se ocupa de la interfaz con PHY (MII/GMII/RGMII), y cosas como el cálculo de CRC.
Básicamente, transmite datos a la MAC y respeta cualquier solicitud de espera que pueda recibir de ella.
En el lado de recepción (que es idéntico), el MAC transmite a su aplicación en forma de marcos de ethernet, nuevamente, muy fácil de decodificar. Por lo general, el MAC tiene la opción de descartar tramas con CRC incorrecto.
Use gigabit ethernet para velocidades razonablemente altas.
Simplemente pon:
aplicación (fpga) <-> MAC (fpga) <-> PHY (chip externo) <-> Magnético (paquete externo) <-> conector
No es necesario que escriba la IP de MAC, muchos lo han hecho antes, todos los principales proveedores de fpga tienen una oferta y opencores.org tiene una gratuita (velocidad triple, etiquetada como estable).
Puede comenzar con un kit de desarrollo antes de embarcarse en su propio pcb, lo ayudará a validar su diseño con un costo mínimo.
Incluso podría comenzar validando la idea solo con su computadora enviando marcos de ethernet sin procesar (búsquelo en Google, incluso Python proporciona una API para esto), y más adelante esto lo ayudará a verificar lo que está transmitiendo desde el fpga.
martin thompson