Nios II = Microblaze

[Stifler]

Altera finally wakes up. They realize that the window register type
architecture is not good for FPGAs and probably in general. They can
no longer support their own marketing hype about how great Nios I is.
If Nios 1 was so great, why did it need a complete redesign and
rearchitecture? It means it was poor. That's the only reason you do a
complete redesign. I believe they have switched to 32 bit instructions
also. Didn't it used to be 16 bit? Guess that wasn't so great either.

They copy the Xilinx Microblaze style implementation. To me it shows
who knows what about designing and running a soft processor in an
FPGA. Enough said.

They throw all the current Nios customers under the bus. Requires
publishing a 38 page app note to switch a Nios 1 to Nios II design.
Current Nios users, I feel sorry for you. Be careful and do your back
ups!

 

[Ken Land]

"Stifler" <seannstifler69@hotmail.com> wrote in message
news:bf780a06.0405241256.1b6a51e1@posting.google.com...

Altera finally wakes up. They realize that the window register type
architecture is not good for FPGAs and probably in general. They can
no longer support their own marketing hype about how great Nios I is.
If Nios 1 was so great, why did it need a complete redesign and
rearchitecture? It means it was poor. That's the only reason you do a
complete redesign. I believe they have switched to 32 bit instructions
also. Didn't it used to be 16 bit? Guess that wasn't so great either.

They copy the Xilinx Microblaze style implementation. To me it shows
who knows what about designing and running a soft processor in an
FPGA. Enough said.

They throw all the current Nios customers under the bus. Requires
publishing a 38 page app note to switch a Nios 1 to Nios II design.
Current Nios users, I feel sorry for you. Be careful and do your back
ups!

I try not to respond to trolls, but in your case I'll make an exception.

You don't know what your talking about!

Nios I with SOPC builder is a small fast, flexible processor with great
tools. Nios II is even better. It's smaller, faster, and has even better
tools.

How someone could see such an upgrade as something to feel sorry about is
madness. If your car dealer called you up and said come pickup your new
replacement car only it looks better, runs faster and gets better mileage,
would you turn him down?

Try to use some common sense!

Ken Land

 

[Jon Beniston]

I believe they have switched to 32 bit instructions
also. Didn't it used to be 16 bit? Guess that wasn't so great either.

Depends on what you are interested in. If it's code density, then
16-bit instructions are great. NIOS had a significant code size
advantage over MicroBlaze. NIOS II doesn't. Perhaps that isn't
important, but when you have an instruction cache, good code density
can also improve performance (less cache misses).

Cheers,
JonB

 

[Goran Bilski]

Jon Beniston wrote:

I believe they have switched to 32 bit instructions
also. Didn't it used to be 16 bit? Guess that wasn't so great either.



Depends on what you are interested in. If it's code density, then
16-bit instructions are great. NIOS had a significant code size
advantage over MicroBlaze. NIOS II doesn't. Perhaps that isn't
important, but when you have an instruction cache, good code density
can also improve performance (less cache misses).


With the few benchmarks that I have done, I didn't see any big savings

in the NIOS I code size.
I think that most NIOS2 users will see that the code size will not
increase that much compared to NIOS1.
A 32-bit instruction can do more for each instruction than a 16-bit
instruction and a 16-bit ISA also have problems with immediate values.

So the code size is very application dependent but you will not see a
"significant" difference.

Cheers,
JonB

 

[Uncle Noah]

"Stifler" <seannstifler69@hotmail.com> wrote in message
news:bf780a06.0405241256.1b6a51e1@posting.google.com...
Altera finally wakes up. They realize that the window register type
architecture is not good. They can no longer support their own marketing
If Nios 1 was so great, why did it need a complete redesign and
rearchitecture? It means it was poor. That's the only reason you do a
complete redesign. I believe they have switched to 32 bit instructions
also. Didn't it used to be 16 bit? Guess that wasn't so great either.

Other user said:

Nios I with SOPC builder is a small fast, flexible processor with great
tools. Nios II is even better. It's smaller, faster, and has even better
tools.

