@User Matt suggested during the office hours that I ask you. The management core needs a flash chip to boot up, but if my design doesn't need the management core for "production" use, I can spare the flash chip. However, by default the gpio directions are handled by the management core. Matt said that you can override this and hardcode the pin directions using gen_gpio_defaults.py. Have you got some pointers on how to do this?

Copy the file

user_defines.v

from the caravel

verilog/rtl/

directory to your user project

verilog/rtl/

directory and edit it as needed for your project.

Thank you. What does "controlled by the management core" exactly mean for the

_MGMT_

versions? Are they available in their respective directions without the mgmt core but changeable via the mgmt core after boot, or are they plain inaccessible without the mgmt core?

If you have a GPIO set to one of the

_MGMT_

settings, then only the management can control the GPIO output. The way it is set up, both management and user areas can read GPIO input.

Ok, I have a rough understanding of the GPIO controls now. Your answers and reading

verilog/rtl/gpio_control_block.v

helped clear it up a bit. I still don't fully get how output works in the default configuration. If I don't touch

user_defines.v

, pins are set up as

GPIO_MODE_MGMT_STD_INPUT_NOPULL

. This sets

gpio_dm=3'b001

,

gpio_inenb=0

,

gpio_outenb=1

and

mgmt_ena=1

. Therefore

pad_gpio_outenb=mgmt_gpio_oeb

and

pad_gpio_out=mgmt_gpio_out

. So if the user project sets

user_gpio_oeb=0

, the management area has to somehow forward data from

user_gpio_out

to

mgmt_gpio_out

. How and where does this forwarding happen?

No, once the

mgmt_ena

bit is set to

1

, then nothing that the user project does has any effect.

user_gpio_oeb

and

user_gpio_out

are ignored.

Oh, I see that the firmware can change the pad configuration at runtime via the serial loader on the housekeeping interface, so

mgmt_ena

is not a permanent setting. I was worried that projects not overriding

user_defines.v

(which is 99% of projects) would have their

io_out

and

io_oeb

ignored. Now I can sleep better. 🙂

Right. The specific purpose of

user_defines.v

is to have a user project power up into the right state while bypassing the management SoC completely---such as if you wanted to demonstrate the user project on a tiny board without the overhead of additional parts like the SPI flash chip.

Yes, that's exactly what I wanted to do with my mpw5 project (but not my mpw3 & 4 projects).