[Milkymist-devel] Single-Thread AEMB
Florian Fainelli
florian.fainelli at openpattern.org
Tue Jun 2 09:49:36 PDT 2009
Le Tuesday 02 June 2009 17:46:15 Shawn Tan, vous avez écrit :
> On Monday 01 June 2009 11:41:32 pm you wrote:
> > Hi,
> >
> > On Monday 01 June 2009 17.00.48 Shawn Tan wrote:
> > > 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.
> > >
> > > I'm not quite sure if a single-threaded core may be better because of
> > > the wasted cycles encountered by data and control hazards.
> >
> > The balance is between :
> >
> > * having good performance with 2 threads and no hazards thanks to a good
> > load- sharing between the interrupt service routine and the main program
> > (other optimizations should be avoided without a heavy framework like
> > OpenMP to keep portability), and
> > * having good performance with only 1 thread subject to hazards, and a
> > quite short pipeline plus a variety of well-known systematic techniques
> > to reduce the occurrence or impact of such hazards (instruction
> > reordering, loop unrolling, branch delay slots, etc.) that are already
> > implemented in GCC (no extra software work required). A branch predictor
> > could also be added to reduce the impact of control hazards (bimodal is
> > quite simple and efficient and should fit well in FPGAs).
> >
> > This is only my gut feeling, but it seems in favor of the single-thread
> > version.
> >
> > > There's only one real way to test this though - to design a
> > > single-threaded version and compare them side-by-side. (=
> >
> > It could also be useful to have a high-level (not RTL) simulator to
> > quickly test the impact of various architecture modifications (multiple
> > way caches, branch predictor, multiple threads, etc.) without taking the
> > time to go into the RTL design and coding.
>
> I think that having a software simulator might be a good idea. It could
> also be helpful with development/debugging work. You guys have any ideas on
> writing one? I've never written a software CPU simulator before.
You should have a look at or1ksim (OpenRISC) and the microblaze qemu port
here: git://repo.or.cz/qemu/edde.git microblaze
--
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/20090602/9e959d52/attachment-0001.pgp>
More information about the Devel
mailing list