Hi @Mitch Bailey, I was trying to integrate extra-be-checks into our still-in-analog design environment. Some questions arrise while reading how to use the tools. - It seems that

hier-check

it's used exclusive on digital designs only, Am I wrong? Is the only tool exclusive to digital? - The netgen and magic configurations on

$LVS_ROOT/tech/gf180mcuD/

are different from the ones given on open_pdks, what should I do? there's a warning also. - Can I have only one

lvs_config.json

for all my designs? Including padring analysis. I mean, using the same json for all the tools. - I'm having troubles with a simple inverter example

inv_sample

. the inv_sample.gds.spice is not generated. Thanks for sharing this validation scripts, this will help a lot in our future designs.

@aquiles viza

- It seems that

hier-check

it’s used exclusive on digital designs only, Am I wrong? Is the only tool exclusive to digital?

Correct, this check compares the verilog hierarchy to the layout hierarchy and issues a warning in the log if there are differences. It is intended to be a quick sanity check to quickly identify inconsistencies that result from using wrong versions of the netlist.

- The netgen and magic configurations on

$LVS_ROOT/tech/gf180mcuD/

are different from the ones given on open_pdks, what should I do? there’s a warning also.

If by configurations, you mean the netgen setup file and the magic tech file, then, yes, there are currently some differences. The netgen setup file difference should only be additions that allow matching between prefixed cell names. The magic tech differences should only be those that are needed to extract the layout without well connections. The nowell extracted layout is used to find soft connection errors. Ideally, these changes should be incorporated in to the pdk version, but I haven’t been able to talk Tim into that yet. If there are differences that are causing problems, please let me know and I’ll push an update.

- Can I have only one

lvs_config.json

for all my designs? Including padring analysis. I mean, using the same json for all the tools.

The command line overrides the top source block, top layout block, and gds file, so I guess it is possible to include all the source netlists and other parameters in one lvs_config.json file. However, the intention is to allow hierarchy

lvs_config.json

files that encapsulate the details for sub levels. You can see examples in the

tech/<process>/lvs_config.<block>.json

files. The

chip_io

file is particularly complex, but the top level is relatively simple.

- I’m having troubles with a simple inverter example

inv_sample

. the inv_sample.gds.spice is not generated.

The

$LVS_ROOT/tech/gf180mcuD/lvs_config.base.json

file references a

STD_CELL_LIBRARY

variable that hasn’t been set. See

lvs_config.caravel_core.json

for an example. The

lvs_config.base.json

file will load the standard cell spice library, so you don’t need to duplicate that in your

lvs_config.json

. After setting

LVS_ROOT

,

WORK_ROOT

,

PDK_ROOT

, and

PDK

and adding the schematic spice to the

lvs_config.json

file, try

$LVS_ROOT/run_be_checks lvs_config.json inv_sample inv_sample inv_sample.gds

Another option is to specify the

TOP_LAYOUT

,

TOP_SOURCE

, and

LAYOUT_FILE

in the

lvs_config.json

file. If you open the extracted spice file and see subckts with auto-generated net names, I suggest added those cells to the

EXTRACT_FLATGLOB

list in the

lvs_config.json

file. Please let me know if you have any trouble or questions.