NEORV32 as Vivado IP

[stnolting]

I was experimenting with Vivado, block designs and a large TCL script to provide a simple way pf packaging the processor as dedicated IP module (-> #894). The TCL script overrides the default configuration options to provide a quite fancy customization GUI. This is how it looks so far:

The synthesized design runs on an Arty-a7 board without any problems. 🚀

The script is still a bit experimental and I've only tested it with Vivado 2019 so far. So it would be great if someone else could test the script and the IP integration. 😉

[Sam-Vervaeck]

Probably not the most deep question, but as a beginner I have to start my understanding somewhere... :

How does using neorv32 as an IP change the way you can simulate program execution? From the user guide I figured out program simulation by following the section on installing a program directly into memory. Then I can just give the core a clk and it will automatically start executing the program. I assume it does not work the same way when used as an IP block in a block diagram?

[stnolting]

That does also work when you use the NEORV32 as IP block - you just need to re-package the core after updating/installing the program into it's memory.

[Sam-Vervaeck]

Ah that makes sense! Thank you I'll try that out!

[BEforlin]

Hi @stnolting,

I have been using the soc as a packaged IP for a while now, but its nice to have an official packaged version, thanks for that!

I have tested the script and packaging with Vivado 2023.2 works fine. I am in the process of creating a bigger design with the core on the block diagram, if I encounter any issues I will reply here, but so far so good.

Small comments:

• On the User guide bullet point 4. Execute source source neorv32_vivado_ip.tcl in the TCL console. Source is written 2 times.
• The default option for clock frequency in the customization GUI is 0, is this intended?
• I just noticed that changing the "GPIO port pins" in the customization GUI does not actually change the number of exposed pins.

[stnolting]

I have tested the script and packaging with Vivado 2023.2 works fine. I am in the process of creating a bigger design with the core on the block diagram, if I encounter any issues I will reply here, but so far so good.

Sounds great! I look forward to hearing what you have to report 😉

On the User guide bullet point 4. Execute source source neorv32_vivado_ip.tcl in the TCL console. Source is written 2 times.

Oh, typo! I'll fix that!

The default option for clock frequency in the customization GUI is 0, is this intended?

Hm right... Maybe I can try to remove the default value so that the user is forced to configure this.

I just noticed that changing the "GPIO port pins" in the customization GUI does not actually change the number of exposed pins.

That is also something I am working on. The idea behind this for the "normal" top entity is that you always get the same entity regardless of the actual configuration. But the for the IP block this is unpretty as you need to use slice/concat components to always make a 64-bit port even if you just need one IO pin.

[stnolting]

Btw, I am working on auto-resizing ports in #913.

[robhancocksed]

One thing that's unclear is that in the case where the boot loader is not being used and you created a custom IMEM image to build into the core, previously we just excluded the neorv32_application_image.vhd file from the build and included our own generated VHDL file instead. I'm not sure if there is a way to do that with the IP package at the moment? It seems like it just pulls in all VHDL files from rtl/core right now.

[stnolting]

If you use the Makefile's install target the default memory image (neorv32_application_image.vhd) in rtl/core will get overridden. Then, you can just re-package the IP and you will have a setup that boots up your custom image.

Another option is to replace the image file right inside the packaged IP folder - but Vivado might complain about that (I have not tested that yet).

[robhancocksed]

That would probably work, but wouldn't be the greatest as we are using neorv32 as a submodule in our project, and overwriting the file would cause the repository to always show up as dirty.

Maybe an optional command-line option to the Tcl script to give it an alternate IMEM and/or DMEM source file path to use rather than the built-in one?

[stnolting]

[...] overwriting the file would cause the repository to always show up as dirty.

Right, that is a problem. How about using the bootloader + an external SPI flash (maybe the FPGA's bitstream storage) for providing the boot image?

Maybe an optional command-line option to the Tcl script to give it an alternate IMEM and/or DMEM source file path to use rather than the built-in one?

That might be an option. But I'm not sure how to do this in a handy way right now... 🤔

Or maybe you could really try this:

Another option is to replace the image file right inside the packaged IP folder

[robhancocksed]

Right, that is a problem. How about using the bootloader + an external SPI flash (maybe the FPGA's bitstream storage) for providing the boot image?

That's something we've looked into, but it does make some things more complicated. This device has redundant FPGA bitstreams on the configuration flash and we'd need to make sure that was accounted for in handling the software boot image as well. There would also be some additional work in handling updates to the logic and software images. Given that the device we are using has enough block RAM to just compile in the entire software image, we decided to go with that approach.

Another option is to replace the image file right inside the packaged IP folder

That might be sufficient if it works? I assume you'd have to re-run the packaging of the IP each time.

[stnolting]

That might be sufficient if it works? I assume you'd have to re-run the packaging of the IP each time.

It should be sufficient if you just replace neorv32_bootloader_image.vhd in the packaged IP folder as these are the actual source files for the specific IP block (of course you will have to re-run out-of-context synthesis of that IP module):

neorv32/rtl/system_integration/neorv32_vivado_ip_work/packaged_ip/src/neorv32$ ls
neorv32_application_image.vhd  neorv32_cpu_cp_cfu.vhd        neorv32_debug_dm.vhd      neorv32_intercon.vhd  neorv32_top.vhd
neorv32_boot_rom.vhd           neorv32_cpu_cp_cond.vhd       neorv32_debug_dtm.vhd     neorv32_mtime.vhd     neorv32_trng.vhd
neorv32_bootloader_image.vhd   neorv32_cpu_cp_fpu.vhd        neorv32_dma.vhd           neorv32_neoled.vhd    neorv32_twi.vhd
neorv32_cache.vhd              neorv32_cpu_cp_muldiv.vhd     neorv32_dmem.default.vhd  neorv32_onewire.vhd   neorv32_uart.vhd
neorv32_cfs.vhd                neorv32_cpu_cp_shifter.vhd    neorv32_dmem.entity.vhd   neorv32_package.vhd   neorv32_vivado_ip.vhd
neorv32_clockgate.vhd          neorv32_cpu_decompressor.vhd  neorv32_fifo.vhd          neorv32_pwm.vhd       neorv32_wdt.vhd
neorv32_cpu.vhd                neorv32_cpu_lsu.vhd           neorv32_gpio.vhd          neorv32_sdi.vhd       neorv32_xbus.vhd
neorv32_cpu_alu.vhd            neorv32_cpu_pmp.vhd           neorv32_gptmr.vhd         neorv32_slink.vhd     neorv32_xip.vhd
neorv32_cpu_control.vhd        neorv32_cpu_regfile.vhd       neorv32_imem.default.vhd  neorv32_spi.vhd       neorv32_xirq.vhd
neorv32_cpu_cp_bitmanip.vhd    neorv32_crc.vhd               neorv32_imem.entity.vhd   neorv32_sysinfo.vhd

Another option would be to disable the internal IMEM and use a pre-initialized processor-external memory for the application code. The makefile provides options to generate Vivado memory initialization files (i.e. *.coe and *.mem). However, that might introduce additional latency (so would need to enable at least the instruction cache).