SKY130 designs fail to run (and takes a long time to do so)

[xobs]

Describe the bug
When running one of the built-in SKY130 macros, the generation process takes a VERY long time and fails.

Version
5ad1db9

To Reproduce

1. Check out the repository
2. Create and activate a python venv
3. Install python requirements: pip install -r requirements.txt
4. Run OPENRAM_HOME=$PWD/compiler/ OPENRAM_TECH=$PWD/technology PDK_ROOT=$PWD/PDKs make pdk
5. Run git -C PDKs/open_pdks checkout master # this step is required to get make install to work
6. Run OPENRAM_HOME=$PWD/compiler/ OPENRAM_TECH=$PWD/technology PDK_ROOT=$PWD/PDKs make install
7. Run the synthesis:

time \
PYTHONPATH=$PWD/compiler:$VIRTUAL_ENV/lib/python3.10/site-packages/ \
OPENRAM_HOME=$PWD/compiler/ \
OPENRAM_TECH=$PWD/technology \
PDK_ROOT=$PWD/PDKs \
python3 \
$PWD/compiler/openram.py \
macros/configs/sky130_sram_1kbyte_1r1w_8x1024_8.py

Expected behavior
The build should complete, and in a reasonable time

Logs

(pyenv) user@Ondo:/opt/Si/src/or2$ time \
PYTHONPATH=$PwD/compiler:$VIRTUAL_ENV/lib/python3.10/site-packages/ \
OPENRAM_HOME=$PWD/compiler/ \
OPENRAM_TECH=$PWD/technology \
PDK_ROOT=$PWD/PDKs \
python3 \
$PWD/compiler/openram.py \
macros/configs/sky130_sram_1kbyte_1r1w_8x1024_8.py
|==============================================================================|
|=========                       OpenRAM v1.2.0                       =========|
|=========                                                            =========|
|=========               VLSI Design and Automation Lab               =========|
|=========        Computer Science and Engineering Department         =========|
|=========            University of California Santa Cruz             =========|
|=========                                                            =========|
|=========          Usage help: [email protected]           =========|
|=========        Development help: [email protected]        =========|
|=========          Temp dir: /tmp/openram_user_12795_temp/           =========|
|=========                See LICENSE for license info                =========|
|==============================================================================|
** Start: 11/25/2022 17:42:58
Technology: sky130
Total size: 8192 bits
Word size: 8
Words: 1024
Banks: 1
RW ports: 0
R-only ports: 1
W-only ports: 1
DRC/LVS/PEX is only run on the top-level design to save run-time (inline_lvsdrc=True to do inline checking).
Characterization is disabled (using analytical delay models) (analytical_delay=False to simulate).
Only generating nominal corner timing.
Words per row: 8
Output files are:
/opt/Si/src/or2/macro/sky130_sram_1kbytes_1r1w_8x1024_8/sky130_sram_1kbytes_1r1w_8x1024_8.lvs
/opt/Si/src/or2/macro/sky130_sram_1kbytes_1r1w_8x1024_8/sky130_sram_1kbytes_1r1w_8x1024_8.sp
/opt/Si/src/or2/macro/sky130_sram_1kbytes_1r1w_8x1024_8/sky130_sram_1kbytes_1r1w_8x1024_8.v
/opt/Si/src/or2/macro/sky130_sram_1kbytes_1r1w_8x1024_8/sky130_sram_1kbytes_1r1w_8x1024_8.lib
/opt/Si/src/or2/macro/sky130_sram_1kbytes_1r1w_8x1024_8/sky130_sram_1kbytes_1r1w_8x1024_8.py
/opt/Si/src/or2/macro/sky130_sram_1kbytes_1r1w_8x1024_8/sky130_sram_1kbytes_1r1w_8x1024_8.html
/opt/Si/src/or2/macro/sky130_sram_1kbytes_1r1w_8x1024_8/sky130_sram_1kbytes_1r1w_8x1024_8.log
/opt/Si/src/or2/macro/sky130_sram_1kbytes_1r1w_8x1024_8/sky130_sram_1kbytes_1r1w_8x1024_8.lef
/opt/Si/src/or2/macro/sky130_sram_1kbytes_1r1w_8x1024_8/sky130_sram_1kbytes_1r1w_8x1024_8.gds
WARNING: file hierarchy_layout.py: line 646: Could not find pin gnd on col_cap_bitcell_2port
WARNING: file hierarchy_layout.py: line 646: Could not find pin gnd on col_cap_bitcell_2port
WARNING: file hierarchy_layout.py: line 646: Could not find pin gnd on col_cap_bitcell_2port
WARNING: file hierarchy_layout.py: line 646: Could not find pin gnd on col_cap_bitcell_2port
** Submodules: 3.9 seconds
** Placement: 0.0 seconds
**** Retrieving pins: 0.0 seconds
**** Analyzing pins: 0.0 seconds
**** Finding blockages: 2.3 seconds
**** Converting blockages: 0.3 seconds
**** Converting pins: 0.0 seconds
**** Separating adjacent pins: 0.0 seconds
*** Finding pins and blockages: 39.2 seconds
*** Maze routing pins: 62.9 seconds
**** Retrieving pins: 0.0 seconds
**** Analyzing pins: 0.1 seconds
**** Finding blockages: 6.0 seconds
**** Converting blockages: 0.2 seconds
**** Converting pins: 4.4 seconds
**** Separating adjacent pins: 24.5 seconds
*** Finding pins and blockages: 73.9 seconds
*** Maze routing supplies: 365.5 seconds
** Routing: 758.6 seconds
ERROR: file magic.py: line 317: Unable to load LVS results from /tmp/openram_user_12795_temp/sky130_sram_1kbytes_1r1w_8x1024_8.lvs.report
Traceback (most recent call last):
  File "/opt/Si/src/OpenRAM/compiler/verify/magic.py", line 315, in run_lvs
    f = open(resultsfile, "r")
