Hi all, I am working on an eval card for the llc1394 project (http://www.opencores.org/projects.cgi/web/llc1394/overview). I need a compact and fast 32 bit CPU to go along with this core. So far I was not able to identify a good alternative to the MicroBlaze (the board uses a Spartan-3 FPGA). Can someone explain why MicroBlaze seems to be so much faster than any of the free cores out there? Thanks, /Mikhail

At 11:14 2004-07-14, you wrote:


Hand-crafted architecture-specific synthesis and placement...

Regards.

Microblaze was talor made for Xinilx FPGA devices.... try targeting the Microblaze to say an Altera device (probably not all that trivial) and see if there is a difference :) ----- Original Message ----- From: "Pablo Bleyer Kocik" pbk at embedded.cl> To: "Discussion list about free open source IP cores" cores at opencores.org> Sent: Wednesday, July 14, 2004 8:37 AM Subject: Re: [oc] Why open processors are so much slower than commercial ones? --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.703 / Virus Database: 459 - Release Date: 6/10/2004

On Wed, 14 Jul 2004 09:51:48 -0700 "Michael Ayton" mike_ayton at dsl-only.com> wrote: MA> MA> Microblaze was talor made for Xinilx FPGA devices.... try targeting the MA> Microblaze to say an Altera device (probably not all that trivial) and see MA> if there is a difference :) Unfortunately, I can't try your experiment since I don't believe the MicroBlaze is available in source code. I understand the sarcasm, but let's try to be more specific, what are those architecture specific details used in MicroBlaze that make it run at least 2 times faster than anything in the open domain (probably 3-5 times faster than most of the stuff )? I could understand if let's say multiplication in a CPU not targeted to a specific architecture was slower, since Xilinx has hardware multipliers, but what are the other features? Any FPGA has plenty of LUTs and FFs and I think these days we can count on having dual port memories as well... /Mikhail

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 14 July 2004 23:37, Pablo Bleyer Kocik wrote:


Another reason I can think of is that the Microblaze has a comparatively
simple ISA.. Most of the instructions can be decoded by just using the first
6 bits and at most another 2/3 bits...

And I think that you can get the RTL Microblaze code, at least that's what the
website says, but I think that you'll have to fork over a bundle before
getting it..

- --
with metta,
Shawn Tan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA9c4eUgUYbQRKphMRAncBAKCZlykqv9ewUUQ08Mya8agh7lE1qACgq1xn
Ic0dXzrhUb+l8Tmy9XQEQmM=
=DFue
-----END PGP SIGNATURE-----

Aloha!

Mikhail Matusov wrote:
What do you mean with "faster"? Faster in terms of clock frequency or faster in terms of execution performance i.e. efficiency? Is it the first version, then, as others have stated, Xilinx have invested in hand-mapping and tweaking the micro-arch to take advantage of the FPGA-arch, something they should be the experts on. You could/should be able to get very close if you did the same thing and people have in fact designed processing elements (PEs) specifically for a given FPGA-arch. Also, check out the work by Ray Andraka, who for many years have hand tweaked DSP-cores for FPGA with impressive results: http://www.andraka.com/ If it's the second version of "faster", then I'm not totally convinced that OC-cores are that much worse. I've done some benchmarking of the OpenRisc and it's not that bad, and part of that is quite probably also related to the code generator in the compiler, not the core itself. Also, if you look at, for example Alteras first Nios processor it actually had a pretty inefficient API which resulted in big programs and low execution performance. The new Nios II is *much* better. The MicroBlaze API is good, but IMHO not mind bogglingly impressive and unique in terms of performance in the world of processor cores. -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. VP, Research & Development ---------------------------------------------------------------------- InformAsic AB / Hugo Grauers gata 5B / SE-411 33 GÖTEBORG / Sweden Tel: +46 31 68 54 90 Fax: +46 31 68 54 91 Mobile: +46 733 75 97 02 E-mail: joachim.strombergson at informasic.com Home: www.informasic.com ----------------------------------------------------------------------

