5.8 Modelado con xDEVS del ciclo de instrucción MOV AL, BL
Con el propósito de validar la arquitectura del simulador VonSim8 y analizar su comportamiento interno, se modela la instrucción MOV AL, BL como un caso de estudio representativo del flujo básico de ejecución a nivel de hardware.
VonSim8 adopta el modelo de Von Neumann, caracterizada por la utilización de un bus único compartido para instrucciones y datos, lo cual introduce el clásico cuello de botella estructural (limitación en el acceso concurrente a datos e instrucciones). En este contexto, la Unidad de Control (UC) debe sincronizar con precisión los accesos concurrentes a memoria y al bus.
Este modelo aplica el formalismo DEVS (Discrete EVents System Specification), introducido en el capítulo 3.3, para representar la ejecución a nivel de Transferencia entre Registros (RTL) como una secuencia de eventos discretos temporizados. La simulación se construye sobre la plataforma xDEVS, utilizando la biblioteca xdevs.py (Python), cuya elección se justificó en la sección 3.3.2.
De acuerdo con el formalismo DEVS, cada componente funcional del procesador —como los registros, la Unidad de Control (UC), la memoria y el bus— se modela como un modelo atómico, mientras que las interacciones entre ellos se describen mediante un modelo acoplado jerárquico. Esta estructura jerárquica permite capturar la concurrencia de eventos y la propagación temporal de señales entre componentes, manteniendo la trazabilidad de cada transición de estado.
5.8.1 Componentes del simulador VonSim8
Los componentes que intervienen en el ciclo completo de instrucción (Fases de Captación y Ejecución) se modelan como modelos atómicos o acoplados dentro de la plataforma xDEVS, cada uno con sus puertos de entrada, salida y retardos (tiempos de avance \(\tau\)) definidos.
La Tabla 5.13 sintetiza los modelos y componentes fundamentales del simulador VonSim8, especificando para cada uno sus funciones, señales de entrada y salida, así como los retardos asociados. Esta presentación estructurada permite comprender la organización interna del sistema y el comportamiento de sus elementos durante la simulación.
| Modelo | Descripción | Entradas / Salidas | Retardo |
|---|---|---|---|
| IP (Instruction Pointer) | Contiene la dirección de la próxima instrucción a ejecutar. Envía su valor al MAR. | \(\tau_{ip} = t_{ip}\) | |
| MAR (Memory Address Register) | Almacena la dirección recibida desde el IP y la utiliza para acceder a la memoria unificada. | \(\tau_{mar} = t_{mar}\) | |
| MEM (Memoria unificada) | Memoria compartida que contiene instrucciones y datos. Devuelve o almacena la palabra solicitada. | \(\tau_{mem} = t_{mem}\) | |
| MBR (Memory Buffer Register) | Registro intermedio que conecta la memoria con los registros internos. | \(\tau_{mbr} = t_{mbr}\) | |
| IR (Instruction Register) | Registro de instrucción que recibe la palabra desde el MBR y la expone a la UC para su decodificación. | \(\tau_{ir} = t_{ir}\) | |
| REG_BANK (Banco de Registros) | Modelo acoplado que agrupa los registros AL, BL, CL y DL. Cada uno se modela como componente atómico capaz de leer o escribir datos a través del bus compartido. El banco administra las señales de control (, ) y coordina las operaciones entre los registros bajo las órdenes de la UC. | \(\tau_{regbank} = t_{regbank}\) | |
| UC (Unidad de Control) | Coordina el ciclo de captación y ejecución, generando las señales de control y arbitraje del bus. | \(\tau_{control} = t_{control}\) | |
| BUS / Árbitro | Canal compartido de comunicación entre IP, MAR, MEM y el banco de registros. Garantiza acceso exclusivo mediante señales de control. | \(\tau_{bus} = t_{bus}\) |
5.8.2 Fases del ciclo de instrucción
El ciclo de instrucción se compone de dos fases principales, controladas por la Unidad de Control (UC) y modeladas mediante transiciones de estado y funciones temporizadas en el formalismo DEVS:
Fase de captación (Fetch): lectura de la instrucción desde la memoria unificada.
Fase de ejecución (Execute): transferencia del contenido del registro fuente BL al registro destino AL.
5.8.3 Fase de captación (Fetch)
La fase de captación tiene como objetivo obtener la instrucción almacenada en la memoria unificada, utilizando el valor del Instruction Pointer (IP) como dirección base, y transferirla al Instruction Register (IR) para su posterior decodificación. Este proceso marca el inicio del ciclo de instrucción y determina la secuenciación temporal de accesos a memoria, condicionada por el modelo Von Neumann (memoria y bus compartidos).
En VonSim8, esta fase reproduce la restricción estructural propia de la arquitectura Von Neumann (bus y memoria compartidos), modelando el acceso exclusivo durante la lectura de la instrucción.
La Tabla 5.14 expone la secuencia de microoperaciones y eventos DEVS que modelan la fase de captación (Fetch) en el simulador. Esta representación permite analizar en detalle el flujo de acciones internas durante la obtención de instrucciones, aportando rigor al estudio del ciclo de ejecución.
| Paso | Microoperación | Descripción | Funciones DEVS |
|---|---|---|---|
| 1 | UC \(\rightarrow\) IP | La UC genera una señal de lectura hacia el Instruction Pointer. | \(\lambda(UC) \rightarrow \delta_{ext}(IP)\) |
| 2 | IP \(\rightarrow\) MAR | El IP emite la dirección actual de instrucción hacia el MAR. | \(\lambda(IP) \rightarrow \delta_{ext}(MAR)\) |
| 3 | UC \(\rightarrow\) MEM\(\,\); \(\,\)IP \(\leftarrow\) IP+1 | La UC activa la señal mem_read para iniciar la lectura de la instrucción y, de forma concurrente, incrementa el valor del IP en una unidad. | \(\lambda(UC) \rightarrow \delta_{ext}(MEM)\); \(\lambda_{UC} \rightarrow \delta_{ext}(IP)\) |
| 4 | MEM \(\rightarrow\) MBR | La memoria unificada devuelve la instrucción solicitada después de su retardo interno (\(\tau{mem}\)). | \(\delta_{int}(MEM) \rightarrow \lambda(MEM) \rightarrow \delta_{ext}(MBR)\) |
| 5 | MBR \(\rightarrow\) IR | El MBR transfiere la instrucción recibida al registro IR. | \(\lambda(MBR) \rightarrow \delta_{ext}(IR)\) |
| 6 | IR \(\rightarrow\) UC | El IR genera un evento de salida notificando a la UC que la instrucción está lista para decodificación. | \(\lambda(IR) \rightarrow \delta_{ext}(UC)\) |
Durante esta fase, el bus se arbitra mediante un protocolo de petición-concesión (/), garantizando exclusión mutua en el acceso y previniendo colisiones.
5.8.4 Fase de Ejecución (Execute): MOV AL, BL
En la fase de ejecución, la UC decodifica el contenido del IR y activa las señales necesarias para que el Banco de Registros (REG_BANK) transfiera el dato desde el registro fuente BL hacia el registro destino AL a través del bus compartido.
El REG_BANK se modela como un componente acoplado que contiene cuatro modelos atómicos: AL, BL, CL y DL. Cada registro posee sus propias entradas (enable_in, enable_out, data_in, data_out), mientras que el banco actúa como mediador, gestionando la habilitación del registro fuente y destino según las señales emitidas por la UC.
La Tabla 5.15 detalla la secuencia de microoperaciones que conforman la ejecución de la instrucción modelada en el simulador. Esta información permite analizar el proceso interno paso a paso, facilitando la comprensión de la dinámica operativa durante la fase de ejecución.
| Paso | Microoperación | Descripción | Funciones DEVS |
|---|---|---|---|
| 1 | UC: decodifica(IR) | La UC interpreta el opcode MOV y determina los operandos AL y BL. | \(\lambda(UC) \rightarrow \delta_{ext}(REG\_BANK)\) |
| 2 | UC \(\rightarrow\) REG_BANK.enable_out(BL) | La UC habilita la salida del registro BL en el Banco de Registros. | \(\lambda(REG\_BANK) \rightarrow \delta_{ext}(BL)\) |
| 3 | BUS \(\leftarrow\) BL | El valor de BL se transfiere al bus compartido. | \(\lambda(BL) \rightarrow \delta_{ext}(BUS)\) |
| 4 | UC \(\rightarrow\) REG_BANK.enable_in(AL) | La UC habilita la entrada del registro AL en el Banco de Registros. | \(\lambda(UC) \rightarrow \delta_{ext}(REG\_BANK)\) |
| 5 | AL \(\leftarrow\) BUS | El registro AL captura el dato presente en el bus y actualiza su valor interno. | \(\lambda(BUS) \rightarrow \delta_{ext}(AL)\) |
Las microoperaciones se ejecutan conforme a las funciones DEVS de transición interna \(\delta_{int}\), transición externa \(\delta_{ext}\) y de salida (\(\lambda\)).
5.8.5 Validación experimental
La implementación en xdevs.py reproduce 11 microoperaciones (6 en Fetch y 5 en Execute) y, para este caso de estudio, produce 14 ciclos totales y 45 transiciones DEVS. Se mantiene esta métrica de forma consistente en el cuerpo del texto y el Anexo D (6.4). Los resultados confirman:
- Correctitud funcional: la transferencia AL ← BL se ejecuta correctamente (
AL: 0x01h → 0x0Ah). - Coherencia temporal: cada componente respeta sus retardos \(\tau\) especificados.
- Sincronización del bus: el acceso exclusivo se garantiza mediante señales de control.
La traza completa de ejecución, que incluye todos los eventos \(\lambda\), \(\delta_{int}\) y \(\delta_{ext}\) con sus marcas temporales, se presenta en el Anexo D (6.4), donde se evidencia la coordinación correcta entre la UC, el bus y los registros involucrados.
5.8.6 Conclusión
El modelado del ciclo de instrucción MOV AL, BL mediante el formalismo DEVS, implementado sobre la plataforma xDEVS con la biblioteca xdevs.py, demuestra la viabilidad de representar con rigor y precisión el comportamiento temporal de la arquitectura VonSim8 a nivel de transferencia entre registros (RTL). La descomposición del procesador en modelos atómicos (IP, MAR, MEM, MBR, IR, REG_BANK) y su orquestación mediante un modelo acoplado jerárquico permiten capturar tanto la concurrencia de eventos como las dependencias estructurales inherentes a la arquitectura de Von Neumann.
Los resultados experimentales validan la correctitud del modelo: la ejecución de la instrucción requiere 14 ciclos distribuidos en 6 microoperaciones de captación (Fetch) y 5 de ejecución (Execute), generando un total de 45 transiciones DEVS (\(\lambda\), \(\delta_{int}\), \(\delta_{ext}\)) con un tiempo real de simulación de 3.36 ms. La traza temporal evidencia cómo la Unidad de Control sincroniza el acceso exclusivo al bus compartido y a la memoria unificada, reproduciendo fielmente el cuello de botella estructural de Von Neumann.
Desde una perspectiva de validación arquitectural, este enfoque posibilita la instrumentación de métricas cuantitativas de rendimiento —CPI (Cycles Per Instruction), latencia de acceso a memoria, tiempo de ocupación del bus— que constituyen indicadores objetivos para evaluar el comportamiento del sistema y detectar inconsistencias en el diseño. La modularidad del modelo DEVS facilita, además, la extensión futura del simulador mediante la incorporación de nuevos componentes (ALU, pipeline, cache) sin comprometer la estructura existente.
Desde una perspectiva pedagógica, el modelo ofrece una representación explícita y observable de las dependencias funcionales entre componentes internos del procesador, permitiendo a los estudiantes comprender cómo las restricciones arquitecturales —bus único, acceso secuencial a memoria, coordinación mediante señales de control— impactan directamente en el rendimiento del sistema. De este modo, la visualización de las transiciones de estado y la propagación temporal de eventos no solo valida el modelo, sino que refuerza el aprendizaje de conceptos fundamentales como el ciclo de instrucción, la sincronización de componentes y las limitaciones estructurales de las arquitecturas clásicas.