Hello everyone, I've just integrated analog macro (OpAmp) into caravel (user_project_wrapper), providing GDS, LEF, SPICE (generated from xschem, copied to spi/lvs subdirectory), Verilog stub. Everything is fine while hardening user_project_wrapper (= flow is successfull, including LVS) and resulting GDS looks as expected. However, during precheck LVS is failing. According to "lvs.report", everything seems to be ok (screenshot included).

Cell pin lists are equivalent.

Device classes user_project_wrapper and user_project_wrapper are equivalent.

"lvs.log" states that:

circuit opamp_cascode contains no devices.

and there's a warning:

Warning: device level LVS may be incomplete due to 1 unflattened cell(s)

However, everything seems to be totally fine, because:

Circuits match uniquely.

On the other hand, "LVS_check.log" states that, for analog macro:

Circuit 1 contains 98 devices, Circuit 2 contains 98 devices.

Circuit 1 contains 4605 nets,    Circuit 2 contains 6017 nets. *** MISMATCH ***

Final result:

Top level cell failed pin matching.

In "soft.report", I see some mismatches (example screenshot included).

@Paweł Sitarz Congratulations on integrating your design! Please be aware that the LVS included in the flow is not a full device level LVS. It only compares at the top level - the subcircuits are not included and only the pins are checked. (netgen will match an empty circuit to a non-empty circuit with no error.) The LVS in precheck is a full device level LVS where empty cells are flagged with

device level LVS may be incomplete

. You can check the

tmp/lvs.unflattened

file to find the missing cell. You can then add the spice or verilog for that cell to

lvs/user_project_wrapper/lvs_config.json

. This is the configuration file that allows full device level LVS by specifying all the source files. Merely placing the file in

spi/lvs

is not sufficient (historically this is where extracted netlists were placed). Your

soft.report

is showing a result that seems to indicate that there was a problem with extraction. Can you share your

lvs/user_project_wrapper/lvs_config.json

file?

Hi @Mitch Bailey, You are right, "lvs.unflattened" has this line pointing to opamp:

opamp_cascode is a black box in the source

I've got spice netlist file already added to LVS_SPICE_FILES. Also tried once to create new group LVS_SPICE_FILES_TO_FIX and put opamp netlist there (saw it somewhere), but without luck. This is my current lvs_config.json:

{

"TOP_SOURCE": "user_project_wrapper",

"TOP_LAYOUT": "$TOP_SOURCE",

"EXTRACT_FLATGLOB": [

""

],

"EXTRACT_ABSTRACT": [

"*__fill_*",

"*__fakediode_*",

"*__tapvpwrvgnd_*"

],

"LVS_FLATTEN": [

""

],

"LVS_NOFLATTEN": [

""

],

"LVS_IGNORE": [

""

],

"LVS_SPICE_FILES": [

"$PDK_ROOT/$PDK/libs.ref/sky130_fd_sc_hd/spice/sky130_ef_sc_hd__decap_12.spice",

"$PDK_ROOT/$PDK/libs.ref/sky130_fd_sc_hd/spice/sky130_fd_sc_hd.spice",

"$UPRJ_ROOT/spi/lvs/opamp_cascode.spice"

],

"LVS_VERILOG_FILES": [

"$UPRJ_ROOT/verilog/gl/user_proj_example.v",

"$UPRJ_ROOT/verilog/gl/$TOP_SOURCE.v"

],

"LAYOUT_FILE": "$UPRJ_ROOT/gds/$TOP_LAYOUT.gds"

}

As per spice netlist generation, I have this "LVS netlist: Top level is a .subckt" option enabled when generating netlist from xschem, as shown on screenshot. Do I need to do that differently?

May I suggest this lvs_config file?

{
  "STD_CELL_LIBRARY": "sky130_fd_sc_hd",
  "INCLUDE_CONFIGS": [
    "$LVS_ROOT/tech/$PDK/lvs_config.base.json"
  ],
  "TOP_SOURCE": "user_project_wrapper",
  "TOP_LAYOUT": "$TOP_SOURCE",
  "EXTRACT_FLATGLOB": [
    ""
  ],
  "EXTRACT_ABSTRACT": [
    ""
  ],
  "LVS_FLATTEN": [
    ""
  ],
  "LVS_NOFLATTEN": [
    ""
  ],
  "LVS_IGNORE": [
    ""
  ],
  "LVS_SPICE_FILES": [
    "$UPRJ_ROOT/spi/lvs/opamp_cascode.spice"
  ],
  "LVS_VERILOG_FILES": [
    "$UPRJ_ROOT/verilog/gl/user_proj_example.v",
    "$UPRJ_ROOT/verilog/gl/$TOP_SOURCE.v"
  ],
  "LAYOUT_FILE": "$UPRJ_ROOT/gds/$TOP_LAYOUT.gds"
}

