Hi We are working on mixed signal design. We have a digital Macro and integrate it into user analog project wrapper along with our analog design in magic and manually do the routing , finally generate spice file and gds. How we can incorporate our digital design into xschem for the purpose of LVS in precheck?

@Allwan S Anand Create a symbol for your digital macro in xschem and connect it. Edit the symbol and add the property

type=primitive

. Make sure the pins on the symbol are in the same order as the ports in verilog - you can open the sym file and rearrange the pins or add the

sim_pinnumber

property to each pin. When you create the spice netlist, it will have a digital macro instance but no subcircuit. Create a

script

for running netgen.

set layout [readnet spice <extracted_spice>]
set source [readnet spice <spice_netlist_from_xschem>]
readnet verilog <verilog_gL_macro> $source
lvs "$layout user_analog_project_wrapper" "$source user_analog_project_wrapper" $env(PDK_ROOT)/$env(PDK)/libs.tech/netgen/$env(PDK)_setup.tcl lvs.report

Run netgen with

netgen -batch source script

@Allwan S Anand this manual page explains all the options to create a symbol that matches an existing macro.

Hi, thanks for the response. I tried the steps mentioned above but could not complete the flow. Screenshots of error and supporting files are attached below. Please give proper suggestions

@Allwan S Anand 1. Add

VGND

and

VPWR

pins to your

pmw_generator

symbol. 2. Don’t use global

VGND

or

VPWR

symbols. Use named wires instead. 3. When you export your netlist from xschem, set

Simulation

->

LVS netlist: top level is a .subckt

4. Use the actual file names in your script, surrounded by ” if necessary.

set layout [readnet spice "user_analog_project_wrapper_layout.spice"]

5. The lvs command should contain the top cell names, not the file names

lvs "$layout user_analog_project_wrapper" "$source user_analog_project_wrapper"

6. The instance name for the

pwm_generator

symbol should begin with an

X

7. The

pwm_generator

symbol pins are in this order

wb_clk_i wbs_dat_i[0] wbs_dat_i[1] wbs_dat_i[2] wbs_dat_i[3] wbs_dat_i[4] wbs_dat_i[5]
+ wbs_dat_i[6] wbs_dat_i[7] net1 wb_rst_i

The verilog pins are in this order

VGND,
    VPWR,
    clk,
    pwm_out,
    rst,
    duty_cycle

with the

duty_cycle

bus indexes in reverse order. They need to be in the same order. I find it easiest to open the

pwm_generator.sym

file and rearrange them. 8. You can create the layout netlist without parasitic capacitors. Use

ext2spice lvs
ext2spice -o user_analog_project_wrapper_layout.spice

I followed @Mitch Bailey's instructions above but cannot get LVS clean either. Proceeded to strip down to only one digital buffer in Verilog and tried to get a match but cannot. Port order and port names the same. There's no xschem involved here, I manually created a simple test case to isolate the issue. Located here: https://github.com/ajcci/sky130_ajc_ip__overvoltage/tree/main/mag/lvs/vlog_lvs_testcase Tarball version: https://github.com/ajcci/sky130_ajc_ip__overvoltage/blob/main/mag/lvs/vlog_lvs_testcase.tar.gz Type the following to run:

netgen -batch source runlvs

If anyone has a working example or knows how to get it to work, please help. @Tim Edwards has given me some helpful pointers after the Chipalooza layout review but I still can't get it to work. Layout netlist:

*This is the extracted netlist from layout

.subckt sky130_ajc_ip__overvoltage dvdd dvss otrip otrip_decoded

*Digital route extracted from layout
xIdig dvdd dvss otrip otrip_decoded overvoltage_dig

.ends

.subckt overvoltage_dig VPWR VGND otrip otrip_decoded
xbuf2 otrip VGND VGND VPWR VPWR otrip_decoded sky130_fd_sc_hd__buf_2
.ends

.subckt sky130_fd_sc_hd__buf_2 A VGND VNB VPB VPWR X
X0 X a_27_47# VGND VNB sky130_fd_pr__nfet_01v8 w=650000u l=150000u
X1 a_27_47# A VPWR VPB sky130_fd_pr__pfet_01v8_hvt w=640000u l=150000u
X2 VGND a_27_47# X VNB sky130_fd_pr__nfet_01v8 w=650000u l=150000u
X3 X a_27_47# VPWR VPB sky130_fd_pr__pfet_01v8_hvt w=1e+06u l=150000u
X4 VPWR a_27_47# X VPB sky130_fd_pr__pfet_01v8_hvt w=1e+06u l=150000u
X5 a_27_47# A VGND VNB sky130_fd_pr__nfet_01v8 w=420000u l=150000u
.ends

