Alternatives to NIOS

I'm surprised.

NIOS II should work quitte well with out any OS involved.

MicroBlaze should not work will in Altera arch. as it was designed and hand optimized for the Xilinx arch.

PicoBlaze may work well for you, but it is not really a processor, but more of a control store state machine (OK - a small processor)

Tell us all of your experiences so we all can get a little smarter.

Someone did already some stuff with Mico32 on altera.

I had this link somewhere, but it seems to be down at the moment :

https://roulette.das-labor.org/bzrtrac/wiki/soc-lm32 (https://roulette.das-labor.org/bzrtrac/wiki/soc-lm32)

Anyway, I do applications with my own hal and kernel, this released me a lot from the task of trying to keep up with the ever changing Altera stuff. Remember the days that Altera decided to not support the so called legacy design flow anymore... :mad:

Stefaan

--- Quote Start ---

I'm surprised.

NIOS II should work quitte well with out any OS involved.

--- Quote End ---

I didn't mean NIOS doesn't work well without an OS. I meant that NIOS seems to be designed for being efficient in big projects (where you would usually use an OS).

NIOS seems to be designed mainly for the /s and /f cores. I want a smaller processor. I want something with an area size similar to the /e core, but not at the expense of 6 clocks or more per instruction. This is almost ridiculous for RISC. It is, of course, just a consequence of NIOS being designed around a deep pipeline. Again, great for the bigger cores, but too bad for the /e core. A processor designed from the ground for a shorter pipeline would be much more efficient on small cores (but of course, not as much efficient as NIOS for bigger cores).

I think you have some misperception of a pipline. It's unavaidable to have a pipline, especially with FPGA technology. Without the pipline (wich is not so deep as you might think, 5 is about standard, the nios fast processor version has one more).

The deeper the pipline, the bigger the branch penalty...

The microsblaze has only 3 I think (not sure). Mico32 from lattice also 5 if I well remember.

Hower, you have the option for NIOSII to work without a pipline (the small versio). Then the speed is rather slow (~6 cycles per instruction).

All depends on what you really need, and what you define as an "free, ideally open-source soft-core". Like in my case, I started already many times to develop a 32 bit processor, but anytime I stop because I don't have the knowledge (and time) to do a port of gcc. The toolchain is most of the times the bottleneck, without a decent compiler you can't do anything.

Stefaan

there are many soft-cores available at opencores.org like AVR core or OpenRisc

altera ported openrisc 1200 to StratixIII device and it requires around 7000 LE, way too much compared to Nios' > 1000 LEs. so even for small control application with program less than 2KB, Nios seems to be tiny enough!

--- Quote Start ---

altera ported openrisc 1200 to StratixIII device and it requires around 7000 LE

--- Quote End ---

OpenRisc is not an attractive alternative to Nios. At least not to me.

I made some research and I couldn't find exactly what I wanted. FPGA soft-cores of standard off the shelf micros are usually not too efficient. Currently Lattice cores seems to be the best alternative.

I've never used Nios II, but from the technical specs it looks quite impressive. I think you'd be hard pressed to find a C programmable core that is significantly better.

That said, the license can be an issue which is why I have my own (GPL'ed) solution: A MIPS compatible 32-bit core (http://thorn.ws/yari). I'd love to see a performance comparison between it and Nios II, but I haven't yet taken the time to do it myself. It certainly won't satisfy the OP as it weighs in at ~ 7k LC, but performance was priority for YARI, not resource consumption.

Regards

Tommy

One major problem for using alternate softcores, is that there is no smooth way to do JTAG debugging.

If you are restricted to documented interfaces, the only way to do JTAG debugging, is using TCL scripting. It might be feasible to run a debugger that would create TCL scripts on the fly, invoke a quartus executable, and parse the results. But this is hardly usable and would be extremely slow.

You can implement a JTAG debugger using some already reverse-engineered interfaces. But you still wouldn't be able to run the debugger concurrently with other Altera Jtag tools, such as Signal Tap.

This is too bad. I wonder if Xilinx also has so many undisclosed JTAG aspects.

Wow what a strange complaint. I have designed processing cores and you can't get the performance without the pipeline. So you can either sacrifice the performance and use the /e core or you can accept the resource usage of the higher performance cores.

None of my designs to date have used an OS. I tend to burden the processor with a lot of control and communication logic that would be extremely time consuming and even impossible to implement in firmware. The processor has become a critical component in my designs. As such I have no problem sacrificing a small percentage of the chip to it. I get way more functionality per gate from the processor than any other piece of firmware. My firmware exists to perform time-critical functions that are impossible to do in a processor.

Even the /s and /f cores are pretty small. That fact that you don't find these sizes acceptable would indicate that you are not going to use the processor for much (not getting your value). If you're not going to use the processor for much then why not just implement the needed functions in firmware. Or add a hard micro-controller to your board and interface it with the FPGA. The price/gate for the NIOS is very reasonable. Throw in all of the ease-of-use issues and the NIOS is a no-brainer.

Jake

--- Quote Start ---

Wow what a strange complaint. I have designed processing cores and you can't get the performance without the pipeline.

--- Quote End ---

I didn't complain about the pipeline. All I said about the pipeline, is that its depth has a devastating effect on the /e core. The /e core seems to implement all the pipeline stages, but in a sequential, non-pipelined way.

That was a sample to make the point that NIOS is designed to be efficient for the /f and /s cores, not for the /e core. I wasn't complaining. I realize that is the best solution for most cases.

I just was hoping I could find something else designed from the ground for a smaller size. But seems there is no such a thing. Everybody targets high-performance cores such as Nios, or tiny 8-bit softcores such as PicoBlaze or Mico8. Nothing in the middle.