Also, be sure the spice netlist is output to the directory you expect. The default is probably not what you expect. Check that the top subckt is

.subckt opamp_cascode

without a leading

*

.

@Mitch Bailey I'm aware that xschem by default is saving netlist in subdirectory of user's home directory, but checked once again that I'm using proper netlist. I verified no leading '*' was present. Then I tried with _lvs_config_ you proposed and HOORAY, LVS passed! Thank you very much! :) I see only this warning related to LVS:

WARNING ERC CHECK FAILED, stat=4, see /home/zwierzak/projects/caravel_user_project/precheck_results/27_OCT_2023___20_26_03/logs/LVS_check.log

I went through this log and haven't found ERC. Is it something I should be worried of? The last thing I need to work on is OEB check failing, but I've already found out that this is due to analog pins not having OE set to high, no matter if GPIO is configured as GPIO_MODE_USER_STD_ANALOG or GPIO_MODE_MGMT_STD_ANALOG (tried both). The easiest way to do that I'm aware of is to create simple verilog module having 6 outputs all tied to '1'/VCC, harden it, place as a macro and connect it to those 6 analog pins. Is there by any chance better or simpler way?

Currently, the OEB check does not consider the gpio defaults block settings in

user_defines.v

, so this is a warning. It is probably not a bad idea to tie

io_oeb

high and

io_out

low for gpio’s that are not being used. The ERC results should be in a file named

cvc.errors.gz

. It may be in the

precheck_results/<tag>/tmp

directory. If you’re design is analog, they are likely to be false errors, but if you post the file, I’ll take a look.

Isn't it safer to set io_out also high to not create short circuit for analog signal on the same pin? I know that driving io_oeb high should disable output driver, but it all depends on internal IO pad design. All my OEB errors are related to pads I connected to OpAmp via analog_io[] signals in user_project_wrapper. Here's my cvc.error file. It seems I've got something like "Secondary HI-Z error" for all transistors that are connected to input/output pads of OpAmp macro.

@Paweł Sitarz

Isn’t it safer to set io_out also high to not create short circuit for analog signal on the same pin? I know that driving io_oeb high should disable output driver, but it all depends on internal IO pad design.

With `caravel`/`caravan`, it also depends on the gpio wrapper

$CARAVEL_ROOT/verilog/rtl/gpio_control_block.v

. This incorporates the settings in

caravel_user_project/verilog/rtl/user_defines.v

. For sky130, see the attachment for a breakdown of the control bits. You can view the schematic for the gpio itself (but not the

gpio_control_block

) here. From what I can tell, if you’re using one of the

ANALOG

defaults,

OUTPUT_DISABLE

is high which puts the output drivers in a Hi-Z state.

All my OEB errors are related to pads I connected to OpAmp via analog_io[] signals in user_project_wrapper.

The default CVC/OEB power settings do not define any of the analog_io pins so these can show up as Hi-Z errors in

user_analog_project_wrapper

. You may ignore these. Alternatively, you should be able to copy the

cvc.power.user_analog_project_wrapper

file in

prechecks/<tag>/tmp/

to

lvs/user_analog_project_wrapper/cvc.power.user_analog_project_wrapper

and add the settings for the

analog_io

pins. precheck should pick those settings up on the next run.

Hi @Mitch Bailey, I created small digital block to just output '1's and then after hardening I connected all its outputs to io_oeb signals for GPIOs I connected analog signals from OpAmp. Tying all those io_oeb's to '1'/High made OEB check passing :) On the other hand, it turned out that io_out should not be connected at all for pads where io_analog is connected, otherwise there would be OEB error reported and OEB check would fail for that reason.

@Paweł Sitarz Actually, with the latest version of the oeb check, it’s best to tie the

io_out

high or low on analog gpio ports and fix

io_oeb

high.

Hmm, but if I have both io_out and io_analog connected to the same pad, I get OEB error saying that I can connect either analog or out, not both. How to check OEB check / precheck version and update to newest? I wonder if OEB check on Efabless submission portal is new or not

Make sure you add

venv-cocotb

to your

.gitignore

