So in openframe, the

analog_noesd_io

vs

analog_io

difference is the presence of a 150R resistance. But I was wondering how risky the

noesd

version is ? I thought the pad themselves had some esd structure that would be present anyway (in the gpiov2 block) ?

Depends on the type of ESD event. Yes, there are the standard reverse-biased ESD diodes on the pads to vddio and vssio. However, the usual recommendation is to put a series resistor between the pad and the analog circuit, and then have an additional local pair of diodes at the circuit (for inputs). The additional diode pair, if I recall correctly, is particularly effective for machine-model ESD events. I think a good rule of thumb would be to use the series-resistor-protected connection for high-impedance analog inputs, and the no-ESD connection for analog outputs.

Yeah, unfortunately we don't really know if the user is going to use it for inputs or for output 😅 I was just asking because with the fairly long routing, we already get ~ 100 ohm of resistance just as

met4

trace between the pad and the analog switch selecting use design, so when you add the 150 series R, that starts limiting the usefulness for outputs. In another domain, do we have any vague idea of the parasitics from those internal terminals to the actual QFN pad ?

@tnt: The parasitics can be extracted in magic; it's possible to specify individual nets by name for full parasitic extraction, so you would not need to extract the entire design (which probably isn't practical).

extresist include <netname>

If you know that the route is going to be around 100 ohms anyway, then yes, I would suggest going with the "noesd" connection, and maybe add local diodes somewhere in the core. . . Although if you connect into the user areas with pass gates, the pass gate diffusion should suffice.

Ah yeah, all connections are made through pass transistor, so good point about the diffusion.

Well, I can reproduce that segfault. . . Something new for me to work on.

Sorry to keep you busy 😅 But at least this one is not high priority, we now have a working build of TinyTapout and GPIO PEX was mostly just curiosity to try and model analog path a bit more precisely.