¿Por qué no implementar 1Gbps, cuando todo lo que necesito son 20Mbps?

Question

Antecedentes

Estoy trabajando con un cliente en un gran proyecto que requiere el diseño de un chip de red personalizado para resolver los requisitos de transferencia de datos dentro del proyecto. La red está pensada para enviar pequeños paquetes a pocos centímetros de una PCB a otra a través de un único cable de par trenzado. Nosotros diseñaremos y especificaremos el protocolo de red, y otra empresa se encargará de la implementación del silicio.

Estimo que una velocidad de datos de 20 Mbps entre los nodos podrá hacer frente fácilmente a la cantidad de datos que hay que enviar, con mucho margen de maniobra en caso de que la cantidad de datos aumente en el futuro.

Problema

El cliente me pregunta por qué especifico sólo 20Mbps. ¿Por qué no algo como 1Gbps? ¿No sería mejor? Intuitivamente, creo que aumentar la velocidad de datos más allá de lo necesario es una mala idea. Al principio pensé que el cableado tendría que estar apantallado (cosa que no quiero), pero al mirar las categorías de cables Ethernet, veo que Gigabit Ethernet puede funcionar con cable Cat 6, que no necesita estar apantallado.

Otras limitaciones

• El proyecto está desesperadamente limitado por el espacio, y no tenemos espacio para cosas como los imanes, a menos que sea un componente muy pequeño (0603 como máximo).
• Los cables deben ser lo más finos y flexibles posible.
• El dispositivo funcionará con alimentación de enchufe, por lo que no hay ningún requisito particular de bajo consumo.

Pregunta

¿Cuáles son los problemas, en términos de diseño de silicio, cableado y cualquier otro, que pueden enfrentarse a 1Gbps, que no serían tan graves a 20Mbps? ¿Debo seguir la sugerencia de mi cliente de implementar la red a 1Gbps, o debo insistir en implementar sólo lo necesario?

Estamos bajo un estricto acuerdo de confidencialidad, así que no puedo dar demasiados detalles sobre nuestros requisitos. Pero le ruego que deje un comentario si necesita alguna aclaración.

Answer 1

Las señales TTL (single-ended, sin terminación) pueden manejar fácilmente 20 Mbps o más - mira el SPI, por ejemplo. Si sólo vas a recorrer unos pocos centímetros, el cable de cinta y los conectores IDC (o una placa base de algún tipo) te llevarán de una placa a otra.

1 Gbps te lleva a tener que lidiar con trazos, conectores y cables de impedancia controlada. Los receptores tendrán que utilizar técnicas PLL/DLL para mantener la sincronización y separar el reloj de los datos, mientras que a la velocidad más lenta bastará con la lógica sincrónica normal. El exceso de 50× y los dolores de cabeza adicionales simplemente no merecen la pena, si estás seguro de que 20 Mbps serán suficientes en un futuro próximo.

---

Una vez diseñé (hace unos 25 años) un protocolo de bus serie personalizado para el control y el estado de placa a placa entre placas en un rack de telecomunicaciones. Una especie de cruce entre I 2 C y SPI - señales unidireccionales como SPI, pero direcciones de dispositivos integrados como I 2 C.

Answer 2

Algunas razones:

Potencia

Una mayor velocidad significa más potencia. No sólo necesitas circuitos analógicos más rápidos, que consumirán más energía, sino que toda la electrónica que los rodea debe ser más rápida. Sus sistemas digitales, sus latches, la gestión del reloj, etc. Si consigues ese 1 Gbps utilizando señalización multinivel, ahora necesitas mejores ADC y DAC. Es posible que tenga que empezar a manejar un filtrado más complejo. Podría empezar a necesitar FEC, que también tiene que estar a la altura.

Tamaño del chip

Más rápido significa más cosas. Se necesita una mayor estabilidad del reloj, lo que implica circuitos más grandes. Se necesita una mejor sincronización, lo que implica un sistema de recuperación de reloj más complejo. Es posible que tengas que cambiar al uso de DSP para hacer la ecualización de los canales. Su FEC potencialmente necesario necesita espacio en el chip.

Sensibilidad al medio ambiente

