[Milkymist-devel] Single-Thread AEMB

Sébastien Bourdeauducq sebastien.bourdeauducq at lekernel.net
Sun May 31 15:46:44 PDT 2009


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

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



More information about the Devel mailing list