I’m working on a gpio default checker for caravel/caravan. Here are the current specs. There’s a link to a truth table with the sky130 mpw-7 results on a separate tab. Comments are appreciated. One current concern is that analog and digital connections to the same gpio are flagged as errors. In the case of multi-project designs, it is possible that one design would want to use a gpio as digital and another design use the same gpio as analog. Reprogramming the gpio as ANALOG works for the analog case, but even if the gpio is programmed as a digital input/output, the analog connection remains. This will still work if the analog project uses the gpio for input only or disables the output if used for output. However, analog output that is not disabled will possibly interfere with digital input/output. Another problem also related to multi-project designs is that when a gpio has both input and output connections, the checker flags an error if the default is not BIDIRECTIONAL. It is possible that one module wants to use the gpio as output and another as input, but never both at the same time. The gpio would be reprogrammed according to the intend usage. So 2 problems with the current check program: 1. mixed analog and digital usage 2. mixed input and output usage (not bidirectional) I have some ideas about solutions, but would like to hear community suggestions.

I would like to also allow

GPIO_MODE_USER_STD_OUTPUT

for fixed outputs, for the use case where I pull the pin up/down during boot and then reconfigure it to

GPIO_MODE_MGMT_*

from firmware.

@htamas thanks for the input. What’s the difference between having (advantage of allowing) user driven pull up/down during boot and using

GPIO_MODE_MGMT_STD_INPUT_PULLUP

or

GPIO_MODE_MGMT_STD_INPUT_PULLDOWN

as the default and reprogramming from firmware.

That should be fine as well. Didn't consider using

INPUT

modes for output functionality. By the way, how do the drive strengths compare?

The drive strengths for the dm[2:0] combinations are here. And here are the bit values for the constants

I'm not sure I completely get it. Let's assume I set the default mode as

GPIO_MODE_MGMT_STD_INPUT_PULLUP

. Then the output will be either a weak 1 or a strong 0, depending on the output from the management core, which hasn't finished booting yet. Am I missing something?

The

gpio_control_block

will set the pull up/down levels for

mgmt

modes. From

caravel/verilog/rtl/gpio_control_block.v

/* For 2-wire interfaces, the mgmt_gpio_oeb line is tied high at    */
    /* the control block.  In this case, the output enable state is     */
    /* determined by the OEB configuration bit.                         */

    assign pad_gpio_outenb = (mgmt_ena) ? ((mgmt_gpio_oeb == 1'b1) ?
                        gpio_outenb : 1'b0) : user_gpio_oeb;

    /* For 2-wire interfaces, if the pad is configured for pull-up or   */
    /* pull-down, drive the output value locally to achieve the         */
    /* expected pull.                                                   */

    assign pad_gpio_out = (mgmt_ena) ? ((mgmt_gpio_oeb == 1'b1) ?
                        ((gpio_dm[2:1] == 2'b01) ? ~gpio_dm[0] : mgmt_gpio_out) :
                        mgmt_gpio_out) : user_gpio_out;

pad_*

signals connect to the actual gpio.

mgmt_*

signals are mostly from the management core (

mgmt_ena

is the low bit of the gpio defaults).

user_*

signals are from the user area.

gpio_*

signals are the programmed constants. In response to your question, for

GPIO_MODE_MGMT_STD_INPUT_PULLUP

and

GPIO_MODE_MGMT_STD_INPUT_PULLDOWN

, (if

mgmt_gpio_oeb

is high), the output level is determined by the constant

gpio_dm[2:0]

and is not dependent on the

mgmt_gpio_out

level. I suppose there could be a problem if

mgmt_gpio_oeb

was low during power up. @Tim Edwards are the

mgmt_gpio_oeb

levels guaranteed during the power on sequence?

Ok, so if

mgmt_gpio_oeb

is high, then

GPIO_MODE_MGMT_STD_INPUT_PULLUP

is guaranteed to put a weak 1 on the pad (as opposed to a strong 1 with

GPIO_MODE_USER_STD_OUTPUT

, but it should be fine as long as the interfacing IC doesn't use a pull-down).

Ok, so if

mgmt_gpio_oeb

is high, then

GPIO_MODE_MGMT_STD_INPUT_PULLUP

is guaranteed to put a weak 1 on the pad (as opposed to a strong 1 with

GPIO_MODE_USER_STD_OUTPUT

, but it should be fine as long as the interfacing IC doesn’t use a pull-down).

That is my understanding.

Let’s say I’d like to use a pin as an output from the user project, but also send it to the management core

In this case, I believe the expected default is

GPIO_MODE_USER_STD_OUT_MONITORED

although technically your suggestion of

GPIO_MODE_USER_STD_OUTPUT_BIDIRECTIONAL

would also work. The only difference between the 2 defaults is the

OUTPUT_DISABLE

bit, but as shown in the

gpio_control_block

code above, this bit (

gpio_outenb

) is not used in user modes.

@Mitch Bailey: What exactly are you considering the "power on sequence"? The power-on-reset circuit holds the pads in tristate until it flips after the 3.3V power is applied. There is an assumption that the 1.8V power is good by the time the power-on-reset signal flips. Assuming that's true (it should be, for the development board), then all of the digital (including the GPIO defaults and the management processor and housekeeping) are in the default state at that time.

@Tim Edwards thanks. I think the power-on-reset signal answers the question related to levels at power up. All gpio buffers will be in a Hi-Z state. I’ve been telling people that the

GPIO_MODE_MGMT_STD_INPUT_PULLDOWN

mode is equivalent to the

GPIO_MODE_USER_STD_INPUT_PULLDOWN

mode but you don’t need to set

io_out

and

io_oeb

if you use

GPIO_MODE_MGMT_STD_INPUT_PULLDOWN

. Looks like this might only be correct when

mgmt_io_oeb

is high. Is

mgmt_io_oeb

high by default?

mgmt_gpio_oeb

is tied high for all GPIOs except 0, 1, and 35 to 37.

So

GPIO_MODE_MGMT_STD_INPUT_PULLUP/DOWN

may not be strictly equivalent to

GPIO_MODE_USER_STD_INPUT_PULLUP/DOWN

with the correct

io_out

and

io_oeb

for all gpio. For these 5 gpio in

GPIO_MODE_MGMT_STD_INPUT_PULLUP/DOWN

mode,

INPUT_DISABLE

will be low, meaning

mgmt_gpio_oeb

will also be low when the management function is not active. This means that

pad_gpio_outenb

will be low and

pad_gpio_out

will be

mgmt_gpio_out

which may or may not be the level expected. Is that correct?

@Mitch Bailey: You want to set the input disable bit high in the configuration in the housekeeping module which is, in effect, how you can directly control the OEB signal for those five pads. It's a bit of a roundabout method. If I had given it a bit of thought, I probably could have come up with something not so confusing.

@Tim Edwards not sure I completely understand the difference between the configuration in the housekeeping module and the actual configuration stored at the

gpio_control_block

in this case. Let’s say the user wants to use a gpio for input with a pullup/down but didn’t connect the user

io_out

and/or

io_oeb

. For gpio 2 - 34, I believe using

GPIO_MODE_MGMT_STD_INPUT_PULLUP/DOWN

will work. For gpio 0, 1, 35, 36, 37, will it be a 2 step process? First, program the gpio with

GPIO_MODE_MGMT_STD_INPUT_PULLUP/DOWN

, and then overwrite the configuration in the housekeeping module for that gpio with a value that has

INPUT_DISABLE

high? So the gpio is actually in input mode, but the housekeeping module thinks input mode is disabled.

Yes, that's the way I think it works according to the verilog code in the control block and the housekeeping block.