Por favor corrígeme si estoy equivocado. En general, he leído que para FPGA, el reloj maestro es una mala práctica de diseño y que uno debería usar master clock & habilitación de reloj siempre que el circuito necesite un reloj dividido y use un PLL para multiplicar el reloj maestro.
¿Los mismos principios se aplican también a los diseños ASIC?
¿Cuáles son las prácticas de diseño seguras cuando el circuito necesita un reloj dividido o multiplicado?
Para responder a su pregunta, las mismas pautas no se aplican a los ASIC y los relojes cerrados se usan con mucha frecuencia para reducir el consumo de energía.
En los FPGA, las señales de reloj tienen recursos de enrutamiento dedicados que aseguran una entrega sesgada de los relojes a áreas bastante grandes de circuitos. Si intenta controlar el reloj, entonces la salida de la puerta probablemente se verá obligada a utilizar los recursos de enrutamiento de la señal lógica normal, lo que puede generar retrasos significativos y causar grandes sesgos de reloj. Los FPGA están diseñados con algunas suposiciones acerca de cómo se debe hacer el diseño lógico, y una de esas suposiciones es que se usan señales de habilitación de reloj en lugar de relojes cerrados. Para los FPGA comunes, el consumo de energía es enorme de todos modos, por lo que hay poca motivación para controlar los relojes.
Los ASIC son una bestia muy diferente. Cuando diseñas un ASIC tienes control completo sobre las puertas y los cables. Puede crear con seguridad un reloj cerrado y asegurarse de que la señal del reloj cerrado se distribuye correctamente. Esta es una técnica muy común para minimizar el consumo de energía. Por ejemplo, mire un microcontrolador moderno y verá que, en el software, puede encender y apagar la señal del reloj para grandes trozos de circuitos, como un UART. El inconveniente es que los diseñadores de ASIC deben utilizar herramientas de análisis de temporización muy costosas y sofisticadas para hacer esto correctamente.
Respuesta corta:
Los relojes cerrados son muy malos.
Evite usar múltiples relojes cuando pueda (llamados dominios de reloj).
Investiga e implementa el cruce de dominios de reloj cuando no puedes.
Obtenga información sobre los dominios de reloj síncrono (relojes relacionados) y los dominios de reloj asíncrono.
Aprende sobre la metaestabilidad.
Respuesta larga:
Tiene razón, se recomienda encarecidamente usar un solo reloj y luego pasar las señales de habilitación en su diseño a los componentes que deben estar apagados o encendidos condicionalmente, en lugar de controlar el reloj. También puede utilizar una señal de activación como sugirió para ejecutar una sección a una velocidad de reloj más baja, más adelante.
La idea es minimizar el número de dominios de reloj y minimizar el número de cruces de dominio de reloj. Esto es absolutamente cierto para los ASIC, al igual que para los FPGA, e incluso para los circuitos lógicos discretos.
Cuando toda la lógica se realiza con el mismo reloj (sin compuertas de reloj) todas las actualizaciones de la lógica al mismo tiempo (con un poco de retardo llamado sesgo de reloj)
Esto es genial, porque puede estar seguro de que todas las entradas de todos sus registros se han configurado correctamente con el tiempo suficiente para que sea válido para el próximo reloj, y sabe que todas las salidas de registro serán válidas después del reloj ocurre. Esto es lo básico de un diseño síncrono.
Cuando tiene dos eventos relacionados que ocurren en diferentes relojes, incluso si están estrechamente relacionados (como una lectura de un registro de otro registro, pero de un reloj cerrado) existe el riesgo de que los datos se corrompan cuando se transfieren . Esto se llama metaestabilidad.
Si necesita más de un reloj, defina cuidadosamente lo que debe suceder en cada dominio del reloj y determine cuáles son los requisitos de comunicación. ¿Necesita enviar datos en ambas direcciones o solo necesita enviar datos del reloj más rápido al más lento? ¿O tal vez el reloj más lento al más rápido? ¿Cuántos datos debo enviar y con qué frecuencia debo enviarlos?
Hay una solución de dominio de reloj cruzado para cada uno de estos casos, y cada solución es ligeramente diferente. Afortunadamente, no es necesario volver a inventar la rueda (aunque es probable que tenga que volver a escribirla)
FPGA 4 fun tiene una excelente introducción a esto:
enlace