Datos cronometrados incorrectos al usar cadenas margarita directas de registros de desplazamiento 594/595

Me sorprendió un poco encontrar esta pregunta y su respuesta .

esquemático

simular este circuito : esquema creado con CircuitLab

Cuando se conectan en cadena varios registros de desplazamiento HC595 o HC594, con SCLK (reloj de entrada en serie) y RCLK (reloj de registro de salida) compartidos, ¿puede haber una violación de tiempo que conduzca a que se registren datos incorrectos en SDI de los chips 'posteriores' (SR 2 en el lado derecho del esquema)?

La respuesta en el enlace anterior implica que, al recibir un borde SCLK, se podrían muestrear datos SDI después de que se hayan actualizado los datos SDO del registro anterior. Nunca presté atención a esto porque pensé que, por diseño, el retraso de propagación lo haría imposible. Según entendí, el CLK siempre llegaría primero y la actualización de SDO se retrasaría por el retraso de propagación de CLK a SDO dentro del chip anterior en la cadena.

Ejemplos:

Las piezas 74HC genéricas parecen confirmar que el tiempo mínimo de espera de SDI requerido suele ser <3 ns, mientras que el retraso mínimo de propagación de CLK a SDO es de al menos 12 ns.

La serie LVC más rápida no es tan clara en este sentido ( ejemplo de Nexperia ): el retraso de propagación mínimo es de solo 1,5 ns, pero el requisito de tiempo de espera típico es de alrededor de 0,1 ns con el valor absoluto en el peor de los casos dado para que sea el mismo que el Valores de retardo de propagación de CLK a SDO. Esto me sugiere que incluso el LVC está diseñado de tal manera que SDO nunca puede superar al CLK en una cadena de margaritas.

¿He sido descuidado/afortunado? Si es así, ¿bajo qué condiciones pueden aparecer estas violaciones y cómo solucionarlas suponiendo que todavía quiero usar un SCLK alto de ~ 20 MHz?

Otro factor a favor de la sincronización adecuada: el tiempo de espera y los retrasos se refieren a 1,5 V (tabla 8), pero los niveles de conmutación están por debajo/por encima de eso, es decir, más tarde.
No revisé lo que dices que es sospechoso, pero simplemente no suena agradable. Probablemente, esté viendo el artefacto de la correlación SCLK y RCLK. ¿Cuál es el sesgo entre SCLK y RCLK?
@jay, vuelva a leer la pregunta y especialmente el enlace. No reclamo nada, todos los circuitos en los que he usado 595 conectados en cadena han funcionado perfectamente. La respuesta en el enlace afirma que los datos incorrectos en SDI son un problema común debido a problemas de sincronización entre SDO/SDI y SCLK. RCLK no importa para la pregunta, solo se dibuja para completar
tobalt Leí la hoja de datos 74HC595 suya y de Ti, y que "esta pregunta". @WoutervanOoijen debería tener la oportunidad de retirarlo, antes de que todos nos confundamos. No hay base para su declaración: "La salida de la cadena de margarita cambia en el mismo borde del reloj que la entrada de las siguientes muestras de chips". La hoja de datos solo dice al revés.

Respuestas (1)

el retardo de propagación mínimo es solo de 1,5 ns, pero el requisito de tiempo de espera típico es de alrededor de 0,1 ns con el valor del caso más desfavorable absoluto dado que es el mismo que los valores de retardo de propagación de CLK a SDO. Esto me sugiere que incluso el LVC está diseñado de tal manera que SDO nunca puede superar al CLK en una cadena de margaritas.

Bueno, sí, está diseñado para usarse en cadena, ¡pero no hay mucho margen!

En mi opinión, es importante no arruinar el diseño con estos chips, especialmente los LVC. Definitivamente ese no es el tipo de chips para crear prototipos con cables voladores por todas partes...

Puede ejecutar el reloj en "contracorriente" a los datos, de modo que el último chip en la conexión en cadena del registro de desplazamiento obtenga su borde de reloj primero. Entonces tendría un poco más de tiempo de espera a medida que el reloj se propaga hacia el chip anterior, que actualiza su salida y se propaga en la otra dirección hacia el siguiente chip. Por lo tanto, esta disposición agregaría los tiempos de propagación del reloj y las trazas de datos entre chips al margen de tiempo, convirtiéndolos en una ventaja en lugar de un problema.

