management gpio pull up and down doesn't work

[M0stafaRady]

management gpio registers reg_gpio_mode1 and reg_gpio_mode0 don't have an affect in the value of gpio_in_core when floating.

[RTimothyEdwards]

Can you be more specific? Why would they be floating, and why would you expect them to affect gpio_in_core?

[M0stafaRady]

@RTimothyEdwards, I understand that these 2 registers are responsible for writing the dm value for the management GPIO. That means changing them while management GPIO is configured as input would put it in one of these states pull-up, pull-down or no pull. However whatever combination I use the management GPIO is in pull-down state. please correct me if I'm wrong

[RTimothyEdwards]

Are you talking about the sky130 version or the GF180MCU version?

[RTimothyEdwards]

Okay, I assume this is the sky130 version, because mode0 and mode1 names got changed in the gf180MCU version. I think the answer is that the sky130 GPIO cell has a weird way of implementing pull-up and pull-down. If you want pull-up, you will need to (1) configure the DM value for a pull-up function, (2) enable both the output and input, and (3) drive the output to 1. If you want pull-down, you will need to (1) configure the DM value for a pull-down function, (2) enable both the output and input, and (3) drive the output to 0.

[M0stafaRady]

here I'm talking about sky130.
FYI, GF180 also have the same issue but the state is no-pull.

[RTimothyEdwards]

The GF180MCU version doesn't have pull-up and pull-down controls on the management-controlled GPIO, unless we add them to the management SoC.

[RTimothyEdwards]

The GF180MCU version has much worse problems:

`ifdef USE_POWER_PINS
        .VDD    (VDD),          // Common padframe/ESD supply
        .VSS    (VSS),          // Common digital ground
        .gpio_pu_select_core(VSS),
        .gpio_pd_select_core(VSS),
        .gpio_schmitt_select_core(VSS),
        .gpio_slew_select_core(VSS),
`endif

Somehow, signal lines have ended up within the USE_POWER_PINS block for the padframe, and the signals are being passed power supply values instead of digital constant values. And the chip_io.v file does not have the right names for those connections (gpio_pu_select instead of gpio_pu_select_core, for example), so those are floating inputs and need to be fixed.

[M0stafaRady]

) configure the DM value for a pull-down function, (2) enable both the output and input,

I tried this and it doesn't matter what value the dm has unless it not an invalid value 3'h0 or 3'h1. If dm has a valid value the state of input pad caravel_top.uut.soc.core.gpio_in_pad would follow the output value if output is enabled. I don't have a problem with this behavior if it okay with you too.

[RTimothyEdwards]

@M0stafaRady : I have a definite problem if the GPIO is not acting like a pull-up or pull-down when it is configured as such. All the other 38 GPIO behave correctly with respect to the "pullupdown" testbench. Is there a specific testbench and result that you can point to that shows that the GPIO is not behaving as expected? Have you tried analyzing the results to understand why?

[M0stafaRady]

I haven't figure out the reason why it behave like this yet. I created a temp test at branch mgmt_gpio_pu_pd in caravelrepo. you can check the last commit to read the test To run it you just need to run this command ./verify_cocotb.py -t mgmt_gpio_pu_pd -tag mgmt_gpio under caravel/verilog/dv/cocotb after you export MCW_ROOT, CARAVEL_ROOT and PDK