Hi,

Since I designed the MicroBlaze, I can say why MicroBlaze ended up to way it
did.
There is a tradeoff between area and performance and I tried to find a good
compromise.
MicroBlaze has good enough performance and can still be implemented even to
smaller devices.
I could have made MicroBlaze smaller but with less performance or vice verse.

In MicroBlaze, this is what I did for the link register
In PowerPC the link register is a special register and in order to save it
you first have to move to a
general purpose register, the same for restoring it.
So it actually takes three instructions, one for the branch, one for moving
the link register to a general purpose and
one for saving to memory.
Since MicroBlaze has 32 register, I can use one of them as the link register
(r15) and thus save one instruction compared to PPC.
A branch and save onto stack instruction have to do
1. PC <- PC + offset
2. mem(r1) <- PC
3 r1 <- r1 -1
This would introduce one adder , one mux and more decoding logic and would
increase the size of MicroBlaze with 10%.
The gain would be 1 clock cycle for all branch to a subroutines that isn't a
leaf subroutine.

Which one is better, it depends on the application but I took the decision to
have a link register because it cleaner and wouldn't force
one register to be the stack pointer. Adding the logic may or may not
decrease the clock frequency, even if it's not on the critical path
the design will be bigger and thus move thing further apart from each other,
this can in itself introduce larger routing delay.

For the coming MMU on MicroBlaze, yes, a MMU will introduce 1 clock cycle
penalty for looking up a MMU table.
In PPC that's normal.

Göran Bilski


robfinch@... wrote:

> > This delivers flexibility, and more importantly, simplicity, in the
> > instruction set and in the implementation.
>
> I was thinking in terms of from a programming standpoint. AFAIK
> programming wise, there is no advantage. In terms of hardware, I
> won't argue there is no advantage. It depends on your goals. Keeping
> things simple and general purpose leads to hardware that has a small
> footprint and is fast.
>
> I have to admit, stacking the pc register instead of using a link
> register does lead to a little more hardware. The overwhelming reason
> to do things that way is that I find it aestically pleasing. If you
> are looking at the benefit versus cost from a mathematical
> perspective there is probably little or no difference, in which case
> it would logically be better to go with the simpler hardware. But, I
> was brought up on the likes of the 6502,Z80,68k,x86 processors and
> the risc paradigm of using a link register just seems plain alien,
> especially considering what you really want to do with the pc is
> stack it on a subroutine call. The human factor.
>
> I don't know if I'll implement push and pop instructions because the
> pop instruction requires a register file with two write ports in
> order to execute in a single cycle. There's also no real reason to
> implement them as subroutine parameters should be passed via
> registers, not on the stack.
>
> The processor I'm working on now (the BlueBird) is getting to be
> quite large (over 40% of SpartanII 2S200). It has loads of different
> instruction formats, complex decoding, a four stage instruction
> pipeline and other features. I've found I've been able to add complex
> features to the processor without affecting the performance because
> the thing that limits performance right now is access to the block
> ram. My instincts tell me that the block ram access is what is going
> to limit performance and I've not worried so much about the
> complexity of the decoder. If anybody wants a good laugh, the current
> verilog source for the bluebird (not working yet) is available on my
> website.
>
> I've been wondering what Xilinx is going to do a couple of years from
> now when their customers start asking for memory management for the
> MicroBlaze soft cpu. My guess is extra pipeline stalls.
>
> Sorry for the long post.
> Rob http://www.birdcomputer.ca
>
> PS. Does AFAIK = as far as I know ? (I've been guessing what all the
> internet acronyms are.
>
> To Post a message, send it to: fpga-cpu@eGroups.com
> To Unsubscribe, send a blank message to: fpga-cpu-unsubscribe@eGroups.com
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/