Hi guys, I think you have answered your own question there Mikhail. We don't have access to the source code, which very much suggests that they have compiled it very specifically for that Spartan series. Similar to if you try to compile a matrix multiple program (for example) with the C compiler GCC, compared to by hand, you'll find that you get a HUGE markup in execution time doing it by your self. Compilers aren't very smart!! So I suggest that maybe they have closed to hand compiled the core, making sure all the blocks are laid out very cleverly to reduce clock delay and skew. Even though FPGA clock distribution is very intelligent these days, a compiler will never really beat a human taking the time do it. Also, if the source code was available, it really isn't uncommon for them to put a check in their compiler to look for the source code of the Microblaze and just output the standard fully optimized output. I've seen a similar thing done in standard software code also, many companies do bench marks on their processors using modified compilers that just output really really optimized code for their machines. Making their performance look better :-) Look fwd to hearing a response - Justin -----Original Message----- From: Mikhail Matusov [mailto:misoma at rogers.com] Sent: Thursday, 15 July 2004 3:43 AM To: Michael Ayton; Discussion list about free open source IP cores Subject: Re: [oc] Why open processors are so much slower than commercial ones? On Wed, 14 Jul 2004 09:51:48 -0700 "Michael Ayton" mike_ayton at dsl-only.com> wrote: MA> MA> Microblaze was talor made for Xinilx FPGA devices.... try targeting the MA> Microblaze to say an Altera device (probably not all that trivial) and see MA> if there is a difference :) Unfortunately, I can't try your experiment since I don't believe the MicroBlaze is available in source code. I understand the sarcasm, but let's try to be more specific, what are those architecture specific details used in MicroBlaze that make it run at least 2 times faster than anything in the open domain (probably 3-5 times faster than most of the stuff )? I could understand if let's say multiplication in a CPU not targeted to a specific architecture was slower, since Xilinx has hardware multipliers, but what are the other features? Any FPGA has plenty of LUTs and FFs and I think these days we can count on having dual port memories as well... /Mikhail

Hi Justin,



Not quite sure what you are saying here, it seems to be contradictory. You
say "you get a HUGE markup in execution time doing it by your self" which,
to me, means it runs slower... I think you meant to say the opposite, that
you believe it will run faster if you hand compile it, as you then say
"Compilers aren't very smart". Actually, this, in my experience, is not
true. It is rare, these days, that you can hand compile code that runs
faster than a compiler can, especially code of any size. Compilers have
come a very long way over the past few decades.



You are probably correct, but keep in mind, software does not have
placement/routing, and FPGA hardware does...what this means, is there is yet
another level of complexity beyond compilation that attributes to FPGA
hardware performance. The hardware compilers are in fact reasonably good
these days, but there have been no real improvements in placement/routing,
algorithmically that is.

The saving grace is that FPGA manufacturers are making faster chips with
more resources. Kind of the same reason the PC runs so fast, even with bad
C code. And speaking of bad code, it is really essential, for using any
compiler, that the code writer understand what the compiler does with what
constructs, as some will compile more "efficiently" than others. It helps
to run a few test cases of different methods of writing the same algorithm
and seeing what the compiler does.

Regards,

Austin

Hi Joachim,



I would call that simply good (necessary) engineering.

Regards,

Austin

Thank you for pointing that our Austin.
You are right, what I meant by markup was that it goes faster! I worded that
quite badly! Sorry everyone!

You are right, but I recently compared a matrix multiply program (hence my reference earlier) assembled by hand and compared it with gcc, and hand compiled code ran a lot faster. But do note, it is only a small program. But as you very correctly mentioned, its up to the writer of the code to understand the architecture and the compiler to get the most out of it. For a very complex system like hardware compilers it's hard for developers describing hardware in the language to really know how the interpretation stage and hardware compiler stages actually work. I've been working with modifying a MIPS processor to suit my needs of late, and I've found that the closest a developer can get to a hand optimizing your VHDL compilation is to edit make sure the compiler understands what you mean by looking at the Fitter Equations, and you can optimize speed (sometimes) by looking at the floorplan and trying to make the clocks propagation length smaller. It's a difficult task! So I guess in closing, it may be for these reasons that a Xilinx written MicroBlaze will work best for a Xilinx FPGA. Xilinx know the quirks of their system, and the way their hardware compilation works. I wonder if Xilinx (or Altera) go to the extend of analyzing the compilers of their competitors, and find out what how to make the MicroBlaze code compile to run slower/less efficient on the other brand FPGA's as to keep their competitive advantage??? -----Original Message----- From: Austin Franklin [mailto:austin at darkroom.com] Sent: Thursday, 15 July 2004 10:06 PM To: Discussion list about free open source IP cores Subject: RE: [oc] Why open processors are so much slower than commercial ones? Hi Justin,

Not quite sure what you are saying here, it seems to be contradictory. You
say "you get a HUGE markup in execution time doing it by your self" which,
to me, means it runs slower... I think you meant to say the opposite, that
you believe it will run faster if you hand compile it, as you then say
"Compilers aren't very smart". Actually, this, in my experience, is not
true. It is rare, these days, that you can hand compile code that runs
faster than a compiler can, especially code of any size. Compilers have
come a very long way over the past few decades.



