[microblaze-uclinux] FSL coprocessors vs custom instructions

[John Williams <jwilliams@xxxxxxxxxxxxxx>]

Matthew Rubenstein wrote:
> 	Hi - I see how the FSL saves development time, but how does it execute
> faster than an instruction, when both are made of HW logic on the same
> chip?

I think there's a couple of ways that FSL makes sense over custom 
instructions:

1 - as Goran points out, an FSL-based coprocessor can take an arbitary 
number of inputs (albeit sequentially, so there's a performance hit from 
microblaze keeping it busy)

2 - custom instructions (esp. badly designed ones) can interfere with 
the Fmax of the processor, since they sit in the processor's critical 
path (effectively a parallel ALU).  Get more than a few levels of logic 
between pipeline stages and watch Fmax head south towards 50MHz...  Now 
your custom instruction is costing your entire system serious MIPs.

FSL (and HW-based coprocessors in general) seems to make sense if:

1 - the FSL core can do a particular computation faster (ie in fewer 
cycles) than the equivalent algorithm implemented in the microblaze, OR

2 - the FSL core's computation can be done in parallel with the 
microblaze.  This tends to be more likely in cases where the microblaze 
pumps a few data items to the FSL, says "go", gets on with something 
else, and then checks back later to see if the FSL is done.

There are other cases too, these just seem to be the obvious ones.

FSL is nice because it's so close to the heart of the CPU, yet still 
somewhat loosely coupled.  You don't have to hit the shared bus to get 
your data to the coprocessor.


Cheers,

John
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/