Schematic netlist:

*This is the netlist that initiates Verilog Gate-Level netlist

.subckt sky130_ajc_ip__overvoltage dvdd dvss otrip otrip_decoded

*Verilog Gate-Level netlist
xIdig dvdd dvss otrip otrip_decoded overvoltage_dig

.ends

.subckt sky130_fd_sc_hd__buf_2 A VGND VNB VPB VPWR X
X0 X a_27_47# VGND VNB sky130_fd_pr__nfet_01v8 w=650000u l=150000u
X1 a_27_47# A VPWR VPB sky130_fd_pr__pfet_01v8_hvt w=640000u l=150000u
X2 VGND a_27_47# X VNB sky130_fd_pr__nfet_01v8 w=650000u l=150000u
X3 X a_27_47# VPWR VPB sky130_fd_pr__pfet_01v8_hvt w=1e+06u l=150000u
X4 VPWR a_27_47# X VPB sky130_fd_pr__pfet_01v8_hvt w=1e+06u l=150000u
X5 a_27_47# A VGND VNB sky130_fd_pr__nfet_01v8 w=420000u l=150000u
.ends

Verilog netlist:

module overvoltage_dig (
input VPWR,
input VGND,
input otrip,
output otrip_decoded
);

wire VPWR;
wire VGND;
wire otrip;
wire otrip_decoded;

 sky130_fd_sc_hd__buf_2 output0 (.A(otrip),
    .VGND(VGND),
    .VNB(VGND),
    .VPB(VPWR),
    .VPWR(VPWR),
    .X(otrip_decoded));

endmodule

LVS report:

Circuit 1 cell sky130_fd_pr__nfet_01v8 and Circuit 2 cell sky130_fd_pr__nfet_01v8 are black boxes.
Warning: Equate pins:  cell sky130_fd_pr__nfet_01v8 is a placeholder, treated as a black box.
Warning: Equate pins:  cell sky130_fd_pr__nfet_01v8 is a placeholder, treated as a black box.

Subcircuit pins:
Circuit 1: sky130_fd_pr__nfet_01v8         |Circuit 2: sky130_fd_pr__nfet_01v8         
-------------------------------------------|-------------------------------------------
1                                          |1                                          
2                                          |2                                          
3                                          |3                                          
4                                          |4                                          
---------------------------------------------------------------------------------------
Cell pin lists are equivalent.
Device classes sky130_fd_pr__nfet_01v8 and sky130_fd_pr__nfet_01v8 are equivalent.

Circuit 1 cell sky130_fd_pr__pfet_01v8_hvt and Circuit 2 cell sky130_fd_pr__pfet_01v8_hvt are black boxes.
Warning: Equate pins:  cell sky130_fd_pr__pfet_01v8_hvt is a placeholder, treated as a black box.
Warning: Equate pins:  cell sky130_fd_pr__pfet_01v8_hvt is a placeholder, treated as a black box.

Subcircuit pins:
Circuit 1: sky130_fd_pr__pfet_01v8_hvt     |Circuit 2: sky130_fd_pr__pfet_01v8_hvt     
-------------------------------------------|-------------------------------------------
1                                          |1                                          
2                                          |2                                          
3                                          |3                                          
4                                          |4                                          
---------------------------------------------------------------------------------------
Cell pin lists are equivalent.
Device classes sky130_fd_pr__pfet_01v8_hvt and sky130_fd_pr__pfet_01v8_hvt are equivalent.

Class sky130_fd_sc_hd__buf_2 (0):  Merged 2 parallel devices.
Class sky130_fd_sc_hd__buf_2 (1):  Merged 2 parallel devices.
Subcircuit summary:
Circuit 1: sky130_fd_sc_hd__buf_2          |Circuit 2: sky130_fd_sc_hd__buf_2          
-------------------------------------------|-------------------------------------------
sky130_fd_pr__nfet_01v8 (3->2)             |sky130_fd_pr__nfet_01v8 (3->2)             
sky130_fd_pr__pfet_01v8_hvt (3->2)         |sky130_fd_pr__pfet_01v8_hvt (3->2)         
Number of devices: 4                       |Number of devices: 4                       
Number of nets: 7                          |Number of nets: 7                          
---------------------------------------------------------------------------------------
Netlists match uniquely.

