Comparison of LEON2, Microblaze and Openrisc processors

I would have thought that a comparison of synthesisable cores would have included a Nios 2 as well, and would have included other fpga targets - the conclusions might have been wildly different if an Altera fpga were used, or even if a different Xilinx fpga were used rather than just the one Virtex II. The thesis claims to cover portability, yet only considers "porting" the cores to a single Virtex II board! As open designs, the Leon2 and Openrisc cpus are a world apart on portability compared to vendor-specific cores like the Microblaze and the Nios. I think it is also important to make version information clear - I don't know details about the processors here, but the Nios family has changed dramatically in the year or so that I've been using it, and such comparisons are only valid for a particular generation of the cores.

During the mentioned study, we were limited to a Virtex-II board and could thus not evaluate the Nios processor. However, we have ordered an Altera Cyclone board with the Nios-II design kit. A follow-up study will be made this spring, evaluating Nios-II and LEON2 on Altera hardware. It is not possible to evaluate Microblaze and Nios on the same hardware since only mapped netlists are provided with their design kits.

Jiri.

"jiri_gaisler" skrev i meddelandet news: snipped-for-privacy@c13g2000cwb.googlegroups.com...

The big question is if it makes sense to use 2-8000 CLBs for a CPU in the first place? Reasonably, such a chip will need to have an external flash memory and the pins between the FPGA and the Flash.

Think it will be hard to pricewise meet a hardwired solution with internal/external CPU. Think it would be nice to compare with a solution based on the AT91FR40162 (10 x 10 mm) running 60 MIPS at 20 mW with a smaller FPGA.

The FPSLIC and some PowerPC equipped Virtex are another approach which should be more cost effective for most applications

One advantage of implementing in FPGA, is it allows you to migrate if chips become obsolete. Then again, going with a Microblaze will force you into Xilinx FPGAs, and if you choose the Leon/OpenRISC, the core is more expensive.

Building your own chip, is of course more fun!

--
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.

Good point, but... It depends upon the problem.

Lots of interesting problems will fit into on-chip RAM. They might fit better into a special purpose CPU. That costs more design time.

External serial flash will be horribly slow, but might be good enough for some problems. Only takes a few pins. You could use on chip RAM for a cache or load it explicitly (bank switching).

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

The PicoBlaze, and tiniest variant of NIOS are interesting forthis

Yes, a core that used 50MHz SPI memory, and was optimised for serial-code fetch could be quite interesting....

-jg

One of the few reasons why you would want to have a soft processor today, is if you can boost your application through a non standard instruction set.

Why would you choose an FPGA with a soft Microblaze/Leon/OpenRISC over an FPGA with a hardwired Microblaze/Leon/OpenRISC?

If you come to the conclusion that a hardwired Leon is better than a soft one, then you need to ask yourself, if it is very important having a Leon, or will an external ARM7 chip do? The AT91FR40162 is 10 x 10 mm so it is not a lot of board space yuou can save by just having an external flash.

If you had a low cost coverification tool for the specific architecture then it is easier to develop the FPGA, and this could be one motivation. I have not heard about coverification for the cores mentioned above though.

A multichip package with flash and FPGA would make the proposal more attractive if you need certain combinations not available in std micros like PCI bus enabled controller. This would result in smaller board space. You can of course do a multichip FPGA + Flash Micro, but market might be smaller

You mean an FPSLIC ;-) Loads from

--
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.

In any case, you would expect that the MicroBlaze would perform better on a Xilinx device. Can one of the Xilinx Apps Guys comment why an open core CPU has a better performance than MicroBlaze?

Thanks,

Luc

This just suggests to me that the Sparc instruction set architecture (ISA) used by Leon is more "efficient" than Microblaze, in the sense that it does more computational work per cycle (MIPS per MHz).

However, that efficiency is clearly coming at significant logic expense, as evidenced by Microblaze demolishing both Leon and OpenRisc when the numbers are normalised with respect to LUTs (MIPS/MHZ/LUT), where I think Microblaze was better by factors of 4X to 8X in all configurations.

What this suggests to me is that if you can exploit parallelism in your application by plonking down two or more microblazes [1], then you will get a big win over Leon or OpenRisc, in terms of FPGA size, and thus perhaps power consumption and all the rest[2].

No-one in this newsgroup should be surprised by an experiment that demonstrates that you can trade time for area. It's just a design choice.

Seperate to that, there are possibly some other irregularities with the comparison, such as the fact that microblaze debug logic was left enabled, which introduces both Fmax and LUT count penalties.

Of course, what it really proves is that meaningful benchmarks are hard. No surprises there.

Regards,

John

[1] and keep them busy with meaningful work [2] Multiprocessor microblaze systems are getting more and more attention recently - as evidenced by recent posts here and in other forums. I think this is largely due to the Microblaze's FSL bus, which is much much easier to work with than conventional shared bus architectures, and the cache coherency issues that they introduce.

Well,

One thing out of many thing on this report, they didn't enable the barrel shifter on MicroBlaze which makes a big difference in performance benchmarks.

Göran

Luc wrote:

"Can one of the Xilinx Apps Guys comment why an open core CPU has a better performance than MicroBlaze?"

Why do you assume that a CPU which is open-source should perform worse than a CPU which is closed-source? Sun will open-source the Solaris 10 operating system - will Solaris then become less performant than when it was closed source?

LEON was designed for critical space applications at the European Space Agency. It has been open-sourced to increase testing in order to minimize the risk of latent errors. The fact that it has better CPI (clock per instruction) than Microblaze and Openrisc depends on several aspects: more advanced cache, lower branch and load delay, larger register file, better optimizing compiler. Whether it is open-source or not does not affect the performance ... Jiri.