@Mitch Bailey, we are getting the OEB error for digital inputs and output, please see the screenshot. We have tried the user_defines.v settings you adviced here: https://open-source-silicon.slack.com/archives/C02096M650E/p1694936784747689?thread_ts=1681286955.054969&cid=C02096M650E However, we still get the failed state. What do we EXACTLY need to do to void this for both digital input and output using GPIO? Thx in advance! cc @Mario Romero @Alfonso Cortés

@Jorge Marin the only error that you absolutely have to fix is for gpio 7. This is an output pin, but oeb is not connected to anything. If you want the output to always be active, connect

io_oeb[7]

to logic low. The other warnings maybe not be a problem depending on your

user_defines.v

. It’s probably good practice to tie the unused

io_out

high or low and the unused

io_oeb

high.

(@Tim Edwards this is the issue mentiones in the other thread) @Mitch Bailey Thanks for your reply, we have tried connecting to logic low manually in magic (we are using analog-on-top approach), but we get the same issue We have also tried to check in the local precheck script what is it exactly that is being checked but can't get it (by the way, the local precheck reports error for digital input, nit warning, which is confusing)... can you maybe elaborate on this? Like, how does the check find out if there is a low connection, is it aware of the grounds or anything? We just wnt to make sure we have a simple case that passes, can you give some advice on how to do that? which low signal in the caravan is for sure available and removing the error?

The oeb check uses the extracted netlist. The expected input levels are vssd1/vssd2 or vccd1/vccd2.

@Jorge Marin: If you want to tie off a digital control signal, it cannot be tied to an analog ground, as that crosses domains and becomes an ESD issue. You should always tie it off to the user digital ground.

@Tim Edwards indeed, thanks for the comment, this was just for testing My question is: what is conceptually a digital low int eh caravel? a connection to the digital GND pin would be enough? can you explain a bit what the check that generates the OEB error actually does?

Ideally, you should use a digital

conb

cell and connect to the OEB line from that, but yes, you should be able just to connect it directly to

vssd1

. The check was needed because we got too many projects which would fail because the user (1) did not connect OEB, and (2) did not do a top-level simulation (which would have caught the error). So the check looks at every user

in/out/oeb

net in the netlist (extracted from layout, I think) and makes sure that the use of

oeb

is consistent with connections to

in

and

out

. What each of the three pins is connected to will indicate whether the pad is intended to be used as an input, and output, or bidirectional. If the wiring is inconsistent with intended use, the pins will be flagged as an error.

OK, thanks to both, we are trying a new precheck, will keep you posted

There may be a problem with the oeb check return codes causing the check to fail. However, it is probably a good idea to tie unused

io_out

to high or low and tie unused

io_oeb

to high.

How can we confirm this? We have spent a full day trying to understand the problem, we would really appreciate if you help us debugging it

Someone with access to the platform needs to check that the return codes warnings only on the oeb check are not fatal. @omla @Marwan Abbas You could also (should) tie all the unused

io_oeb

to high. The sky130

caravel_core

buffers

io_out[6:0]

and

io_oeb[6:0]

, so unless you connect those, you might have leak current there.

@omla @Marwan Abbas @Tim Edwards @jeffdi we would really appreciate your help with this, as mentioned by @Mitch Bailey

(@Jorge Marin: I do not have access to the platform---This will have to be handled by Jeff or Omla.)

@Tim Edwards thanks, how can I reach them?

@Jorge Marin hi. it looks like the issue is related to error code reporting for this check when there is a warning. I’ve gone ahead and submitted a override tapeout for your project based your last precheck.

@jeffdi hello, we got a big delay with this and we found several issues with lvs in our design, not a good scenario We may still need to do some precheck-tapeout loops, how to manage this issue in this context?

Ok. I would suggest running precheck locally if you can. Then submit on the platform when ready and ping me to run tapeout.

Ok, thanks

@Jorge Marin, both

mpw-precheck

&

tapeout

have been updated on the platform, feel free to try again.

ok, thanks

> • should we connect ALL the io_out pins which are not used as outputs, even if they are used as inputs? yes. on the the input pads, set

io_oeb

to high just to be safe. > • are the io_out and io_oeb recommendations also valid for functional pins 0 to 6, used for housekeeping? Yes, definitely. Turns out that because of the distance from the user_project to the pads, these signals are actually buffered in

caravel_core

before reaching the respective gpio_control_blocks. Unconnected inputs to buffers can cause leaks due to Hi-Z input because both the nmos and pmos might be on.

@Mitch Bailey, just to confirm • The

io_oeb[x]

of a GPIO that is used as output must be connected to low • The

io_out[x]

of a GPIO that is not used as output should be connected to low or high • The

io_oeb[x]

of a GPIO that is used as input should be connected to high

@Alfonso Cortés basically, that is correct. More exactly, anytime a gpio is used as an output

io_oeb[x]

should be low. It doesn’t have to be fixed low, because bidirectional pads are also allowed. Sometimes they’re in input mode,

io_oeb[x]

is high and when in output mode,

io_oeb[x]

is low. For input gpio, the user_defines.v values for each block may cause the io_oeb value to be irrelevant, but tying high avoids the possibility of error.