Adding Custom On-Chip Hardware Alongside Neorv32

[DS-567]

Hi Stephan,

Would really appreciate your help on this if you get a chance. I am injecting faults into Neorv32 while it is running some various simple algorithms and it is going well so far. But I would now like know if the faults are causing the algorithm to produce errors or cause the Neorv32 to crash etc. Currently the algorithm runs and I extract some data from inside Neorv32 (program counter etc).

Now however I need Neorv32 to store the result from a number sorting algorithm for example somewhere where I can access the numbers to check for correctness with my own hardware all on chip. By default this data will be computed and stored in DMEM so should be able to use load/store instructions to move it somewhere else like custom hardware for example.

So it seems I could use:

1. The Custom Functions Subsystem (CFS) and just write my computed data to memory mapped registers quite easily with a bit of software on the Neorv32 side. I assume I can then make these registers visible to my own custom RTL modules to read anytime? Seems like a good idea as the software framework supports easy C functions to write and read to/from these registers?

2. Or the wishbone interface. Is this an option too or is the CFS a better idea?

What is your opinion?

Thanks in advance!

[stnolting]

Hey @DS-567!

How much data do you want to store? Is this data access/evaluated by the core itself or by some custom hardware module?

From a functional point of view both of the concepts you mentioned would do the job. The CFS, however, can address up to 256 bytes (when not using some FIFO-based / pointer-like access mechanism). Wishbone-coupled devices are not limited and can occupy an address space of up to 4GB.

[DS-567]

You could assign fixed addresses for all the arrays in your C code. But together with the rtl mods the setup would get less and less maintainable... 🙈😅

Yeah I know what you mean, it will become a mess and easy to make setup mistakes. I will have a think about that.

Do you mean the times it takes to configure the DMA or the actual data transfer time?

The actual time taken to transfer the data from DMEM to my custom RAM with the DMA. As I have to wait some time on this as I don’t know when the DMA transfer is done.

100 clock cycles per word? Maybe less?

[stnolting]

If there is no bus congestion and if your external memory odes not have any additional latency then transferring one element (byte or word, doesn't matter) takes about 5 clock cycles.

[DS-567]

If there is no bus congestion and if your external memory odes not have any additional latency then transferring one element (byte or word, doesn't matter) takes about 5 clock cycles.

Perfect, this is working fine 😁.

   // setup XIRQ
  neorv32_xirq_setup();
  neorv32_xirq_channel_enable(0); // trigger = XIRQ input 0

In the above code you have given for the interrupt triggering the DMA, can the software for setting up / enabling the external interrupt requests also be done in hardware like I am doing with the automatic DMA transfer instead of having to do it inside the main() function?

asm volatile ("fence"); // make sure main memory is sync with d-cache

Also can this line be removed or what does it do exactly?

[stnolting]

In the above code you have given for the interrupt triggering the DMA, can the software for setting up / enabling the external interrupt requests also be done in hardware like I am doing with the automatic DMA transfer instead of having to do it inside the main() function?

In theory this should work. Just enable the according channel right during the reset pulse:

neorv32/rtl/core/neorv32_xirq.vhd

Line 96 in dc15beb

irq_enable <= (others => '0');

But beware, this is not the intended functionality and I have never tested that 😅

asm volatile ("fence"); // make sure main memory is sync with d-cache

Also can this line be removed or what does it do exactly?

Where did you find that? fence flushes/reloads the data cache. If the data cache is not implemented/enabled then this instruction has no effect and can be removed.

[DS-567]

In theory this should work. Just enable the according channel right during the reset pulse:

This seems to work actually. I have removed all software for the interrupts and just made the RTL change to just enable the irq channel used (8 in my case), and the dma transfer still appears to trigger 🤷‍♂️😂.

Where did you find that? fence flushes/reloads the data cache. If the data cache is not implemented/enabled then this instruction has no effect and can be removed.

I think it was in the dma example. I can remove as the d-cache is not enabled in my design. Thanks

Basically, yes 😅 You would just need to adjust the reset value of all the configuration registers:

This is also working now 😁. I have no software for interrupt or DMA setup/trigger. The RTL changes you advised seemed to work well. Thanks Stephan!

[stnolting]

Great to hear! 👍

[DS-567]

Hi again Stephan,

However, after you have triggered the DMA operation just wait for some time before you start reading out your data.

Just a couple of quick questions:

1. Can the engine.done signal in the neorv32_dma.vhd RTL file be used to produce a DMA automatic transfer done flag that I could read instead of just waiting some time. Can the engine.done signal get asserted if the transfer encounters an error like the interrupt output seems to do?

2. When observing the engine.done and engine.busy signals on ILA, it seems that the DMA is continuously being triggered instead of just triggering and executing its operation once after the interrupt. The interrupt only gets generated once but the DMA seems to keep getting 'triggered'? Would this be because the interrupt pending isn't cleared in any software or what could cause this?

The images below shows a successful DMA transfer completing (writing 25 to my RAM location at address 24) and the second one zooms out showing this operation appearing to repeat infinitely.

Image One (This is one successful DMA operation)

Image Two (See the engine done/busy signals toggling)

*Note, dma_transfer_done is a custom output I added to neorv32_dma module and it is just assigned the engine.done signal.

[stnolting]

Can the engine.done signal in the neorv32_dma.vhd RTL file be used to produce a DMA automatic transfer done flag that I could read instead of just waiting some time. Can the engine.done signal get asserted if the transfer encounters an error like the interrupt output seems to do?

From a software point of view you can read the DMA's control register and check the DMA_CTRL_BUSY bit to find out if the DMA is idle (again). However, there is currently no flag to check if a pre-configured transfer has been completed. But I think this would be a nice feature we could add?! 🤔

From a hardware point of view you can check the DMA's interrupt output. This signal will be high for one clock cycle when a transfer has been completed.

neorv32/rtl/core/neorv32_dma.vhd

Line 54 in 97859da

irq_o : out std_ulogic -- transfer done interrupt

When observing the engine.done and engine.busy signals on ILA, it seems that the DMA is continuously being triggered instead of just triggering and executing its operation once after the interrupt. The interrupt only gets generated once but the DMA seems to keep getting 'triggered'? Would this be because the interrupt pending isn't cleared in any software or what could cause this?

Hm, this should not happen... The automatic transfer mode gets triggered on a rising edge of the enabled interrupt source. Maybe you have multiple sources enabled? What is your reset-configuration of the FIRQ mask?

neorv32/rtl/core/neorv32_dma.vhd

Line 140 in 97859da

config.firq_mask <= (others => '0');