https://open-source-silicon.dev logo
Join Slack
Powered by
<@U016EM8L91B> I'm also not sure where to put netg...
# magic
m
@User I'm also not sure where to put netgen bugs, but I think one was introduced in this commit: commit 064195ecc9e87cc143c35ade2d2ae5e77366dd1b (HEAD) Author: Tim Edwards <tim@opencircuitdesign.com> Date: Sun Jul 11 170450 2021 -0400 Reinstated some code that had been commented out that prints pin information for a non-matching pin in circuit1 and generates a proxy pin in circuit2---there is some case where this is redundant, I think, but I need to find the example. (It's from a while back, but I'm just upgrading!) In this example, you can just run "run_lvs.sh" as the netlist is already extracted. The netlist is pretty simple, just an 8x8 bitcell array. The extracted netlist has a pin "comment_0_0#" that didn't previously cause a problem when mismatching, but now it does. Instead, it now generates 64 proxy nets that don't match.
05_bitcell_array_test.tar.gz
t
The best place for netgen bugs is just the github issue tracker, but here is fine.
m
@User The work around I'm using for 
sram_1rw1r_32_256_8_sky130
in netgen's setup file flattens the effected cells. Takes a couple hours to run, though.
Copy code
flatten class precharge_array "-circuit1 precharge_0"
flatten class precharge_array_0 "-circuit1 precharge_1"
flatten class port_data "-circuit1 precharge_array"
flatten class port_data_0 "-circuit1 precharge_array_0"
flatten class dummy_array "-circuit1 sky130_fd_bd_sram__openram_dp_cell_dummy"
flatten class replica_column "-circuit1 sky130_fd_bd_sram__openram_dp_cell_dummy"
flatten class replica_column "-circuit1 sky130_fd_bd_sram__openram_dp_cell_replica"
flatten class replica_column_0 "-circuit1 sky130_fd_bd_sram__openram_dp_cell_dummy"
flatten class replica_column_0 "-circuit1 sky130_fd_bd_sram__openram_dp_cell_replica"
flatten class replica_bitcell_array "-circuit1 dummy_array"
flatten class replica_bitcell_array "-circuit2 dummy_array"
flatten class bitcell_array "-circuit1 sky130_fd_bd_sram__openram_dp_cell"
flatten class bitcell_array "-circuit2 sky130_fd_bd_sram__openram_dp_cell"
For reference, I've documented everything I needed to do to get LVS to pass on the 
caravel
storage
module which uses 
sram_1rw1r_32_256_8_sky130
here: https://github.com/d-m-bailey/caravel/blob/d-m-bailey-lvs/docs/source/lvs.rst
I believe this is the same issue I logged for netgen here https://github.com/RTimothyEdwards/netgen/issues/29
m
@User Yeah, I never had to do that until this last version, so I'm not sure what is different.
But that bug does look like it matches
netgen 1.5.196 works fine for me since it is before this change
t
It's very hard to pull out connected nets like that in a consistent way. I think for this particular problem the solution is to prevent magic from extracting "comment" (or any non-electrical type) as a node in the extracted netlist.
m
What causes that?
t
Not sure. Maybe historically the "connect" section didn't enumerate all electrically significant layers and so everything is considered electrically significant. I thought I added a way to specify otherwise, which I'm looking for right now. . .
@User: Found it. Using the line "resist <layer> None" in the extract section will prevent <layer> from being extracted as an electrical node. So try "resist comment None".
👍 1
m
@User I don't know how I didn't go back to this, but this didn't fix the problem.
Also, this means going back and fixing all the old magic tech files?
I added it below the other resist in the extraction section of SCN4ME_SUBM.tech
@User Hi Tim, following up on this new port extraction issue. 1) It didn't solve the problem and 2) we'd have to edit all the old tech files.
@User ^^
@User I'm still struggling to fix this error. Changing that option in the extract did not remove it...
@User Looking closer, the "comment_0_0#" in my example was from the bounding box layer. Setting "resist bb None" fixes it, but that would need to be retroactively added to all tech files... instead can it be skipped somehow?
@User Did you change the default value for extract to do extract unique?
t
I could probably put some code into magic that would keep a list of all layers used in device and parasitic extraction, and then automatically remove all the types that aren't in that list, which would remove stuff like comment and bounding box automatically.
No, I did not change the default setting for "extract".
m
Hm. It's not connecting some things that are all labeled "vdd"
t
If it's not connecting them in extraction, then it could only be because some labels are not correctly attached to the layer underneath. Otherwise, the net would always take the name of the label, so all such nets would have to be connected.
m
It has something to do with the pin changes still. (Old versions work fine...)
t
You can figure that out by selecting part of a net that you think is "vdd", and see if the label got highlighted along with the net. If not, then the label isn't considered connected to the net.
m
Yes, it is all connected fine in layout
Oh, actually, the label is not connected.
This layout hasn't changed in 3+ years though
I don't think that is it. It works fine in Magic 8.3.197 but not in 8.3.254
And the label doesn't get highlighted in either one
t
It is just as likely that magic's handling of the extraction is what changed. A lot of the extraction stuff is very complicated, and I can't guess at all of the unintended consequences of making a change. I can only say that with the generous help of Mitch Bailey, it has been getting a lot better recently. But I can't guarantee that something that worked in the past won't have broken. Mainly because I'm missing a large enough set of regression tests to know when some obscure behavior changed.
Which is just to say, that if you point me to which layout exhibits the behavior, and given that you have already told me two versions that exhibit different behaviors, I should be able to track it down.
m
It looks like an extra pin gets extracted for some reason. I'm using readspice but then it appends an extra port that isn't in the spice.
8.3.197.spice8.3.254.spice
14_replica_column_test.zip
14_replica_column_test.zip
In the replica_cell_1rw, there is no Q_bar port but there is a label inside the cell for Q_bar and that net is intentionally shorted to vdd. However, it extracts two unique ports vdd and Q_bar
t
The short answer is that I have been modifying a lot of code related to disconnected and unnecessary ports, so I have probably failed to catch some set of layouts, and have likely broken exactly the thing that was supposed to be fixed. Thanks for posting the zip file; I'll track down what's going on.
m
Removing the extra label gets rid of the problem. So it seems that the extractor must extract a port for every label?
t
It's a multiple-step operation; it will create a port for every label, but then it should remove anything that is not explicitly marked as a port or is not connected to anything.
m
Ok, this one gets missed. I have a work around for now to move forward though.
m
@User the programs and setup I'm using allow me to get a clean LVS result for the 
sky130_sram_2kbyte_1rw1r_32x512_8
in the 
mgmt_core_wrapper
module of caravel (mpw-3) in about 20 minutes. I believe most chip level LVS should be done with 
extract unique
, because you don't want a virtual connection at the top level. I don't know how you'd extract subcells with virtual connections and then do the top level without. I think magic has an option to do the opposite, though (extract the top with virtual connections and the subcell ports as unique). My local version of netgen doesn't add proxy ports (instead it flattens circuits with mismatched ports) but I still need to clearly explain why to @User.
t
@User: This appears not to be a proxy port issue, but is something I haven't seen before. @User: The basic extraction has gone schizophrenic and is using the label "vdd" when generating parasitics and connections from top down into the replica cell, but using the label "Q_bar" when writing the node name in the extracted cell itself. There is supposed to be a clearly defined order of precedence for names that is being subverted somehow. I'm looking into it.
@User: That took much of the day to figure out. I made a change a long time ago not to generate 
equiv
statements in the .ext file output for every possible label on every net, unless the command 
extract do aliases
is given. I must have had a loose screw that day, since that breaks backwards compatibility and is normally something I avoid at all costs; it should have been left with 
extract do aliases
being the default. Regardless, though, the real problem is that with the default 
extract no aliases
, magic did not record which labels it was not generating 
equiv
statements for, but then did all its hierarchical processing using all labels, so it could could end up using any name for a net whether or not that name was in the .ext file for that cell. So I added some code (version 8.3.257) to track labels that are not output, and refuse to generate any hierarchical paths using those names. I also confirmed that simply adding 
extract do aliases
to the extraction script also works. I have not yet looked at getting some automatic handling of non-electrical layers implemented.
👍 1
@User: I have now also implemented the idea of using the types in the "extract", "connect", and "contact" sections of the tech file to generate a complete list of types that can be extracted as electrical nodes, which should be backwardly-compatible with the older SCMOS tech files.
Open in Slack
PreviousNext
Powered by