Nios V – Intel's RISC-V Processor

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.

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.

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

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.

What I’ve seen is that a product is being designed with both ARM and RISC-V cores. The RISC-V cores outperformes the equivalent ARM cores and have no licensing costs. It’s used if it’s a management core not usually programmed by the customer or specialized low power and/or low latency processing. The ARM cores are used for TrustZone, FPU and DSP functionality and for the extensive IDE, debugging and trace support.

I can see RISC-V gradually taking over, since it now has a foot in the door. But it’ll take a long time and depends on third party development.

I'm optimistic but not particularly bothered as long as X86 goes the way of the dodo i.e. people have argued that ARM could be the better ISA for the processor in your laptop.

One thing that we will have to see about is whether the extension model they have now actually holds in the future e.g. will we see a high performance fork of RISCV in the future, or simply (say) a chinese-only company who don't particularly care using parts of the instruction encoding space for their own purposes.

In general it has a bright future. It is not nearly as revolutionary as, for example, the Mill CPU by Out Of the Box Computing, but it does have some refinements from all the lessons learned over the decades of ISA design.

As more designs get produced, there will be more and more pressure on the chip designers to stick to the published specifications, instead of going their own way. Why? Because everyone will want to just use the existing toolchains (GCC, LLVM, etc.) and not have to support proprietary extensions. It helps that the specs themselves are easily available.

The implementations that exist now are not at the leading edge of performance, but they are more than good enough for many applications. This will improve over time.

One of the best features of the ISA is the design for extensions... meaning that extensions were planned from the very beginning. Unlike other architectures, where often the ISA is designed to be "complete", and adding extensions inevitably becomes difficult, expensive (cost or run-time performance, or both), or complex (which slows adoption).

> eventually become a major force in processor ISAs.

In what market segment?

Will RISC-V win a substantial market shares in embedded / micro- controller usage? Very likely. It is sort of started happening already.

Will RISC-V wins over a substantial market in current x86-64 and ARMv8 segment. Highly Unlikely. I have seen zero argument or proposition that even make sense for this to happen. Other than people want it or certain country want it for whatever ideology reason.

I think people are too optimistic, even if it ever manages ARM adoption scale, nothing prevents OEMs to ship their RISC-V implementation with proprietary extensions.

Dreamers gotta dream I suppose.

Main challengers is the ARM CPU line. I can see China making RISC-V chips for Microwaves and TV sets and mobile devices.

My opinion is not informed, but from my point of view the opposite is true. It's been 10 years since the first specs and silicon, according to https://riscv.org/about/history/. And it seems that one has to go way out of their way to find RISC-V systems in the wild.

Just like Nios II, it's a processor. It doesn't have to be "hard" silicon. Calling it a "little FPGA program" seems very dismissive. I don't know what you mean by "1990 style".

I mean, it's a soft core like Nios I through IV. I know Altera would sell you a license if you wanted to dump it into a hard flow for some reason. I assume Intel will too? The Altera division seems fairly independent post acquisition.

Also Intel's not intimidated by the gate count niche of classic five stage RISCs; they gave that market up decades ago.

A processor design in a HDL like Verilog or VHDL is not really a "program". It is a textual representation of physical hardware configuration. Seeing it as a program is usually the the root of problems faced by amateur HDL designers.

It's a soft-CPU. It's not that it was designed 30 years ago, those just aren't meant to be deep and wide OoO cores.

It is not a program. It is a hardware design tuned to be efficiently mapped onto the primitives/resources in the specific FPGA fabric of the target devices. I'm fairly sure the actual source code is far from little. But the number of resources needed is quite low.

Given a clock and access to memory it will execute programs.

Could you elaborate on the "1990 style"? What do you mean?

Is it that it is a moderately pipelined, single issue, RISC like (explicit load/store, fixed width instructions, fairly large register file) CPU design? Why then, all RISC-V, ARM etc cores targeted for low cost embedded, IoT systems are 1990 style.

This is out of my realm, isn't it at least a little relevant to vet a (logical) design with an fpga before doing the full process? Or are those worlds things worlds apart?

They're heavily used in the Stratix 6,7,8 and 9 FPGA families.

I have no idea how you arrived at a millions/billions number.

The Nios II family has existed for years, with very little ongoing development. FPGA soft cores don't go above the ~1.5 Dhrystone MIPS per MHz because the increased complexity to go above the 5-stage pipeline doesn't play well with FPGA-style logic. The Nios II/f already occupied that space.