<@U017X0NM2E7>: Ask this in the <#C016H8WJMBR|ope...
# verification-be
t
@User: Ask this in the #openlane channel because it appears at first glance to be an issue with the openlane scripts, or maybe just the setup you made for running openlane. Magic will always generate subcircuit wrappers if the cell top level has ports and the option "ext2spice subcircuit top on" is selected.
m
@Tim Edwards As always, thanks for the quick response. I'll change the openlane script to see if the "ext2spice subcircuit top on" setting makes a difference. If it's missing, I'll move the issue to openlane. BTW, is this seting new?
t
No, it's usually just done implicitly by the cover-all
ext2spice lvs
command.
m
@Tim Edwards I think I've narrowed the issue down a bit.
ext2spice lvs
is being set, but there are no ports in the ext files extracted from the gds. In the output spice, lower level circuits have ports (even with no ports in the ext file), but the top level has no wrapper. Can you verify that even if
ext2spice subcircuit top on
(
ext2spice lvs
) is specified, the top level will not have a subcircuit wrapper if the cell has no ports? (the issue on github has a simple test case) My guess now is that either the GDS was created without the port information, or magic's tech file isn't recognizing the layers for ports as they are being read in. In either case, it would be an open_pdks issue.
t
Neither would be an open_pdks issue. If the ports aren't in the GDS, then it's the responsibility of whatever tool was creating the layout to add ports. If it's the GDS read-in, then in should be using
cif istyle sky130(vendor)
to make sure the ports get read as ports.
m
@Tim Edwards Thanks again for the hints. I'll continue to look into it. It may have something to do with me trying to run LVS on mpw-1 designs using the current openlane.
@Tim Edwards You were right. The openlane scripts are missing the cif specification. Adding that line results in valid spice file generation. I'll see if I can make a pull request (or 2). The gds merge function does not appear to specify the cif option either. It does use gds readonly, though. Would that keep the port definitions in the merged output gds?
t
There's a point at which the GDS is only going straight to manufacture, and the labeling/ports won't make any difference. But yes, it would be better to have the right input style.