Mike, question about the spec. I thought the dataHazard module only looks at the IF ID part of the pipeline and, if it detects a hazard, will stall the pipeline once (NOP). It does not need to look at the other parts of the pipeline right? From the design doc it seems like it does.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have been thinking about this, and I think the best way is to have the dataHazard output a reset and enable signal for each register. Keep in mind the reset signal from the outside will also reset the registers, and the it has priority.
Data hazard and forwarding are similar, but they have different functionality.
Data forwarding will look at rs, rt from decode stage, and rs rt from ex stage. It will look at the rw from ex stage and mem stage and the register enable. If both the from ex and mem are the same, data from ex stage has priority. If rw is zero, we shouldn't forward.
The forwarding logic to ex is the same as the forwarding logic to decode. Brandon, you will have to look at the memToReg signal and regWrite signal to tell if it's a lw, and if it's a lw, and the rs and rt are the same as rw, provided rw is not 0. Stall the pipeline. If the instruction in decode is branch, and rs and rt are the same as rw from ex. If it's lw in mem stage, stall the pipeline.
The branch will complicated everything up.
Some one check the register value for jr, is coming from the forwarding logic. Brandon, you have to check this too.
Suppose
lw $1 0 ($2),
jr $1. //or skip 1 instruction
lw $1, 0 ($2)
add $2, $3, $3 //unrelated instruction
beq $1, $4, label
Have fun!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I suppose you combine them together, to make 1 module because we should be able to save some logic gates this way. Just remember the forwarding logic controlls the muxes, regardless if there is hazard. There are 2 sets of muxes, because there are forwarding logic in decode and ex stage. I guess the dataHazard first has to detect it needs to forward, and then it will check if there is a hazard.
Brandon, go ahead if you want to combine them together, since Brian won't able to work on that until Monday, and we need to move ahead.
Mike, question about the spec. I thought the dataHazard module only looks at the IF ID part of the pipeline and, if it detects a hazard, will stall the pipeline once (NOP). It does not need to look at the other parts of the pipeline right? From the design doc it seems like it does.
I just update the design doc.
I change the module to hazardDetecting.
Brian is doing dataForwarding
I have been thinking about this, and I think the best way is to have the dataHazard output a reset and enable signal for each register. Keep in mind the reset signal from the outside will also reset the registers, and the it has priority.
Data hazard and forwarding are similar, but they have different functionality.
Data forwarding will look at rs, rt from decode stage, and rs rt from ex stage. It will look at the rw from ex stage and mem stage and the register enable. If both the from ex and mem are the same, data from ex stage has priority. If rw is zero, we shouldn't forward.
The forwarding logic to ex is the same as the forwarding logic to decode. Brandon, you will have to look at the memToReg signal and regWrite signal to tell if it's a lw, and if it's a lw, and the rs and rt are the same as rw, provided rw is not 0. Stall the pipeline. If the instruction in decode is branch, and rs and rt are the same as rw from ex. If it's lw in mem stage, stall the pipeline.
The branch will complicated everything up.
Some one check the register value for jr, is coming from the forwarding logic. Brandon, you have to check this too.
Suppose
lw $1 0 ($2),
jr $1. //or skip 1 instruction
lw $1, 0 ($2)
add $2, $3, $3 //unrelated instruction
beq $1, $4, label
Have fun!
I suppose you combine them together, to make 1 module because we should be able to save some logic gates this way. Just remember the forwarding logic controlls the muxes, regardless if there is hazard. There are 2 sets of muxes, because there are forwarding logic in decode and ex stage. I guess the dataHazard first has to detect it needs to forward, and then it will check if there is a hazard.
Brandon, go ahead if you want to combine them together, since Brian won't able to work on that until Monday, and we need to move ahead.
For example:
lw $2, 0($3)
add $1, $2, $3
beq $1, $2, label
we need to stall if
lw $5, 0($6)
sw $3, 4($5)
we might miss this part
in general, we only need to look check rw==rt if alusrc = 0
we still need to check rw == rs