La única forma en la que pensé para contrarrestar esto es CON Y la entrada del reloj del flip flop con un reloj que es más rápido que el reloj principal ... así se garantizará que los datos se registrarán al final de ese ciclo.
Esto me suena como una opción de arquitectura que eventualmente limitará el rendimiento (velocidad de reloj máxima) que puede lograr con su diseño. Si sus registros pueden funcionar a la velocidad de reloj más rápida, eventualmente querrá intentar que todo el sistema funcione tan cerca de esa velocidad de reloj como pueda, pero entonces no podrá tener una "lenta" reloj y un reloj "rápido" para hacer esto con.
Para hacer esto, estoy recuperando datos de la memoria, colocándolos en el bus de datos y luego ingresándolos en un registro, todo en una sola operación. Me preocupa que el borde ascendente del reloj principal ocurra en el registro antes de que los datos se recuperen de la memoria ... una especie de demora de propagación / condición de carrera.
Primera solución
Una de las maneras en que se le ocurre resolver este problema es sacar los datos de la memoria en el flanco ascendente del reloj y registrarlo en el registro del flanco descendente. Ya que su registro no tiene un bit de configuración para el cual responde (como lo haría si estuviera diseñando en un FPGA), tendría que generar la señal apropiada usando un inversor (NO puerta) entre la "principal" La señal del reloj y el registro.
Más generalmente, es posible distribuir varias fases de su reloj (por ejemplo, 0, 90, 180 y 270 grados) en lugar de solo reloj y reloj invertido. Y usa estas diferentes fases para ejecutar diferentes acciones en diferentes momentos. Por supuesto, debe realizar un análisis bastante cuidadoso de cada interfaz en la que los datos se transfieren de una fase a otra para asegurarse de que se cumplan los tiempos de configuración y retención.
Según mi entender, posiblemente los diseños de reloj multifase fuera de fecha eran bastante comunes en la era del diseño lógico discreto, y también eran comunes (y pueden seguir siendo comunes) en ASIC y diseños de chips personalizados. Pero son bastante infrecuentes en el diseño de FPGA debido a la complejidad del análisis de temporización.
Segunda solución
Otra opción es crear una máquina de estado del controlador que habilite y deshabilite diferentes elementos en diferentes ciclos de reloj según sea necesario. Por ejemplo, habilitaría la salida de memoria en el ciclo 1 y habilitaría el registro para enganchar los datos en el ciclo 2. Ya que su registro aparentemente no tiene una entrada de habilitación de reloj, es posible que tenga que hacer esto ANDando una máquina de estado Salida con la entrada del reloj al registro.
Este tipo de diseño era bastante común en la era de las CPU de lógica discreta, y es lo que se enseñó en los cursos de lógica digital de pregrado a principios de los 90. Una versión elaborada de este esquema se llama microcoded architecture .
Por supuesto, esta arquitectura significa que necesita más de un ciclo de reloj para completar cada instrucción. Pero serían los ciclos múltiples de su reloj rápido, no su reloj "lento" original el que se usaría, y ya está utilizando más de un ciclo del reloj rápido por instrucción en su diseño.
