Simulación guiada por eventos

La microarquitectura modelada en Sim-async está compuesta por distintos mó- dulos que ejecutan concurrentemente y se transmiten datos entre sí utilizando un protocolo de comunicación. La ejecución asíncrona de esta microarquitectura no se rige por ninguna señal de reloj, por lo que los instantes de tiempo en que cada componente del sistema inicia o finaliza un cómputo son desconocidos a priori. La indeterminación en la temporización, sumada a la variación en el tiempo de cómputo que se aplica en los modelos asíncronos, hacen que la simulación de este procesador no se pueda reducir a un bucle que procese ciclos completos de ejecución, como en el caso de los sistemas síncronos.

Para resolver esta cuestión, Sim-async integra un mecanismo de gestión de even- tos que permite modelar cualquier temporización asociada a la ejecución de la microarquitectura. Según este mecanismo, el inicio del cómputo de cada etapa o unidad funcional del procesador tiene asociado un evento particular o evento de simulación que, a su vez, puede generar eventos adicionales que modelen la tem- porización de las comunicaciones de datos. Los eventos se insertan en una cola de eventos pendientes, donde se almacenan ordenados y esperan hasta el momento en que el simulador los procesa. Cada uno de los eventos que se manejan en el simulador posee la siguiente información:

Tiempo de inicio: instante de tiempo (de la línea temporal simulada) en que el evento se genera e inserta por primera vez en la cola de operaciones pendientes.

Etapa: fase de la microarquitectura a la que corresponde la operación. Dependiendo de la etapa, los valores pueden ser distintos:

• Fetch: los eventos relacionados con esta etapa se identifican como G_FETCH.

• Issue: el modelado de esta etapa se divide en dos fases: inicio de Is- sue, denotado como G_INIISSUE, y fin de Issue, G_ENDISSUE. En la primera fase el simulador comprueba las condiciones que se deben cumplir para que la etapa inicie su ejecución. Estas condiciones son

4. Simulación arquitectónica de sistemas asíncronos 125 dos: (1) existen instrucciones en la cola donde escribe Fetch, IQ; (2) tanto el ROB como las RSs tienen entradas disponibles. En caso de cumplirse ambas condiciones, se simula el comienzo en la ejecución de la etapa Issue. Para ello se obtiene la latencia de la etapa de la correspondiente función de distribución y se marcan como “ocupadas” todas sus estructuras. Sin embargo, no se envía ningún resultado a los receptores de esta etapa hasta que no transcurra esa latencia. El fin de la ejecución de la etapa lo determina el evento G_ENDISSUE, que se genera con un tiempo igual a la suma de la latencia de la etapa más el tiempo del evento de inicio, y se inserta ordenadamente en la cola de eventos. Es G_ENDISSUE el evento que se encarga de activar el envío de resultados y de marcar la etapa Issue como disponible para realizar el siguiente cómputo.

• Exec: para esta etapa también se utiliza un modelado dividido en dos eventos. El inicio de la etapa Exec supone localizar una entrada de las RSs asociadas a la correspondiente FU donde los operandos estén disponibles para iniciar el cómputo. En caso de encontrarlo, se inicia la simulación de la ejecución de etapa, que consiste en marcar la corres- pondiente FU como ocupada y obtener su tiempo de cómputo según la función de distribución. Todo este proceso inicial se asocia al evento G_INIEXEC. El final de la etapa consiste en enviar los resultados al registro que se sitúa tras la FU, liberando los recursos ocupados. Estas acciones se asocian al evento G_ENDEXEC. Para especificar cuál es la FU afectada, los eventos incluyen un campo llamado estructura, que se explica más adelante.

• Write-back: la ejecución de esta etapa también se modela a través de dos eventos, G_INIWB y G_ENDWB en este caso. Se encargan, una vez más, de marcar la frontera temporal donde el hardware asociado a esta etapa está ocupado. Solo la fase final, representada por el even- to G_ENDWB aplicará modificaciones sobre las estructuras en que escribe esta etapa.

• Commit: de nuevo, los principales eventos asociados a esta etapa son dos: G_INICOMMIT y G_ENDCOMMIT. Al igual que en Write-

126 4.4. Estructura del simulador

Etapa Eventos Asociados

Fetch G_FETCH

Issue G_INIISSUE, G_ENDISSUE

Exec G_INIEXEC, G_ENDEXEC

Write-back G_INIWB, G_ENDWB

Commit G_INICOMMIT, G_ENDCOMMIT

G_FLUSH

Tabla 4.1: Eventos de simulación asociados a cada una de las etapas del procesador.

back, estos eventos se encargan de delimitar el tiempo durante el cual la etapa está ocupada. G_ENDCOMMIT marca el momento en que se deben aplicar los cambios causados por las instrucciones finaliza- das. La etapa Commit también genera un evento adicional, asociado indirectamente a todas las etapas del procesador. Se trata del evento denominado G_FLUSH, correspondiente al vaciado (flush) de todas las estructuras y etapas del procesador. Este evento se genera cuando Commit detecta que la predicción para una instrucción de salto fue incorrecta, caso en que se necesita retomar la ejecución por el camino que no se eligió en la predicción.

Estructura: campo aplicable a los eventos asociados a la etapa Exec, donde es necesario reflejar a cuál de las unidades funcionales se refiere el evento, o bien si se trata de una instrucción de acceso a memoria.

Índice en el ROB: los eventos no sólo se asocian a la etapa y/o estructura a la que corresponden, sino que además se refieren a una instrucción concreta de las que se ejecutan. Este campo realiza esa asociación, indicando el índice ó entrada del ROB que ocupa la instrucción relacionada con el evento. PC : el contador de programa (PC ) también se almacena en los eventos. La utilidad fundamental de este campo es controlar el destino y origen de los saltos en la ejecución de las fases Fetch y Commit.

Los eventos de simulación, por tanto, acotan los instantes en que cada una de las etapas computan y ayudan a modelar su ejecución. En la Tabla 4.1 se muestra un resumen donde se incluyen los eventos de simulación asociados a cada etapa.

4. Simulación arquitectónica de sistemas asíncronos 127