[Milkymist-devel] Single-Thread AEMB

[Shawn Tan]

On Monday 01 June 2009 06:46:44 am you wrote:
> > Is there an urgent need for a single-threaded one?

Sounds like the problems are mainly software portability issues. If an 
application is written as a single-threaded app, it will only benefit from the 
interrupt handling of the AEMB. Customising an app for the AEMB would make it 
less portable.

> 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

If the main app has dependencies with the interrupt routine, some basic 
synchronisation needs to be done, at least. Otherwise, it should not be a real 
issue.

> * 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 wondering if it may be possible to solve them at the software level. I 
agree that something like OpenMP would be overkill. I'm more inclined to 
consider it as two cores that share the same memory. But a better cache 
integration will definitely help.

> * 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

As for digital filters, it might be possible to use some ping-pong buffers and 
pass the buffers from one thread to the other to process in parallel. But like 
you said, that would make the code less portable.

> * 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).

I'm not quite sure if a single-threaded core may be better because of the 
wasted cycles encountered by data and control hazards. There's only one real 
way to test this though - to design a single-threaded version and compare them 
side-by-side. (=

I'll put some more thought into some of your issues.

-- 
with metta,
Shawn Tan.