Re: [microblaze-uclinux] SMP

[George Smith <gesmith@xxxxxxxxxxxxxxxxxx>]

hi
 Thanks for the feedback. I completely miss the fact that you cannot
invalidate the cache line externally via a hardware interface. I also
agree about that, at the moment, the hardware trade off to implement a
snooping protocol might not be a good one. However as the the 65nm
fpga's and 45nm fpga's are available, resources should become less of an
issue.

gesmith


On Fri, 2006-03-17 at 19:01, John Williams wrote:
> Hi George,
> 
> George Smith wrote:
> 
> >  I was meaning SMP in the classical sense, where multiple cpu's a
> > running symetrically under an OS. As far as master/slave MP, I
> > understand how to accomplish that and there's certainly application
> > there.
> 
> I've built something I call protoSMP - two kernels running independently
> out of a shared memory.   Not rocket science, but not SMP either.  You
> can link them with FSL channels and do IPC that way.
> 
> >  The point on the the write allocates is that I believe you could do
> > your own cache coherency via CacheLink if the microblaze would do a
> > write allocate on write miss. The write allocate would stall the
> > processor and allow you to do you own work. (Of course it already does a
> > read allocate so that end is covered.)
> 
> As I see it the problem is that there's no way of forcing a cache
> invalidation back to the MicroBlaze.
> 
> Picture the scenario where CPU0 has a word in cache.  CPU1 writes to
> that address.  Even if your CacheLink snoop unit knows that CPU0 has
> that word cached, it cannot force CPU0 to invalidate that cacheline.
> Next time CPU0 reads that address, it fetches from cache, and you are
> incoherent.
> 
> There are ways around this, but requires a software intrusive invalidate
> cycle.  It quickly gets ugly, slow and error-prone.
> 
> Although SMP would be nice, from a philosophical point of view I'm not
> sure that cache snoop units etc are a good use of LUTs and especially
> scarce BRAMs.  These are FPGAs, we should probably be building
> innovative custom architectures and tools to support them, rather than
> re-engineering the compromises forced upon our fixed-silicon bretheren.
> 
> However, I would also concede that the same argument could be levelled
> against Linux on a soft-core CPU!
> 
> Cheers,
> 
> John
> 
> 
> ___________________________
> microblaze-uclinux mailing list
> microblaze-uclinux@xxxxxxxxxxxxxx
> Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
-- 
George Smith
VP Engineering
Linear Acoustic, Inc

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