Experiences with Microblaze and Nios

Hi All,

In my work, I develop high speed counting and measuring systems. Our systems typically use FPGAs for high speed digital logic and a microcontroller for control and calibration. To reduce costs, power and space, I have been looking at the idea of implementing the microcontroller function into the FPGA using either Microblaze or Nios. Does anyone have experience with these two products? Have you used them in a commercial product? Are these IP cores and the software to implement them mature enough to be practical and reliable? How good is the software development environment for code that runs on the synthesized microcontroller. Do it include breakpoints, single stepping and examination of register and memory variables? I would like to hear anyones experience with Microblaze and Nios.

Thanks, Bob Davis

Reply to
Robert Davis
Loading thread data ...

memory

well I am doing exactly this kind of system with MicroBlaze, special cores and peripherals to take care of high speed and Microblaze doing the rest.

so what I can say (applies to Xilinx ISE /EDK Microblaze)

  • useable yes
  • development environment, useable actually version 6 quite good
  • break points single stepping all is available

you can write custom peripheral cores, and custom logic cores integrate it into the MicroBlaze system and then use it as super-component in toplevel normal FPGA design. You change some C source, compile and merge with bitstream download run debug. It all works. A nice thing is also ChipScope logic analyzer - you can use it also in MicroBlaze design, at the moment I only use the logic analyzer cores in toplevel only but should also be possible to use them inside the MicroBlaze system (or use special OPB Bus Analyzer core). another nice thing is that all this could be done over JTAG port only so if nothing works except JTAG port you can get the MicroBlaze working and examine the program, peripherals, etc..

As of NIOS I assume pretty similar things should be possible as well but I can not comment as so far all attempts to install NIOS license have been failed :(

One BIG comment - dont expect always a cost reduction, both MB and NIOS take up FPGA resources and in most cases they need external memory so the cost is relative - if your FPGA is already relativly large then having MB/NIOS is probably very cheap as it takes small % of the FPGA, if your current FPGA is small then adding MB/NIOS would require larger FPGA, possible BGA package, more complex PCB board, etc..

probably a cheapest MB solution is XC2S300E + 16 Bit Flash memory + XC9536XL that downloads the bitstream into FPGA and serves as main code memory later.

smallest Xilinx FPGA that is reasonable for MB useage is Spartan 200 (minimal system fits int XC2S100 too, but almost no peripherals).

NIOS has more options to choose, some of them should have lower resource need than MB so it could be cheaper in relative FPGA resource terms.

Optionally you can use some other more suitable FPGA processor for your system, something that uses less resources.

antti xilinx.openchip.org

Reply to
Antti Lukats

Thank you Antti. You have given me a lot of useful information. We currently use the XC2S200, but I am looking at moving to a larger part, maybe a Spartan 3 when the becomes available. Anyway thanks again. Can any one else share your experience with Microblaze or NIOS.

RKD

microcontroller

have

development

it

cores

FPGA

download

you

if

failed

FPGA

XC9536XL

later.

Reply to
Robert Davis

Hi Robert,

Antti's golden rule #1 (for MicroBlaze) its 50% of XC2S200 :)

I forgot to mention that the most valuable resource is RAM space, when you dont have external RAM (only external ROM) then the internal BRAM space is almost minimal (even after playing with linker scripts). In case of XC2S200 or XC2S300 you only have 4KB read write section. Situation would be much better in Spartan3, with more onchip RAM.

I wrote some small post about Selecting FPGA for MicroBlaze (xilinx.openchip.org, choose MicroBlaze forum)

For you if you can use external ROM _and_ RAM or external RAM and some option for initial download of programe code into it you are much safer than using only external ROM (and BRAM for read write).

Antti

PS time to learn is also $$$ I could foreseen that you can easily waste more then 2 weeks setting up linker scripts. (I spent more).

any

and

microcontroller

Reply to
Antti Lukats

Hi Bob,

I have been using Nios with great success in a product destined for commercial use. The tools are fairly mature. Nios is instantiated within Altera's SOPC Builder, which automatically builds a interconnect fabric so that Nios can talk to whatever on-chip/off-chip peripherals you like. Nios comes with GNU tools including a GUI debugger. The debugger does all the things you mention. It runs in emulation though and is therefore a little slow on my system. It also has the OCI debug core which I have not used. I do not use an IDE for development, I'm in the dark ages in that respect, writing my programs in Vim, etc.

Altera just announced Nios II, which I would consider for future designs. I hear it is coming with a nice IDE.

-- Pete

Reply to
Peter Sommerfeld

My experience is solely with microblaze - porting the uClinux kernel (you can read all about it at

formatting link
so I can't really comment on NIOS.

WRT microblaze, it too uses a gcc-based toolchain for software development (including gdb and Insight graphical front end for debugging), and command line tools to assemble the hardware system (processor, buses, peripherals etc). These tools integrate with the standard Xilinx synthesise and implementation tools.

There is a GUI/IDE bolted on the front of this, if that's more your style. I do all my development (software and hardware) at the command line, but I find the GUI useful for generating system "templates" which I then specialise according to my needs.

Currently the EDK (embedded development kit) only runs on Windows and Solaris, but as of 6.2 (due in a few months), Linux should be supported through the entire flow.

Personally I think that microblaze is a very sleek little processor - it is very tightly targeted to the xilinx fpga technology. Running systems at 100 MHz is common, and up to 125MHz is possible under certain conditions and on certain devices. Instruction and data caches (using Xilinx BRAM cells) improve performance dramatically.

The instruction set is very RISC, and easy to write. The gcc-based toolchain is complete, and largely bug free (I've found more than a few for them in the last 12 months!). The tools (both h/w and s/w) improve significantly with each successive release.

Microblaze has a very cool little feature called FSL - fast simplex links. These are unidirectional, point to point buses (really just data pipes), with built-in FIFOs, that bolt right into the heart of the processor, with direct register access. The hardware interface is also very simple, so these are great for applications that require streaming data, and when you don't want the full weight of a 32 bit address + data bus.

FSL is a bit of a sleeper - people haven't really caught on to it yet, but when they do it will have a great impact. I note recently that Antti has posted about his experiences with FSL, and he's caught the bug too!

One final comment I will make, and I expect this applies equally to NIOS, is that the tools make a great effort to protect you from what is, underneath it all, a very complicated process. I've learned this recently when trying to do some things off the beaten path.

The implication is that if you want to step outside the boundaries of the anticipated development flow, you must be prepared to do the hard yards to get there.

I expect that 95% of users are perfectly well served by the pushbutton approach. For the other 5% - well, there's always this newsgroup!

Hope this is useful to you.

Regards,

John

Reply to
John Williams

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.