Hey, I have an RTL design that I have pushed through synthesis but it is failing LVS prechecks on the efabless shuttle. I looked through the LVS_precheck log and the only thing that seemed like an error is this:

! Checking pmos gate vs source errors: 

Usage ERROR: Time: 6  Memory: 411416  I/O: 112  Swap: 0
Saving min/max voltages...
CVC: Propagating Simulation voltages 1...
Usage SIM1: Time: 6  Memory: 417224  I/O: 120  Swap: 0
Power nets 84059
Saving simulation voltages...
CVC: Propagating Simulation voltages 3...
Usage SIM2: Time: 6  Memory: 418808  I/O: 120  Swap: 0
Power nets 84059
Added 0 latch voltages
CVC: Calculating min/max voltages...
Processing trivial nets found 49415 trivial nets
MaximumQueue Counts (size/enqueue/requeue) 156652/282003/0
MinimumQueue Counts (size/enqueue/requeue) 150608/278981/0
CVC: Ignoring invalid calculations...
CVC:   Removed 0 calculations
Copying master nets
CVC: Ignoring non-conducting devices...
CVC:   Ignored 0 devices
Usage MIN/MAX2: Time: 7  Memory: 425408  I/O: 120  Swap: 0
Power nets 167736

any tips on how to debug this sort of issue? I am not sure exactly what issue is being described here.

@Edmund Lam Can you share your

LVS_check.log

file? (The `Usage ERROR`: line is an unfortunate choice of a step name. It is showing the usage stats for the

error

detection step of CVC-RV and is a normal message.)

Here is LVS_check, lmk if you need anything else

@Edmund Lam netgen will “match” missing circuits. In your case, LVS is “passing” but there are 2 (or maybe just 1) circuit that is being compared as a block box.

LVS result:
Final result: 
Circuits match uniquely.
.
LVS Done.
Warning: device level LVS may be incomplete due to 2 unflattened cell(s): see /mnt/users_data/jobs/cornellcustomsiliconsystems/C2S2-Digital-Tapeout-SP24/6387583e-58f1-44b1-a834-5e0e269a1ef4/outputs/reports/lvs.unflattened

What is in

outputs/reports/lvs.unflattened

?

I see, I am getting

tapeins_sp24_tapein1_Interconnect is a black box in the source
tapeins_sp24_tapein1_Interconnect contains no devices

in lvs.unflattened. Is this because I am instantiating it as a macro when synthesizing user_project_wrapper? If so, how can I get LVS to pass?

If it doesn’t contain any devices, there are 2 ways to handle it. By default, magic will not extract subckt for cells that do not contain devices. You can force magic to extract an empty subckt by adding the cell to

EXTRACT_ABSTRACT

in the

lvs_config.json

file. However, if you the cell has a hierarchy, that may not be extracted. I recommend that you try flattening the cell during LVS using

LVS_FLATTEN

in the

lvs_config.json

file. Let me know if you have problems.

Thanks! I reran and it seems to be better now but I am getting

Top level cell failed pin matching

. What could be causing this?

@Edmund Lam reversed pins, multiple pins with the same label but unconnected, spelling errors, etc. Try checking the lvs report.

How does this happen even though it synthesized?

@Edmund Lam in older versions of netgen, this “error” would sometimes be generated when the output nets where intentionally tied either high or low. What version of netgen are you using? Is this the result of

make run-precheck

?

Yes, this is a result of run-precheck.

Short answer is io_oeb should be tied high or low depending on usage. io_out should also be tied if not used. Can you check the netgen version? Should be at the top of the lvs log.

1.5.272

. I am using input_nopull so I read that io_oeb can be either low or high and it shouldn't matter?

If you have the gpio configured in a

USER

mode and don’t connect

io_oeb

, there may be leakage due to Hi-Z input to a logic gate in

gpio_control_block

. You can either tie

io_oeb

or use the

MGMT

version (input will still go to the user area). However, gpio 0-5 have

io_out

and

io_oeb

buffered in the caravel_core, so you’ll want to tie these even if they are configured in

MGMT

mode.

lvs.report

Don’t tie any of the

io_in

signals. Unused

io_out

may be either high or low. Unused

io_oeb

tied high is probably safest. I apologize for the trouble you’re facing. It’s due to a mismatch in the PDK and the lvs system. Are you running precheck locally or on the platform?

on the platform

Woah.

io_oeb

signals need to be low for outputs. For inputs, you can tie

io_oeb

either high or low.

io_oeb

includes 0-5 (along with

io_out

for 0-5).

io_out

signals go into logic gates in

gpio_control_block

. Floating inputs into logic gates can cause leaks because both the nmos and pmos may be on. Platform precheck is broken. Do you pass precheck locally?

MPW_TAG=mpw-9i make precheck
make run-precheck

My precheck locally keeps failing with

Error: 157

. I can run again once my synthesis run finishes though.

If I set unused gpios to MGMT OUTPUT do I still need to tie them?

In that case, you only need to tie

io_out

and

io_oeb

for gpio 0-5.

Something like this should work then?

@Edmund Lam If you’re using the caravel framework, I think there are a total of 38 gpio.

I am assuming as they are set to MGMT it should be ok

@Edmund Lam I see. You are correct.

I am still having the same issue where io_oeb and io_outs are being shuffled around. Could this be because my inner module uses io_oeb and io_out as port names? All the other ports seem to be connected properly, only the ones where I do .io_out(io_out[4:0]) have this issue

Can you share the full lvs.report file?

Yup, here it is:

@Edmund Lam Instead of looking at the end of the report, I suggest looking at circuits that have

Flattening non-matched subcircuits ...

The first one that shows up is

sky130_fd_sc_hd__dfxtp_4

. This is a standard cell that should not show a mismatch and indicates a problem with the rule version and the pdk. This is from the local precheck correct, right? (remember, LVS on the platform precheck is currently broken). Could you try with volare pdk version

dd7771c384ed36b91a25e9f8b314355fc26561be

?

How can I do that? Also, my local LVS is erroring out with Error:157 every time I run it, and it seems to originate from somewhere in the dockerfile...

Looks like the step after the XOR that’s causing the error. From what I can see, that’s the magic drc step. To just run lvs in precheck, try

make lvs-user_project_wrapper

I managed to get precheck running (it looks like I/O possible is a race condition issue with serial ports?) I ran it directly in the docker image and it occasonally passed that spot