Unidad Hazard

La unidad de hazard ocurre cuando múltiples instrucciones son ejecutadas de forma

concurrente y una instrucción que depende de un resultado de otra operación no se
encuentra terminada, es decir, la operación aún no ha finalizado.

La llamada operación hazard ocurre cuando una instrucción escribe en un registro y

posteriormente lee el registro(RAW - read after write hazard).

Los Hazards son clasificados como data hazards o control hazards. Un data hazard
ocurre cuando una instrucción trata de leer un registro que todavía no se ha escrito con
anterioridad previa a la instrucción. Un control hazard ocurre cuando la decisión la cual se
buscará no toma el tiempo necesario en el tiempo de búsqueda.

Algunos data hazard son resueltos por forwardings también llamados bypassing un
resultado desde la memoria o la etapa writeback a la instrucción dependiente en la etapa
de ejecución. Para ello se añaden dos multiplexores en frente de la ALU para seleccionar el
operando ya sea del archivo del registro (register file) o de la memoria o de la etapa
writeback( etapa de reescritura )

Forwarding es necesario cuando una instrucción en la etapa de ejecución (Execute Stage)

tiene un registro de origen que coincide con el registro de destino de una instrucción en la
memoria o en la etapa de reescritura( writeback stage)
Al añadir dos multiplexores forwarding, la unidad de hazard recibira cuatro señales desde el
datapath que indicarán si el registro de origen en la etapa de ejecución coincide con el
registro de destino en la memoria y etapa de ejecución.

La Unidad de Hazard también recibirá la señal RegWrite desde la memoria o la etapa

Writeback para saber si el registro destino se escribirá realmente.

Data Hazards with Stalls

Forwarding es suficiente para resolver RAW Data Hazard cuando el resultado es
computado en la etapa de ejecución (Execute stage) de una instrucción, porque este
resultado puede entonces ser enviado a la etapa de ejecución de la siguiente instrucción.
Desafortunadamente, la instrucción LDR no termina de leer datos hasta el final de la etapa
de memoria, por lo que su resultado no se puede enviar a la etapa de ejecución de la
siguiente instrucción. Decimos que la instrucción LDR tiene una latencia de dos ciclos,
porque una instrucción dependiente no puede usar su resultado hasta dos ciclos después

Stall
The Hazard Unit examines the instruction in the Execute stage. If it is an LDR and its
destination register (WA3E) matches either source operand of the instruction in the Decode
stage (RA1D or RA2D), then that instruction must be stalled in the Decode stage until the
source operand is ready.

When an LDR stall occurs, StallD and StallF are asserted to force the Decode and Fetch
stage pipeline registers to hold their old values. FlushE is also asserted to clear the contents
of the Execute stage pipeline register, introducing a bubble.
Solving Control Hazards
Posibles preguntas:

- ¿Qué cambios se realizaron a la unidad de control del procesador de un solo

ciclo y al datapath para adaptarlo al pipeline?
R// Se agregan 3 registros, el condunit se saca de la unidad de control y se deja en
un módulo aparte, el decodificador no sufre cambios. Para el datapath se agregan 4
registros, 3 de ellos sincronizados con el controlador y dos multiplexores cuya
habilitación depende del hazard.

- ¿En qué procesador se basaron para el pipeline?

R// En el procesador de un solo ciclo // Porque dijo que en el multicliclo??

- ¿Qué pasa con los registros de las banderas?

R// Como es una señal de retroalimentación que se devuelve al registro que separa
la etapa del decode y del execute, entonces el siempre se queda ahí dando vueltas
hasta que el flagwrite se ponga en uno en la etapa de decode y pues se actualizan
las banderas.

- ¿Qué pasa con el registro de destino?

R// A diferencia del procesador de un solo ciclo, donde todo se hace pues en un solo
ciclo, como este es paso a paso y son varias instrucciones a la vez, el registro de
destino tiene que viajar junto con el resto de las señales de control.
 El register file se utiliza para la activación cuando el reloj está bajo, esto por que la
entrada está negada,
Se puede hacer poniendo la entrada del reloj negada o con señales activas en bajo.

