Hey guys, just wanted to double check my understanding, is it correct to assume that if we turn the RISC-V processor off, we won't be able to access any of the chip pins (besides power)? It seems like they are all IO that I assume all go through the processor, just wanted to double check.

@Chris Lonergan depends on the gpio mode configured.

MGMT

modes direct the gpio input and output to the RISC-V processor.

USER

modes direct the input and output to the user area. (It’s a little more complicated and there are exceptions, but that’s the general idea). So even if you don’t use the RISC-V processor, you can still use the gpio if they are configured in one of the

USER

modes.

Is this true even if the processor is not on (reset pin held or something like that)?

That I don’t know.

@Chris Lonergan: The reset pin does not affect the GPIO configuration settings. If

user_defines.v

is edited to set the GPIO in user-project-accessible modes on power-up, then you don't need to run the processor at all and can force it permanently to reset. If you don't have the proper configuration on power-up, you can run a program on the processor that configures the GPIO, and then force the processor into reset. The GPIOs will continue to keep the configuration.

Ok, thank you, and is this the preferred way to put the processor into low power/off mode?

There's not really a "low power" mode per se, but yes, disabling the processor through reset is the best you can do.

Great, thanks, and just to check my understanding, when the professor is in reset mode, the gpios are routed through and usable during the time it is being reset (if configured correctly)?

They are not actually routed "through". Each GPIO is multiplexed between two sets of control signals, one coming from the management processor, and the other coming directly from the user interface. The scan chain that holds the static configuration for each GPIO is independent of all the control signals, and is the part that does not reset when the processor is reset. If the static configuration has the GPIO under the control of the user project, then the GPIO can only be driven by the user project.

ok, yeah I'm just trying to make sure the muxes working does not depend on the processor being not in reset

See the

caravel/verilog/rtl/gpio_control_block.v

file here.

@Mitch Bailey: Yes, but just looking at the control block verilog is not enough to know where its reset comes from; in fact, its path is quite convoluted but originates in

housekeeping.v

where it is driving by the power-on-reset signal (which remains constant zero shortly after power-up and is not affected by the

RESETN

pin). Also within housekeeping, it can be manually overridden to force all GPIOs back to the power-on-reset state.

Ok, thank you, so will the muxes still work and allow the user area to access signals outside of the chip when the processor is in reset? Assuming they are configured correctly before holding the reset pin?

A lower power solution than holding reset would be to use an external clock with the CPU and just stop the clock....(THat won't draw the reset power and will leave all pins in a known state as of the last executed instruction

True, and the caravel demo board has a jumper to disable the clock.