Can someone confirm something about the IO for me....
# sky130
Can someone confirm something about the IO for me. To get a input will pull up, setting the mode to GPIO_MODE_USER_STD_INPUT_PULLUP isn't enough , the oeb and out signal need to be driven to 0 & 1 respectively ? I thought that mode would enable the pullup no matter what and so in the chip I have oeb set to 1 and out set to 0 to disable the output buffer but I couldn't observe the pullup and re-reading the doc, I think tha might be the issue why I'm not seeing the pullup on the IO.
Just for background (I think you've figured this out already): The I/O pads have a very weird setup for pullup and pulldown. Rather than just coupling in a resistor to power or ground like you might expect, they just couple a series resistor from the output buffer to the pad (specifically, they have separate resistors on the negative and positive sides of the output buffer, so that the output buffer can drive one direction strongly while it drives the other direction weakly). The pullup or pulldown function is then a combination of (1) connecting the series resistor from output buffer to pad, and (2) turning on the output buffer and setting it to 1 (pullup) or 0 (pulldown). Now some of the pad configuration is manipulated inside the
module. As you noted above, the DM setting that enables pull-up or pull-down has to be combined with OEB set to zero and the output value set to 1 (pullup) or 0 (pulldown).
line 239 specifically overrides the output value appropriately for pullup or pulldown function. The caveats are: (1) There is no equivalent override for OEB, mainly because it's just a configuration bit; and (2) There is no automatic override of the output value for user, as opposed to management, pullup or pulldown mode. Number (2) seems to be an oversight, while (1) is intentional. Conclusions: (1) The bit definitions for GPIO_MODE_[USER/MGMT]_STD_INPUT_[PULLUP/PULLDOWN] all need to clear bit one or else the function won't work properly. That means the definitions should be fixed as follows:
Copy code
And (2), For the two user modes, the output must be set appropriately to 0 for pulldown function and 1 for pullup function, and this oversight should be corrected for the next version of caravel/caravan.
I will generate issues in the issue tracker for caravel.
Thanks for confirming. My logic doesn't drive the output / output enable pins properly so nothing I can do about that, but needing an external pull up isn't a big deal ( compared to the rest 😅 )
Although ... seems I could just configure it as a management input and the input signal would still be wired to the input of my logic.
Yes, that should work!
Question: Do you have to run your chip at a very specific voltage? Mine would only run for any length of time at 1.79V and would fail after a few clock cycles if I moved the voltage up or down by 10mV (!).
Oh yeah, I run it at ~1.326V and there is only a range of ~ 10-20 mV where it works. Exact value depend on the die.
And there is only ~ 50% of the dies where it works at all.
That matches my experience exactly, within limited statistical variation. I got two boards sent to me by Jeff. One worked, the other didn't. The one that worked would only work at a specific voltage in an approximately 10mV range.
Is there some power sequencing requirements btw ? On my test bed I have this weird issue where the chip dos nothing (despite repeated resets) when I have the chip plugged into the test bed when I power the test bed. I have to unplug the chip and replug it for it to start working ... not really sure what's up with that. Or maybe it doesn't like slow power ramp-up ( voltage being driven from a buffered RC filtered PDM means very slow rampup on power on ... ).
The one thing I can think of is that the power-on-reset circuit is generating a 15ms delay after detecting a good 3.3V supply before lifting reset. However, that's done assuming some future version with on-board LDOs. With an off-chip 1.8V supply, you could end up with unknown behavior if you brought up the 3.3V supply first, and the 1.8V supply came up more than 15ms later. Which could entirely depend on the specific LDO chips used.