Procesador pipeline: se crea por medio de la división del procesador de un solo ciclo a 5
módulos o etapas, por lo que ayuda a que 5 instrucciones puedan ser ejecutadas
simultáneamente, una para cada etapa. Lo que pasa es que cada una de las etapas va a
guardar ese pedacito, ese 1/5 de toda la lógica, se dice que la frecuencia del reloj es 5
veces más rápida.

Leer, escribir en la memoria y en los registros, la alu generalmente son las rutinas que
generan los mayores retrasos, por lo que cada una de estas etapas del pipeline ataca esas
ejecuciones que son mas lentas, los cuales son el fetch, el decode, el execute, la memoria y
el writeback. En la etapa del fetch el procesador lee la siguiente instrucción de la memoria.
En la etapa de decode, el procesador lee los registros fuentes del register file y decodifica la
instrucción para producir una señal de control. En la etapa de ejecución, el procesador
trabaja en conjunto con la alu y ejecutan las instrucciones. En la etapa de memoria, el
procesador lee y escribe datos en la memoria y por último en la etapa de writeback, el
procesador escribe un resultado en un registro.

La unidad de hazard ocurre cuando múltiples instrucciones son ejecutadas de forma

concurrente y una instrucción que depende de un resultado de otra operación no se
encuentra terminada, es decir, la operación aún no ha finalizado. existen casos como por
ejemplo El file register que puede ser leído en la primera mitad del ciclo de reloj y puede ser
escrito en la siguiente mitad del ciclo de reloj, por lo que no es necesario un hazart. En
algunas operaciones como el add, and,orr,sub, las instrucciones leen el registro en alguno
de los 2 ciclos de la etapa 4, produciendo un valor malo en el resultado y otras si lo hacen
en alguna parte del ciclo pero en la etapa 5 que es la indicada por lo que si no se hace un
tratamiento a esto, se puede incurrir en errores

Esto se soluciona con la NOP entre instrucciones de sumas ands, esto permite que la
instrucción que dependa de una anterior, no haga su labor antes de que el valor correcto se
encuentre en el registro.

Hay 2 tipos de Hazard, el datos y el de control. El de datos ocurre cuando una instrucción
trata de leer un registro que no ha sido escrito aun. La de control es cuando aun no se ha
tomado la decisión de por cual instrucción es la siguiente en el fetch durante el tiempo del
fetch. Todo eso se usa para que el procesador se ejecute.

Se adiciona el Hazard que recibe 4 señales del datapath, estas son las que indican que
indican si los registros de origen en la etapa de ejecucion coinciden con los registros de
destino en las etapas de Memoria y Ejecución. La otra señal que recibe es la regwrite desde
la memoria y desde el writeback, y es el encargado de saber el registro de destino donde va
a ser escrito.

Existen casos donde una instrucción tiene 2 ciclos de latencia, esto se da porque la
instrucción dependiente no puede leer el resultado si no hasta 2 ciclos de reloj después, por
lo que entendí, el Hazard no resuelve esto, ahí es cuando aparece el stall en el pipeline que
básicamente retiene la operación hasta que los datos estén disponibles. Si no estoy mal
cuando se hace un stall al pipeline lo que se hace es deshabilitar el registro del pipeline
para que no cambie el contenido y los datos. Entonces cuando una etapa fue stall, las
anteriores también deben ser stall, entonces ahí es donde aparece el flush, el cual borra la
info para que no haya algún tipo de error.

Resumen: data Hazard pasa cuando una instrucción depende del resultado de otra
instrucción que todavía no ha escrito el resultado en el registro en cuestión, el data Hazard
puede ser resuelto si se adelanta el resultado a tiempo pero si no toca es darle con el stall
hasta que el resultado esté habilitado. Control Hazard pasa cuando la decisión de por cual
instrucción va a ser en el fetch aun no se ha tomado, se soluciona si se predice la
instrucción siguiente que va a pasar al fetch, aquí pasan dos cosas, si la predicción es mala,
se hace un flush, y si la predicción es buena se hace un stall

El único cambio del controlador fue colocar los 3 registros que tienen que estar coordinados
con los registros del datapath
El control unit está separado en otro modulo

Los registros se llaman flop

Las flag están en el condunit son las banderas que se generan cuando hay operaciones de
cualquier cosa,

Al regfile se le cambia el flanco positivo a negativo