https://open-source-silicon.dev logo
Join Slack
Powered by
Chip-3 <https://github.com/UAH-IC-Design-Team/sscs...
# ieee-sscs-dc-22
m
I’ve found that hierarchical extract works best if there are pins defined at every level. You can look at the extracted netlist and find subckts with ‘#’ in the port names - I suggest adding layout pins.
Copy code
Cascode_Amp
cap1
cap128
cap16
cap2
cap32
cap4
cap64
cap8
full_IC_1
r_250
This design has several stand-alone devices that can not be extracted with 
user_analog_project_wrapper
ports (because the interface is fixed). I suggest labeling with labels such as 
amp1_vss
, although this may take some experimentation. Might want to add substrateCut 
81/53
to regions with separate substrate connections.
m
@Mitch Bailey Thank you so much! This is super helpful. LVS: Each of our designs is LVS clean. We each had to handle certain difficulties (such as transmission lines for Brazil or a controller with OpenLane clock tree generation for my SAR ADC) that we handled each rather differently. So we decided to blackbox at the top level for LVS. I added 
spice_stop
markers in xschem to force the netlist generation to only one level and then added 
model {….} blackbox
to the netgen tcl file. Apart from the issues previously mentioned to you we are in the process of resolving it seems to be working. However, I’m totally open to using a different method like you’re describing here. Would you recomend I try a full hierarchical extract? What do you mean by “find subckts with ‘#’ in the port names”? With the layout pins on the caps, they are technically subcircuits wrapping arrays of caps that get parallel merged together in the LVS (it is clean). In the schematic each of them are simply a single primitive capacitor. How would you advise adding pins to those? It would make LVS easier to read.
m
Would you recomend I try a full hierarchical extract?
If it’s possible. I’ve seen many errors missed when black-boxing. Black-boxing is ok for intermediary checks, but the final check should be full hierarchy, IYAM.
What do you mean by “find subckts with ‘#’ in the port names”?
Copy code
.subckt Cascode_Amp w_n28102_1439# a_37501_4001#
...
.subckt full_IC_1 vss_uq0 vss pll_controller_0/s_in a_n5863_11174# a_24731_n15678#
In the schematic each of them are simply a single primitive capacitor. How would you advise adding pins to those?
Those I’d suggest flattening. When extracting from gds,
Copy code
gds flatglob cap*
gds read <gds-file-name>
l
The standalone cells are under my design, and I envisioned them to be isolated from the caravan IO pins (and thus I thought to leave them without any labeling). Would it work better if I named the pads and added a noConn cell in xschem? And what exactly is this substrateCut layer? Is it just to aid LVS in seeing different bulk domains or does it imply some kind of physical separation/isolation in the die?
m
@Leonardo Gomes I beleive the substratecut layer is only an LVS marker. I’m working it in now
m
@Leonardo Gomes substrateCut layer is just to separate the substrate regions in LVS. I can ignore the stand alone devices and do LVS on the rest of the chip, but by adding text to the layout and the corresponding cells to the schematic, you can do LVS with these cells included.
m
@Mitch Bailey I’m working on that now 🙂
Thank you so much for your help
@Mitch Bailey Are there general things I should know about using the substratecut layer? It seems to cause Magic to fail extracting without error (magic simply stops extracting and returns to the normal tcl prompt) from the GDS. I’ve deduced that deep nwells + substratecut layer don’t work well ( which makes sense), but there’s something else still causing issues and I haven’t figured out what it is yet.
m
I add the 
substratecut
layer in klayout at the 
user_analog_project_wrapper
level. If you’re trying to add in magic, I believe it goes on the same plane as nwell or dnwell so they can’t overlap. You might be able to add them at a higher level.
2 Views
Open in Slack
PreviousNext
Powered by