Hacker News Reader

The Nios II is quite old. When II/e was designed you had basically the PicoBlaze as competition. In comparison the Nois II/e SW can be compiled using gcc and have less constraints on code size.

The point of these very small CPU cores is basically as a flexible state machine that can be updated (inlcuding fix bugs) in the control path. In a big FPGA design you can have tens, hundreds of them inside larger cores. So worst in terms of performance, but far from worse in terms of functionality, power consumption, flexibility in comparison with complex FSMs.

Today you could use a number of RISC-V implementations (the SERV for example is really tiny: https://github.com/olofk/serv) or other soft CPU cores.

But the Nios was really great when it came, esp Nios II, which removed the issue of having to use different tool chains for the compact, large version was very useful. You can easily extend the ISA, connect co-processors, had a clean interface to the rest of the design. And as long as you used Altera FPGAs free as in beer.

In large systems such a 3G, LTE base station there can be thousands of Nios II cores. They have (are) used in automotive and provides hard real time control.

Yeah, this was weird: A major negative of Intel's offering is that the Nios V is only available for the Pro version of Intel's Quartus toolchain.

I mean people can import the VexRISCV verilog and get a faster and better chip for "free" so where does Intel think the value add is here? It is quite curious.

Now it would be interesting if they made hard-logic versions to compete with say the Cortex-M series from ARM or something but this seems like it isn't in the cards.

If the middling performance and lack of compressed instructions aren't an issue, then the automatic BSP generation, the Platform Builder integration, and the debugger ease of use can be a pretty strong arguments. The Nios II/e was good enough for many slow control tasks.

Fair enough, I've been playing around with Litex which puts the Xilinx soft processor tools to shame.

I'm not quite certain what's the use case for most soft CPU's on FPGA-s. My experience is from the other side (Xilinx) and it's more than half a decade old, however looking at stuff it doesn't seem to me that things have changed that much. What 2 useful CPU designs I used were the PicoBlaze, a bespoke microcontroller with a weird architecture designed to take advantage of FPGA implementation details, and was ridiculously tiny, like a RAM block + a few slices worth. The other one was the ARM Cortex A9 core physical core on the Zynq FPGA.

MicroBlaze, Xilinx's own big soft-CPU core was a combination of slow and large, with a buggy compiler to boot.

> I'm not quite certain what's the use case for most soft CPU's on FPGA-s.

They are used for state machines and control algorithms that are complex enough that you don't want to implement them in HDL. High-speed interface (eg, DDR4, high-speed ADC) initialization and training is a common example.

> MicroBlaze, Xilinx's own big soft-CPU core was a combination of slow and large, with a buggy compiler to boot.

Agree, but Xilinx now basically put 2+ ARM cores in everything which solves the problem extremely well.

> Intel compares the performance to a Nios II/e (it's 4x faster!), but at 6 cycles/instruction, no multiplier, one bit per clock shifter (IOW: no barrel shifter), the II/e is about the worst little CPU you can imagine.

Okay, let's do a better one.

On a stratix 10:

II/e uses 414 units, II/f uses 1006 units, and V/m uses 1580.

II/e gets .107 DMIPS/MHz, II/f gets .753, and V/m gets .464.

Coremark for II/e is 19, for II/f is 229, and for V/m is... only 16?

II/e runs at 320MHz, II/f at 300MHz, and V/m at 362MHz.

Overall, not looking great for the cost, but if you really want RISC-V I'm sure that has value.

And what's with CoreMark? I do notice they gave the II/f a big cache for that test.

Section 5.3 of the Nios V Quickstart Guide (https://www.intel.com/content/www/us/en/programmable/documen...) has a waveform of the instruction AXI bus.

I think the memory system in that example has a 3 cycle memory access latency, and the CPU waits for one instruction to arrive before requesting the next one. I'm almost surprised that they manage 0.464!

The Coremark score doesn't make any sense indeed. Where did you find these numbers?

> I think the memory system in that example has a 3 cycle memory access latency, and the CPU waits for one instruction to arrive before requesting the next one. I'm almost surprised that they manage 0.464!

I'm sure the 4+2KB of cache helps.

> Where did you find these numbers?

https://www.intel.com/content/www/us/en/programmable/documen...

https://www.intel.com/content/dam/www/programmable/us/en/pdf...

That seems unbelievably large for V/m. A VexRISCV using 352 Cyclone V ALMs gives 10% better dhrystone than V/m, and a configuration using 1764 ALMs gives you 1.2 DMIPS/MHz, I and D caches, branch prediction, Supervisor mode, MMU -- full Linux kernel capability.

> And what's with CoreMark?

The Nios V core is RV32IA. No multiplier.

It's that big and they didn't put even a small multiplier in, let alone try to grab a hardware unit? Jeez.

Yeah that's really terrible. And you need a Quartus Pro license to boot? Woof.

C extension saves code size, but the C decoder uses LUTs so on a small program you can lose overall by implementing C.

If you assume that you're trading LUTs for LUTRAM at 4 bits per LUT then each instruction that uses C saves 16 bits or 4 LUTs. If half the instructions in the program can use C then you can save about 2 LUTs per instruction by implementing C.

If it takes 200 LUTs to implement C (that might be a little low?) then your program code needs to have 100 instructions before you even start to win.

I'd imagine a lot of places where you're replacing something that could almost be a state machine would use smaller programs than that.

Some popular small RISC-V cores don't implement C, and I think all the others give you the choice.

I'm not familiar with Intel's FPGAs but Google suggests "M9K" is the unit of block RAM across at least some of their range. That's 8192 bits or 1 KB. The RV32I [1] register set is 128 bytes. A lot of things wouldn't need any additional state, leaving 896 bytes for code -- 224 instructions without C, maybe 300 with C. If you're under 224 instructions then there's no point implementing C.

[1] you can save 64 bytes of registers by using RV32E. Tests using Embench show, IIRC, up to a 30% code expansion by using RV32E due to register spills and reloads. So even with 1 KB total space for registers+program+RAM that might be a net loss. Or your code might not expand at all. RV32E does save interrupt latency / thread switch time. You're probably not doing either of those.