Both can have good share in the market. For my own purposes it is more
probable that i would use Nios than MicroBlaze.

In Microblaze there is no way to add your own custom instructions. It
is not an extensible processor but just provides the means to add
peripherals to a small SoC. Correct me if i am wrong. I just hope that
the tools (assembler, simulator, debugger) can be retargeted for the
new ISA. Or be able to use inline assembly with the new instructions.
The corresponding hardware should be built by some RTL description i
would give.

Since customization is out of the issue, no Microblaze for me.

Uncle "The G.B. Man" Noah

 

[Goran Bilski]

Have you looked at the FSL interface on MicroBlaze?
It will allow you to create custom functions which can be more powerful
than custom instructions.

Göran

Uncle Noah wrote:

"Stifler" <seannstifler69@hotmail.com> wrote in message
news:bf780a06.0405241256.1b6a51e1@posting.google.com...


Altera finally wakes up. They realize that the window register type
architecture is not good. They can no longer support their own marketing
If Nios 1 was so great, why did it need a complete redesign and
rearchitecture? It means it was poor. That's the only reason you do a
complete redesign. I believe they have switched to 32 bit instructions
also. Didn't it used to be 16 bit? Guess that wasn't so great either.



Other user said:


Nios I with SOPC builder is a small fast, flexible processor with great
tools. Nios II is even better. It's smaller, faster, and has even better
tools.



Both can have good share in the market. For my own purposes it is more
probable that i would use Nios than MicroBlaze.

In Microblaze there is no way to add your own custom instructions. It
is not an extensible processor but just provides the means to add
peripherals to a small SoC. Correct me if i am wrong. I just hope that
the tools (assembler, simulator, debugger) can be retargeted for the
new ISA. Or be able to use inline assembly with the new instructions.
The corresponding hardware should be built by some RTL description i
would give.

Since customization is out of the issue, no Microblaze for me.

Uncle "The G.B. Man" Noah

 

[Jon Beniston]

With the few benchmarks that I have done, I didn't see any big savings
in the NIOS I code size.

Here's a few results for you:

Dhrystone 0.873552983
JPEG 0.651083295
g726 0.781745341
g711 0.724035608
GSM 0.74610231
AES 0.659236641
TCP/IP 0.638751451
bzip2 0.812246882

I.e. NIOS is on average 25% smaller than Microblaze. Note: I have
taken into account the size of crt0 etc. etc..

I think that most NIOS2 users will see that the code size will not
increase that much compared to NIOS1.

They will lose that 25%. Maybe it isn't important.

A 32-bit instruction can do more for each instruction than a 16-bit
instruction

Sure, but not all the time.

and a 16-bit ISA also have problems with immediate values.

I don't know what you mean by problems, but yes, a 16-bit instruction
doesn't have as large a range for immediates as a 32-bit instruction.
NIOS got around this with their prefix instruction. They just happend
to lose out on performance as they didn't choose to decode a prefix
and the subsequent instruction in parallel.

So the code size is very application dependent but you will not see a
"significant" difference.

Well, 25% seems significant to me.

I don't want to come accross as some NIOS fanboy, because I'm not.
It's just those are the facts as I seem them.

Cheers,
Jon

 

[Jon Beniston]

In Microblaze there is no way to add your own custom instructions. It
is not an extensible processor but just provides the means to add
peripherals to a small SoC. Correct me if i am wrong. I just hope that
the tools (assembler, simulator, debugger) can be retargeted for the
new ISA. Or be able to use inline assembly with the new instructions.
The corresponding hardware should be built by some RTL description i
would give.

Is anyone actually doing this?

Cheers,
JonB

 

[Goran Bilski]

Jon Beniston wrote:

With the few benchmarks that I have done, I didn't see any big savings
in the NIOS I code size.



Here's a few results for you:

Dhrystone 0.873552983
JPEG 0.651083295
g726 0.781745341
g711 0.724035608
GSM 0.74610231
AES 0.659236641
TCP/IP 0.638751451
bzip2 0.812246882

I.e. NIOS is on average 25% smaller than Microblaze. Note: I have
taken into account the size of crt0 etc. etc..