Sin embargo, si ejecuta el reloj en "contracorriente" a los datos, por supuesto, el tiempo de propagación en ambas trazas debe estar por debajo de un ciclo de reloj (con margen), para que cada chip obtenga el bit correcto, sin violación de tiempo, cuando su reloj la entrada ve un borde.

Tenga en cuenta que esto no tiene nada que ver con la frecuencia, porque en este caso las violaciones de configuración/retención ocurren cerca del borde del reloj a medida que el reloj y los datos se propagan a través de sus respectivas rutas. La frecuencia del reloj solo determina cuántas veces sucede por segundo, pero no si la violación sucede o no. La frecuencia importaría si fuera tan alta que la suma de los tiempos de preparación y espera más los accesorios no encajaran en un período.

También está el problema de la integridad de la señal en el reloj, ya que alimentará muchas entradas de reloj: si se enruta con stubs largos o no está terminado, podría sonar, duplicar el reloj o bordes desordenados. Me gustaría que el borde del reloj fuera limpio y rápido sin demorarse en la zona muerta, para que las diferencias en el voltaje de umbral entre los chips no agreguen más incertidumbre de tiempo.

Si cambiara la salida en un borde del reloj y muestreara la entrada en el otro borde, entonces tendría un margen de tiempo de medio ciclo, lo que haría que funcionara incluso con el peor diseño posible. Pero eso también reduciría a la mitad la velocidad máxima del reloj, lo que haría que el chip fuera menos útil.

Ya veo, así que todo se reduce a no arruinar el diseño (al que siempre presto el cuádruple de atención). Si ejecuto un rastro SCLK largo y sinuoso entre los chips, el SCLK podría tomar demasiado tiempo :) Mi nota sobre los 20 MHz fue porque obviamente podía agregar R o C a SDO, para ralentizar los SDO y garantizar que lo hicieran. alternar más tarde, pero eso afectaría el presupuesto de tiempo a tasas SCLK rápidas, por supuesto.
@tobalt R/C también sería mi sugerencia. Todavía hay un factor de 100 entre el período de reloj de 50 ns y la posible violación de tiempo de espera de 0.x ns.
De hecho, una resistencia en la salida de datos probablemente sería suficiente para retrasar la señal un poco al reducir la velocidad de respuesta, sin usar corriente adicional. Estos chips se usan en casi todos los paneles LED de matriz que existen, y funcionan bien...
El límite en la línea de datos puede ser el truco, mientras se habla de una velocidad de reloj de 20 Mhz, por el efecto secundario, no como la resolución real. Sin embargo, mata el margen de ruido, mientras que la velocidad del reloj no representa la velocidad de operación del circuito, mientras sospecha algo relacionado con la integridad de la señal. Me sorprendería si alguna empresa fabricara dispositivos 74HC con ese tipo de especificación de tiempo poco práctica.
@jay Supongo que lo que deduzco de esta pregunta y la respuesta de Bob es que puedo seguir sin importarme si diseño con cuidado y especialmente si me quedo con HC. De hecho, LVC puede volverse un poco complicado, pero no es necesario para mis aplicaciones. Si necesito algo realmente rápido como 100 MHz que requiera LVC, nuevamente no veo mucho margen para los elementos RC en SDO. En cambio, en ese caso confiaría en el hecho de que estos chips están diseñados para conectarse en cadena, de modo que deberían funcionar cuando se colocan correctamente.
@tobalt, estoy de acuerdo! Me alegra ver que se resuelve, mientras podemos darle a Woutervan Ooijen un espacio para su descanso. :)
Las pantallas de matriz LED son bastante comunes como letreros de tiendas, lo más probable es que se ejecuten en un montón de HC595...
Datos cronometrados incorrectos al usar cadenas margarita directas de registros de desplazamiento 594/595
RespuestasAquíPolítica de privacidad1y, 0v