Hi all, I am currently trying to understand the power-on configurations for GPIO in

user_defines.v

. Taking a look at the individual bit fields for the GPIO pad control:

#define MGMT_ENABLE	  0x001
#define OE_OVERRIDE	  0x002
#define INPUT_ENABLE	  0x004
#define OUTPUT_ENABLE	  0x008
#define SCHMITT_SELECT	  0x010
#define SLEW_SELECT	  0x020
#define PULLUP_SELECT	  0x040
#define PULLDOWN_SELECT	  0x080
#define DRIVE_SELECT_MASK 0x300

This means that all of the following user configurations basically ignore the

io_oeb

signal from

user_project_wrapper

, right?

GPIO_MODE_USER_STD_INPUT_*
GPIO_MODE_USER_STD_OUTPUT

For

GPIO_MODE_USER_STD_BIDIRECTIONAL

the

OE_OVERRIDE

bit is not set, therefore

io_oeb

is used. It only has the

OUTPUT_ENABLE

bit set, but shouldn't the

INPUT_ENABLE

bit also be set?

@Leo Moser the input for each gpio passes through a gpio_control_block. The

gpio_control_block

combines the gpio “constant” (they’re reprogrammable) inputs from

gpio_defaults_block

as defined in

verilog/rtl/user_defines.v

with the signals from the

user_project_wrapper

(

io_out

,

io_oeb

,

io_in

).

The

io_oeb

bit is for use with management control of the GPIO, because the management has a simpler interface to each GPIO, with just two signal lines per GPIO (data in and data out). So the "OEB" bit of the GPIO is controlled by the configuration, not by an active signal. The user project has a three-signal interface for each GPIO (data in, data out, and OEB), so the

io_oeb

configuration bit doesn't have any useful function. Note that these comments apply to the sky130 version of caravel only. For the GF version I made a better interface with configuration overrides on the signals.

@Tim Edwards Note that this question is in reference to gf180mcu (notice the 10 bit defines as opposed to 13 for sky130). Looking at the constant definitions, and the schematic, I suspect that, as @Leo Moser mentions, the input will not function in bidirectional mode. Am I wrong? Here’s the code from

gpio_control_block

/* These pad configuration signals are static and do not change	*/
    /* after setup.							*/

    assign pad_gpio_inen            =   gpio_inen;
    assign pad_gpio_slew_sel        =   gpio_slew_sel;
    assign pad_gpio_schmitt_sel     =   gpio_schmitt_sel;
    assign pad_gpio_drive_sel       =   gpio_drive_sel;
    assign pad_gpio_pullup_sel      =   gpio_pullup_sel;
    assign pad_gpio_pulldown_sel    =   gpio_pulldown_sel;

    /* Implement pad control behavior depending on state of mgmt_ena */

    assign user_gpio_in = pad_gpio_in;
    assign mgmt_gpio_in = pad_gpio_in;

    /* OE override signal takes precedence over the state of output enable
     * at the GPIO pad.  Otherwise, the OE signal comes directly from the
     * management SoC or the user project depending on the state of
     * the management enable signal.
     */
    assign pad_gpio_outen = (gpio_oe_override) ? gpio_outen :
			((mgmt_ena) ? ~mgmt_gpio_oeb  : ~user_gpio_oeb);

    assign pad_gpio_out = (mgmt_ena) ? mgmt_gpio_out : user_gpio_out;

gpio_inen

is static and zero in the

BIDIRECTIONAL

modes. It should probably be the opposite of

pad_gpio_outen

in

BIDIRECTIONAL

mode only.

Thanks @Mitch Bailey and @Tim Edwards for the insights and comments. Yes exactly, I am asking for gf180mcu as I am working on a project for it. There I have a simple gpio block that I want to use to read or write from/to the pins, depending on an output enable register. Does this mean that on gf180

io_oeb

has an effect when the GPIOs are set to

GPIO_MODE_USER_STD_BIDIRECTIONAL

?

@Leo Moser I think it has the effect on whether or not

io_out

is output, but I don’t see the effect on

io_in

. 😬

@Leo Moser: Apologies, I'm kind of rushed this morning. I believe you are absolutely right, that the bit setting definitions are a mistake and that INPUT_ENABLE was supposed to be set for bidirectional mode, not OUTPUT_ENABLE. OUTPUT_ENABLE can be anything; since the override bit is not set. The proper definition would be 0x004, not 0x008. You can of course just use the numerical definition in place of the name, so just set the value to 0x004.

@Tim Edwards just to be clear, in bidirectional mode, the input will always be enabled but the output will only be enabled when

io_oeb

is low, correct? If that’s correct, I can log an issue and create a PR.

Thank you both for the clarifications! When I find some time I will set

INPUT_ENABLE

for

GPIO_MODE_USER_STD_BIDIRECTIONAL

and run a caravel-level simulation for my design. Thanks for your help 😃️