https://open-source-silicon.dev logo
Join Slack
Powered by
<@U0175T39732>: The problem is not in netgen; th...
# verification-be
t
@User: The problem is not in netgen; the problem is that magic interprets the "comment" layer as electrically significant, and because it abuts between cells, it has a connectivity that isn't just optimized out by netgen. The solution if for the magic techfile "extract" section to add the line 
resist comment None
so that the "comment" layer will not be considered for extraction (come to think of it, I need to do this in the SkyWater tech file).
m
Interesting. Well, this wasn't an issue until that commit of netgen. The same netlists pass before.
Do we need to also patch the scmos tech files then?
Because this was the standard scn4me_subm technology
t
Somewhere in there, netgen got more rigorous about checking pin connections. I tend to think that it should be considered a netgen issue, in that netgen should be able to determine that the pin connects to nothing and is therefore not electrically significant and should be ignored. Ultimately, though, it's wrong for magic to insist that there is a "node" made up of layer "comment" and that it somehow makes a connection between two cells. I don't recall in the past any standard cells having a comment layer that bounded a cell---as long as comment layers are not overlapping between cells, the issue would not come up.
I guess it should be considered an error in netgen, though, because you could easily do the exact same thing with an electrically significant layer, such as a floating piece of metal1 that connects between two subcells; the extraction would be correct to flag the floating metal1 as a node and as a pin that connects between two cells, but you would not normally consider that such a construct would ever show up in a schematic netlist. But I need to be careful about how I fix it in netgen, because it got broken when I did something to fix another issue. I have an intern working on setting up continuous integration scripts for netgen. Once that's done, it will be a lot easier to check that fixes don't break existing behavior.
m
That's a good internship project!
t
It's not a high school internship; I'm mentoring somebody for Kunal. Generally less time tutoring and more time making progress.
m
@Tim Edwards If you remove the absolute program paths in the 
run_ext.sh
and 
run_lvs.sh
scripts of the 
sky130_sram_macros
, you could get a pretty thorough regression test, I think.
m
Yes, I think that sort of DevOps would be too much for high school
4 Views
Open in Slack
PreviousNext
Powered by