Altering port lists with duplicate ports causes incorrect connectivity

[d-m-bailey]

See RTimothyEdwards/magic#232

[d-m-bailey]

One workaround is to explicitly flattened the subcells with mismatched port names.

[d-m-bailey]

@RTimothyEdwards

Size errors due to flattening are caused by asymmetrical (explanation follows) flattening and are liking due to a bug in the parallel deduction routine. If the netlists are flattened symmetrically, they match.
Asymmetrical flattening occurs when the layout and source have differing cell names and only one is specified to be flattened. For example, AA_example in the layout and example in the verilog source. If example is set to be flattened, it will be flattened when the netlist is read. When the parent cell is compared, the cell counts are compared and mismatches are flattened. This results in not only AA_example being flattened on the layout side, but all of the subcells of the previously flattened example being flattened to the device level on the verilog side. The resulting cells lists are compared and AA_example’s subcells are now unmatched and also flattened to the device level on the layout side. And somewhere in this recursive flattening, the combined sizes appear to be nerfed.
Original layout

AA_user_project_wrapper
  AA_example
    AA_inv

Original verilog

user_project_wrapper
  example
    inv

Preflattening example gives

user_project_wrapper
  example.inv

First comparison of flattens unmatched cells in both

AA_user_project_wrapper
  AA_example.AA_inv

and

user_project_wrapper
  example.inv.pmos
  example.inv.nmos

The second comparison further flattens the layout, resulting in a topology match but size errors.

AA_user_project_wrapper
  AA_example.AA_inv.pmos
  AA_example.AA_inv.nmos

The data in the attached tarfile produces the error with netgen 1.5.251

tar xvf asymmetric-flattening.tgz
cd asymmetric-flattening
netgen -batch source lvs.script

Check lvs.report

asymmetric-flattening.tgz

[RTimothyEdwards]

(@d-m-bailey : If I correct the setup file to update it with respect to a number of changes and corrections made in the last year or so, then this circuit passes LVS just fine. The problem is that it is using a custom setup file that was apparently created a long time ago and not kept up to date with changes made in the PDK.) EDITED---Never mind, I thought I had put the flattening of the subcell under the top in the script, but I hadn't. Adding it makes the problem come back. But why is tiny_user_project being flattened anyway?

Edited again---Actually it's not even the flattning of tiny_user_project that makes the difference, it's the equating of prefixed cell names to non-prefixed cell names. Still investigating.

[d-m-bailey]

@RTimothyEdwards thanks for looking into this. The workaround is to flattened both the layout and netlist cells, so this is not critical.

If you could reread my first comment, it might make a little more sense what's going on.
Here's the results of the first flattening attempt before comparing (tiny_user_project in verilog has been pre-flattened via the setup file command).

Flattening instances of sky130_fd_sc_hd__a2bb2o_1 in cell user_project_wrapper (1) makes a better match
Flattening instances of sky130_fd_sc_hd__o211ai_1 in cell user_project_wrapper (1) makes a better match
...

Flattening instances of Z1_AX_tiny_user_project in cell Z1_user_project_wrapper (0) makes a better match

So the standard cells in verilog don't match what's in the layout at this level, so they're flattened to the device level and tiny_user_project in the layout doesn't match the pre-flattened verilog, so it's flattened.

In the next round, the layout is flattened to the device level.

Making another compare attempt.

Flattening instances of Z1_AX_sky130_fd_sc_hd__a2bb2o_1 in cell Z1_user_project_wrapper (0) makes a better match
Flattening instances of Z1_AX_sky130_fd_sc_hd__o211ai_1 in cell Z1_user_project_wrapper (0) makes a better match
...

The reason I'm flattening the user_proj_example level (tiny_user_project in this case) is because layout ports are being extracted as netxxx and matched to random symmetric io_out[x] etc. nets that cause altered port lists and subsequently, port mismatches at the top level if not flattened. You can see this in the tiny_user_project comparison which is done in spite of flattening.

Subcircuit pins:
Circuit 1: Z1_AX_tiny_user_project         |Circuit 2: tiny_user_project
-------------------------------------------|-------------------------------------------
net35                                      |io_out[15] **Mismatch**
net64                                      |io_oeb[22] **Mismatch**
net36                                      |io_out[20] **Mismatch**
net72                                      |io_oeb[21] **Mismatch**
net69                                      |io_out[21] **Mismatch**
net71                                      |io_oeb[20] **Mismatch**
net37                                      |io_out[22] **Mismatch**
net70                                      |io_oeb[19] **Mismatch**
net38                                      |io_out[23] **Mismatch**

Preventing flattening by looking ahead to see matches in the hierarchy would also result in a clean LVS run, but there is still the underlying issue that flattening causes size errors. I think even if the design is flattened to the device level, LVS should pass. Could this be an overflow problem?

[RTimothyEdwards]

@d-m-bailey : Ha, I got caught once again staring at the comment in my code that said "still left to do. . .". I had not implemented the code to handle a subcircuit property M > 1 when flattening the subcircuit. It's actually an easy implementation. I guess I had just jotted down the comment and never got back to it. I am pushing the fix now (version 1.5.253).

I would have posted this earlier but I got a segfault on the original example and just got around to fixing it. Everything is pushed now to opencircuitdesign.com.

[d-m-bailey]

@RTimothyEdwards Great! Looks like this should deal with the mismatched flattening.

But what about the size errors? If the there's a situation that requires flattening to the device level, the sizes would be expected to match, right?

[RTimothyEdwards]

@d-m-bailey : No, the size errors are a result of failing to copy the number of devices for M during flattening. At the last stage, netgen sees that the device counts don't match, so it makes a last-ditch attempt to see if the total area (for diodes) matches on both sides. Probably it would be more meaningful for the LVS output if after that it could back-track to the original error (mismatching M) and report that instead, since that would be the more likely error.