Subcircuit pins:
Circuit 1: sky130_fd_sc_hd__buf_2          |Circuit 2: sky130_fd_sc_hd__buf_2          
-------------------------------------------|-------------------------------------------
X                                          |X                                          
VGND                                       |VGND                                       
VNB                                        |VNB                                        
A                                          |A                                          
VPWR                                       |VPWR                                       
VPB                                        |VPB                                        
---------------------------------------------------------------------------------------
Cell pin lists are equivalent.
Device classes sky130_fd_sc_hd__buf_2 and sky130_fd_sc_hd__buf_2 are equivalent.

Subcircuit summary:
Circuit 1: overvoltage_dig                 |Circuit 2: overvoltage_dig                 
-------------------------------------------|-------------------------------------------
sky130_fd_sc_hd__buf_2 (1)                 |sky130_fd_sc_hd__buf_2 (1)                 
Number of devices: 1                       |Number of devices: 1                       
Number of nets: 4                          |Number of nets: 4                          
---------------------------------------------------------------------------------------
Netlists match uniquely with port errors.

Subcircuit pins:
Circuit 1: overvoltage_dig                 |Circuit 2: overvoltage_dig                 
-------------------------------------------|-------------------------------------------
VGND                                       |VGND                                       
VPWR                                       |VPWR                                       
otrip                                      |otrip                                      
otrip_decoded                              |otrip_decoded                              
(no matching pin)                          |proxy1                                     
(no matching pin)                          |proxy2                                     
(no matching pin)                          |proxy3                                     
(no matching pin)                          |proxy4                                     
---------------------------------------------------------------------------------------
Cell pin lists are equivalent.
Device classes overvoltage_dig and overvoltage_dig are equivalent.
  Flattening non-matched subcircuits overvoltage_dig overvoltage_dig

Subcircuit summary:
Circuit 1: sky130_ajc_ip__overvoltage      |Circuit 2: sky130_ajc_ip__overvoltage      
-------------------------------------------|-------------------------------------------
sky130_fd_sc_hd__buf_2 (1)                 |sky130_fd_sc_hd__buf_2 (1)                 
Number of devices: 1                       |Number of devices: 1                       
Number of nets: 4                          |Number of nets: 4                          
---------------------------------------------------------------------------------------
Netlists match uniquely with port errors.

Subcircuit pins:
Circuit 1: sky130_ajc_ip__overvoltage      |Circuit 2: sky130_ajc_ip__overvoltage      
-------------------------------------------|-------------------------------------------
otrip                                      |(no matching pin)                          
otrip_decoded                              |(no matching pin)                          
dvdd                                       |(no matching pin)                          
dvss                                       |(no matching pin)                          
(no matching pin)                          |dvdd                                       
(no matching pin)                          |dvss                                       
(no matching pin)                          |otrip                                      
(no matching pin)                          |otrip_decoded                              
dvdd                                       |(no matching pin)                          
dvss                                       |(no matching pin)                          
otrip                                      |(no matching pin)                          
otrip_decoded                              |(no matching pin)                          
---------------------------------------------------------------------------------------
Cell pin lists for sky130_ajc_ip__overvoltage and sky130_ajc_ip__overvoltage altered to match.
Device classes sky130_ajc_ip__overvoltage and sky130_ajc_ip__overvoltage are equivalent.

Final result: Top level cell failed pin matching.

Run script:

set layout [readnet spice "sky130_ajc_ip__overvoltage.spice"]
set source [readnet spice "sky130_ajc_ip__overvoltage_lvs.xschem"]
readnet verilog overvoltage_dig.v $source
lvs "$layout sky130_ajc_ip__overvoltage" "$source sky130_ajc_ip__overvoltage" /usr/local/share/pdk/sky130A/libs.tech/netgen/sky130A_setup.tcl lvs.report

@Tim Edwards This passes in netgen

1.5.269

. Might have something to do with the changes in

bf67d3c2754a6cdcd6cc5fe7e69ea1fddd855dd2

. Not in the lvs.result file, but the script generates this message.

Subcircuit pins:
Circuit 1: _PLACEHOLDER_                   |Circuit 2: overvoltage_dig                 
-------------------------------------------|-------------------------------------------
(no matching pin)                          |1                                          
(no matching pin)                          |2                                          
(no matching pin)                          |3                                          
(no matching pin)                          |4                                          
VPWR                                       |(no matching pin)                          
VGND                                       |(no matching pin)                          
otrip                                      |(no matching pin)                          
otrip_decoded                              |(no matching pin)                          
---------------------------------------------------------------------------------------

