Diseño de transmisión SPI de 8 MHz

Actualmente estoy trabajando en una PCB para un cubo LED de 8x8x8. El diseño de PCB en el estado actual se puede encontrar a continuación:

Interfaz de transferencia de datos

El ATmega328P (16Mhz) utilizará SPI para enviar los datos necesarios a cuatro chips TLC5940 (escala de grises de 12 bits, controlador LED de 16 canales) y un TPIC6B595 (registro de desplazamiento de 8 bits). Para obtener FPS lo suficientemente alto y aún tener suficiente tiempo de CPU para los efectos, la interfaz SPI debe ejecutarse a 8 MHz.

No estoy seguro del diseño correcto para evitar problemas como datos dañados.

Partes de diseño relevantes para estas preguntas:

A) Datos SPI: desde el pin ATmega SPI hasta el primer TLC y luego conectados en cadena a través de los siguientes tres TLC hasta el TPIC (cada rastro ~ 2-3 cm de largo)

B) Reloj SPI: desde el pin del reloj SPI de ATmega en dos direcciones. En primer lugar, al encabezado del ISP correspondiente y, en segundo lugar, en todos los TLC al TPIC. Cada pin de reloj de datos TLC está conectado por una rama muy corta de la línea de reloj. La línea termina en el pin de reloj del chip TPIC. (longitud total de la línea ~ 23-25 ​​cm de largo sin ramas)

C) Reloj GS: Necesario para mantener en funcionamiento el PWM de escala de grises de los TLC. A través del fusible CKOUT establecido, se envía una señal constante de 8 Mhz a través de esta línea a todos los pines del reloj en escala de grises TLC (~20 cm de largo sin ramas).

D) En blanco: De ATmega a todas las TLC, terminando en la última. Por lo general, nivel GND, alternado regularmente para restablecer el contador PWM en TLC. Durante la actualización de datos para los TLC, es alto durante los primeros bytes transmitidos y luego se vuelve a establecer bajo mientras el resto de los bytes se desplazan hacia afuera (para reducir el tiempo de inactividad del LED)

E) Latch: Desde ATmega conectado a todas las TLCs y el chip TPIC. Siempre bajo excepto por un cambio rápido (cuando SPI no está activo)

F) Capas de PCB: Líneas rojas arriba, líneas azules abajo. El fondo tiene además un relleno de suelo completo, como se ve en la ampliación de un TLC:

TLC de cerca

Mis preguntas sobre el diseño de transmisión de datos:

1) ¿Está bien enrutar esas líneas más de ~14 cm en paralelo? Blank y latch ("líneas tranquilas") están en el medio y las líneas "ruidosas" GS Clock y SPI clock en el exterior (0,05 pulgadas de distancia entre cada línea), pero por lo tanto cerca de los pines IC.

2) ¿Están bien las ramas cortas de 90° para conectar cada IC a las líneas de datos o esto creará problemas?

3) ¿Qué pasa con la reflexión/terminación de la señal (para el reloj SPI y GS)? He leído varios artículos sobre ese tema, pero realmente no entendí todo. Algunas personas afirman que a 8Mhz no hay problema. Otros diferencian entre la duración del trance y así sucesivamente. Algunas soluciones, como la terminación de la línea final, aparentemente solo funcionan para una sola carga, por lo tanto, esto obviamente no funcionará para mí. Hasta ahora no he encontrado nada concreto/claro con respecto a este tema. Siento que esto podría ser un factor decisivo para mi tablero en este momento.

4) ¿Qué pasa con la ruta de retorno de la señal? Traté de hacer posible que la corriente de retorno siguiera el rastro superior relevante en la capa inferior, pero quedan algunos obstáculos (como las conexiones del reloj GS, el pestillo y los rastros en blanco a los pines del PLC). ¿Sigue siendo aceptable el diseño a este respecto?

Atentamente,

ratuso

Ese es un diseño atractivo. A juzgar únicamente por el diseño, no creo que tenga ningún problema con SPI de 8 MHz, sus espacios libres se ven bien y el diseño general es limpio y consistente. SPI es bastante resistente (según mi experiencia) a la interferencia autoinducida. Has pensado mucho en esto por lo que parece. Por cierto, puedes guardarte una vía (ver pin 12 en IC3).
Observación aleatoria no relacionada: su anotación de dimensión vertical en el lado izquierdo de la imagen no está alineada correctamente con el contorno de su tablero.
De acuerdo con @Wossname. Puede hacer un prototipo de esto con confianza, dados los tiempos involucrados y su diseño. Sus preocupaciones estarían justificadas por un aumento de frecuencia x10.

Respuestas (1)

Esta respuesta ( ¿Se necesitan resistencias de terminación para UART, I2C y SPI? ) básicamente le dice que un SPI de 50 MHz probablemente sea bueno para pistas de> 7 cm. Todo lo que tiene que hacer es mantener el reloj y los datos aproximadamente de la misma longitud. El SPI unidireccional es bastante indulgente debido a la naturaleza dual de registrar los datos en un borde y luego volver a registrarlos en el otro.

A 8 MHz, el período es de 125 ns y el tiempo dado para que los datos se asienten (después de que cambien en un flanco de reloj) es, por lo tanto, de 62 ns. Tendría que hacer que las longitudes de las líneas de datos y SCL sean enormemente diferentes para llegar a un retraso cercano a los 60 nanosegundos.

Esta respuesta solo se aplica al envío de datos desde un maestro; surge otro problema mayor cuando se vuelven a ingresar datos desde un esclavo: esto determina la longitud máxima de la pista / cable en última instancia, pero si solo está enviando datos de maestro a esclavo, entonces no hay problema.

Tengo tiempo para establecerme, pero por lo que entendí, los problemas con la reflexión y la falta de terminación pueden provocar picos en los bordes de la señal. En este caso, supongo que esos picos podrían reconocerse como tics de reloj adicionales si son lo suficientemente grandes, ¿verdad? Entonces, incluso si la señal se establece en lugar de un reloj, el IC podría generar múltiples. ¿Es correcto este entendimiento? ¿Y podría ser un problema aquí?
Lea mi respuesta en la pregunta vinculada: cualquier pregunta, por favor plantéela como un comentario debajo de esa respuesta (creo que es una forma más relevante de hacer las cosas).
@ratuso, es muy poco probable que su circuito sea capaz de sonar lo suficientemente fuerte como para producir bordes de reloj falsos. Funcionará bien. No estás empujando la tecnología ni cerca de sus límites :)