Contención de bus al direccionar búferes de tres estados por salida del decodificador

Actualmente estoy rediseñando el algoritmo de propagación de señal de un simulador de circuito que estoy desarrollando como proyecto de hobby ( https://www.antarescircuit.io ).

En el nuevo diseño, estoy tratando de detectar cuándo se afirman señales en conflicto en los cables y emito una advertencia si este es el caso. Ahora recibo muchas advertencias al simular la famosa máquina MIC-1 según "Structured Computer Organisation" de Andrew S. Tannenbaum. Se originan a partir de la contención del bus cuando se leen valores de registro del scratchpad de la CPU (también conocido como archivo de registro).

El circuito del scratchpad se ve de la siguiente manera:

Se supone que los búferes de tres estados en el lado derecho controlan qué registro envía su valor actual a la ruta de datos B de la CPU. El registro es seleccionado por la entrada de 4 bits "FB", cuyo valor es decodificado por un decodificador 4-16.

El problema es que el decodificador (como cualquier circuito combinacional) produce resultados intermedios debido a los retardos de propagación de las distintas puertas lógicas que lo componen. En el ejemplo anterior, se debe direccionar el registro 6, pero por un breve momento, el decodificador establece más de una línea de salida en "alta".

La contienda existe durante 20 ns y está determinada por un solo retardo de puerta. Elegí este valor para la simulación porque parece estar en el rango de las puertas de hardware reales típicas. La señal permanece entonces estable durante al menos 9000 ns.

La causa raíz de la disputa se ilustra en la siguiente instantánea del decodificador. Las señales que pasan por los inversores tardan más y las puertas AND de salida producen resultados intermedios no válidos.

Nota: La instantánea se toma de una prueba con un decodificador 3-8. El decodificador 4-16 utilizado en el scratchpad consta de dos de ellos. Y no se deje confundir por las burbujas "cero" en las salidas de AND. Estos son producidos por la función de animación de flujo de señal y representan las señales que fluirán a las salidas con el próximo ciclo de simulación, estableciendo así la salida esperada y correcta del decodificador.

La pregunta es cómo se pueden evitar las señales conflictivas en las salidas de los búferes de tres estados. He considerado las siguientes opciones.

1. Temporización precisa : agregue búferes no inversores con el mismo retraso de propagación que los inversores al decodificador para asegurarse de que todas las señales lleguen a las puertas AND al mismo tiempo. Esto hace que la simulación funcione correctamente, pero me parece una trampa, y no estoy seguro de si esto realmente eliminaría el problema en el hardware real, donde enfrentaría varios retrasos de propagación debido a las diferencias de fabricación de las puertas lógicas.
2. Sincronización : entiendo que la lógica combinacional generalmente produce resultados intermedios, y los circuitos cronometrados generalmente se usan para lidiar con eso. Sin embargo, ni Tannenbaum en su libro mencionó este problema cuando explicó el bloc de notas, ni pude encontrar información en la red que discutiera si es legítimo controlar directamente los buffers tristate con la salida de decodificadores combinacionales. Intentar sincronizar la salida del decodificador requeriría un cambio significativo en la microarquitectura de la CPU, lo que probablemente implique la necesidad de introducir otra señal de reloj secundario.
3. Ignore el problema : podría ignorar fácilmente el problema, ya que el circuito de CPU simulado funciona bien a pesar de la contención temporal del bus. Sin embargo, me gustaría hacer eso solo si mi diseño del scratchpad es razonable, y es común ignorar situaciones de contención tan breves y temporales, incluso cuando se ejecuta el circuito en hardware real. Pero dado que esta situación, al menos según tengo entendido, representa "cortocircuitos" temporales en hardware real, dudo que sean aceptables.

Soy más un ingeniero de software que un ingeniero eléctrico y, por lo tanto, quizás no esté al tanto de una solución posiblemente obvia para mi problema, por lo que se agradece cualquier ayuda.