You are probably correct, but keep in mind, software does not have
placement/routing, and FPGA hardware does...what this means, is there is yet
another level of complexity beyond compilation that attributes to FPGA
hardware performance. The hardware compilers are in fact reasonably good
these days, but there have been no real improvements in placement/routing,
algorithmically that is.

The saving grace is that FPGA manufacturers are making faster chips with
more resources. Kind of the same reason the PC runs so fast, even with bad
C code. And speaking of bad code, it is really essential, for using any
compiler, that the code writer understand what the compiler does with what
constructs, as some will compile more "efficiently" than others. It helps
to run a few test cases of different methods of writing the same algorithm
and seeing what the compiler does.

Regards,

Austin

Hi Justin,



Ah, not really...just do some short examples, and examine the output. I
always try case statements (of variable number of cases) and compare that to
if/else etc. I have had this argument for YEARS about HDL compiler
manufacturers providing BNF or what ever, so they would document the input
constructs, and the output from the compiler for a given construct, thus
allowing for designers to choose the better construct for their needs. I
finally just wrote up a little set of test cases, and I just run those with
each new HDL compiler/revision I get. Helps me find their bugs ;-)



I believe the processor, and other IP, is shipped as an already compiled
module, so the compiler won't do any changing of the logic.

Regards,

Austin

Hi,

Interesting thread.

As the designer of MicroBlaze, I can provide a little more details.

In order to get the best performance, you have to optimize all part of
the system.

1. The Instruction Set
The instruction set has to be optimized for an FPGA design.
ex.
For the logical instructions, I use a LUT for each bit of result.
With a 4-input LUT, I need 2 inputs for the two operands and that gives
me 2 inputs for the type of logical instruction.
With 2 inputs, I can do 4 different logical instructions.
MicroBlaze have just 4 logical instructions, no more, no less.
Just doing 3 instructions, won't save any area at all,
Doing 5 logical instructions would cost twice the amount of area.

The actual opcode values is choosen to minimize the control logic.
ex. I have a result mux which selects the source for the new value to
the register file. Bit 0-1 is the actual selector for that mux, which
means 0 LUTs for that control logic. Most of the layout of the opcodes
has been done for this purpose.
Bit 4-5 determine the operation of the ALU block, etc...

2. The actual datapath implementation has to match with the FPGA.
For an ASIC design, the area cost is very different for an ALU than a
MUX but for an FPGA the area is actually the same.
A processor design has a lot of muxes and they needs to be minimzed
since they cost in area and performance. Extreme pipelines will run very
slow on a FPGA design due to all muxes for resolving the pipeline
hazardous.

3. The exact HDL coding of the processor has to be optimized.
I have done a lot of FPGA design tricks to get optimized performance
and area. (The Xilinx carry-chain is extremly powerful and normally
under used).
The source code for MicroBlaze exists but not as open-source.
It can be purchased from Xilinx.
A FPGA specific version exists and also a pure RTL version.
The pure RTL version can be targetting to ASIC and when implemented
on a FPGA, the synthesis tools and PAR is quite good on optimized the
design. The results is within 10% of area and performance compared to
the FPGA specific version.
I have only handcoded and handplaced logic that is within the critical
paths, very little has been needed for the area since I tend to write RTL
code that is well suited for an FPGA.

The best design tools is still the paper and the pen.
Every design tricks starts with a datasheet of the CLB and blank piece
of paper.

Göran Bilski

----- Original Message ----- From: goran.bilski at x...goran.bilski at x...> To: Date: Tue Aug 10 16:06:43 CEST 2004 Subject: [oc] Why open processors are so much slower than commercial ones?
implemented

A high frequency processor is not necessary a fast processor. A 8 bits cpu could be fast, but a 32 bits one will not be so fast. 2007/9/7, caodayong at uestc.edu.cn caodayong at uestc.edu.cn>:

Agree with "In order to get the best performance, you have to optimize all part of the system". Actually not every aspects of a processor design(note RTL coding is only a very small portion of the front-end design) is that interesting or easy to accomplish by a small amount of people. Therefore, not many people tried to do them except for the industry. Chunyang Gou ----- Original Message ----- From: caodayong at uestc.edu.cncaodayong at u...> To: Date: Fri Sep 7 14:02:00 CEST 2007 Subject: [oc] Why open processors are so much slower than commercial ones?