Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ASIC Processor boot conccept #878

Closed
ucycg opened this issue Apr 18, 2024 · 13 comments
Closed

ASIC Processor boot conccept #878

ucycg opened this issue Apr 18, 2024 · 13 comments

Comments

@ucycg
Copy link
Contributor

ucycg commented Apr 18, 2024

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
Copy link
Contributor Author

ucycg commented Apr 18, 2024

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 ucycg closed this as completed Apr 18, 2024
@ucycg
Copy link
Contributor Author

ucycg commented Apr 19, 2024

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
Copy link
Owner

That looks great! 👍
Keep us updated if you like 😉

@ucycg
Copy link
Contributor Author

ucycg commented Apr 23, 2024

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
Copy link
Owner

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
Copy link

jtplaarj commented Apr 24, 2024

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

I have successfully used it with neorv32 with minor changes.

@stnolting
Copy link
Owner

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

I thinks it looks quite promising.

@jtplaarj
Copy link

jtplaarj commented Apr 25, 2024

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
Copy link
Owner

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
Copy link
Contributor Author

ucycg commented Apr 26, 2024

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
Copy link
Owner

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 🙈😅

SPI_FLASH_CMD_WAKE = 0xAB, /**< Wake up from sleep mode */

@ucycg
Copy link
Contributor Author

ucycg commented Apr 26, 2024

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.
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
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants