Indirect boot mode

[alyxazon]

Hi all,

Quick question about the boot process. I want to use the indirect boot mode (no boot loader).

Quote:

"In contrast, boot scenario 2b uses a processor-external IMEM. In this scenario the system designer is responsible for providing an initialized external memory that contains the actual application to be executed."

My understanding is that the neorv32_top.vhd should provide a way to connect an external RAM/ROM? Like a generic i.e. MEM_USE_EXTERNAL and a view pins (imem_req/imem_rsp)?

Or what is the official/correct way to do this?

For better understanding, my use case is as follows:

• I need to change the code on the RISC during runtime (as fast as possible).
• Sequence: Stop the CPU, change/modify the content/program on the IMEM, start the CPU again.
• The IMEM should be a dual port RAM.
  • Side A is connected to the processor (as the IMEM).
  • Side B is connected to a wishbone bus (to change/modify the contect).
• The wishbone bus can be accessed by via Ethernet and PCIe. There is no UART and I want to avoid using some fancy virtual UART :)

[stnolting]

Hey @alexazon.

Quote:

"In contrast, boot scenario 2b uses a processor-external IMEM. In this scenario the system designer is responsible for providing an initialized external memory that contains the actual application to be executed."

This refers to a direct boot mode, i.e. there is no code being executed that is responsible (like the bootloader) of fetching the actual application code.

My understanding is that the neorv32_top.vhd should provide a way to connect an external RAM/ROM? Like a generic i.e. MEM_USE_EXTERNAL and a view pins (imem_req/imem_rsp)?

This option is supported! 😉

• Disable the processor-internal IMEM (MEM_INT_IMEM_EN => false) and disable the bootloader (INT_BOOTLOADER_EN => false) to select the "direct boot mode".
• Enable the external bus interface (XBUS_EN => true) and connect your "application image memory" to the processor's external bus.
• When the CPU comes out of reset it will boot from address 0x00000000. Since there is no internal IMEM available, these instruction fetch requests will be delegated to the external bus interface.

So, all you need to do is to connect your application code memory to the external bus interface and "map" it to address zero.

You can "halt" the core by keeping the reset signal active (= low) until your external memory is initialized with the actual application code.

[alyxazon]

Hi @stnolting,

First of all: Thanks for your quick response. I've already played around with the boot and imem parameters in a simulation and noticed the behavior you describe.

Let me explain my use case in a more detailed way.

I need to use the wishbone (XBUS) interface to access a wishbone subsystem with multiple devices, connected by a wishbone crossbar. There are at least 4 different wishbone masters (including the NEORV32). If I add the IMEM here, I'll get multiple delays (crossbar) and possible blockages (depending on my implementation).

That's why I prefer to have the IMEM exclusively and close to at the processor.

Additionally I wanted to change the constants...

constant mem_imem_base_c : std_ulogic_vector(31 downto 0) := x"00000000";
constant mem_dmem_base_c : std_ulogic_vector(31 downto 0) := x"80000000"

... to a higher address space. 0x0 to 0x80000000 shall be the wishbone address range.

I see 2 ways to fix this:

1. Expose the IMEM
2. Add a fancy wishbone arbiter (crossbar light with no or less delay) that checks the xbus_adr_o signal to switch between the IMEM and the multimaster system.

Please let me know if I missed something.

For technical reasons I would like to instantiate the IMEM with a MIF file [1]. In other words: I need a default neorv32 application in my FPGA bitstream.

If I understand your code correctly, I need to generate my own neorv32_application_image.vhd to do this, in case I don’t use the XBUS?

[1] https://www.intel.com/content/www/us/en/programmable/quartushelp/17.0/reference/glossary/def_mif.htm

[stnolting]

I need to use the wishbone (XBUS) interface to access a wishbone subsystem with multiple devices, connected by a wishbone crossbar. There are at least 4 different wishbone masters (including the NEORV32). If I add the IMEM here, I'll get multiple delays (crossbar) and possible blockages (depending on my implementation).

So lot's of traffic there?
Note that the core also provides an AXI-stream-compatible streaming interface (SLINK). Maybe you can use that as well to move data to/from the core?!

