stnolting / neorv32

:desktop_computer: A small, customizable and extensible MCU-class 32-bit RISC-V soft-core CPU and microcontroller-like SoC written in platform-independent VHDL.
https://neorv32.org
BSD 3-Clause "New" or "Revised" License
1.55k stars 215 forks source link

ASIC Processor boot conccept #878

Closed ucycg closed 5 months ago

ucycg commented 5 months ago

I'm currently exploring the possibility to create an ASIC from a specific NeoRV32 configuration. As I'm still a student without much experience in digital design I still have a lot of things to figure out on this endeavour.

One thing I currently came across, as it is fundamental for the ASIC processor to be actually usable is the boot concept. I was always thinking I would use the bootloader to upload binaries from an External SPI Flash via the auto boot SPI process. But today I realized that the bootloader itself is contained in the neorv32_boot_rom.vhd which isn't exactly synthesizable either.

So now my second next idea would be to use the XIP module with another External SPI Flash as a replacement ROM which contains the bootloader code instead. Is this a reasonable approach?

When I use the XIP module is it still possible to also execute instructions from internal IMEM as well?

As for the processor internal IMEM/DMEM I have the plan to replace the architecture of these moduels with a technology dependent version which is based on RAM.

ucycg commented 5 months ago

Okay as an update after talking to a PhD at my university it seems that actually synthesizing the neorv32_boot_rom.vhd might be possible. I will try this soon and if there is interest I can update this Issue with my results from netlist synthesis of a design that includes the bootloader.

ucycg commented 5 months ago

Yeah so I managed to synthesize a netlist in our tech process and simulated the startup of the bootloader successfully which tells me that the boot_rom is successfully synthesized in the GTL netlist. I would still like to find out how much area is occupied by that memory, which i couldnt figure out until now sadly. Bildschirmfoto vom 2024-04-19 15-42-50

stnolting commented 5 months ago

That looks great! :+1: Keep us updated if you like :wink:

ucycg commented 4 months ago

Currently I'm creating a SPI flash dummy verilog module to load an executable binary via the bootloader with SPI into the NeoRV32 all inside a xecilium sim.

stnolting commented 4 months ago

Sounds like a cool project!

If you "just" want to support read accesses (i.e. no flash write) you only need to implement the READ command, so the logic should be quite simple. Hit me up if I can help you in any way.

jtplaarj commented 4 months ago

Picorv32 has such a simulation module por XIP: https://github.com/YosysHQ/picorv32

I have successfully used it with neorv32 with minor changes.

stnolting commented 4 months ago

You mean this one? https://github.com/YosysHQ/picorv32/blob/main/picosoc/spiflash.v

I thinks it looks quite promising.

jtplaarj commented 4 months ago

Yes. I have done small changes, it looks like neorv32 implementation of XIP and that of picorv32 are not exactly the same. the spi simulator from picorv32 waits for one command to initialize the flash, while neorv32 does not send it. Because of that, I have changed line 63 and initialize reg powered_up = 1 to avoid the issue.

I have an small python script that converts main.bin to a hex file for the spiflash.v module.

stnolting commented 4 months ago

So the SPI model is waiting for some "get out of standby mode" command?

Is that a common command understood by most flash chips? If yes, then we should add this to the bootloader. πŸ€”

ucycg commented 4 months ago

That was a thing that I already noticed while implementing my SPI flash. Maybe you are talking about somehting else, but in the bootloader.c code there is already a spi_flash_wakeup() function called in spi_flash_check() sending cmd 0xAB, which is mentioned as optional in the datasheet currently. Sadly not every flash has this wake up from deep sleep. The first one that comes up on google from Microchip for example has this command, but it corresponds to a READ_ID cmd for example.

stnolting commented 4 months ago

Maybe you are talking about somehting else, but in the bootloader.c code there is already a spi_flash_wakeup() function [...]

Oh, right... Seems like I have forgotten that πŸ™ˆπŸ˜…

https://github.com/stnolting/neorv32/blob/8ca618c351b4ff42b8633488e88ab9e0f1723bed/sw/bootloader/bootloader.c#L177

ucycg commented 4 months ago

I wrote a crude simple flash emulation module and in simulation the auto boot scenario is working :smile: The NeoRV32 now reads the data from the virtual flash module via SPI and starts executing the blink_led_example binary. grafik One thing I don't quite understand currently is that a first setup where I decreased the memory to 8KB IMEM and 2KB DMEM was loading the software as well, but couldn't execute it. I only changed the memory size inside my wrapper module. I dont quite understand what else I have to change to use different memory sizes. I there something in the linker that I have to change ? Or do I have to respect the memory sizes when I compile my application? I can also formulate this in another issue if that is better.

stnolting commented 4 months ago

I wrote a crude simple flash emulation module and in simulation the auto boot scenario is working πŸ˜„ The NeoRV32 now reads the data from the virtual flash module via SPI and starts executing the blink_led_example binary.

That's great! πŸš€

One thing I don't quite understand currently is that a first setup where I decreased the memory to 8KB IMEM and 2KB DMEM was loading the software as well, but couldn't execute it. I only changed the memory size inside my wrapper module. I dont quite understand what else I have to change to use different memory sizes. I there something in the linker that I have to change ? Or do I have to respect the memory sizes when I compile my application? I can also formulate this in another issue if that is better.

You will need to recompile your application if you change the memory size of the hardware (actually only if you shrink it). Since this is a common pitfall, it might be good to clarify this in another issue.