Nios II = Microblaze

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!

Reply to
Stifler
Loading thread data ...

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

Reply to
Ken Land

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

Reply to
Jon Beniston

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.

Reply to
Goran Bilski

Other user said:

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

Reply to
Uncle Noah
040105020401030703060100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit

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:

Reply to
Goran Bilski

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

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

Sure, but not all the time.

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.

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

Reply to
Jon Beniston

Is anyone actually doing this?

Cheers, JonB

Reply to
Jon Beniston

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.

Normally not.

But most of the time.

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.

Göran

Reply to
Goran Bilski

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.

Reply to
E.S.

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

Reply to
Ken Land

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

Heard before, but why in this context ?

Reply to
E.S.

Register windows.

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

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

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

Reply to
Jon Beniston

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.

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

Reply to
Jon Beniston

and

usefull

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

Reply to
Kenneth Land

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.

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.

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.

Reply to
David Brown

Likewise, this is the whole BLEEPING point of having a coprocessor interface: it gives you a separate pipeline for your instructions, etc etc etc, so you can have the advantages of a "custom" extention to your instruction set, without having it in the pipeline or even necessarily in the critical path...

Chimaera (a hard processor design with an in-the-pipeline reconfigurable unit for custom instructions) was, IMO, a failure compared to GARP (a hard processor design with a reconfigurable unit as a MIPS coprocessor, with its own specialized memory interfaces).

Yet Chimaera was a useful failure, an incredibly valuable negative result: showing just how little one could achive with in-the-pipeline custom instructions.

Especially since, for custom instructions, you are often dealing with large working sets (otherwise you don't really benefit in the first place), so having a coprocessor with its own optimized (eg, streaming, strided-streaming) memory access ports is a huge win over "in-the-pipeline" custom instructions.

--
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu
Reply to
Nicholas C. Weaver

OK, I got it. Thanks ;-)

But I wasn't even thinking about the NIOS MicroBlaze competition (?)

More along the lines, how I like to expand my processors. And my software guys are trying to kill me each time we invent a new instruction ;-)

Cheers

Reply to
E.S.

Microblaze (no grapes) - so you say "They are probably sour anyway")

You'd be treated better here! I'm more of a software guy, but I'd be very happy if my hardware guy took the initiative to add instructions to my NiosI/II!

Take care

Reply to
Kenneth Land

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.