which is probably where all the

proxy

ports originate. @Robin Tsang thanks for the test case. Can you log an issue on the

netgen

repo?

Thanks Mitch, giving it a try.

I am utterly aggravated by the idea that a code fix I made to netgen specifically to address issues of the result being dependent on the order in which files are read is causing netgen to have a new issue of precisely the same variety.

Documented the steps to get it work here under the section "Layout vs Schematic (LVS)": https://github.com/ajcci/sky130_ajc_ip__overvoltage/tree/main

thanks @Mitch Bailey after following instructions, now i can complete netgen-lvs flow but still shows netlists do not matching. I just harden a digital macro and created a symbol of design in xschem with exact ports in verilog and tried to check netgen-lvs. The whole process is done inorder to check mixed signal integration and its precheck. please clarify some doubts like.. 1)lvs report shows device mismatch as "sky130_fd_sc_hd__fill_1, sky130_fd_sc_hd__fill_2, sky130_fd_sc_hd__tapvpwrvgnd_1" devices are present in verilog file but not in spice file generated from mag of harden macro? 2)both have same number of netlists, but showing net mismatch? 3) can you suggest a proper way for integrating mixed signal designs in order to pass lvs check? hereby attaching supporting files

@Allwan S Anand I assume that you’re running the layout extraction manually. Can you share your commands to extract the layout including reading the gds? Can you try to

load

the

fill_1

,

fill_2

, and

tapvpwrvgnd_1

cells and set

property LEFview true

for each one. That should keep them around after extraction.

@Mitch Bailey For layout extraction, i use following commands in magic

extract all
ext2spice lvs
ext2spice -o pwm_generator_layout.spice

Can you please elaborate how can i load

fill_1

,

fill_2

, and

tapvpwrvgnd_1

cells and set

property LEFview true

for each one.?

@Allwan S Anand

Can you share your commands to extract the layout including reading the gds?

The gds for for digital macro should have a

GDS_FILE

property. This causes magic to use the gds file data for the macro instead of reconverting macro magic layers to gds when creating the integrated gds. You should avoid saving any modified cells of gds files read into magic because this

GDS_FILE

pointer will be lost. For LVS, I suggest you create a gds file of your top design that will include the gds for the digital macro. I think this will work.

load pwm_generator_layout
gds write pwm_generator_layout.gds

You should then quit magic and restart.

gds read pwm_generator_layout.gds
load sky130_fd_sc_hd__fill_1
property LEFview true
load sky130_fd_sc_hd__fill_2
property LEFview true
load sky130_fd_sc_hd__tapvpwrvgnd_1
property LEFview true
load pwm_generator_layout
extract all
ext2spice lvs
ext2spice -o pwm_generator_layout.spice

and then close magic without saving. Good luck.

thanks @Mitch Bailey now both number of devices and nets are same. but finally showing Netlists do not match. Don't know why? just comparing both generated layout vs spice(verilog). Does the matching instance should in same order?if so how can we make that?

Can you share the lvs result file?

hi @Mitch Bailey hereby attaching the lvs report.

@Allwan S Anand Is this LVS result the output of openlane, or have you modified the layout or verilog after openlane. What version of netgen are you using here. The version will show in the lvs log (but not the report). Sorry, I couldn’t see any easy to spot errors in the lvs.report.

@Mitch Bailey No, its not lvs output of openlane. I got that report from running

set layout [readnet spice "pwm_generator_layout.spice"]
set source [readnet spice "pwm_generator.spice"]
readnet verilog pwm_generator.v $source
lvs "$layout pwm_generator" "$source pwm_generator" $env(PDK_ROOT)/$env(PDK)/libs.tech/netgen/$env(PDK)_setup.tcl lvs.report

I am using Netgen version 1.5.133. what my thought was, the netlists order are not matching (i mean pins are connected differently) when comparing lvs of (extraction of spice from mag file of digital macro) and (extraction of spice form xschem symbol of digital macro(including generated verilog netlist)). Devices and pins are same but its just connected order is different (As shown in below figure). Even during hardening process itself, flow checks lvs pass with pin matching. flow itself correctly extracting spice file in pin order. But when we manually extract spice from mag, the pin order seems different results in lvs netlist do not match. My concern is does it affect during running precheck in caravan analog process while integrating digital macro in analog design ? Expecting your comments about it?

