5 ms·

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),

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-and-Traps.html https://tomverbeure.github.io/2021/07/18/VexRiscv-OpenOCD-an...)

ChuckMcM 5y ago
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.
- tverbeure 5y ago
  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.
  - ChuckMcM 5y ago
    Fair enough, I've been playing around with Litex which puts the Xilinx soft processor tools to shame.
Dylan16807 5y ago
> 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.
- tverbeure 5y ago
  Section 5.3 of the Nios V Quickstart Guide (https://www.intel.com/content/www/us/en/programmable/documentation/jmv1629188568604.html#fyy1630546382179 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?
  - Dylan16807 5y ago
    > 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/documentation/lae1629183268014.html https://www.intel.com/content/www/us/en/programmable/documen... https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ds/ds_nios2_perf.pdf https://www.intel.com/content/dam/www/programmable/us/en/pdf...
- drmpeg 5y ago
  > And what's with CoreMark? The Nios V core is RV32IA. No multiplier.
torginus 5y ago
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.
- rkangel 5y ago
  > 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.
- brandmeyer 5y ago
  > 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.
JoachimS 5y ago
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 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.
brucehoult 5y ago
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.

ChuckMcM 5y ago

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.

tverbeure 5y ago
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.
- ChuckMcM 5y ago
  Fair enough, I've been playing around with Litex which puts the Xilinx soft processor tools to shame.

Dylan16807 5y ago

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

tverbeure 5y ago
Section 5.3 of the Nios V Quickstart Guide (https://www.intel.com/content/www/us/en/programmable/documentation/jmv1629188568604.html#fyy1630546382179 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?
- Dylan16807 5y ago
  > 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/documentation/lae1629183268014.html https://www.intel.com/content/www/us/en/programmable/documen... https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ds/ds_nios2_perf.pdf https://www.intel.com/content/dam/www/programmable/us/en/pdf...
drmpeg 5y ago
> And what's with CoreMark? The Nios V core is RV32IA. No multiplier.

torginus 5y ago

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.

rkangel 5y ago
> 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.
brandmeyer 5y ago
> 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.

JoachimS 5y ago

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

brucehoult 5y ago

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.