file. You don’t want to push that to the repo. Precheck may need to be fixed to ignore that directory. Thanks for reporting.

Make sure you add venv-cocotb to your .gitignore file.  You don't want to push that to the repo.
Precheck may need to be fixed to ignore that directory. Thanks for reporting.

Ok, good to know.

That sounds like an older version of the oeb check. The newer one should be installed soon that allows fixed connections to io_out with analog connections.

Ok, need to be ready to tapeout on 6th 🙂

At the end, is the SPDX compliance treated as a warning or an error? Could you log an issue to the mpw_precheck repo about the file extensions for the binary files?

It's being reported as error:

Ok. Thanks. I’ll bring it up at tomorrow’s meeting.

Thanks, David! I'm just looking through issues already reported to mpw_precheck to not create duplicate and will fill out new one

I think if you have verilog modules and spice subkt definitions of the same circuit, you’re going to see problems. The verilog modules for

top_ew_algofoogle

and

analog_io_control

are just stubs, right? They don’t contain any subcircuits or devices, right? If that’s the case, you should probably remove the verilog file references.

They both are Gate Level Verilog, so contain subcircuits. I removed verilog files and run full LVS once again. Is it better to use spice netlist or gl verilog here (both are pure digital)?

If they’re digital, I’d use the verilog. I’d advise against using extracted spice files. That’s not really a comparison. Do you spice files generated from xschem for the analog circuits?

Actually I removed spice netlist files for digital but that didn't helped

If you’re able to share

precheck_results/<tag>/tmp/lvs.report

, I can take a look.

"Top level is subckt"

What about

TOP_analog.spice

?

Yes, TOP_analog also comes from xschem

The verilog modules have to be listed in order, children before parents.

Yes, TOP_mixed (parent) includes TOP_analog and TOP_digital

This cell has unmatched non-floating pins.

Circuit 1: crosstalk_glitch_detector                                              |Circuit 2: crosstalk_glitch_detector
----------------------------------------------------------------------------------|----------------------------------------------------------------------------------
TXRX_B_NEG                                                                        |TXRX_B_NEG
TXRX_B_POS                                                                        |TXRX_B_POS
blip_RX                                                                           |blip_RX
vdd                                                                               |vdd
vss                                                                               |vss
TXRX_B_POS_via_R                                                                  |(no matching pin)
TXRX_B_POS_via_R                                                                  |(no matching pin)

It might work if this was flattened with

LVS_FLATTEN

in the

lvs_config.json

file. There are size errors here. Can you verify?

Circuit 1: ramp_samp_accumulation                                                 |Circuit 2: ramp_samp_accumulation
----------------------------------------------------------------------------------|----------------------------------------------------------------------------------
inv_P8u_N3u (1)                                                                   |inv_P8u_N3u (1)
schmitt_ratio_1_to_1 (1)                                                          |schmitt_ratio_1_to_1 (1)
sky130_fd_pr__pfet_01v8 (29->10)                                                  |sky130_fd_pr__pfet_01v8 (37->10)
sky130_fd_pr__nfet_01v8 (13->3)                                                   |sky130_fd_pr__nfet_01v8 (120->3)
sky130_fd_pr__nfet_01v8_lvt (1)                                                   |sky130_fd_pr__nfet_01v8_lvt (4->1)
Number of devices: 16                                                             |Number of devices: 16
Number of nets: 16                                                                |Number of nets: 16
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
Netlists match uniquely with property errors.
sky130_fd_pr__pfet_01v8:2 vs. sky130_fd_pr__pfet_01v8:M3:
 w circuit1: 2   circuit2: 1   (delta=66.7%, cutoff=1%)
sky130_fd_pr__pfet_01v8:10 vs. sky130_fd_pr__pfet_01v8:M7:
 w circuit1: 2   circuit2: 1   (delta=66.7%, cutoff=1%)
sky130_fd_pr__pfet_01v8:0 vs. sky130_fd_pr__pfet_01v8:M8:
 w circuit1: 2   circuit2: 1   (delta=66.7%, cutoff=1%)

and here

