multi vt support failing during run_magic_spice_export

[vijayank88]

Description

I am trying to use sky130_fd_sc_hdll std cell library during synthesis and sky130_fd_sc_hd cell library during optimization by setting below variable in config.tcl. #multi vt checking set ::env(STD_CELL_LIBRARY) "sky130_fd_sc_hdll" set ::env(STD_CELL_LIBRARY_OPT) "sky130_fd_sc_hd"

But got failed with error. Logs shown in relevant ###Logs area for reference.

Environment

• Operating System Information: uname -a --- Linux a4e01c18ec2e 5.11.0-25-generic #27~20.04.1-Ubuntu SMP Tue Jul 13 17:41:23 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

• Docker Version: docker --version--- Docker version 20.10.8, build 3967b7d

  • If you're using Podman, please also include this information.

• OpenLane Tag in use: python3 ./get_tag.py in the main OpenLane directory. --- 2021.08.17_03.26.57

Reproduction Material

• List the commands used to run the design.
• Take in-built spm design in openlane.
• Update design/spm/config.tcl with below lines: set ::env(STD_CELL_LIBRARY) "sky130_fd_sc_hdll" set ::env(STD_CELL_LIBRARY_OPT) "sky130_fd_sc_hd" bash$ ./flow.tcl -design spm

Check logs for above failure messages.

Expected behavior

Successful design completion.

Logs

Extracting sky130_fd_sc_hdll__decap_3 into sky130_fd_sc_hdll__decap_3.ext:
Extracting sky130_fd_sc_hdll__clkbuf_6 into sky130_fd_sc_hdll__clkbuf_6.ext:
Extracting uart into uart.ext:
uart: 364 fatal errors
Total of 364 errors (check feedback entries).
exttospice finished.
Using technology "sky130A", version 1.0.203-0-g13e0611
[ERROR]: There are illegal overlaps (e.g., routes over obstructions) in your design.
[ERROR]: See /openLANE_flow/designs/uart/runs/multivt/logs/magic/30-magic_ext2spice.feedback.txt for more.
[INFO]: Calculating Runtime From the Start...
[INFO]: Flow failed for uart/20-08_12-47 in 0h6m3s
[INFO]: Generating Final Summary Report...
[INFO]: Design Name: uart
Run Directory: /openLANE_flow/designs/uart/runs/multivt
Source not found.
----------------------------------------

LVS Summary:
Source: /openLANE_flow/designs/uart/runs/multivt/results/lvs/uart.lvs_parsed.gds.log
Source not found.
----------------------------------------

Antenna Summary:
No antenna report found.
[INFO]: check full report here: /openLANE_flow/designs/uart/runs/multivt/reports/final_summary_report.csv
[INFO]: Saving Runtime Environment
[ERROR]: Flow Failed.

    while executing
"quit_on_illegal_overlaps -log [index_file $::env(magic_log_file_tag)_ext2$extract_type.feedback.txt 0]"
    (procedure "run_magic_spice_export" line 63)
    invoked from within
"run_magic_spice_export"
    (procedure "run_lvs_step" line 9)
    invoked from within
"[lindex $step_exe 0] [lindex $step_exe 1] "
    (procedure "run_non_interactive_mode" line 43)
    invoked from within
"run_non_interactive_mode {*}$argv"
    invoked from within
"if { [info exists flags_map(-interactive)] || [info exists flags_map(-it)] } {
	puts_info "Running interactively"
	if { [info exists arg_values(-file)..."
    (file "./flow.tcl" line 351)

[vijayank88]

@Manarabdelaty @Indira suggestion as follows:

Tim Edwards identified that the issue is with the skywater-pdk lef views for the buffer cells. The buffer cells have LI pin layer as part of the power and ground nets while all the other HDLL cells mark the li net as obstruction. I believe Tim will fix it in open_pdks by generating the lef views from magic instead. Until open_pdks is updated, you can for now add this to your config.tcl:

set ::env(QUIT_ON_ILLEGAL_OVERLAPS) 0

This will prevent openlane from quitting on illegal overlaps and it should continue to run the DRC and LVS steps.

With above set variable i'm able to pass LVS stage error.

From the spm design resizer logs I don't see much improvements because of using different library. See the attached images. There is WARNING ODB-0045. Cells and component value increased by using hdll and hd std cell library. Refer the attached image for ODB warnings.

[donn]

The lack of an improvement is not really an issue here, but the PDK should be fixed.

[Manarabdelaty]

@vijayank88 Another possible solution is to run the spice extraction on the gds instead of the lef view. This solution is generally better than setting QUIT_ON_ILLEGAL_OVERLAPS to zero because if there is an actual illegal overlap, it will be caught. You can add this to your config.tcl to do so:

set ::env(MAGIC_EXT_USE_GDS) 1 
set ::env(RUN_CVC) 0 

You will need to disable running CVC in this case because of this issue https://github.com/d-m-bailey/cvc/issues/233

[vijayank88]

@Manarabdelaty updated config.tcl and ran able to complete the flow without fail, but results same like above

[tspyrou]

I think we should make a fork of the openpdk and keep it stable and update only when new versions work in the flow. This is what OpenROAD-flow-scripts has been doing and is much more stable. Right now the head of OL is unstable. @mkkassem @mithro

[donn]

A fork is unnecessary as we already do precisely what you’re asking for here using tags. This usecase likely doesn’t work with the current iteration of the PDK because it never did, not because a regression has occurred in the PDK. Remember, ORFS does not use Magic for anything, so any percieved regression would just be items that are not supported by our current setup.

[dralabeing]

@donn @Manarabdelaty What is the ETA on fixing the PDK since the above workarounds don't work for this test case?

[mithro]

I think we should make a fork of the openpdk and keep it stable and update only when new versions work in the flow. This is what OpenROAD-flow-scripts has been doing and is much more stable. Right now the head of OL is unstable. @mkkassem @mithro

You should most certainly be using the latest version and submitting fixes when things break. Stability comes from improving the CI, testing and increasing the number of users -- not by making the rate of change slower.