FileNotFoundError: [Errno 2] No such file or directory: '/tmp/openram_user_12795_temp/sky130_sram_1kbytes_1r1w_8x1024_8.lvs.report'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/Si/src/OpenRAM/compiler/openram.py", line 77, in <module>
    s = sram(name=OPTS.output_name,
  File "/opt/Si/src/OpenRAM/compiler/modules/sram.py", line 49, in __init__
    self.s.create_layout()
  File "/opt/Si/src/OpenRAM/compiler/modules/sram_base.py", line 231, in create_layout
    self.DRC_LVS(final_verification=OPTS.route_supplies, force_check=OPTS.check_lvsdrc)
  File "/opt/Si/src/OpenRAM/compiler/base/hierarchy_design.py", line 71, in DRC_LVS
    self.lvs_errors = verify.run_lvs(self.cell_name, tempgds, tempspice, final_verification=final_verification)
  File "/opt/Si/src/OpenRAM/compiler/verify/magic.py", line 317, in run_lvs
    debug.error("Unable to load LVS results from {}".format(resultsfile), 1)
  File "/opt/Si/src/OpenRAM/compiler/debug.py", line 47, in error
    assert return_value == 0
AssertionError

real    104m36.071s
user    104m17.438s
sys     0m18.397s
(pyenv) user@Ondo:/opt/Si/src/or2$

Additional context
It is unclear whether this should take as long as it does. The majority of the time (around 95 minutes) is spent in a process called magicdnull.

This does not happen when using scn4m_subm as a library with a 16x2 library. It appears to only happen when using SKY130.

[mguthaus]

Please use the docker image to run the tools. Netgen isn't installed and you likely have on incompatible version of magic installed.

In the macros directory, you can run "make "

[xobs]

netgen is installed, and I've got the latest version of magic. I think maybe magic is segfaulting? Is there any way to find out?

When I run it in debug mode, I see this in the output:

Extracting sky130_sram_1kbyte_1r1w_8x1024_8_pinv_7 into sky130_sram_1kbyte_1r1w_8x1024_8_pinv_7.ext:
Extracting sky130_sram_1kbyte_1r1w_8x1024_8_pdriver_1 into sky130_sram_1kbyte_1r1w_8x1024_8_pdriver_1.ext:
Extracting sky130_sram_1kbyte_1r1w_8x1024_8_pinv_10 into sky130_sram_1kbyte_1r1w_8x1024_8_pinv_10.ext:
Extracting sky130_sram_1kbyte_1r1w_8x1024_8_delay_chain into sky130_sram_1kbyte_1r1w_8x1024_8_delay_chain.ext:
Segmentation fault
Fri Nov 25 22:34:49 +08 2022: Finished (139) GDS to MAG using Magic /opt/Si/magic/bin/magic
Fri Nov 25 22:34:50 +08 2022: Starting DRC using Magic /opt/Si/magic/bin/magic

[mguthaus]

The latest versions may not work. The versions in the Docker are known to work.

They've introduced bugs throughout time and we need to get them fixed before we can use the latest versions. This is particularly true with substrate extraction and matching ports in LVS.

[mguthaus]

Your temp directory (shown at the beginning of the run) will have the standard output .out and error .err of the run as well as shell scripts to rerun it. This should also be run in docker to recreate with the right versions though.

[mguthaus]

Need to test/submit bug to magic with this as a test case.

[proppy]

I was able to use the latest packaged version of magic and netgen:

  + magic                  8.3.346_0_g01f2ce3  20221104_084554       litex-hub/linux-64       5MB
  + netgen                 1.5.242_0_g4edaf08  20221104_084554       litex-hub/linux-64     795kB

and the latest version of the PDK from https://github.com/vlsida/sky130_fd_bd_sram and https://github.com/google/skywater-pdk-libs-sky130_fd_sc_hd

with in this notebook:
https://gist.github.com/proppy/ca838cce6dbb983e876f9704d8ffa0a9

I realize that might not be a supported combinaison as the versions might differ from the blessed versions currently specified in https://github.com/VLSIDA/OpenRAM/blob/stable/Makefile, but I wanted to mention it as an additional datapoint.

[mguthaus]

@proppy That creates a dual port but we have had more issues with substrate extraction in the single port memories. They use a different bitcell that is harder to extract with the current algorithms...