Additionally I wanted to change the constants... ... to a higher address space. 0x0 to 0x80000000 shall be the wishbone address range.

That should be fine. Keep in mind that you'll need to do the same modifications in the linker script:

neorv32/sw/common/neorv32.ld

Lines 26 to 42 in 792cc45

	/* ************************************************************************************************* */
	/* +++ NEORV32 memory layout configuration +++ */
	/* If the symbols are not explicitly defined the default configurations are used. If required, only */
	/* edit the very last entry in each row. */
	/* NOTE: section sizes have to be a multiple of 4 bytes; base addresses have to be 32-bit-aligned. */
	/* ************************************************************************************************* */
	/* Default rom/ram (IMEM/DMEM) sizes */
	__neorv32_rom_size = DEFINED(__neorv32_rom_size) ? __neorv32_rom_size : 2048M;
	__neorv32_ram_size = DEFINED(__neorv32_ram_size) ? __neorv32_ram_size : 8K;
	/* Default HEAP size (= 0; no heap at all) */
	__neorv32_heap_size = DEFINED(__neorv32_heap_size) ? __neorv32_heap_size : 0;
	/* Default section base addresses */
	__neorv32_rom_base = DEFINED(__neorv32_rom_base) ? __neorv32_rom_base : 0x00000000;
	__neorv32_ram_base = DEFINED(__neorv32_ram_base) ? __neorv32_ram_base : 0x80000000;

I see 2 ways to fix this:

1. Expose the IMEM
2. Add a fancy wishbone arbiter (crossbar light with no or less delay) that checks the xbus_adr_o signal to switch between the IMEM and the multimaster system.

Unfortunately, there is no default mechanism for option 1. So, I would recommend option 2 to keep the code base as clean as possible. 😉 The idea with the arbiter sounds good.

You could add register stages to keep the critical path short. And you could add the XBUS cache to hide some of the additional delays.

For technical reasons I would like to instantiate the IMEM with a MIF file [1]. In other words: I need a default neorv32 application in my FPGA bitstream. If I understand your code correctly, I need to generate my own neorv32_application_image.vhd to do this, in case I don’t use the XBUS?

The default software makefile can already generate Xilinx-related memory initialization files (make mem and make coe). I completely forgot about the mif format... 😅 I'll add support for that ASAP (-> #949).

[alyxazon]

Hi,

First of all: Thank you for adding the MIF support. I'll test it when it's inside the main branch (and all checks are successful 😄)

You could add register stages to keep the critical path short. And you could add the XBUS cache to hide some of the additional delays.

I assume that I need to add registers here to multiplex a 32bit data/address bus, but on the other hand I would like to avoid additional delays.

Silly question: Ok, let's assume I'm using the XBUS and the AXI interface. What happens when I issue a simple pointer-based write?

What I mean:

uint32_t *p_wishbone_space = (uint32_t *)0x00000064; // between 0x0 and 0x7ffffff0
uint32_t *p_axi_space = (uint32_t*)0x800000c4; // between 0x80000000 and 0xa0000000
uint32_t wishbone_value = *p_wishbone_space;
uint32_t axi_value = *p_axi_space;

How does the "CPU" know which interface to use?

[stnolting]

I'll test it when it's inside the main branch (and all checks are successful 😄)

Thank you very much! (#949 is merged)

I assume that I need to add registers here to multiplex a 32bit data/address bus, but on the other hand I would like to avoid additional delays.

How about this?

XBUS ---> mux ---> reg_stage ---> your_wishbone_network
           |
           v
       your_imem

This would keep the critical path short (at least on the processor side) allowing high bandwidth to your external IMEM.

Silly question: Ok, let's assume I'm using the XBUS and the AXI interface. What happens when I issue a simple pointer-based write?

That depends on the processor/memory configuration and on the address you are referencing.

How does the "CPU" know which interface to use?

Any access to an "unmapped" address gets redirected to the XBUS interface. This is what "void" means here:

For example, if the internal IMEM is disabled (MEM_INT_IMEM_EN => false), then the entire address range between 0x00000000 and 0x7FFFFFFF belongs to the "void". Hence, any access to this address space will be converted into an XBUS access request.