Questions about using NEORV32 Core

[DS-567]

Hi there

I am trying to select a RISC-V softcore CPU for our research project involving fault injection on embedded processors, and considering using this Neorv32 core. It seems to have great documentation and appears easy to use, but I have not tried it yet. I have a few questions if you have a chance to help me out.

1. Can this core be simulated/programmed for Xilinx and Intel devices using Vivado and Quartus ModelSim respectively? Has it been proved on both hardware/software platforms?

2. We require to be able to write C code for the core, run simulations to gather core data and write it to a file (i.e. reg values, PC values, ALU data). We then want to be able to inject faults into the HDL code and produce the same text file so we can compare how the core behaves under faulty conditions. Does this sound like something the Neorv32 is able to do easily?

3. It mentions that the core has been designed with safety in mind. Are these fault handlers that are in the core design typical of all RISC-V cores, or just this design? I.e. will this affect the data we gather from faults injected into just this core that won't be typical of RISC-V cores out there?

4. What is the simplest way for a beginner to set up a simulation of a basic neorv32 core doing something simple like the blink led?

Thanks in advance for any help.

[stnolting]

Hey there!
Sounds like a really interesting project! 👍

Can this core be simulated/programmed for Xilinx and Intel devices using Vivado and Quartus ModelSim respectively? Has it been proved on both hardware/software platforms?

The core has been synthesized for Xilinx, Intel and Lattice FPGAs (plus some additional FPGAs from smaller vendors) and has been simulated using commercial (e.g. Modelsim) and open source (e.g. GHDL) simulators. You can find some pre-configured (community-based) setups for different platforms and toolchains in neorv32-setups.

We require to be able to write C code for the core, run simulations to gather core data and write it to a file (i.e. reg values, PC values, ALU data). We then want to be able to inject faults into the HDL code and produce the save text file so we can compare how the core behaves under faulty conditions. Does this sound like something the Neorv32 is able to do easily?

The software framework including the "drivers" / hardware abstraction layer is entirely based on C and documented using doxygen: https://stnolting.github.io/neorv32/sw/files.html

For dumping data: there is a "simulation" mode provided by the processor's UART that allows to output application data right to the simulator's console (-> "Simulation mode" in https://stnolting.github.io/neorv32/#_primary_universal_asynchronous_receiver_and_transmitter_uart0). This also allows to dump plain application data by writing 32-bit values to a text file. For example, this feature is used by the RISCOF-based ISA compatibility check to output the test final results (-> neorv32-riscof).

The VHDL rtl code (-> https://github.com/stnolting/neorv32/blob/main/rtl/core/neorv32_uart.vhd#L597) could be replicated inside the CPU to output "architectural state" data like pipeline buffers, ALU results and other intermediate signals.

It mentions that the core has been designed with safety in mind. Are these fault handlers that are in the core design typical of all RISC-V cores, or just this design? I.e. will this affect the data we gather from faults injected into just this core that won't be typical of RISC-V cores out there?

The RISC-V spec. does not require n implementation to actually trap when - for example - an illegal/malformed instruction word gets executed. However, the NEORV32 was designed to ensure that all illegal instruction are identified as such and that all bus/memory accesses are checked for timeouts and proper acknowledges.

What is the simplest way for a beginner to set up a simulation of a basic neorv32 core doing something simple like the blink led?

The project's user guide is the right place to get started. We have simplified system wrappers available (rtl/processor_templates) for creating small setups just to try things out. There is also a section about running a "quick" simulation: https://stnolting.github.io/neorv32/ug/#_hello_world

[stnolting]

I will update the according sections of the user guide.

[DS-567]

No problem at all, thank you 😀. Seems like a really great project you have put together here.

Also I have wrote my own simple C code for the neorv32 and it works perfectly. Which IDE platform do you recommend using to write C code for the neorv32? I am guessing it doesn't matter as the complication is done using the terminal and not within an IDE?

[stnolting]

I prefer using a standalone editor and the console 😅 but I know that some people are using Eclipse, where they just import the NEORV software framework (makefile, HAL libraries, ...). Seems like such a setup is not to complicated.

[stnolting]

Seems like a really great project you have put together here.

Thank you very much!

[DS-567]

Stephan, when installing executables from C code directly into IMEM on the FPGA during synthesis, is there a way to have an assembly file generated alongside the .vhd application file? So we can see what riscv assembly instructions are being performed by the neorv32 cpu during operation from the user C code?

[GideonZ]

Hi DS-576, The assembly instructions can be seen in different ways. You can have the compiler generate the assembly LIST file, for example by adding ***@***.***"* to your makefile, or to your command prompt when invoking GCC. Another option is to disassemble the executable (.elf) file by using objdump. You can use the *riscv32-elf-unknown-objdump -d* command to do this. Best regards, Gideon Message ID: ***@***.*** com>

…

[stnolting]

I am not familiar with this specific board. Most FPGA boards use the USB-JTAG bridge for FPGA programming only, so the JTAG signals are not accessible by the actual user logic...

It might be possible to add the NEORV32 JTAG Tap to the FPGA's JTAG chain FPGA-ibternally by using some primitive (BSCAN?) but I have never tested that.

However, using an external JTAG adapter seems to be the simplest option here.

[stnolting-ims]

https://docs.xilinx.com/r/2021.1-English/ug953-vivado-7series-libraries/BSCANE2

[DS-567]

Hi again Stephan, I apologise for bothering you so much. The documentation is brilliant, I am just not all that familiar with some of these concepts and hardware.

You mention in the user guide that the FT2232H-56Q Mini Module device can be used for JTAG communication between FPGA and PC. The Basys3 seems to have a breakout for JTAG on the board through the JTAG header J5, as shown in the diagram below. If this works, how do I map these pins on the JTAG header to the neorv32 top level JTAG I/Os? I am correct in saying that you can only use specific pins for JTAG that the board manufacturer has ran out to headers or connectors for this?

Also when using the on-chip debugger to view the core during operation and we place breakpoints and read register values, does this actually change the processors control flow? Is the program counter (PC) register for example affected by using the on chip debugger?

[stnolting]

Hi again Stephan, I apologise for bothering you so much. The documentation is brilliant, I am just not all that familiar with some of these concepts and hardware.

No worries. I am happy to help. :)

The Basys3 seems to have a breakout for JTAG on the board through the JTAG header J5, as shown in the diagram below. If this works, how do I map these pins on the JTAG header to the neorv32 top level JTAG I/Os? I am correct in saying that you can only use specific pins for JTAG that the board manufacturer has ran out to headers or connectors for this?

I think this JTAG pin header just gives access to the signals from the USB-JTAG bridge (so you use an external adapter to program the FPGA).

The FPGA has dedicated programming pins (for the JTAG interface). As far as I know, these pins have a fixed function and cannot be used for the user logic. However, you can always route the NEORV32 JTAG signals to any user IO and connect an external JTAG adapter.

Also when using the on-chip debugger to view the core during operation and we place breakpoints and read register values, does this actually change the processors control flow? Is the program counter (PC) register for example affected by using the on chip debugger?

This is a complex question 😅 The NEORV32 on-chip debugger uses the "execution based debugging concept" (see page 99, appendix A.2 of docs/references/riscv-spec.pdf). This concept does not "freeze" the CPU when the debugger takes over control, it rather allows the debugger to run programs on the CPU. This happens transparently for the user as the "logical state" of the application being debugged is not altered.

[DS-567]

Thanks, I will give this a go 👍.