Mitch Bailey
07/31/2020, 9:47 AM20Mhz
07/31/2020, 11:32 AMMatthew Guthaus
07/31/2020, 4:22 PMMitch Bailey
08/03/2020, 1:23 AMMatthew Guthaus
08/25/2020, 4:53 PMMitch Bailey
10/09/2020, 2:36 AMMitch Bailey
11/04/2020, 1:34 AMMitch Bailey
11/08/2020, 8:46 PMmag
views instead of maglef
views. (Change to run_magic_spice_export
in scripts/tcl_commands/magic.tcl
)
2. instead of netgen -batch lvs
, I execute the following script to add the cdl subcircuit definitions to the verilog netlist.
model blackbox on
readnet spice /openLANE_flow/sky130_fd_sc_hd.v.cdl 1
lvs {$layout $module_name} {$schematic $module_name} $setup_file $output -json
3. The sky130_fd_sc_hd.v.cdl
is created by copying sky130A/libs.ref/sky130_fd_sc_hd/cdl/sky130_fd_sc_hd.cdl
and changing M-devices to X-devices and adding device libraries to model names
sed -e 's/^M/XM/' -e 's/ [np]fet/ sky130_fd_pr__&/' <input> > <output>
Since extraction gives X-devices, the cdl must be modified to match (otherwise the pin names don't match). Currently, the netgen setup file only permutes devices prefixed with library names, so even though netgen compares <model> to <library>__<model>, permuted pins won't match.
4. I've also modified sky130A/libs.tech/netgen/setup.tcl
to ignore tapvpwrvgnd
cells. The connectivity has already been extracted and the subcircuits in the netlists are empty. (extracted netlist has no definition, so netgen adds placeholders with default pins. It appears that these don't match the pin names defined in the cdl)
5. The version of magic in the rc4 docker does not extract mosfet with source and drain connected to the same net. decap cells are currently ignored in the netgen setup, so shouldn't break the current LVS. Personal opinion is to keep decap cells in low level LVS (check the number), but that requires a change to sky130A/libs.tech/netgen/setup.tcl
There may still be some problems with the port numbers in the mag files, but should be fixed soon. I made some other changes to extract mos capacitors and those currently cause property errors, but these should go away with the latest version of magic.Mitch Bailey
11/09/2020, 7:45 AMMitch Bailey
11/18/2020, 6:50 AMMitch Bailey
11/18/2020, 12:28 PMMitch Bailey
11/18/2020, 1:38 PMzipdiv
design does not pass LVS (abstract or device level). The circuits are the same, but the ports o_quotient[2:0]
don't match. Digging through the netlists, it appears that the cause is a buffer placement. I've removed the power connections for sake of brevity.
sky130_fd_sc_hd__dfxtp_4 _2916_ (
.CLK(clknet_4_11_0_i_clk),
.D(_0002_),
.Q(o_quotient[0]),
);
sky130_fd_sc_hd__inv_8 _2638_ (
.A(o_quotient[0]),
.Y(_0596_)
);
sky130_fd_sc_hd__buf_2 psn_inst_psn_buff_37 (
.A(o_quotient[0]),
.X(psn_net_37)
);
sky130_fd_sc_hd__buf_2 psn_inst_psn_buff_38 (
.A(psn_net_37),
.X(psn_net_38)
);
sky130_fd_sc_hd__nor2_2 _2880_ (
.A(psn_net_49),
.B(psn_net_38),
.Y(_0809_)
);
In the zipdiv.lvs.powered.v
file, the latch output o_quotient[0]
is input to an inverter and a buffer-buffer-nor2 gate.
X_2916_ _2927_/CLK _2916_/D _2916_/Q sky130_fd_sc_hd__dfxtp_4
X_2638_ _2916_/Q _2640_/B sky130_fd_sc_hd__inv_8
Xpsn_inst_psn_buff_37 _2916_/Q o_quotient[0] sky130_fd_sc_hd__buf_2
Xpsn_inst_psn_buff_38 o_quotient[0] _2880_/B sky130_fd_sc_hd__buf_2
X_2880_ _2880_/A _2880_/B _2881_/B sky130_fd_sc_hd__nor2_2
In the extracted spice file, the latch output is an internal signal _2916_/Q
which is buffered to become o_quotient[0]
.Tim Edwards
11/18/2020, 2:47 PMMitch Bailey
11/18/2020, 3:48 PMAhmed Ghazy
11/18/2020, 4:45 PMAhmed Ghazy
11/18/2020, 4:56 PMCircuit 1 contains 1883 devices, Circuit 2 contains 1883 devices.
Circuit 1 contains 1426 nets, Circuit 2 contains 1426 nets.
Circuits match with 1 symmetry.
Resolving automorphisms by property value.
Resolving automorphisms by pin name.
Netlists match with 1 symmetry.
Circuits match correctly.
Result: Circuits match uniquely.
Logging to file "/openLANE_flow/designs/zipdiv/runs/lvs_issue/results/lvs/zipdiv.lvs.log" disabled
LVS Done.
LVS reports no net, device, pin, or property mismatches.
Total errors = 0
However, I am suspecting that sometimes something goes wrong with OpenPhySyn's pin swapping algorithm, but I can't seem to catch a test case...Mitch Bailey
11/18/2020, 5:28 PMMitch Bailey
11/19/2020, 4:23 AMAPU
design and got the following 'errors' (which may be classified as warnings, if there is no problem.)
DmaAddr[15] shorted to VPWR
DOUT[5] shorted to VGND
The data I'm using is from @User. develop-cvc
branch, I believe. I checked the lvs/APU.lvs.powered.v
file and indeed, these 2 nets were connected to power/ground.
I was wondering if this is the intended operation of the circuit? If it is, I can ignore these errors for this circuit.
There are 8 other designs (only 2 of which have LVS errors) with the same type of error. I can create a list of terminals tied to power/ground. Would that be useful.Riking28
11/19/2020, 6:07 AMMitch Bailey
11/20/2020, 6:55 AMMitch Bailey
11/27/2020, 6:44 PMnetgen
doesn't flag any errors if one of the cells has no devices and the other has no devices or nets. This is from the caravel user_project_wrapper
design. There is no definition for the verilog user_proj_example
in user_project_wrapper.synthesis.v
so it looks like netgen
creates one.
Reading netlist file /project/openlane/user_project_wrapper/runs/user_project_wrapper/results/magic/user_project_wrapper.spice
Reading netlist file /project/openlane/user_project_wrapper/runs/user_project_wrapper/results/synthesis/user_project_wrapper.synthesis.v
Contents of circuit 1: Circuit: 'user_proj_example'
Circuit user_proj_example contains 0 device instances.
Circuit contains 0 nets, and 614 disconnected pins.
Contents of circuit 2: Circuit: 'user_proj_example'
Circuit user_proj_example contains 0 device instances.
Circuit contains 0 nets.
Circuit user_proj_example contains no devices.
Contents of circuit 1: Circuit: 'user_project_wrapper'
Circuit user_project_wrapper contains 1 device instances.
Class: user_proj_example instances: 1
Circuit contains 614 nets, and 32 disconnected pins.
Contents of circuit 2: Circuit: 'user_project_wrapper'
Circuit user_project_wrapper contains 1 device instances.
Class: user_proj_example instances: 1
Circuit contains 612 nets, and 32 disconnected pins.
Circuit 1 contains 1 devices, Circuit 2 contains 1 devices.
Circuit 1 contains 612 nets, Circuit 2 contains 612 nets.
Netlists match uniquely.
Result: Circuits match uniquely.
Logging to file "/project/openlane/user_project_wrapper/runs/user_project_wrapper/results/lvs/user_project_wrapper.lvs.log" disabled
LVS Done.
LVS reports no net, device, pin, or property mismatches.
It looks like LVS passes, but if you look at the pin counts for user_proj_example
, there's a difference of 2 (612 vs 614). The verilog does not contain VPWR
and VGND
.Tim Edwards
11/27/2020, 7:05 PMMitch Bailey
11/30/2020, 4:02 AMext2spice
would generate duplicate nets in a subckt definition?
.subckt DFFRAM A[0] A[1] A[2] A[3] A[4] A[5] A[6] A[7] CLK Di[0] Di[10] Di[11] Di[12]
+ Di[13] Di[14] Di[15] Di[16] Di[17] Di[18] Di[19] Di[1] Di[20] Di[21] Di[22] Di[23]
...
+ Do[29] Do[2] Do[30] Do[31] Do[3] Do[4] Do[5] Do[6] Do[7] Do[8] Do[9] EN WE[0] WE[1]
+ WE[2] WE[3] VPWR VGND VGND VPWR VPWR VGND VGND VPWR VGND
VPWR and VGND appear multiple times in the definition (not the instance). I would expect that the subckt ports are unique.
This is from running device level LVS on caravel/openlane/mgmt_core
The DFFRAM.ext
file only has one port and one net for each of VPWR and VGND.Tim Edwards
11/30/2020, 6:34 PMMitch Bailey
12/17/2020, 1:47 AMconnect(1): no such node COLUMN\[0\].RAMCOLS/DIBUF\[31\]/VPWR
connect(2): no such node COLUMN\[0\].RAMCOLS/DIBUF\[31\]/VPWR
I'm trying to do LVS on the GDS vs gate level verilog + spice libraries, but ran into many of the above errors on the DFFRAM block.Tim Edwards
12/17/2020, 2:40 AMMitch Bailey
12/17/2020, 2:50 AMMitch Bailey
12/17/2020, 3:51 AMbox 104502 79709 104504 79711
feedback add "Label \"no_jumper_check\" attached to more than one unconnected node: c_83_258#" pale
box 104605 79709 104607 79711
feedback add "Label \"no_jumper_check\" attached to more than one unconnected node: c_186_258#" pale
box 104652 79694 104654 79696
feedback add "Label \"resistive_li1_ok\" attached to more than one unconnected node: c_233_273#" pale
box 104464 79694 104466 79696
feedback add "Label \"resistive_li1_ok\" attached to more than one unconnected node: c_45_273#" pale
Looks like it's a problem or incompatibility with the current GDS.
This GDS extracts with no errors. (cksum)
1092943470 45638256 caravel/openlane/DFFRAM/runs/DFFRAM/results/magic/DFFRAM.gds
This one has the unconnected node errors.
3090695239 46588662 caravel/gds/DFFRAM.gds
Mitch Bailey
12/19/2020, 1:39 PMnetgen
, too, if you're using macros.
https://github.com/RTimothyEdwards/netgen/pull/13Mitch Bailey
12/21/2020, 4:16 AMdecap
cells of sky130_fd_sc_hvl
Here's a sample netlist from the spice library.
.subckt sky130_fd_sc_hvl__decap_8 VGND VNB VPB VPWR
X0 VGND VPWR VGND VNB sky130_fd_pr__nfet_g5v0d10v5 w=750000u l=1e+06u
X1 VPWR VGND VPWR VPB sky130_fd_pr__pfet_g5v0d10v5 w=1e+06u l=1e+06u
X2 VPWR VGND VPWR VPB sky130_fd_pr__pfet_g5v0d10v5 w=1e+06u l=1e+06u
X3 VGND VPWR VGND VNB sky130_fd_pr__nfet_g5v0d10v5 w=750000u l=1e+06u
.ends
And here's the netlist from the extracted GDS (mgmt_protect_hv.gds
from caravel)
.subckt sky130_fd_sc_hvl__decap_8 VNB VGND VPWR VPB
X0 VGND VPWR VGND VNB sky130_fd_pr__nfet_g5v0d10v5 w=750000u l=1e+06u
X1 VNB VGND VPWR VPB sky130_fd_pr__pfet_20v0 w=1e+06u l=1e+06u
X2 VNB VGND VPWR VPB sky130_fd_pr__pfet_20v0 w=1e+06u l=1e+06u
X3 VGND VPWR VGND VNB sky130_fd_pr__nfet_g5v0d10v5 w=750000u l=1e+06u
.ends
1. You'll notice that the pfet models are different. 5V vs 20V
2. The power short shows up on the pfets. Instead of the source and drain both being connected to VPWR, one is connected to VNB, which is VGND and since the gate is tied low, VPWR shorts to VGND.
Could this be a rule problem?