I was wondering if it would be possible to run a program on the management SoC directly from RAM - either the DFFs or the SRAM. I came across this post from 3 years ago. It mentions that the program base address is hardcoded in the RTL. Is this still the case? I couldn't find a reference to such a base address in the RTL now.

What does programme base address mean to you? The memory map is a hardware design detail. If you are are using the stock (as it comes) project. There is a memory execute in place SPI flash, a CPU reset address, a very limited amount of DFF RAM (which is also needed to operate a stack), some peripherals and an address aperture on the wishbone available for your custom caravel_user_project

What we're hoping to achieve is to use a small battery to persist the data in RAM, and not reset the device after programming, eliminating the flash entirely. I'm wondering if it's possible to configure the CPU to begin executing instructions directly from its DFFs on reset.

I'm sure anything is possible. It depends on much effort you are expecting to put into it. I think it is safe to say you can not achieve this by default. It sounds like you need a custom caravel (no matter how you look at it), so first I would understand what that means. For example check if you can simply modify the caravel verilog and build your GDS and submit to efabless, or if by default you only get to submit GDS for the user_project_area and efabless will integrate with a stock/standard caravel build around it. If this is the case you might need to look at Open Frame to be able to submit a modified version of caravel for manufacture. Now the kind of modification needed to caravel might be: • think through the need to boot once from flash (to program/setup/initialize DFF data), this first reset and boot needs to assume undefined states of internal registers • think though how to have an additional kind of reset, one which resets everything except the special registers to manage the CPU PC reset address • implement a simple register on wishbone bus, this register might only to be a single DFF. One to store enable/activation. On a hard-reset it will deactivate and ensure 0x1000_0000 is presented to CPU port on reset. On soft-reset it will (if activated) present 0x0000_0000 to CPU otherwise 0x1000_0000. • the Vex CPU already has a 32bit port on the CPU module that contains the reset address • you might be able to be clever and reuse the SPI DI line state during a standard reset release to indicate if the kind of reset is a soft or hard reset. but this is an area you need to evaluate and have a plan, worst case scenario use an additional external IO pin and attach a switch on your PCB. note: if you use a switch or something that permanently disconnects DI line on PCB this is going to cut off access to flash completely which may not be desirable, I am suggesting it only needs to hold the state around the time of reset release, which might occur a long time after a nominal powerup sequence, due to power-on-reset needing to see voltage-good indicator for all rails before starting a reset-release sequence.

Thank you for your help, these are really great pointers for how we'd go about doing this!

While I bring up the point of needing a hard-reset that does run from flash to be able to program the DFF in the first place, this is push back against your requirement "eliminating the flash entirely". You can of course accept that maybe you always boot from flash, and have the initial code from flash look for a magic sequence/integrity check of DFF data area to decide if it can jump there now or needs to initialize it first.