[Open-graphics] CPU fetch stage

[Timothy Normand Miller]

On 3/20/07, Nicholas S-A <nova at macintoshclub.com> 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