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.
It will be interesting to see how it compares against the VexRiscv, an open source RISC-V CPU that's quite popular in the FPGA world with excellent performance (at ~1 Dhrystone MIPS/MHz it's roughly double that of the Nios V) for a very little resources.
An incomprehensible decision is to make the Nios V only support uncompressed 32-bit instructions. This is a CPU that will live inside an FPGA and that will often be paired with a single FPGA block RAM to store instructions and data. By not including 16-bit compressed instructions, they'll add some 30% bloat to the code.
A major negative of Intel's offering is that the Nios V is only available for the Pro version of Intel's Quartus toolchain.
The biggest benefit of the Nios V is that its debugger logic will seamlessly integrate with Intel FPGA's virtual JTAG infrastructure. This means that, as long as you stay within Intel's development ecosystem, embedded SW debugging should be a breeze. With other CPUs, there are additional hoops to make that work. (I wrote about that here: https://tomverbeure.github.io/2021/07/18/VexRiscv-OpenOCD-an...)
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.
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.
In semi-related news: Initial RISC-V KVM (think fast virtual machines) support for Linux has been pulled by the KVM Maintainer and queued for inclusion in the 5.16 release.
Does anybody have informed opinions about the future of RISC-V? The pace of development in the space seems frantic (though early) and the IP situation seems like it's ripe to eventually become a major force in processor ISAs.
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.
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 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?
It's a pretty smart decision for them. They save who knows how many millions/billions in supporting a very proprietary ISA and the resulting proprietary software stack.
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.
[+] [-] tverbeure|4 years ago|reply
It will be interesting to see how it compares against the VexRiscv, an open source RISC-V CPU that's quite popular in the FPGA world with excellent performance (at ~1 Dhrystone MIPS/MHz it's roughly double that of the Nios V) for a very little resources.
An incomprehensible decision is to make the Nios V only support uncompressed 32-bit instructions. This is a CPU that will live inside an FPGA and that will often be paired with a single FPGA block RAM to store instructions and data. By not including 16-bit compressed instructions, they'll add some 30% bloat to the code.
A major negative of Intel's offering is that the Nios V is only available for the Pro version of Intel's Quartus toolchain.
The biggest benefit of the Nios V is that its debugger logic will seamlessly integrate with Intel FPGA's virtual JTAG infrastructure. This means that, as long as you stay within Intel's development ecosystem, embedded SW debugging should be a breeze. With other CPUs, there are additional hoops to make that work. (I wrote about that here: https://tomverbeure.github.io/2021/07/18/VexRiscv-OpenOCD-an...)
[+] [-] JoachimS|4 years ago|reply
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.
[+] [-] ChuckMcM|4 years ago|reply
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.
[+] [-] torginus|4 years ago|reply
MicroBlaze, Xilinx's own big soft-CPU core was a combination of slow and large, with a buggy compiler to boot.
[+] [-] Dylan16807|4 years ago|reply
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.
[+] [-] brucehoult|4 years ago|reply
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.
[+] [-] tlamponi|4 years ago|reply
[0]: https://lore.kernel.org/kvm/82568eff-1eff-5e63-4264-ef0c25f7...
[+] [-] unwind|4 years ago|reply
[+] [-] bane|4 years ago|reply
[+] [-] audunw|4 years ago|reply
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.
[+] [-] mhh__|4 years ago|reply
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.
[+] [-] ansible|4 years ago|reply
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).
[+] [-] ksec|4 years ago|reply
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.
[+] [-] pjmlp|4 years ago|reply
Dreamers gotta dream I suppose.
[+] [-] cable2600|4 years ago|reply
[+] [-] geeB|4 years ago|reply
[+] [-] wyldfire|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] fucksamsung|4 years ago|reply
[deleted]
[+] [-] Ericson2314|4 years ago|reply
[+] [-] 0xTJ|4 years ago|reply
[+] [-] monocasa|4 years ago|reply
Also Intel's not intimidated by the gate count niche of classic five stage RISCs; they gave that market up decades ago.
[+] [-] vvikas01|4 years ago|reply
[+] [-] tux3|4 years ago|reply
[+] [-] JoachimS|4 years ago|reply
Given a clock and access to memory it will execute programs.
[+] [-] JoachimS|4 years ago|reply
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.
[+] [-] temp0826|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] lxe|4 years ago|reply
[+] [-] tverbeure|4 years ago|reply
[+] [-] marcodiego|4 years ago|reply
[+] [-] hajile|4 years ago|reply
[+] [-] tverbeure|4 years ago|reply
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.