State of the AXI4-Lite wrapper

[Sam-Vervaeck]

As mentioned in my other post, I want to use this processor for my thesis. I remember looking at it a while back and seeing the AXI4-Lite wrapper. This one seems to be gone now and replaced by the Vivado IP wrapper. In the user guide the old AXI4-Lite wrapper is still referenced however.

What is the current state of this wrapper? Does the new one still provide the exact same functionality as the wrapper with the previous neorv32_top_axi4lite name? Is there just an extra Vivado IP ability added to it in tandem with that tcl script?

[stnolting]

This one seems to be gone now and replaced by the Vivado IP wrapper.

That's right.

In the user guide the old AXI4-Lite wrapper is still referenced however.

Oh, where? I need to fix that 😅

What is the current state of this wrapper? Does the new one still provide the exact same functionality as the wrapper with the previous neorv32_top_axi4lite name? Is there just an extra Vivado IP ability added to it in tandem with that tcl script?

Correct. The new wrapper provides the same functionality - plus all the configuration options and signals that were missing in the old one.

Btw, this new file (neorv32_vivado_ip.vhd) can also be used for plain HDL-based designs. The Vivado IP block is just an optional add-on.

I'll update some parts of the documentation to make this more clear.

[Sam-Vervaeck]

Oh, where? I need to fix that 😅

I went to double check the section in the user-guide I was looking at and I think Chrome still had a cached version open. After refreshing the page the docs updated to the new file naming, so my bad. Sorry!

To add a second deeper question though: I find it hard to get a clear answer online on the difference between "add module" and "add IP" in a Vivado block design. My supervisors told me the "add module" workflow is normally less of a pain? I have an accelerator block design I want to attach neorv to instead of a microblaze. But after I added all the RTL of neorv32 and I selected "add module" the neorv_top file was greyed out, I could not select it. Is there a reason you went for the IP block workflow for neorv32 instead of adding it as a module?

[stnolting]

I went to double check the section in the user-guide I was looking at and I think Chrome still had a cached version open. After refreshing the page the docs updated to the new file naming, so my bad. Sorry!

I just updated some of the documentation. So maybe it wasn't there before.

I find it hard to get a clear answer online on the difference between "add module" and "add IP" in a Vivado block design.

Well, in general an IP block is just another design module, right? 😅

I have an accelerator block design I want to attach neorv to instead of a microblaze.

Do you use a plain-HDL setup or do you use a Vivado block design?

But after I added all the RTL of neorv32 and I selected "add module" the neorv_top file was greyed out, I could not select it. Is there a reason you went for the IP block workflow for neorv32 instead of adding it as a module?

I recommend to use the provide packaging script. Just run that, update the Vivado IP repository and your done. Then you can add NEORV32 from the IP catalogue to your block design or you can instantiate the provided HDL wrapper.

[Sam-Vervaeck]

Hey, sorry for the delay. I had to figure out some theory and exam season is coming up as well. To come back to this:

Do you use a plain-HDL setup or do you use a Vivado block design?

I have this accelerator and they made use of a block design with a microblaze as cpu:

I wanted to try to replace the microblaze by the neorv32.

I recommend to use the provide packaging script. Just run that, update the Vivado IP repository and your done. Then you can add NEORV32 from the IP catalogue to your block design or you can instantiate the provided HDL wrapper.

I did this so now I have access to the neorv32 IP block when I add the IP folder to my Vivado projects.

I was wondering though how the IP and block design would change my workflow. For example: neorv32 has uart and GPIO build in, so do you connect your uart board connection directly to the neorv32 in the block design? Because on the microblaze everything goes through AXI interconnects.

Also in the other IP discussion post and in the user guide this figure is shown:

What is the goal of wiring up the AXI4-Stream Data FIFO in that way? What is the intended functionality?

[Sam-Vervaeck]

Starting from your Microblaze design you could use the NEORV32-internal peripherals to replace the AXI-Timer, the uartlite and maybe even the DMA module. Additionally, you do not need any explicit program/Data memory anymore as the NEORV32 already have internal ones.