Woah. netgen is currently at around

1.5.272

. Can you update? The pin order in net lvs report are pretty random in my experience. With netgen, the input order to logic gates matters. How much of this design was done by hand?

In your run scrip I think it’s missing the definition of the spice library of the standard cells. If you don’t have that line, I can see why the fill and tap cells don’t match up. Netgen will black box those cells if you don’t define it, so it appears in the Verilog netlist but not the Magic netlist, therefore LVS mismatch. If it’s defined, the fill and tap cells get evaluated down the hierarchy and resolves to nothing and then will match the Magic extracted netlist.

@Robin Tsang Thanks for pointing that out. @Allwan S Anand Can you try this

set layout [readnet spice "pwm_generator_layout.spice"]
set source [readnet spice "pwm_generator.spice"]
readnet spice $env(PDK_ROOT)/$env(PDK)/libs.ref/sky130_fd_sc_hd/spice/sky130_fd_sc_hd.spice $source
readnet verilog pwm_generator.v $source
lvs "$layout pwm_generator" "$source pwm_generator" $env(PDK_ROOT)/$env(PDK)/libs.tech/netgen/$env(PDK)_setup.tcl lvs.report

thanks @Mitch Bailey @Robin Tsang for your suggestions. I will try that. Also i have one more doubt for running precheck , how do we setup lvs_config.json file. Is it like below

{
  "STD_CELL_LIBRARY": [
    "sky130_fd_sc_hvl",
    "sky130_fd_sc_hd",
    "sky130_df_pr"
  ],
  "INCLUDE_CONFIGS": [
    "$LVS_ROOT/tech/$PDK/lvs_config.base.json"
  ],
  "TOP_SOURCE": "user_analog_project_wrapper",
  "TOP_LAYOUT": "user_analog_project_wrapper",
  "EXTRACT_FLATGLOB": [
    ""
  ],
  "EXTRACT_ABSTRACT": [
    ""
  ],
  "LVS_FLATTEN": [
    ""
  ],
  "LVS_NOFLATTEN": [
    ""
  ],
  "LVS_IGNORE": [
    ""
  ],
  "LVS_SPICE_FILES_TO_FIX": [
    "$UPRJ_ROOT/xschem/user_analog_project_wrapper.spice"
  ],
  "LVS_SPICE_FILES": [
    ""
  ],
  "LVS_VERILOG_FILES": [
    "$UPRJ_ROOT/verilog/rtl/pwm_generator.v"
  ],
  "LAYOUT_FILE": "$UPRJ_ROOT/gds/user_analog_project_wrapper.gds"
}

here i included my generated verilog netlist file of digital macro, the xschem spice files includes my schematic analog design + digital macro symbol, and gds file of wrapper contains both mixed designs. do i need to put any spice file in netgen folder in caravel_user_project_analog in order to pass consistency check? Is this way correct or do i need to change anything?

@Allwan S Anand I’d move

LVS_SPICE_FILES_TO_FIX

to

LVS_SPICE_FILES

. and yes, you’ll need to copy a spice file to

netgen

to get precheck to pass. Unforunately,

STD_CELL_LIBRARY

is not a list variable. If you’re using both

sky130_fd_sc_hvl

and

sky130_fd_sc_hd

then I suggest these settings.

"STD_CELL_LIBRARY": "sky130_fd_sc_hd",

"LVS_SPICE_FILES": [
        "$PDK_ROOT/$PDK/libs.ref/sky130_fd_sc_hvl/spice/*spice",
		"$UPRJ_ROOT/xschem/user_analog_project_wrapper.spice"
	],

Thanks @Mitch Bailey that's okay, i understood. but here comes one more doubt, while copying the xschem spice file to netgen it only contains the analog schematic and and digital macro symbol instances(netlists). Does it affect consistency check? because we are not providing anything related to digital macro like (generated verilog netlists)?

The consistency check only checks the top level.

thanks @Mitch Bailey while running precheck i got lvs error. the lvs report is attached here. The pin order of nfets and pfets seems diiferent.

@Allwan S Anand The source netlist should not include subckt definitions for primitive devices like

sky130_fd_pr__nfet_g5v0d10v5

. Can you share your source schematic?

@Mitch Bailey sorry, i didn't get you?

@Allwan S Anand

Can you share your source schematic?