Circuit 1: pwm_delay_tune_openloop                                                |Circuit 2: pwm_delay_tune_openloop
----------------------------------------------------------------------------------|----------------------------------------------------------------------------------
inv_P8u_N3u (4)                                                                   |inv_P8u_N3u (4)
nand_P3u_N2u_compact (3)                                                          |nand_P3u_N2u_compact (3)
transistor_50u_PFET_CELL_HEIGHT10 (1)                                             |transistor_50u_PFET_CELL_HEIGHT10 (1)
schmitt_ratio_1_to_1 (1)                                                          |schmitt_ratio_1_to_1 (1)
sky130_fd_pr__pfet_01v8 (31->6)                                                   |sky130_fd_pr__pfet_01v8 (31->6)
sky130_fd_pr__res_xhigh_po (8->4)                                                 |sky130_fd_pr__res_xhigh_po (4)
sky130_fd_pr__nfet_01v8 (34->6)                                                   |sky130_fd_pr__nfet_01v8 (34->6)
sky130_fd_pr__cap_mim_m3_1 (4)                                                    |sky130_fd_pr__cap_mim_m3_1 (4)
Number of devices: 29                                                             |Number of devices: 29
Number of nets: 27                                                                |Number of nets: 27
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
Resolving symmetries by property value.
Netlists match uniquely with property errors.
sky130_fd_pr__cap_mim_m3_1:20 vs. sky130_fd_pr__cap_mim_m3_1:C4:
 w circuit1: 2.11   circuit2: 2   (delta=5.35%, cutoff=1%)
sky130_fd_pr__cap_mim_m3_1:19 vs. sky130_fd_pr__cap_mim_m3_1:C6:
 w circuit1: 3.69   circuit2: 6   (delta=47.7%, cutoff=1%)
 l circuit1: 3.69   circuit2: 2   (delta=59.4%, cutoff=1%)
sky130_fd_pr__cap_mim_m3_1:18 vs. sky130_fd_pr__cap_mim_m3_1:C7:
 w circuit1: 4.82   circuit2: 6   (delta=21.8%, cutoff=1%)
 l circuit1: 4.81   circuit2: 4   (delta=18.4%, cutoff=1%)
sky130_fd_pr__cap_mim_m3_1:9 vs. sky130_fd_pr__cap_mim_m3_1:C8:
 w circuit1: 5.73   circuit2: 6   (delta=4.6%, cutoff=1%)
 l circuit1: 5.73   circuit2: 8   (delta=33.1%, cutoff=1%)
sky130_fd_pr__res_xhigh_po:23 vs. sky130_fd_pr__res_xhigh_po:R1:
 l circuit1: 5.94   circuit2: 6.04   (delta=1.67%, cutoff=1%)
sky130_fd_pr__res_xhigh_po:8 vs. sky130_fd_pr__res_xhigh_po:R5:
 l circuit1: 5.94   circuit2: 3.02   (delta=65.2%, cutoff=1%)
 w circuit1: 0.7   circuit2: 0.35   (delta=66.7%, cutoff=1%)
sky130_fd_pr__res_xhigh_po:7 vs. sky130_fd_pr__res_xhigh_po:R2:
 l circuit1: 5.94   circuit2: 1.51   (delta=119%, cutoff=1%)
 w circuit1: 1.4   circuit2: 0.35   (delta=120%, cutoff=1%)

Looks like there might be extraneous text or ports in this cell

Circuit 1: top_ew_algofoogle                                                      |Circuit 2: top_ew_algofoogle
----------------------------------------------------------------------------------|----------------------------------------------------------------------------------
clknet_leaf_69_i_clk                                                              |(no matching pin)
clknet_4_5_0_i_clk                                                                |(no matching pin)
clknet_4_7_0_i_clk                                                                |(no matching pin)
clknet_leaf_76_i_clk                                                              |(no matching pin)
...
net297                                                                            |(no matching pin)
net298                                                                            |(no matching pin)                  
net299                                                                            |(no matching pin)                                                                 
net3                                                                              |(no matching pin)                      
net30                                                                             |(no matching pin)                 
net300                                                                            |(no matching pin)                     
net301                                                                            |(no matching pin)                               
net302                                                                            |(no matching pin)               
net303                                                                            |(no matching pin)                                                                 
net304                                                                            |(no matching pin)                                                                 
net305                                                                            |(no matching pin)
net306                                                                            |(no matching pin)
net307                                                                            |(no matching pin)

There are config setting when running openlane to output internal nets. You probably don’t want to do that. However, it’s not too difficult to delete all the unnecessary text with klayout. Then your top level

Circuit 1: TOP_mixed                                                              |Circuit 2: TOP_mixed

---------------------------------------------------------------------------------------------------------------------------------------------------------------------
Net: vccd1                                                                        |Net: _noconnect_1_
  TOP_digital/vccd1 = 1                                                           |  TOP_digital/vccd1 = 1
  ramp_and_samp_for_TOP_analog/vdd = 1                                            |
  inv_P8u_N3u/vdd = 6                                                             |
  glitch_pulse_extender/vdd = 2                                                   |
  flop_7474_type/d = 2                                                            |

