PHYS Ethernet o FPGA

6

¿Cómo se usa un controlador estándar PHYS Ethernet? Las hojas de datos no proporcionan esquemas y, principalmente, solo proporcionan 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.

Ya que quiero transmitir los datos lo más rápido posible, no quiero usar paquetes. Desde 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 empaquetador de paquetes mínimo de los datos. ¿Significa esto que no puedo simplemente transmitir los bits al control de Ethernet pero debo empaquetarlos primero?

También, 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 esto 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 esto). ¿Sería mejor usar un FPGA para codificar el flujo de bits en 8b / 10b y usar palabras de control para indicar el inicio del flujo y aún así poder obtener una transmisión de datos a altas velocidades? (Obviamente, todavía se utilizan señalización diferencial y magnéticos como ethernet / RJ-45)

Un FPGA sería ideal como interfaz para mi aplicación y me 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 por FO. ¿Cuáles son los inconvenientes de usar un FPGA en este caso para "emular" un controlador Ethernet que ignora los problemas de "programación" (supongo que probablemente uno pueda descargarlos)?

    

2 respuestas

7

En primer lugar, aclaremos algunos términos: una interfaz Ethernet suele estar formada por dos partes: una MAC y una PHY. El MAC, Media Access Controller, maneja todo el ensamblaje de paquetes, la transmisión, la recepción y la verificación de errores. Un PHY maneja todo el material de transporte físico, como la modulación de la señal, la gestión del balanceo de CC, el seguimiento de la banda base, etc.

Hay algunas cosas que ambas partes hacen, hasta cierto punto. Tanto MAC como PHY realizan algún nivel de detección de errores de datos. Esto no es una detección de errores redundantes, sino solo la detección de errores que se relaciona directamente con los tipos de cosas que hacen el MAC y el PHY. Además, tanto MAC como PHY dependen de la naturaleza del paquete de Ethernet. El MAC porque utiliza 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 puedes alejarte de los paquetes incluso si solo usas el PHY. Por supuesto, los encabezados de paquetes no tienen que ser encabezados "estándar". Y el CRC no tiene que ser un CRC estándar. Pero todavía está limitado a la longitud máxima de paquete y al espacio entre paquetes que requiere Ethernet estándar. (Nota: es posible que pueda hacer paquetes "jumbo" si ambos PHY lo admiten).

Sin embargo, hay muchos beneficios 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 switches Ethernet estándar para ayudar a conectar diferentes dispositivos entre sí.

Usted menciona que acaba de conectar un "flujo TDM" directamente (más o menos) al PHY. Cada vez que alguien me ha dicho eso, han estado hablando acerca de la ejecución de audio digital multicanal a través de Ethernet. Si ese es el caso, entonces tiene un montón de 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 dime si eso es lo que quieres 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 en Cat-5 utilizando Ethernet PHY y FPGA, pero sin los MAC tradicionales. Algunos de ellos han utilizado los paquetes Ethernet Layer 2 o Layer 3, y otros no. Algunos también han usado tecnología no Ethernet como ATM o FDDI. Algunos de ellos han usado FPGA, pero dentro del FPGA hay una CPU y MAC más tradicionales.

Espero que en este momento 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, sino difícil. Déjame tratar de explicar lo difícil.

Primero, tendrás que dominar el diseño lógico de FPGA. De todos los diseñadores de lógica FPGA profesionales que conozco, este proyecto está más allá de la capacidad de tal vez 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 los FPGA lo suficiente para diseñar esta lógica. Probablemente años si lo haces como pasatiempo.

A continuación, debe aprender exactamente qué hacen un MAC y PHY, y cómo se interconectan. 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 un PCB para hacer todo esto. Tampoco es fácil diseñar una PCB confiable que use FPGA, PHY y haga todo lo correcto para la integridad de la señal de Ethernet. Tampoco es super duro. Pero en una escala de 1-10, siendo 1 muy fácil, este PCB sería aproximadamente un 6. No es difícil para un profesional con experiencia, pero definitivamente es difícil para un EE no profesional.

En este punto probablemente notaste que no respondí directamente a tus preguntas. Esto fue a propósito Podría responder a tus preguntas, pero honestamente eso no te ayudaría. Sería como decirte cómo construir la segunda historia de una casa cuando no has descubierto cómo construir la primera historia o incluso la fundación.

Comienza por aprender todo sobre el diseño de FPGA que puedas. También aprende todo lo que puedas sobre Ethernet. Hay muchos recursos en línea de notas de aplicaciones, hojas de datos y instrucciones. Vaya a opencores.org y estudie sus núcleos Ethernet MAC. Haga esto con diligencia y en un año podría estar listo. Y cuando esté listo, es probable que sepa 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, realmente le será útil.

    
respondido por el user3624
2

Ciertamente, puede utilizar Ethernet + MAC de Ethernet para transmitir cualquier tipo de datos que desee, sin preocuparse por las pilas tcp / ip o udp. La solución que aprovecha al máximo la ip y los chips existentes y aún es muy eficiente sería empaquetar sus datos en marcos Ethernet. No tenga miedo de esto, el encabezado es muy simple y tiene una sobrecarga relativamente baja, especialmente si utiliza tramas gigantes, y el módulo MAC se ocupa de la interfaz con el PHY (MII / GMII / RGMII), y cosas como el cálculo de CRC.

Básicamente, transmite datos al MAC y respeta cualquier solicitud de espera que pueda obtener de él.

En el lado de recepción (que es idéntico), el MAC se transmite a su aplicación en forma de marcos Ethernet, una vez más, 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.

En pocas palabras:

aplicación (fpga) < - > MAC (fpga) < - > PHY (ext. Chip) < - > Magnetics (ext. Pkg) < - > conector

No tiene que escribir el IP MAC, muchos lo han hecho antes, cada proveedor importante de fpga tiene una oferta, y opencores.org tiene uno gratuito (velocidad triple, etiquetado como estable).

Puede comenzar con un kit de desarrollo antes de embarcarse en su propia PCB, lo ayudará a validar su diseño con un costo mínimo.

Incluso puedes comenzar por validar la idea solo con tu computadora mediante el envío de marcos Ethernet sin procesar (google, incluso Python proporciona una api para esto), y más adelante esto te ayudará a verificar lo que estás transmitiendo desde el fpga.

    
respondido por el apalopohapa

Lea otras preguntas en las etiquetas