¿Por qué algunos microcontroladores tienen tan grandes retrasos en la sincronización?

9

En los microcontroladores de la serie SAM-D21 de Atmel, muchos periféricos utilizan un reloj que es asíncrono al reloj principal de la CPU, y los accesos a estos periféricos deben pasar por la lógica de sincronización; en los periféricos cuyo reloj es lento en relación con el tiempo de CPU, esto puede agregar algunos retrasos realmente enormes. Por ejemplo, si el RTC está configurado para usar un reloj de 1024Hz (como parece ser la intención del diseño) y la CPU se está ejecutando a 48Mhz, leer el registro de "hora actual" hará que la lógica del bus inserte más de 200,000 estados de espera (un mínimo de cinco ciclos del reloj de 1024Hz). Aunque es posible que la CPU emita una solicitud de lectura, ejecute algún otro código no relacionado y devuelva más de 200,000 ciclos más tarde para recuperar el tiempo, no parece haber ninguna manera de leer el tiempo más rápido. ¿Qué está haciendo la lógica de sincronización que tomaría tanto tiempo (el tiempo se especifica como al menos 5 ⋅ PGCLK + 2 ⋅ PAPB y como máximo 6 ⋅ PGCLK + 3 ⋅ PAPB)?

Por lo que yo entiendo de la sincronización, un circuito de sincronización de un solo bit retrasará una señal 2-3 ciclos del reloj de destino; sincronizar una cantidad de múltiples bits es un poco más difícil, pero hay una variedad de enfoques que pueden garantizar un comportamiento confiable dentro de los cinco ciclos del reloj de destino si es más rápido que el reloj de origen, y solo unos pocos ciclos más si no lo es. ¿Qué haría el Atmel SAM-D21 que requeriría seis ciclos en el dominio de reloj source para la sincronización, y qué factores favorecerían un diseño cuyos retrasos de sincronización son lo suficientemente largos como para requerir una "sincronización realizada"? "interrumpir, en lugar de uno que asegure que los retrasos de sincronización sean lo suficientemente cortos como para hacer que tales interrupciones sean innecesarias?

    
pregunta supercat

1 respuesta

1

Esa es una forma diferente de hacerme cosas, estoy acostumbrado a mis arquitecturas donde mis registros están en el reloj de mi CPU o al menos la mitad de ese reloj. Así que escribes tus registros y están listos de inmediato. ¿Quizás lo están haciendo de esta manera para ahorrar energía? Si están colocando registros de periféricos en su propio dominio de reloj realmente lento y separado, tal vez no tengan que activarse y ejecutar el oscilador principal o el reloj de la CPU, pero pueden seguir actualizando los valores en el periférico.

Si ese es el caso, entonces podría escribir un registro en su bloque periférico super lento, deshabilitar la isla de alimentación para toda la CPU o el reloj, y dejar que el sincronizador lento lo lea hasta que esté contento y luego interrumpir la CPU para sacarlo del sueño.

Alternativamente, podría permitirte meter la cantidad máxima de instrucciones en tu tiempo de vigilia, en lugar de girar seis ciclos y esperar cada escritura.

En cuanto a por qué usan tantos ciclos de sincronización, podría ser paranoia o podrían estar cumpliendo con algún estándar de alta confiabilidad para uno de sus clientes. No puedo decirlo con seguridad, pero sé que he visto clientes con demandas como que todos los ram tienen ECC y deben estar precargados a un valor establecido, etc.

Supongo que no es una respuesta definitiva, pero esos son mis pensamientos después de revisar un poco la hoja de datos.

    
respondido por el Some Hardware Guy

Lea otras preguntas en las etiquetas