Looks like the verilog is not the powered verilog. openlane should output both powered and unpowered gate level netlists. Make sure you have the

USE_POWER_PIN

directives in the rtl.

Hi @Mitch Bailey, coming in here because we are sharing our area with @Paweł Sitarz 🙂 He's added our TOP_xx .

Regarding directive - is this enough in verilog/rtl/file.v? ``ifdef USE_POWER_PINS`

vccd1,

vssd1,

``endif`

Size errors are all fine. Locally checked 🙂

@Paweł Sitarz that should be enough, but it needs to be not only on the top ports, but on all the module instantiations that use power.

Ok, so it seems that we have two remaining issues here: TOP_mixed not powered somehow and some mismatch on top_ew_algofoogle interface

When you say “earlier appeared to be clean” are you referring to openlane’s abstract LVS or precheck’s device level LVS? Can you share any of this data or add efabless staff as a collaborator on the platform?

I mean both LVS run by 'make lvs-user_project_wrapper' and Precheck were clean

Can you share your

lvs.report

?

lvs.report

I'm just setting up the Repo on Efabless website for our submission

1. From the lvs.report

Circuit 1: crosstalk_glitch_detector                                              |Circuit 2: crosstalk_glitch_detector                                              
----------------------------------------------------------------------------------|----------------------------------------------------------------------------------
sky130_fd_pr__nfet_01v8_lvt (7)                                                   |sky130_fd_pr__nfet_01v8_lvt (9->7)                                                
sky130_fd_pr__nfet_01v8 (3)                                                       |sky130_fd_pr__nfet_01v8 (5->3)                                                    
sky130_fd_pr__pfet_01v8 (6)                                                       |sky130_fd_pr__pfet_01v8 (16->6)    
sky130_fd_pr__cap_mim_m3_1 (3)                                                    |sky130_fd_pr__cap_mim_m3_1 (3)        
sky130_fd_pr__res_xhigh_po_0p35 (1)                                               |(no matching element)                                               
sky130_fd_pr__res_high_po_0p35 (2)                                                |(no matching element)                                                             
sky130_fd_pr__res_generic_po (1)                                                  |sky130_fd_pr__res_generic_po (1)
(no matching element)                                                             |sky130_fd_pr__res_xhigh_po (1)                                                    
(no matching element)                                                             |sky130_fd_pr__res_high_po (2)                                                     
Number of devices: 23                                                             |Number of devices: 23              
Number of nets: 17                                                                |Number of nets: 17

The layout extracted resistor names are different than the schematic names. This is a recent pdk change. Can you change the schematic to match the layout? Here too

Circuit 1: pwm_delay_tune_openloop                                                |Circuit 2: pwm_delay_tune_openloop
----------------------------------------------------------------------------------|----------------------------------------------------------------------------------
inv_P8u_N3u (4)                                                                   |inv_P8u_N3u (4)                       
nand_P3u_N2u_compact (3)                                                          |nand_P3u_N2u_compact (3)                                                          
transistor_50u_PFET_CELL_HEIGHT10 (1)                                             |transistor_50u_PFET_CELL_HEIGHT10 (1)
schmitt_ratio_1_to_1 (1)                                                          |schmitt_ratio_1_to_1 (1)           
sky130_fd_pr__pfet_01v8 (31->6)                                                   |sky130_fd_pr__pfet_01v8 (31->6)       
sky130_fd_pr__res_xhigh_po_0p35 (8->4)                                            |(no matching element)                                                             
sky130_fd_pr__nfet_01v8 (34->6)                                                   |sky130_fd_pr__nfet_01v8 (34->6)
sky130_fd_pr__cap_mim_m3_1 (4)                                                    |sky130_fd_pr__cap_mim_m3_1 (4)
(no matching element)                                                             |sky130_fd_pr__res_xhigh_po (4)
Number of devices: 29                                                             |Number of devices: 29
Number of nets: 27                                                                |Number of nets: 27

2. Do you know how to remove the extra text from

top_ew_algofoogle.gds

using klayout?

Edit

->

Search and Replace

Choose the

Delete

tab

Object...

text

In …

current cell

then

Select  + Delete

and

Delete All

for

Text ~

_*

and

Text ~

net*

and

Text ~

*\.*

