<@U01TQB7GQHW>, <@U01U5Q2MQ3Y>, <@U01RNKP9R0B> , <...
# analog-design
@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
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.
🎉 5
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
Oops, correction. It seems that it is connected through M5/M4/M3 resistor in the netlist. But the P_PAD Pin in layout is only on M5.
I have tried to run a LVS with Netgen but it fails. The pad was warpped to a four-pin subckt. The extracted netlist(
) from magic layout reports zero nodes. In this netlist, the pad was recognized as a min cap. Does this look correct to you? Or maybe I am doing something wrong... Please let me know if you think somethin is wrong. Thanks!
OH, I found the reason. The GDS was accidently changed when I convert it back to
@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.
@Tim Edwards Hi Tim, what's the threshold you set for extraction resistor?
@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.
@Can Wang: If you're doing R-C extraction with magic, then I use the standard tolerance of 10. However, if it is not extracting the LVS netlist correctly, I wouldn't put much trust in the parasitic result.
Thanks! @Tim Edwards Just to attach some the results I had. In the
file, all ports are set. However, port
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
ext2spice -o ./lvs.spice
. From what I am seeing, magic merge port
to port
, then
is merged into a internal port of
, 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
BTW, I painted a psub contact that connects sub to the GND pin
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.
@Can Wang: For one thing, you can't connect to the pad like that. The "m5 resistor" is just a hack way of separating the pad net from the core net, even though they're both electrically connected. SkyWater chose to cut the net in half by putting the "m5 resistor" around the edge of the pad. So if you drop metal5 across that resistor like you're doing with the "out" pin, then you just shorted across that resistor and so shorted P_CORE to P_PAD.
Thanks! That makes a lot of sense why this keeps happening. I had some trouble to label the P_PAD as
. 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.
The problem is most likely that magic wants to attach a label to some layer, and if you don't have the layer in the same cell as the label, it will think the label is floating in space, unless you flag it as a "sticky" label.
Yeah, that's essentially what I did. But most of the time the problem might appear when I
port make
the labels.
I see. Then, I will just follow the standard way to do this. Thanks a lot for the explanations! @Tim Edwards
@Tim Edwards Hi Tim, it might be strange that there seems no m5 resistor layer on the edge of the pad frame... So, the
pin in my extraction results still merges with some internal nodes of pad_and_busses subcell. I've also checked original power pad, it looks like there is no rmetal 5 layer.( I've drawn a rmetal 5 on the side for reference) However, I noticed that when I read the gds, there are several sub-cells missing. I tried reload the latest tech file and it didn't work. Could you give some hints on this issue? Thanks!
This is what I get when I read the analog pad (displaying only rmetal5):
This is mine...
my sky130A version is older than yours. I will try to update that first.
I wouldn't expect that to make a difference for the pad.
But it is also odd that you are seeing DRC errors under the pad for the top_power_hvc_wpadv2 cell (could be an issue with an older magic version), and you are missing the rdl and ubm layers in the tech file (that could be the issue with the older technology version). What are your versions of magic and sky130A?
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
Hi Tim, thanks for the suggestions along the way @Tim Edwards. I was able to extract the pad and run a quick simulation on the analog_pad. Applying a stimulus through a 50-ohm ideal resistor to
and observe the output at
. A 3-dB bandwidth of ~16 GHz is observed. It should be enough for most of the applications in sky130. For your record, most of the parasitic comes from the overlap between
(pad ring metal structure).
@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!