Is this with the register window enable or with the mflat option?

If you add the data into the sizes, the percentage will be even smaller.
For a lot of the application, the data size is normally larger than the
code size.
The only benefit of smaller application size (code and data) is that you
might get away with smaller memories.

I think that most NIOS2 users will see that the code size will not
increase that much compared to NIOS1.





They will lose that 25%. Maybe it isn't important.

Normally not.

A 32-bit instruction can do more for each instruction than a 16-bit
instruction



Sure, but not all the time.

But most of the time.

and a 16-bit ISA also have problems with immediate values.



I don't know what you mean by problems, but yes, a 16-bit instruction
doesn't have as large a range for immediates as a 32-bit instruction.
NIOS got around this with their prefix instruction. They just happend
to lose out on performance as they didn't choose to decode a prefix
and the subsequent instruction in parallel.

Which mean that you will need two 16-bit instructions instead of one

32-bit instruction.
Which is then the same size.
If you look at the NIOS code, you will find a lot of the PFX instructions.

So the code size is very application dependent but you will not see a
"significant" difference.



Well, 25% seems significant to me.

I don't want to come accross as some NIOS fanboy, because I'm not.
It's just those are the facts as I seem them.


Cheers,
Jon

Göran

 

[E.S.]

Uncle Noah wrote:

In Microblaze there is no way to add your own custom instructions. It
is not an extensible processor but just provides the means to add
peripherals to a small SoC. Correct me if i am wrong. I just hope that
the tools (assembler, simulator, debugger) can be retargeted for the
new ISA. Or be able to use inline assembly with the new instructions.
The corresponding hardware should be built by some RTL description i
would give.

Sorry, but I think that "custom instructions" are the worst idea.
Than you have to update (with new versions/revisions) not only your
design, but also the whole toolchain ? (assembler/linker/cc ?)

And there is still tha chance, that the whole CPU slows down, because
of your new instruction, so you even loose, not gaining anything

Much simpler to access a "accelarator" memory mapped, or as a
peripheral, or whatever interface you have for it.

 

[Ken Land]

"E.S." <emu@ecubics.com> wrote in message
news:4KLsc.19641$zs2.4918@fe39.usenetserver.com...

Uncle Noah wrote:

In Microblaze there is no way to add your own custom instructions. It
is not an extensible processor but just provides the means to add
peripherals to a small SoC. Correct me if i am wrong. I just hope that
the tools (assembler, simulator, debugger) can be retargeted for the
new ISA. Or be able to use inline assembly with the new instructions.
The corresponding hardware should be built by some RTL description i
would give.

Sorry, but I think that "custom instructions" are the worst idea.
Than you have to update (with new versions/revisions) not only your
design, but also the whole toolchain ? (assembler/linker/cc ?)

And there is still tha chance, that the whole CPU slows down, because
of your new instruction, so you even loose, not gaining anything

Much simpler to access a "accelarator" memory mapped, or as a
peripheral, or whatever interface you have for it.

Wouldn't you have a hard time setting your inputs, issuing the command, and
retrieving your results in one clock cycle with an external peripheral?
Custom intructions and external peripherals/functions are both very usefull
and have their place.

Ever heard the term "Sour Grapes" ?


Ken

 

[E.S.]

Ken Land wrote:

Wouldn't you have a hard time setting your inputs, issuing the command, and
retrieving your results in one clock cycle with an external peripheral?
Custom intructions and external peripherals/functions are both very usefull
and have their place.

I was thinking along the lines of something what wouldn't use just one
instruction, but could run very well parallel to the cpu for few clocks.
ANd, even use a faster or slower clock ...

Ever heard the term "Sour Grapes" ?

Heard before, but why in this context ?

 

[Jon Beniston]

Is this with the register window enable or with the mflat option?

Register windows.

If you add the data into the sizes, the percentage will be even smaller.

You can add in whatever you want. We wont be talking about code size
though

For a lot of the application, the data size is normally larger than the
code size.

Yes, but for conventional embedded CPU apps, code is different (i.e.
it goes in FLASH/ROM rather than RAM).