Before I get started on trying this out, one more quick thought I had about attaching this accelerator to the neorv32: The accelerator logic is contained in the ComputeCoreWrapper block at the top of the previously posted figure. It uses Axi4 and Axi4-lite for instruction and DMA communication. My first intuition was to hook it up to the external bus interface of neorv32 since the authors also did a similar design with Microblaze. However, would the CFS of neorv32 be a better place to put this accelerator? Or is it too focussed on AXI interfaces to be used with the CFS? I am basing this on the comparison in the user guide which says the external bus interface is better for large complex hardware, which I think this accelerator might be?

[stnolting]

That depends on your accelerator... The CFS provides up to 64 memory-mapped interface registers. Would that match your accelerator's interface?

The CFS is "closer" to the CPU core which results in less access latency making the system more performant.

[Sam-Vervaeck]

@stnolting Hey, i would like to pick this discussion up again to discuss some of your points a bit deeper:

The CFS is "closer" to the CPU core which results in less access latency making the system more performant.

After looking at the datasheet of the CFS and XBUS it is not immediately clear to me what makes it more performant. I also had a look at this image and it seems like the CFS and XBUS split of at about the same point from the central "Gateway" block?

A new question that I have is about the difference in the functionality of the CFS and XBUS. When looking at the VHDL code of both the main difference seems to me that:

• The CFS has only two IO data conduits setup that propagate out of the top module. However, it also has an interrupt line and specific clocking capabilities.
• The XBUS has a more elaborate interface setup that propagates out of the top module with also wrappers available to convert it from Wishbone to AXI4-Lite.

A last difference/similarity:

• Both have access to memory mapped registers. However, because of the memory address map, the CFS only has space for 64 32-bit registers. Meanwhile the XBUS has space for way more, namely the amount of address space not yet in use.

Is there any other major similarity/difference between the two that I am missing?

[Sam-Vervaeck]

Also, is there an easy way to have a second XBUS which is also wrapped in an AXI4-Lite interface? I assume not and that this would require a manual adding of it to the intercon.vhd file etc etc?

EDIT: I guess this is a bit of a stupid question, I can just put an AXI interconnect/smartconnect behind it to get more AXI Master ports

[stnolting]

After looking at the datasheet of the CFS and XBUS it is not immediately clear to me what makes it more performant.

If the XBUS cache is disabled (XBUS_CACHE_EN => false) and there is not additional register stage in the XBUS interface (XBUS_REGSTAGE_EN => false) then the latency when accessing the CFU is identical to the latency when accessing the external bus interface.

If you have a large interconnect attached to the XBUS it is highly recommended to at least enable the register stage to trim the the critical path of the bus.

The CFS has only two IO data conduits setup that propagate out of the top module. However, it also has an interrupt line and specific clocking capabilities.

That's right.

The XBUS has a more elaborate interface setup that propagates out of the top module with also wrappers available to convert it from Wishbone to AXI4-Lite.

Correct. In addition, XBUS accesses are cached if the external bus cache is enabled.

Both have access to memory mapped registers. However, because of the memory address map, the CFS only has space for 64 32-bit registers. Meanwhile the XBUS has space for way more, namely the amount of address space not yet in use.

Correct. But let's better rephrase that: both modules are memory-mapped and are accessed using load/store operations.

Is there any other major similarity/difference between the two that I am missing?

It's a good summary.

The CFU is intended for memory-mapped IO that requires fast accesses. The XBUS is intended for attaching memory, but you can also attach IO devices. However, if the external bus cache is implemented accesses to external IO devices requires extra cycles as these need to bypass the XBUS cache.

Also, is there an easy way to have a second XBUS which is also wrapped in an AXI4-Lite interface? I assume not and that this would require a manual adding of it to the intercon.vhd file etc etc?

No, there is no such option by default. Keep in mind that this is a single-core setup, so the CPU could only serve one XBUS interface at one time (yeah, we have caches and a DMA, but I'll ignore that for now 😅).

I can just put an AXI interconnect/smartconnect behind it to get more AXI Master ports.

Right. 👍