On 3/20/07, Nicholas S-A <[EMAIL PROTECTED]> wrote:
> ...
> // Cause branch
> input [1:0] branch_condition;
> input [31:0] branch_reg_val;
What is branch_reg_val?
(I think I understand now, but you might want to comment about it)
Ok. I added a comment. It's the value of the register we're testing
for a conditional branch.
> ...
> // Decide if we're going to do a branch
> reg do_branch;
> wire beqz = branch_reg_val == 0;
> wire bneg = branch_reg_val[31];
ok, so if I understand correctly, branch_reg_val is r_ix,
which is tested for all the conditions?
I've lost track of some of Petter's conventions. But branch_reg_val
is a 32-bit value that was read out of a register.
> ...
> // Store the PC address we just used (advancing it by one).
> always @(posedge clock) pc <= next_pc + 1;
>
> // If this is a subroutine call, we need to pass the return address
> // down the pipeline
> always @(posedge clock) return_address <= pc + 2;
This is the only thing I am confused about. Suppose we have an
unconditional branch. Then pc = current_addr, next_pc=branch_addr,
but return address would point to the instruction after the one after
this
one. Why isn't it pc+1? What happens to the instruction at
current_addr+1?
Note that this is on a clock edge. It _is_ PC+1, but we're computing
it one cycle in advance.
Also, there's a delay slot. The branch doesn't take effect on the
next cycle but on the cycle after that.
Make sure you understand the timing diagram.
--
Timothy Normand Miller
http://www.cse.ohio-state.edu/~millerti
Favorite book: The Design of Everyday Things, Donald A. Norman, ISBN
0-465-06710-7
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