The only benefit of smaller application size (code and data) is that you
might get away with smaller memories.

You say it like it doesn't matter. Maybe it doesn't with FPGA CPUs as
you're obviously not concerned about price anyway

Cheers,
JonB

 

[Jon Beniston]

Sorry, but I think that "custom instructions" are the worst idea.
Than you have to update (with new versions/revisions) not only your
design, but also the whole toolchain ? (assembler/linker/cc ?)

I don't think it works like this. I think the instructions are already
built in to the toolchain, you just have to define what they do.

If this is the case, then it's not really that flexible as you are
restricted as to what operands you can use.

Much simpler to access a "accelarator" memory mapped, or as a
peripheral, or whatever interface you have for it.

It depends on what you are trying to do. For some tasks, such as
performing a bit reverse or something trivial like that, it will work
well, and the programming model is ideal. For other things, such as
performing block encryption, it obviously isn't going to work. It all
depends on what you are trying to I guess. At least it is nice to have
the option there.

Cheers,
JonB

 

[Kenneth Land]

"E.S." <emu@ecubics.com> wrote in message
news:GsOsc.20467$zs2.931@fe39.usenetserver.com...

Ken Land wrote:

Wouldn't you have a hard time setting your inputs, issuing the command,
and
retrieving your results in one clock cycle with an external peripheral?
Custom intructions and external peripherals/functions are both very
usefull
and have their place.

I was thinking along the lines of something what wouldn't use just one
instruction, but could run very well parallel to the cpu for few clocks.
ANd, even use a faster or slower clock ...

Ever heard the term "Sour Grapes" ?

Heard before, but why in this context ?

Uh.. Because you're saying you don't want something you can't have, even
though it's of great value. (Custom Instructions with Nios (the grapes) vs.
Microblaze (no grapes) - so you say "They are probably sour anyway")

Ken

 

[Kenneth Land]

"Jon Beniston" <jon@beniston.com> wrote in message
news:e87b9ce8.0405251505.5b6713a8@posting.google.com...
<snip>

You say it like it doesn't matter. Maybe it doesn't with FPGA CPUs as
you're obviously not concerned about price anyway

Cheers,
JonB

Hard to imagine an embedded project without an fpga. Might as well have
only one chip (fpga + softcore cpu) and save the board space since you're
most likely going to require an fpga anyway. (board space == $$$, parts
count == $$$)

The reason you would want to use a softcore over hard is because it can be
*exactly* customized to any application. Need 27 serial ports and timers?
no problem. Need none? don't waste the pins or money. Need more
processing power? add custom instructions/external parrallel logic or
another softcore cpu (or 8!).

I've seen hard core projects fail, but a soft core project can only fail
from early abandonment. More/harder work can always find a solution,
because the hardware can become anything you're willing to realize.

Ken

 

[Stifler]

Landman,

First off, your analogy was terrible. You are assuming my getting the
brand new car which is faster and better has no cost. If I knew I
could have had the better car for the same price 2 years earlier, I
would feel like an idiot for not buying it 2 years ago.

From my experience, cpu engineers are never too excited about having a
processor architecture canceled. It's not a free conversion. The cost
of this conversion can be debated. Maybe it's not too costly. A 38
page app note tells me it's not invisible to the engineering team.
Engineering effort is required to switch Nios 1 to Nios II. That's not
free.

Also, custom instuctions are probably as stupid as a window register
file. Why do you need a custom instuction so bad? I believe it's
simply hardware acceleration. There's several ways to accomplish
hardware acceleration. Altera's custom instuction can bog down your
processor Fmax. It goes right into the middle of the pipe. Why not
simply have your processor launch off a separate process while it
continues to grind away at top speed?

I can think of several ways to stomp a custom instruction depending on
what it is. How about using a dual port ram and write a bunch of data
to it. Have my user logic attached to the other side and process it.
Tell me when it's done. Or, use a DMA to transfer a burst of data to a
user peripheral.

Altera hypes this custom instruction crap. It's the same hype as the
windowed register file. It's the same joke. It's probably as stupid of
an idea as having a windowed register file. Which they just chucked.
Along with the 16 bit instructions.

