[Milkymist-devel] Single-Thread AEMB
Florian Fainelli
florian.fainelli at openpattern.org
Sun May 31 23:05:49 PDT 2009
Hi Sebastien, Shawn,
Le Monday 01 June 2009 00:46:44 Sébastien Bourdeauducq, vous avez écrit :
> Hi,
>
> On Sunday 31 May 2009 16.57.56 Shawn Tan wrote:
> > To be honest, I have just submitted my thesis last week. Yeay! It's
> > finally over!
>
> Cool ! Are you publishing any paper ?
>
> > Is there an urgent need for a single-threaded one?
>
> Well, we are starting to have serious problems with AEMB :
> * It's time to design the interrupt-driven rendering system for Milkymist,
> which is highly dependent on whether the CPU has hardware threads or not
> * The full application (with GUI, DMX/MIDI interfaces, etc.) will be quite
> demanding in terms of raw performance and is not straightforward to split
> between two balanced threads (plus all portability issues)
> * I'm having performance issues when running some digital audio filters
> - that cannot be easily split between two threads (at least without
> OpenMP) - that are pretty memory-intensive and could potentially be
> accelerated by using better caches
> * A portable way to deal with the last two problems would be to implement
> OpenMP, but it makes the system pretty complex
> * Some people are trying to run Microblaze ucLinux on the system ; and
> there seems to be stability issues with AEMB (Florian, could you elaborate
> on this?)
Both the uClinux kernel and a simple test program doing context save/restore
on the stack crash the CPU without more information. I did not spend much
time doing this in simulation, which I still plan to in order to narrow down
the problem.
Will try to come up with the standalone program that did trigger this bug.
>
> While it is cool to alternate between threads at each cycle and deal with
> some hazards this way, it actually makes development and portability
> harder. While the current AEMB design is innovative and of an outstanding
> quality, I tend to prefer simple, standard and stupid solutions that work
> immediately instead of custom complex solutions that are hard to deal with.
> The current AEMB development projects (new toolchain and OS) also go in a
> different direction than mine.
>
> I'm currently thinking about moving back to Lattice's Mico32. Compared to
> AEMB, it provides single-threaded "standard" execution, configurable n-way
> set-associative instruction and data caches, and apparently proven ucLinux
> support.
>
> The main issue with Mico32 is that it fails post-PAR timing but this is
> perhaps easier to resolve with RTL optimization and floorplanning than the
> problems with AEMB (for now I did not go further than push-button
> synthesis).
>
> Sébastien
>
> _______________________________________________
> Devel mailing list
> Devel at lists.milkymist.org
> http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
--
Cordialement, Florian Fainelli
OpenPattern SARL - Lead software architect
GSM: +33.632843955
109/111 rue des Côtes
78 600 Maisons-Laffitte
France
------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.milkymist.org/private.cgi/devel-milkymist.org/attachments/20090601/2015e2f6/attachment-0001.pgp>
More information about the Devel
mailing list