Neorv32 AXI-Lite Interface

[Giorgio122]

Good morning @stnolting ,
I am trying to interface the neorv32 with a custom external interface. The simplest approach, for now, would be to attach it externally via AXI-Lite, using the custom neorv32 ip provided through the user guide, as can be seen from the image below.

First of all I want to ask if it is possible to directly attach the neorv32 to the module directly (since the external device has an AXI-LIte interface), but from what I have read from the documentation this should be the correct way, right?
And another question is related to how I can control this interface. In particular, I have read from the documentation that the XBUS is not memory mapped but any memory access done to a "void" address is referred to this interface. However, am I able to control it via software right? But how to do so? Because I have to send specific commands and instructions to the external modules but I'm not sure how I am able to communicate with it.
Thanks in advance!
best regards,
Giorgio

[stnolting]

Hey @Giorgio122!

First of all I want to ask if it is possible to directly attach the neorv32 to the module directly (since the external device has an AXI-LIte interface), but from what I have read from the documentation this should be the correct way, right?

This might be possible. However, I highly recommend to use an AXI interconnect in between as that module will handle all the address mapping.

And another question is related to how I can control this interface. In particular, I have read from the documentation that the XBUS is not memory mapped but any memory access done to a "void" address is referred to this interface. However, am I able to control it via software right? But how to do so? Because I have to send specific commands and instructions to the external modules but I'm not sure how I am able to communicate with it.

Well, the XBUS is memory mapped, but not to a specific address. All load/store operations that do not match any of the internal address regions will be redirected to the XBUS. For example, the address 0xC0000000 is not used by any of the internal modules (except you have a very large DMEM configuration). Hence, when you access this address the memory request will be forwarded to the XBUS and thus to the AXI-Lite port.

In a very simple version you can just use the provided functions for accessing memory on a very low level:

void neorv32_cpu_store_unsigned_word(uint32_t addr, uint32_t wdata);
uint32_t neorv32_cpu_load_unsigned_word(uint32_t addr);

See the according Doygen documentation:

• https://stnolting.github.io/neorv32/sw/neorv32__cpu_8h.html#a173bb06b4ae9c8964469068dafcb7b0e
• https://stnolting.github.io/neorv32/sw/neorv32__cpu_8h.html#a3b6cf445e2136486564ef3d3473c91dd

However, it is much more convenient to use a custom struct that represents your module's register layout and "map" that as a pointer to the base address of your module. This is also the style that is used for all the processor-internal memory-mapped peripherals, for example:

neorv32/sw/lib/include/neorv32_gpio.h

Lines 25 to 34 in 89d0f9d

	/** GPIO module prototype */
	typedef volatile struct __attribute__((packed,aligned(4))) {
	const uint32_t INPUT_LO; /**< offset 0: parallel input port lower 32-bit, read-only */
	const uint32_t INPUT_HI; /**< offset 4: parallel input port upper 32-bit, read-only */
	uint32_t OUTPUT_LO; /**< offset 8: parallel output port lower 32-bit */
	uint32_t OUTPUT_HI; /**< offset 12: parallel output port upper 32-bit */
	} neorv32_gpio_t;
	/** GPIO module hardware access (#neorv32_gpio_t) */
	#define NEORV32_GPIO ((neorv32_gpio_t*) (NEORV32_GPIO_BASE))

[stnolting]

I suggest to use two ILAs: one for the bus from NEORV32 to the interconnect and another ILA to track the communication between the interconnect and your module. Then you can use the bus explorer program to manually trigger a single access that was causing the error and inspect the response signals of the two AXI busses.

[Giorgio122]

Brief update regarding this problem. While I was trying to implement the ILA (Unfortunately the design is quite big and I encountered some timing problems), I did some other tests. What I found out was a strange behaviour. In particular, I saw that the errors reported above are experienced only after 3 or 4 times the program was executed. What I mean is, I implemented the processor with the bootloader, then I started uploading and executing the program one time. Everything was working. Then I adjusted the code, compiled it again, resetted the processor and restarted again. After 3 or 4 times resetting and re-executing the program, the processor returned this error. An initial and simple solution was to reload the bitstream and everything was working again in the same manner. Could this be some sort of problems in the management of the internal memory after the reset, maybe related to the fact that the BRAMS are not correctly cleaned up after every processor reset (and this can also explain why rewriting the bitstream would allow the system to work correctly again)?

[stnolting]

The BRAMs of the processor's IMEM and DMEM should not be affected by a reset nor by a bitstream re-upload. Maybe it is a general reset problem of the system?! :thinkin:

Is the block diagram from your first post still up-to-date?

Why are using an AXI GPIO controller to control the processor reset? Furthermore, this AXI GPIO is controlled by the processor - so if it activates the reset there is no change of removing it again without re-uploading the bitstream. Is there a specific reason why you are not using the global reset also for the processor?

[Giorgio122]

Is the block diagram from your first post still up-to-date?

Yes, the only additions have been the ILA components

Why are using an AXI GPIO controller to control the processor reset? Furthermore, this AXI GPIO is controlled by the processor - so if it activates the reset there is no change of removing it again without re-uploading the bitstream. Is there a specific reason why you are not using the global reset also for the processor?

No particular reasons, just to keep the reset of the processor "separated" from the other components and control it in an independent way.

[stnolting]

I would recommend to also use the reset from the Processor System Reset module - just to prevent any potential deadlocks 😉

[Giorgio122]

Hi @stnolting, sorry for the late reply!
Thank you so much, it should be clear now. I'll try out everything these days and hopefully I would solve the problems I have encountered!
Best regards,
Giorgio