As someone already mentioned, MicroBlaze has an FSL interface for
hardware acceleration. It probably blows away Altera's custom
instruction.


"Kenneth Land" <kland1@neuralog1.com1> wrote in message news:<10b7qg7fqd1cod1@news.supernews.com>...

"Jon Beniston" <jon@beniston.com> wrote in message
news:e87b9ce8.0405251505.5b6713a8@posting.google.com...
snip

You say it like it doesn't matter. Maybe it doesn't with FPGA CPUs as
you're obviously not concerned about price anyway

Cheers,
JonB

Hard to imagine an embedded project without an fpga. Might as well have
only one chip (fpga + softcore cpu) and save the board space since you're
most likely going to require an fpga anyway. (board space == $$$, parts
count == $$$)

The reason you would want to use a softcore over hard is because it can be
*exactly* customized to any application. Need 27 serial ports and timers?
no problem. Need none? don't waste the pins or money. Need more
processing power? add custom instructions/external parrallel logic or
another softcore cpu (or 8!).

I've seen hard core projects fail, but a soft core project can only fail
from early abandonment. More/harder work can always find a solution,
because the hardware can become anything you're willing to realize.

Ken

 

[David Brown]

"E.S." <emu@ecubics.com> wrote in message
news:4KLsc.19641$zs2.4918@fe39.usenetserver.com...

Uncle Noah wrote:

In Microblaze there is no way to add your own custom instructions. It
is not an extensible processor but just provides the means to add
peripherals to a small SoC. Correct me if i am wrong. I just hope that
the tools (assembler, simulator, debugger) can be retargeted for the
new ISA. Or be able to use inline assembly with the new instructions.
The corresponding hardware should be built by some RTL description i
would give.

Sorry, but I think that "custom instructions" are the worst idea.
Than you have to update (with new versions/revisions) not only your
design, but also the whole toolchain ? (assembler/linker/cc ?)

The custom instructions are already available in the toolchain, with
pre-defined macros for the assembly instructions. When you want to actually
use them for something, you can define new names that make more sense in
your application. Gcc does a pretty good job of optomising such assembly
macros, so you don't lose anything. I don't know about Nios II (I haven't
looked in detail yet), but on the Nios I you can also tell gcc to use custom
instructions automatically for certain operations. For example, if you know
your code requires a lot of divisions, you can make a custom hardware
divider and tell gcc to use it for all divisions.

And there is still tha chance, that the whole CPU slows down, because
of your new instruction, so you even loose, not gaining anything

That would be the case if your custom instructions execute too slowly, so
that your cpu's max frequency were reduced. The obvious answer then would
be to use multi-cycle custom instructions.

Much simpler to access a "accelarator" memory mapped, or as a
peripheral, or whatever interface you have for it.

Sometimes that is the case - it depends on what you are doing. Memory
mapped peripherals require memory-style access, however, including loads,
stores and address calculations, whereas custom instructions get their data
immediately. For fast peripherals, custom instructions will save a lot of
overhead.

 

[David Brown]

"Stifler" <seannstifler69@hotmail.com> wrote in message
news:bf780a06.0405252226.60e2d1f0@posting.google.com...

Landman,

Also, custom instuctions are probably as stupid as a window register
file. Why do you need a custom instuction so bad? I believe it's
simply hardware acceleration. There's several ways to accomplish
hardware acceleration. Altera's custom instuction can bog down your
processor Fmax. It goes right into the middle of the pipe. Why not
simply have your processor launch off a separate process while it
continues to grind away at top speed?

I can think of several ways to stomp a custom instruction depending on
what it is. How about using a dual port ram and write a bunch of data
to it. Have my user logic attached to the other side and process it.
Tell me when it's done. Or, use a DMA to transfer a burst of data to a
user peripheral.

What's next, "My dad could beat up your dad" ? You are arguing about
something you aparently neither know about nor care about, so why bother?

