Could I get some help in configuring the GPIO in openframe projects for analog signalling? Reading the docs here, it seems to me I have to do a combination of configure the drive mode to 000, and something involving the analog_en, pol, and sel signals. But, this diagram here suggests to me that maybe pad_a_noesd_h is the same as analog_noesd_io (and analog_io the same as pad_a_esd)? and thus, we don't need to configure anything else to be able to use the pads? (other than oeb)

You probably don't want the "analog_sel/pol/en" signals. Those enable a sort of switched-capacitor function on two common buses amuxbusA and amuxbusB running around the padframe. Just set the DM[2:0] bits to 000, as you mentioned, and then drive the signal through one of the "pad_a_esd" or "pad_a_noesd" pins (rule of thumb: If it's an input, use "pad_a_esd" to avoid hitting FET gates with an ESD event. If it's an output, it's probably okay to use "pad_a_noesd", especially if the series resistance of "pad_a_esd" would be a problem). Yes, "analog_noesd_io" connects to "pad_a_noesd_h", and "analog_io" connects to "pad_a_esd_0". However, you still need to drive the DM [2:0] bits to make sure that the digital buffers are turned off.

Also setting

inp_dis

has been recommended to me to avoid the input buffer ending up using power if the input is in the middle range.

You can view this schematic in xschem here. https://github.com/d-m-bailey/sky130_fd_io As for the configuration, the simplest solution might be to mimic the gpio default settings used for caravel.

sounds good and as always, thanks for the replies all!

@Xiaochen Ni good questions. I assumed that you’d want the power enable signals like

enable_vddio

high (or linked to chip reset), but if you’re just using the gpio for analog, that may not be necessary. My (rather uninformed) suggestion is that if you plan to use any configuration other than something mimicking the standard caravel implementation, that you verify with simulation.

@Xiaochen Ni: The GPIO setup is quite complicated. I would recommend what Mitch said, which is to follow what was done in Caravel. The easiest way to see that is in

verilog/rtl/pads.v

, although it still needs some interpretation:

.OUT(Y_OUT),    \
                .OE_N(OUT_EN_N), \
                .HLD_H_N(loop_one_``X), \
                .ENABLE_H(porb_h), \
                .ENABLE_INP_H(loop_zero_``X), \
                .ENABLE_VDDA_H(porb_h), \
                .ENABLE_VSWITCH_H(loop_zero_``X), \
                .ENABLE_VDDIO(CONB_ONE), \
                .INP_DIS(INPUT_DIS), \
                .IB_MODE_SEL(CONB_ZERO), \
                .VTRIP_SEL(CONB_ZERO), \
                .SLOW(CONB_ZERO),       \
                .HLD_OVR(CONB_ZERO), \
                .ANALOG_EN(CONB_ZERO), \
                .ANALOG_SEL(CONB_ZERO), \
                .ANALOG_POL(CONB_ZERO), \
                .DM(MODE), \
                .PAD_A_NOESD_H(), \
                .PAD_A_ESD_0_H(), \
                .PAD_A_ESD_1_H(), \
                .IN(Y),  \
                .IN_H(), \
                .TIE_HI_ESD(loop_one_``X), \
                .TIE_LO_ESD(loop_zero_``X) )

"CONB_ZERO" means the signal is tied to "LO" on a digital 1.8V "conb_1" cell from the standard cell set. "CONB_ONE" means the signal is tied to "HI" on a "conb_1" cell. Signals on net "loop_one" are getting set by the output TIE_HI_ESD, which is an output from the pad providing a logic high value in the 3.3V domain. Signals on the net "loop_zero" are getting set by the output TIE_LO_ESD, which is an output from the pad providing a logic low value in the 3.3V domain. Net "porb_h" is an output from the Power-on-reset circuit (in the 3.3V domain). Signals with no connection

()

are left unconnected.

Hi Tim, thanks for the info. From my understanding, my current plan is to create a tie cell, with a bunch of conb_1 cells in order to tie all the gpio pins on the wrapper to the correct bit values, all the values for which i get from

caravel/verilog/dv/caravel/defs.h

. My only confusions come from the

ENABLE_

and

HLD_H_N

signals, since I don't see these on the gpio wrapper. Is it safe to assume I can ignore these?

Be aware that all signals with names ending in

_H

are 3.3V domain and to set them to a constant value, you need to loop back a signal to TIE_HI_ESD or TIE_LO_ESD (which are in the vddio 3.3V domain). Some of these connections are made inside the wrapper cell, so if you do not see the signal exported from the wrapper, then you don't need to handle it yourself.

Wait, in the OP it said "openframe" project. Wasn't all the level translation handled in the provided pad ring itself ?

@tnt The chip_io_openframe block has internal 3.3V domain tie high/low signals not visible in the user project wrapper and separate from the 1.8V tie high/low signals available for each gpio in the user project wrapper.

wire [`OPENFRAME_IO_PADS-1:0] loop0_gpio;	// Internal loopback to 3.3V domain ground
	wire [`OPENFRAME_IO_PADS-1:0] loop1_gpio;	// Internal loopback to 3.3V domain power

@Mitch Bailey Yes ok. But so, to come back to the original question of @Xiaochen Ni, he should just use the provided loopback_zero / loopback_one provided by the wrapper which are the only ones visible to the user_project_wrapper and shouldn't touch any of the

_H

signals at all.

@Xiaochen Ni If you are using the

openframe_project_wrapper

, it will be integrated with

chip_io_openframe

. While

openframe_project_wrapper

does have access to many more of the gpio connections, as @Tim Edwards says, you do not have access to all of the gpio connections. The only signals you need to worry about are those available in the

openframe_project_wrapper

. On the other hand, if you are using the gpio cells to add pads internal to the user area for a bare chip, you will need to handle all the 1.8V and 3.3V connections.