@Tim Edwards can you please clarify the purpose/need of the functionality of controlling the io_oeb from the wrapper pin? Am I correct in assuming that as the microcontroller and user_defines.v can manage and control the IO functionality using code, we dont need to do anything to the io_oeb pin?

On the Sky130 version of caravel, if you configure the GPIO for user control, then it expects that you will set the

io_oeb

pin appropriately. On the GF180MCU version of caravel, I realized that some users were misunderstanding the interface and not connecting the

io_oeb

pin, so I added another configuration bit that allows the pad OEB state to be forced by the configuration bit instead of the pin. So what you say is true for the GF180MCU version but not true of the Sky130 version (although I may add the extra bit to the Sky130 version for some future MPW).

@Tim Edwards Thanks. How should we then set io_oeb on the wrapper for sky if we are sharing functionality of one io cell between multiple circuits? So one circuit using input and one using output with the intention of programming the required mode using the SOC.

Tie it to zero. For inputs, you can always set the pad configuration for a management input, but the input signal always goes to both management SoC and the user project, regardless of the setting. And with the management enabled setting, you can configure it with the output shut off so that it is a proper input pad.

@Tim Edwards ok so just to confirm. Inputs can be set as "MGMT_INPUT" in the defines and we dont need to tie ioenb anywhere. Outputs need to be "USER_OUTPUT" with ioenb pin tied low. Shared IO can have ioenb tied low but can be made a proper input by setting it as a "USER_INPUT" in software or can be made into a output by setting it as "USER_OUTPUT" . Is that correct? Thank you for your time.

Everything there is correct except that 'Shared IO can have ioenb tied low but can be made a proper input by setting it as a "MGMT_INPUT" in software'.

Please keep the behaviour of the Caravels in sync between GF180 and Sky130 as much as possible

@Philipp Gühring: Generally, I do, but sometimes it becomes obvious that a modification is badly needed, in which case I will make a change with the intention of making the same change to the other version(s) for the next MPW run. Having an extra control bit to work around a common user misunderstanding was one of those much-needed modifications, and will get added to the sky130 version of Caravel when I have the time to do it.

Actually I was surprised there are different Caravels at all, I thought there would be just one single Caravel which would automatically parameterize itself internal to work on the various PDKs.