I've got no idea about what an FSL interface is, having not looked closely
at the MicroBlaze, so I don't know how it compares to other solutions -
certainly not enough to declare it "stupid". But there are many ways to do
hardware acceleration of a soft cpu on an fpga, and there are many sorts of
tasks that could be accelerated - what is the big problem with Altera
offering one more? I'm sure it is possible to cause yourself problems by
using it badly, such as trying to do a slow process in a single clock cycle
and thus reducing your fMax, or stalling the processor for hundreds of
cycles - that's bad design on the user's part, not the fault of the custom
instruction concept. If your application calls for fast, simple custom
operations, however, then the custom instruction mechanism cuts down the
overhead quite significantly. You choose the hardware acceleration method
that matches the requirements.

Altera hypes this custom instruction crap. It's the same hype as the
windowed register file. It's the same joke. It's probably as stupid of
an idea as having a windowed register file. Which they just chucked.
Along with the 16 bit instructions.

Windowed register files have some advantages over traditional register
banks, and some disadvantages - and how they affect you depends on the
application. Sun's SPARC processors are good for some uses, and poor on
others. There are lots of choices when designing processors - register
setup and instruction formats are two of them. What makes the "best" design
will depend on many factors, such as application, speed, fpga size, fpga
design, code density - and it will also change over time, as the developers
come up with better designs, and as development tools improve. But just
because the Nios II is in many ways better than the Nios I, doesn't make the
Nios I suddenly "crap" or "a joke". When your favourite crisp manufacturer
comes out with a "new, even tastier" variety - does that mean that the old
type is suddenly terrible, and that the company should be condemed for ever
advertising it?

As someone already mentioned, MicroBlaze has an FSL interface for
hardware acceleration. It probably blows away Altera's custom
instruction.

Can you explain how it "blows away" custom instructions? I don't know what
the FSL interface is, so I can't compare them myself.

"Kenneth Land" <kland1@neuralog1.com1> wrote in message
news:<10b7qg7fqd1cod1@news.supernews.com>...
"Jon Beniston" <jon@beniston.com> wrote in message
news:e87b9ce8.0405251505.5b6713a8@posting.google.com...
snip

You say it like it doesn't matter. Maybe it doesn't with FPGA CPUs as
you're obviously not concerned about price anyway

Cheers,
JonB

Hard to imagine an embedded project without an fpga. Might as well have
only one chip (fpga + softcore cpu) and save the board space since
you're
most likely going to require an fpga anyway. (board space == $$$, parts
count == $$$)

The reason you would want to use a softcore over hard is because it can
be
*exactly* customized to any application. Need 27 serial ports and
timers?
no problem. Need none? don't waste the pins or money. Need more
processing power? add custom instructions/external parrallel logic or
another softcore cpu (or 8!).

I've seen hard core projects fail, but a soft core project can only fail
from early abandonment. More/harder work can always find a solution,
because the hardware can become anything you're willing to realize.

Ken

 

[rickman]

Kenneth Land wrote:

"Jon Beniston" <jon@beniston.com> wrote in message
news:e87b9ce8.0405251505.5b6713a8@posting.google.com...
snip

You say it like it doesn't matter. Maybe it doesn't with FPGA CPUs as
you're obviously not concerned about price anyway

Cheers,
JonB

Hard to imagine an embedded project without an fpga. Might as well have
only one chip (fpga + softcore cpu) and save the board space since you're
most likely going to require an fpga anyway. (board space == $$$, parts
count == $$$)

The reason you would want to use a softcore over hard is because it can be
*exactly* customized to any application. Need 27 serial ports and timers?
no problem. Need none? don't waste the pins or money. Need more
processing power? add custom instructions/external parrallel logic or
another softcore cpu (or 8!).

I've seen hard core projects fail, but a soft core project can only fail
from early abandonment. More/harder work can always find a solution,
because the hardware can become anything you're willing to realize.

Ok, how about an 8 bit CPU with an 8 input, 10 bit ADC and a brown out
detector? I think this costs less than $3 and comes in a 28 pin TSSOP
or a 5 x 5 mm QFN. MCUs often have advantages since they are typically
mixed signal chips, not just digital. It can be pretty hard to beat an
MCU with an FPGA when you need even just a little bit of analog.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX