[Open-graphics] CPU fetch stage

Timothy Normand Miller theosib at gmail.com
Tue Mar 20 19:46:42 EDT 2007


On 3/20/07, Petter Urkedal <urkedal at nbi.dk> wrote:
> Not to disturb the flow here, but attached is a draft I made based on
> your previous skeleton.
>
> One thing I noticed when writing this is the constraint posed by the
> convention of registering output.  For instance, the output of the
> memory stage should be a mux between a direct forward of the ALU stage
> and the fetched word.  However, the output from the memory module is
> already registered, so if I understand this right, we can't do the mux
> within the module itself.  My solution was to rip out such cases from
> stage 2 and 4 and do the combinatorics in the top-level module.

We might have to cheat a little now and again and have a small amount
of muxing out the output of a stage.  We'll have to try it and see
what the impact is.  Or we could lengthen the pipeline by a stage....
or other things.

Sometimes, it's how you define the semantics.  The output of MEM is
either what we get from a RAM block, or something we get from I/O, or
something forwarded from an earlier stage.  That means we have to mux
at least three different things AFTER the clock edge.  Either we put
the MUX in MEM (and call it breaking the rules), or we pipe them all
into WB and let it do the MUXing.  The only time it isn't goofy is
when we add an extra pipeline stage (which we may need to do anyhow!).

> Comparing to your new fetch stage, I see a have not made the PC
> available as a return address.  An alternative to yours would be to make
> it readable as a register so that it would be copied before the jump;
> you probably though of that, and I guess it depends whether we need more
> than one level of calls.

I think it would be good for this to be general-purpose enough that we
would have multiple levels of calls.

-- 
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


More information about the Open-graphics mailing list