Si se pasa de unas decenas de megabaudios a lo que sea necesario para el gigabit, se volverá mucho más sensible al entorno. Los pequeños desajustes, que podrían ser imperceptibles a unas decenas de MHz, se convierten en trozos resonantes a frecuencias más altas. Las reflexiones pueden empezar a causar un rendimiento intermitente. Un cable mellado debido al abuso durante años (no conozco el entorno de aplicación de su producto) podría estar bien para velocidades más bajas, pero causar un rendimiento pobre cuando se sube.

Esfuerzo de diseño

Creo que es obvio, por todas las cuestiones adicionales que he comentado anteriormente, que el tiempo y el esfuerzo de diseñar un enlace de comunicación más rápido es significativo. Sólo esto debería ser motivo suficiente.

EMI

Una mayor velocidad significa que el cumplimiento de los requisitos de EMI podría ser más difícil.

Answer 3

La pregunta obvia es: "¿1 Gbps significa 1000BASET Ethernet?". Si eso es lo que piensa el cliente, su exigencia de que "no tenemos espacio para cosas como los imanes" lo descarta de inmediato. Ethernet utiliza imanes en la capa física, y cuando diseñé una interfaz hace algunos años los imanes formaban parte de un cubo de aproximadamente 1 pulgada.

Dices que usas FPGAs, pero no dices de quién. Si vas a usar Xilinx, debes saber que los modelos actuales soportan LVDS de forma nativa, lo que parece ideal para tu propósito. Los primeros sistemas LVDS (televisores de alta definición) funcionaban a 122 Mbps, y la tecnología puede superar ampliamente los Gbps si es realmente necesario. Al ser diferencial, y suponiendo que las dos placas no utilicen tierras flotantes, la inmunidad al ruido es excelente.

En cuanto a tu elección concreta de frecuencias de reloj, añadir más margen de maniobra del que crees que necesitas es una de esas decisiones que pueden salvarte el pellejo en el futuro, así que no descartaría elegir algo como 100 MHz, pero eso depende de ti. Podrías familiarizar a tu cliente con la Ley de Roberge (Jim Roberge fue un conocido profesor de ingeniería eléctrica en el MIT hace unas décadas): "Los que piden más ancho de banda del que necesitan se merecen lo que tienen". Es cierto que se refería a los servosistemas, pero el principio sigue siendo válido en una gama muy amplia de disciplinas.

Answer 4

La aplicación que describes no tiene sentido para saltar directamente a una solución de silicio personalizada. Las velocidades de datos que usted prevé pueden ser manejadas fácilmente por la tecnología FPGA de precio moderado y la FPGA puede ser programada para implementar el protocolo especial si realmente cree que dicho protocolo es necesario.

Lo más frecuente es considerar una capa física estándar y luego construir el protocolo personalizado sobre ella. Para un ancho de banda del canal de comunicaciones de 20 Mbps se debe planificar una sobrecarga de protocolo de cierta cantidad porque el encuadre, la codificación de comprobación de errores y la sincronización consumen parte del ancho de banda. Así que tal vez considere un mayor ancho de banda en bruto para acomodar esta sobrecarga.

Una vez que hayas probado tu diseño, puedes ir al proveedor de la FPGA y hacer que produzca un diseño de chip duro a partir de la programación de la FPGA. Este enfoque mitiga todo el riesgo de desarrollo temprano y reduce los costes generales de la NRE en gran medida con respecto a la "inmersión en el silicio personalizado sólo porque parece genial".

Answer 5

La pregunta real es: ¿por qué diseñar un protocolo cuando ya existe todo?

Para las soluciones Ethenet se toma 10/100 y no 1GbE porque sigue siendo un poco más barato y mucho más fácil de maquetar. Por cierto, Ethernet puede funcionar sin magnetismo. Pero requiere MAC, que puede ser un IC extra. ¿O tiene uno en un microcontrolador?

20Mbps es algo que se ajusta a la capa Rs485 o tal, que es aún más barato y más simple. Los pares trenzados vienen con todo tipo de cables, más o menos flexibles, con conectores o simplemente soldados a su PCB.

Ah, lo más importante. Es más fácil meter la pata con 1Gb. Pero si necesitan espacio para seguir creciendo, limita menos.

En resumen: tienes que conocer los requisitos de tu sistema.