@User, @User, @User , @User (is Estelle on the Slack channel?): I had to get moving on a solution for the analog pad because I need to have the analog project wrapper done and ready for people to use in a few days. So I created a new pad

sky130_ef_io__analog_pad

which now installs from the custom section of open_pdks. It is basically what I suggested, which is a power pad with the clamp circuit yanked out of it, and all metal removed from around the pad except for the pad ring busses. I threw a deep nwell under the whole thing for good measure. I have no idea if it will meet the 5GHz bandwidth requirement, but it is as much as I can do with relatively simple edits.

Hi Tim, Thanks for the efforts. It seems that the P_CORE and P_PAD are both disconnected in netlist and layout. Does it intend to let user choose how to connect them? Thanks

@Can Wang: Since you found the reason. . . any better luck with running LVS? The pad and all its related files are essentially untested, except by you, so if you find anything, let me know.

Hummm, still can't pass lvs. I am double checking the setup, netlist and layout. In the extracted spice netlist of layout, the in/out pin was merged together since they are essentially shorted. This doesn't look correct.

@Can Wang: I'll take a closer look at the netlist. I just saw that it had identified and extracted the metal resistor distinguishing the pad from the core.

Thanks! @Tim Edwards Just to attach some the results I had. In the

EXT

file, all ports are set. However, port

in

disappears when I execute

ext2spice -o

. I think it might be because some of the setting I used to extract netlist is wrong. For extraction, I basically run

extract all

,

ext2spice lvs

and

ext2spice -o ./lvs.spice

. From what I am seeing, magic merge port

in

to port

P_CORE

, then

P_CORE

is merged into a internal port of

m3_xxx

, which is one node of a resistor. Given all that, in the extracted netlist, there are no metal resistor and port

in & P_CORE

. Do you think the extraction step I used looks correct? Thanks

It's a little hard to tell what it's supposed to be without looking at the layout of "pad_con".

FYI (Forgive the ugly drawing... @Tim Edwards

The drawings are a lot less ugly if you use "magic -d OGL" or "magic -d XR". With "magic -d XR" you can use "plot svg" to get an inkscape-ready graphic.

Thanks! That makes a lot of sense why this keeps happening. I had some trouble to label the P_PAD as

out

. I will redo the pin label and delete the extra m5 and try it again.😃@Tim Edwards

To label the pad, you just need to paint a square of metal5 on top of the center of the pad and then label it. Use Edit->Text... and in the text pop-up window, click the "port" checkbox, and make sure the port is defined on metal5.

Yeah, that's essentially what I did. But most of the time the problem might appear when I

port make

the labels.

This is what I get when I read the analog pad (displaying only rmetal5):

This is mine...

I wouldn't expect that to make a difference for the pad.

image.png

You are about 45 commits behind on magic, so you should probably update that as well. The PDK is only supposed to require rev 111, but it's possible that there is something dependent on a later revision that I'm not aware of. The PDK is 61 commits out of date, though, so definitely due for an update.

Sure, I will update them and try again. Thanks a lot! @Tim Edwards

@Can Wang: That's in line with my expectations, actually a bit higher bandwidth than I was expecting. I knew the power rails across the bottom and top of the pad would be the largest coupling components, and I was hoping that it would not be necessary to redraw the padframe rings and move them further from the pad. That could be done, but would be a pain. Good to know it will hit the target without more invasive changes. However, if you need such changes, just let me know.

Thanks for the efforts! @Tim Edwards Really appreciate it!