Enfoques para el almacenamiento y el direccionamiento del microcódigo para la CPU casera

Question

Llevo un tiempo aprendiendo sobre la arquitectura de las CPUs y he diseñado con éxito un par de ellas. Siempre se basaron en el microcódigo para manejar las líneas de control de la CPU.

El microcódigo se almacena en un chip ROM y se direcciona componiendo una dirección de (1 = LSB):

1. Banco
2. Estados de las banderas de la CPU
3. Instrucción
4. Estado T

Tomemos mi última CPU como ejemplo de cómo se construye la dirección:

1. Banco (3 bits) - Hay 48 líneas de control en mi CPU, así que necesito 6 bytes para almacenar todos los estados de las líneas de control. La parte del banco de la dirección me permite direccionar 6 bytes en la ROM del microcódigo.
2. Estados de bandera de la CPU (3 bits) - He reducido mis banderas a cero , llevar y comparar . Se necesitan 3 bits para abordar todas las combinaciones
3. Instrucción (8 bits) - El conjunto de instrucciones requiere más de 127 op-code, por lo que opto por 8 bits.
4. T-state (5 bits) - Algunas instrucciones tardan más de 16 t-states en completarse (las más complejas como las condicionales CALL / RETURN) por lo que con 5 bits tengo espacio suficiente para hasta 32 t-states

El ejemplo final de la dirección ROM del microcódigo sería algo así:

[flags][instruction][t-state][bank] [000][00000000][00000][000]

Ahora mi pregunta: En el ejemplo anterior, parece que he llegado al límite de lo que puedo hacer con este enfoque. La dirección de mi microcódigo ROM es de 19 bits y he encontrado un chip que lo soporta ( 29C040 ) pero parece que no tengo muchas opciones si quiero una dirección grande.

Estoy pensando en mi próxima CPU que necesitará más banderas ( negativo , desbordamiento , paridad ), y quién sabe, tal vez incluso algunas líneas de control más o un poco más para los estados T.

¿Cuál sería un mejor enfoque para almacenar y direccionar mi microcódigo en ese caso?

Lo único que se me ocurre ahora es:

• Añadir más chips de ROM (sólo liberaría 1 bit extra por chip no parece un buen enfoque)
• Limitar el conjunto de instrucciones (además, sólo me daría 1 - quizás 2 - bits extra)
• Limitar el número de líneas de control, pero eso permitiría un menor control sobre la CPU...

Me pregunto cómo se resuelve esto en las CPUs profesionales basadas en microcódigos y qué me estoy perdiendo aquí.

Answer 1

Su esquema de direccionamiento utiliza áreas completamente disjuntas de la memoria de microcódigo para cada instrucción posible. La mayoría de las CPUs tienen mucho microcódigo que puede ser compartido entre instrucciones. Por ejemplo, la búsqueda de la instrucción, la lectura del operando y la escritura del resultado suelen ser idénticas en grandes grupos de instrucciones, con la única diferencia de la operación específica de la ALU realizada en el medio.

También es muy impar almacenar los bytes de la palabra de microcódigo en serie - esto significa que su ROM debe ciclar 6 veces por cada "estado T". Es mucho más común hacer que la memoria de microcódigo sea lo suficientemente amplia como para que cicle al mismo ritmo que el resto de la lógica.

Por último, parece que estás experimentando con el diseño de la CPU. Tal vez deberías considerar el uso de SRAM amplia para tu memoria de microcódigo, y cargarla desde alguna fuente externa (un Arduino o equivalente) cada vez que enciendas tu sistema. Esto haría mucho más fácil hacer cambios.

Answer 2

Para mi CPU casera, el CSCvon8 En este caso, he utilizado una ROM de 4Kx16 para mantener mi microcódigo. La instrucción de 8 bits se encaja en un registro de 8 bits para formar 8 de los 12 bits de dirección a la ROM de microcódigo.

Los 4 bits de dirección de la ROM restantes provienen de un contador de 4 bits. Esto permite que cada instrucción se indexe en 16 microinstrucciones. Y la ROM tiene 16 bits de salida, por lo que tengo 16 líneas de control que puedo ajustar/despejar por microinstrucción.

Una de las líneas de control pone a cero el microcontador, por lo que las instrucciones no tienen que tener exactamente 16 microinstrucciones. Pueden estar compuestas de 2 a 16 microinstrucciones.

Podrías mover los bits de las banderas fuera del espacio de direcciones de la ROM. Yo envío tres líneas de control a un mux 74HCT151 8:1. Esto selecciona uno de los siete bits de bandera para enviar como línea de control al contador de programa. Para generar todos los saltos (==, !=, <, <=, >, >=, siempre, nunca) hago trampa teniendo mi propia ALU. Podrías usar algo de lógica combinacional para unir las banderas N y Z apropiadamente.

Lo que tienes es microcódigo horizontal que es lo que yo también estoy usando. Es posible que desee considerar microcódigo vertical, u otro formato en el que el microcódigo tiene su propia rama / salto interno, es decir, para saltar el microcontador basado en los valores de las banderas.

Echa un vistazo a este ejemplo: https://web.archive.org/web/20160305185415/http://www.mythsim.org/ y mi opinión sobre el mismo enfoque: https://minnie.tuhs.org/Programs/UcodeCPU/index.html (desplácese hasta "La lógica del microcódigo").