(not sure if this will work) you can also search by layer/type. I suggest making a backup of

top_ew_algofoogle.gds

in case something goes wrong. Then rerun the top level openlane. 3. Looks like you’re using two power regions `vccd1`/`vssd1` and `vccd2`/`vssd2`. You’re not using 3.3V power, right?

vssd1

and

vssd2

both connect to substrate causing a short. In your final gds, you can manually add the magic layer

isosubstrate

(second row, first column) so that each vssd1 and vssd2 region is enclosed. Note: this isolation layer must not overlap deep nwell, so you’ll need to cut holes in isosubstrate around the dnwell. This might be better handled in klayout (

areaid.substrateCut

81/53

) because magic can change gds files. See here.

Hi @Mitch Bailey Thank you for going through this. I'm submitting a ChipIgnite as part of a UK team, but we had a lot of spare space so we shared it for free with other users (@Paweł Sitarz @Anton Maurovic). In order to avoid conflicts on the power network, we asked them to use a different power region (vccd2) because then there was no risk of their designs interfering with ours - the two power regions looked like they pinned out separately. I didn't realise they would cause a short through the substrate

@Mitch Bailey Is there a way to check against short circuits on power rails in such cases?

Ok. I’m not suggesting adding deep nwell over the entire region. The

isosubstrate

layer is not a mask layer. It’s just an LVS layer that separates the psubstrate into distinct nodes. The high resistance between substrate connections to distinct ground connections is often ignored by designers.

isosubstrate

permits LVS.

Ahh, so isosubstrate is not some additional thing / operation done during manufacturing, but only seen and used by LVS check?

Ahh I see. Thats ok. We can do whatever we need to pass LVS

If they do not have any deep nwell, that is fine.

So

isosubstrate

is (in KLayout) same as

areaid.substrateCut 81/53

?

@Paweł Sitarz

81/53

is

isosubstrate

in magic.

Yes we are using it Pawel

Yes, I meant I didn't find them in additional designs

Its also really hard to see that Layer in the Klayout colour scheme! I missed it and thought Magic hadn't extracted it.

That should work.

Ad1. crosstalk_glitch_detector and pwm_delay_tune_openloop are now fine 🙂 Ad2. I did removed in Klayout all those texts, so I no longer see those many randomly named nets in top_ew_algofoogle 🙂

1. There’s a device type mismatch. layout is poly netlist is li1.

Circuit 1: crosstalk_glitch_transmitter                                           |Circuit 2: crosstalk_glitch_transmitter
----------------------------------------------------------------------------------|----------------------------------------------------------------------------------
transistor_100u_NFET_LVT_CELL_HEIGHT20 (1)                                        |transistor_100u_NFET_LVT_CELL_HEIGHT20 (1)
transistor_25u_NFET_CELL_HEIGHT5 (2)                                              |transistor_25u_NFET_CELL_HEIGHT5 (2)
buffer_amplifier_chain_self_resetting_oneshot_fast_positive_edge (1)              |buffer_amplifier_chain_self_resetting_oneshot_fast_positive_edge (1)
transistor_800u_PFET_CELL_HEIGHT20 (1)                                            |transistor_800u_PFET_CELL_HEIGHT20 (1)
transistor_50u_PFET_CELL_HEIGHT10 (1)                                             |transistor_50u_PFET_CELL_HEIGHT10 (1)
transistor_200u_NFET_LVT_CELL_HEIGHT20 (3)                                        |transistor_200u_NFET_LVT_CELL_HEIGHT20 (3)
transistor_200u_PFET_CELL_HEIGHT20 (1)                                            |transistor_200u_PFET_CELL_HEIGHT20 (1)
sky130_fd_pr__res_generic_po (1)                                                  |(no matching element)
(no matching element)                                                             |sky130_fd_pr__res_generic_l1 (1)
Number of devices: 11                                                             |Number of devices: 11
Number of nets: 8                                                                 |Number of nets: 8

2. looking at the

top_ew_algofoogle

port mismatch, you can probably delete all text that begins with

c

or

r

. When netgen detects a cell with a mismatch, it will by default flatten that cell and compare at the parent hierarchy. Thus one error in a lower cell can lead to a long hard to understand report. If you know the error is contained in one cell (for example,

crosstalk_glitch_transmitter

) you can add that cell to

LVS_NOFLATTEN

to prevent flattening and isolate the error at that cell.

Indeed. Thank you David for your help today!

Goodnight Mitch. THANK YOU for all of your help. 🙏