The build breaks when the sky130_osu_sc_t18 library is not there, because it tries to move the tlef file with the mv command without checking if the file exists or not, and so the build fails if it's not there (which will always be the case until the library is released).

mv `pwd`/sky130A/libs.ref/sky130_osu_sc_t18/techlef/sky130_osu_sc.tlef `pwd`/sky130A/libs.ref/sky130_osu_sc_t18/techlef/sky130_osu_sc_t18.tlef

mv: cannot stat `/home/travis/build/RTimothyEdwards/open_pdks/sky130/sky130A/libs.ref/sky130_osu_sc_t18/techlef/sky130_osu_sc.tlef': No such file or directory

The solution to this issue is in this PR #39, but it was closed without being merged :-)

The open_pdks/sky130/magic/sky130.tech file extracts generic resistors as R-devices.

Generic resistors

sky130_fd_pr__res_generic_l1
sky130_fd_pr__res_generic_m1
sky130_fd_pr__res_generic_m2
sky130_fd_pr__res_generic_m3
sky130_fd_pr__res_generic_m4
sky130_fd_pr__res_generic_m5
sky130_fd_pr__res_generic_nd
sky130_fd_pr__res_generic_nd__hv
sky130_fd_pr__res_generic_pd
sky130_fd_pr__res_generic_pd__hv
sky130_fd_pr__res_generic_po

Sample extraction (2 terminal resistor):

.subckt sky130_fd_sc_hd__conb_1 VGND VNB VPB VPWR HI LO
R0 HI VPWR sky130_fd_pr__res_generic_po w=480000u l=45000u
R1 VGND LO sky130_fd_pr__res_generic_po w=480000u l=45000u
.ends

The spice library has the 3 terminal X-resistor definitions.

.subckt sky130_fd_sc_hd__conb_1 VGND VNB VPB VPWR HI LO
X0 VGND LO VNB short w=480000u l=45000u
X1 HI VPWR VNB short w=480000u l=45000u
.ends

Maybe change the extraction to rsubcircuits and change the spice library to 2 terminal sky130_fd_pr__res_generic_po devices.

Also the variant(orig) sytle has a spelling error.

 device rsubcircuit sky130_fd_pr_res_generic_nd     ndiffres \
        *ndiff pwell,space/w  error l=l w=w
 device rsubcircuit sky130_fd_pr_res_generic_pd     pdiffres \
        *pdiff nwell    error l=l w=w

Probably should be sky130_fd_pr__res_generic_nd and sky130_fd_pr__res_generic_pd (2 '_' between the 'pr' and 'res')

Generally, high voltage diffusion is expected to be surrounded by a guard ring of the same type (high or low voltage diffusion). Need to check that the HVI layer overlaps are correct if using a low voltage guard ring around a high voltage diffusion area. Likely this situation should be prohibited, but it's unclear that it can be, or should be.

https://docs.github.com/en/github/building-a-strong-community/adding-a-license-to-a-repository

 sudo ./configure --enable-sky130-pdk=~/projects/foundry/skywater-pdk/libraries --with-sky130-local-path=/cad/pdks

configure: Found technology directories: sky130
configure: Checking specified path for 'sky130' at
checking for ... no
configure: error: Specified path for 'sky130' at not found

In the sky130/magic/sky130.tech file, rmp devices are extracted in the ngspice(orig) style, but not the default ngspice() style.

Is this intentional?

For example, with ngspice(orig), we get

.subckt sky130_fd_sc_hd__conb_1 VGND VNB VPB VPWR HI LO
R0 HI VPWR sky130_fd_pr__res_generic_po w=480000u l=45000u
R1 VGND LO sky130_fd_pr__res_generic_po w=480000u l=45000u
.ends

But with the default ngspice(), we get nothing - just the extracted instance.
X_31159_ VGND VGND VPWR VPWR _31159_/HI mem_la_addr[0] sky130_fd_sc_hd__conb_1

Hi, I'm pretty new to the open EDA community, so let me know if there's a better channel for questions like these. I like OpenLANE's use of open_pdks for the distribution of Sky130, but I've been more successful having my designs build with OpenROAD. So my goal was to use open_pdks standalone to have an up-to-date distribution of Sky130 for use in OpenROAD.

It looks like in commit 8292c90 the --with-sky130-source option was removed from the config script, but the documentation in both the readme and on Open PDKs still says to use that option for building. Is the correct new way to specify the location of skywater-pdk to use the -enable-sky130-pdk option? I know about the SKYWATER_PATH variable, but I'm curious about the config script options.

And on a more general level, I'm confused why OpenLANE and OpenROAD are two distinct projects. They seem very similar and differ only in their specific usage of OpenROAD placement, TritonRoute, and PDK distribution. If there's a place where I can learn more about the differences and purposes of each flow that would be helpful.

Magic ver. 8.3 r 57

Message produced before segfault is:

/openlane/pdk/sky130A/libs.tech/magic/current/sky130A.tech: line 567: section compose:
	Unrecognized layer (type) name "obsli,obsm1"

Commenting line 567 cures the problem:

#  paint	 obslicobsm1	 obsli,obsm1

Is there a danger in making cells using the modified tech file?

When doing gate level simulation I have to convert all the fake diodes to real diodes to get it to build. It would be nice to have something in open_pdks to solve this.

Getting an index out of range error on build.

Did:
./configure --enable-sky130-pdk
make

And getting error:

# Install OSU T18 ls digital standard cells.
set -f ; ../common/foundry_install.py -std_format -source -target /home/apond/open_pdks/sky130/sky130A
-techlef sky130_osu_sc_18T.tlef rename=sky130_osc_sc_18t_ls.tlef
-spice 18T_ls/cdl/.spice compile-only exclude=..spice
-lef 18T_ls/lef/.lef
-lib 18T_ls/lib/.lib
-gds 18T_ls/gds/.gds compile-only
options=custom/scripts/gds_import_setup.tcl
-library digital sky130_osu_sc_18t_ls 2>&1 | tee -a sky130A_make.log
Traceback (most recent call last):
File "../common/foundry_install.py", line 430, in
sourcedir = option[1]
IndexError: list index out of range

The process stack diagram shows the layer thickness and elevation.

Is it possible to obtain this information for all possible layers in a textual format? Or is it possible to compute these from existing data?

Any pointers will be useful. Thanks!

Hello,

Following instructions fails with magic exit code -9
Multiple lines spamming "No label found with index ." in log
It blew my log file to about 50GB so I cant copy and paste it here.

I really wanted to try to use this to design custom PLL, but it does not work. Any suggestions?
OS: Ubuntu 20.04 LTS.
Magic: magic-8.3.122
Everything else latest stable

Steps to reproduce:

cd
mkdir skywater
cd skywater
git clone https://github.com/google/skywater-pdk
cd skywater-pdk
git submodule init libraries/sky130_fd_io/latest
git submodule init libraries/sky130_fd_pr/latest
git submodule init libraries/sky130_fd_sc_hd/latest
git submodule init libraries/sky130_fd_sc_hdll/latest
git submodule init libraries/sky130_fd_sc_hs/latest
git submodule init libraries/sky130_fd_sc_ms/latest
git submodule init libraries/sky130_fd_sc_ls/latest
git submodule init libraries/sky130_fd_sc_lp/latest
git submodule init libraries/sky130_fd_sc_hvl/latest
git submodule update
make -j$(nproc) timing 


cd ~/skywater/
git clone --branch 1.0.142 git://opencircuitdesign.com/open_pdks
cd open_pdks
./configure --enable-sky130-pdk=$HOME/skywater/skywater-pdk/libraries --with-sky130-local-path=$HOME/skywater/pdk/skywater130 --enable-xschem-sky130
cd sky130
make -j$(nproc) # <---------------- fails here
sudo make install
cd ~/skywater

Currently trying same without -j option for make

Thanks,
Armleo

Hello,
I initially filed an issue against openlane for this (https://github.com/efabless/openlane/issues/91), and @agorararmard suggested an issue should be filed here as well.
I'm building open_pdk using the rc4 release of openlane. Here are the relevant commits for Skywater and OpenPDK:
SKYWATER_COMMIT: 5cd70ed19fee8ea37c4e8dbd5c5c3eaa9886dd23
OPEN_PDKS_COMMIT: 48db3e1
The build basically appears to work, and I can successfully run the 'test' step from openlane. However, quite a few of the simulation models used by efabless/caravel are not present.
I see the following error when I build pdk_root:

Writing all magic database files^M
Writing 'sky130_fd_pr__cap_vpp_08p6x07p8_m1m2_lishield'^M
Writing 'sky130_fd_pr__cap_vpp_11p5x11p7_m1m2m3m4_shieldl1m5'^M
Writing 'sky130_fd_pr__cap_vpp_11p5x11p7_m1m2_noshield'^M
Writing 'sky130_fd_pr__rf_test_coil1'^M
Writing 'sky130_fd_pr__rf_test_coil2'^M
Writing 'sky130_fd_pr__rf_npn_05v5_W1p00L2p00'^M
Writing 'sky130_fd_pr__rf_test_coil3'^M
Writing 'sky130_fd_pr__cap_vpp_04p4x04p6_m1m2_lishield'^M
Writing 'sky130_fd_pr__pnp_05v5_W3p40L3p40'^M
Writing 'sky130_fd_pr__rf_npn_05v5_W1p00L1p00'^M
Writing '(UNNAMED)'^M
Must specify name for cell (UNNAMED).^M
Done.^M
Error message output from magic:^M
File sky130_fd_pr__rf_npn_05v5_W1p00L1p00.mag couldn't be read^M
No such file or directory^M
File sky130_fd_pr__rf_npn_05v5_W1p00L2p00.mag couldn't be read^M
No such file or directory^M
File sky130_fd_pr__pnp_05v5_W3p40L3p40.mag couldn't be read^M
No such file or directory^M
File sky130_fd_pr__rf_test_coil1.mag couldn't be read^M
No such file or directory^M
File sky130_fd_pr__rf_test_coil2.mag couldn't be read^M
No such file or directory^M
File sky130_fd_pr__rf_test_coil3.mag couldn't be read^M
No such file or directory^M
File sky130_fd_pr__cap_vpp_11p5x11p7_m1m2m3m4_shieldl1m5.mag couldn't be read^M
No such file or directory^M
File sky130_fd_pr__cap_vpp_11p5x11p7_m1m2_noshield.mag couldn't be read^M
No such file or directory^M
File sky130_fd_pr__cap_vpp_08p6x07p8_m1m2_lishield.mag couldn't be read^M
No such file or directory^M
File sky130_fd_pr__cap_vpp_04p4x04p6_m1m2_lishield.mag couldn't be read^M
No such file or directory^M
Can't write file named '(UNNAMED)'^M
Migrating LEF files to layout.^M
Warning:  No LEF files found in /project/fun/openlane/pdk_root/open_pdks/sky130/sky130A/libs.ref/sky130_fd_pr/lef^M

I did a quick check on a few of the files reported missing, and they do exist. I've attached the full log for completeness. Any help is much appreciated!

Best Regards,
Matthew

log.docker.txt

(Note: The reason I'm raising this as an issue instead of a private report and discussion is that it directly affects an issue raised by @mahmoodulhassan-lm with Fault. AUCOHL/Fault#13)

The constructed file list for sky130 is as follows:

/opt/pdks/sky130/sky130_fd_sc_hd/latest/models/*/*.v
/opt/pdks/sky130/sky130_fd_sc_hd/latest/cells/*/*.*.v
/opt/pdks/sky130/sky130_fd_sc_hd/latest/cells/*/*.v

• Now note that this required a separate tweak to sky130, namely, I had to symlink ./libraries/sky130_fd_sc_hd to ./sky130_fd_sc_hd. Otherwise it simply fails to find any files.

That said, the issue in question appears to be from the skywater PDK's libraries/sky130_fd_sc_hd/latest/cells/dlxbn/sky130_fd_sc_hd__dlxbn.behavioral.v file: it is not compatible with IcarusVerilog. From what I can gather, open_pdks merges anything ending with a .v in both the cells and models folders, when only a certain number of files should've been actually merged. I'm not 100% sure naturally, but that appears to be the case.

Answer appears to be: depends which kinda SPICE you ask.
In the cases it does get accepted, it's unclear just what is inferred. (Presumably an open?)

I'm seeing errors like the following but the install doesn't seem to be failing;

# Install OSU T18 ls digital standard cells.
set -f ; ../common/foundry_install.py -std_format -source  -target /ssd/gob/foss-eda-tools/skywater-pdk-libs-sky130_fd_bd_sram/third_party/open_pdks/sky130/sky130A \
        -techlef sky130_osu_sc_18T.tlef rename=sky130_osc_sc_18t_ls.tlef \
        -spice 18T_ls/cdl/*.spice compile-only exclude=*.*.spice \
        -lef 18T_ls/lef/*.lef \
        -lib 18T_ls/lib/*.lib \
        -gds 18T_ls/gds/*.gds compile-only \
                options=custom/scripts/gds_import_setup.tcl \
        -library digital sky130_osu_sc_18t_ls 2>&1 | tee -a sky130A_make.log
Traceback (most recent call last):
  File "../common/foundry_install.py", line 430, in <module>
    sourcedir = option[1]
IndexError: list index out of range

I'm just loading some examples from the standard cell libraries ( the hd variant ) and in those you find layer 83/44 which is some pure text layer. And then layer 236/0 which might be equivalent to 235/4 (which is not used in the std cell library AFAICT) ?

@RTimothyEdwards you said on slack;

The latest push of open_pdks (github.com/RTimothyEdwards/open_pdks) has individual python scripts to build libraries for each of the file formats. These are all self-contained. Namely, the ones you want are "create_lef_library.py", "create_spice_library.py", and "create_gds_library.py". Do not use "create_lib_library.py" (unfinished and probably not useful) or "create_verilog_library.py" (will not work with all the complicated sets of files you have, and the definitions and include statements)

But I can't find them in this repo?

Originated on the open_pdks slack channel:

Netgen correctly reduces 8 parallel PNPs to 1 when no setup tcl is specified. But when the sky130A_setup.tcl setup is included it doesn't reduce the PNPs, resulting in 8 individual devices plus many extra nodes.

I'm using the PNP gds included with the PDK. The extracted netlist ('drc_cell_lvs.spice') and reference netlist ('bandgap_core_bipolars.spice) are attached. The command I'm using is netgen -batch lvs drc_cell_lvs.spice bandgap_core_bipolars bandgap_core_bipolar.spice bandgap_core_bipolars sky130A/libs.tech/netgen/sky130A_setup.tcl

issue_source_files.zip

Running a design through QFlow fails during synthesis due to ABC stage due to the following assertion fail:

ABC: Scl_Libertyosys-abc: src/map/scl/sclLiberty.c:344: Scl_LibertyReadString: Assertion `Pair.End-Pair.Beg < ABC_MAX_LIB_STR_LEN' failed.

I worked around this by just increasing the ABC_MAX_LIB_STR_LEN in the ABC source files and recompiled Yosys but I suspect there's a more elegant way to get around this issue.

I find LVS issues with the attached source files which consist of two sky130_fd_pr__res_xhigh_po resistor networks. Manually inspecting the netlist I see no difference.

Netgen agrees the topology is the same but differs on the property values:

Netlists match uniquely.
Circuits match correctly.
There were property errors.
sky130_fd_pr__res_xhigh_po_1p00_12p4_0[1]/sky130_fd_pr__res_xhigh_po0 vs. sky130_fd_pr__res_xhigh_poRptat3:
w circuit1: 1 circuit2: 7 (delta=150%, cutoff=1%)
sky130_fd_pr__res_xhigh_po_1p00_12p4_0[1]/sky130_fd_pr__res_xhigh_po0 vs. sky130_fd_pr__res_xhigh_poRptat3:
w circuit1: 7 circuit2: 1 (delta=150%, cutoff=1%)
sky130_fd_pr__res_xhigh_po_1p00_12p4_0[9]/sky130_fd_pr__res_xhigh_po0 vs. sky130_fd_pr__res_xhigh_poRctat6:
w circuit1: 1 circuit2: 7 (delta=150%, cutoff=1%)
sky130_fd_pr__res_xhigh_po_1p00_12p4_0[9]/sky130_fd_pr__res_xhigh_po0 vs. sky130_fd_pr__res_xhigh_poRctat6:
w circuit1: 7 circuit2: 3 (delta=80%, cutoff=1%)
sky130_fd_pr__res_xhigh_po_1p00_12p4_0[9]/sky130_fd_pr__res_xhigh_po0 vs. sky130_fd_pr__res_xhigh_poRctat6:
w circuit1: 3 circuit2: 1 (delta=100%, cutoff=1%)

issue_source_files.zip

$ ./configure --with-sky130-source=$HOME/github/google/skywater-pdk/
configure: Found technology directories: sky130
configure: Checking whether source path is specified for 'sky130'
configure: Checking specified path for 'sky130' at /home/tim/github/google/skywater-pdk
checking for /home/tim/github/google/skywater-pdk... yes
configure: 'sky130' source path found at /home/tim/github/google/skywater-pdk
configure: Checking whether local path is specified for 'sky130'
configure: error: Option --with-sky130-local-path=<path> not specified!

c2662b9

There is a README and a README.md file the top level directory. I expected that README is older documentation that should be named something else?

The following descriptions are wrong;

 sky130_fd_pr_rf/		RF primitive devices w/fixed layout 
 sky130_fd_pr_rf2/		Additional RF primitive devices w/fixed layout 

It should be something like the following;

 sky130_fd_pr_rf/		Older library of RF primitive devices w/fixed layout for compatibility (don't use in new designs).
 sky130_fd_pr_rf2/		Current library of RF primitive devices w/fixed layout (use in new designs).

open_pdks/sky130/openlane/sky130_fd_sc_hd/config.tcl contains :

set ::env(LIB_MAX) "$::env(PDK_ROOT)/TECHNAME/libs.ref/sky130_fd_sc_hd/lib/sky130_fd_sc_hd__ff_n40C_1v95.lib"
set ::env(LIB_MIN) "$::env(PDK_ROOT)/TECHNAME/libs.ref/sky130_fd_sc_hd/lib/sky130_fd_sc_hd__ss_100C_1v60.lib"

But that's not good. LIB_MAX is used for maximum delay computations ( for setup time analysis ) and so this should be the slower possible corner ( SS at high temp with low voltage )
And similarely, LIB_MIN is used for minimum delay computations ( for hold time analysis ) and so this should be the fastest possible corner ( FF at low temps with high voltage )

To allow defining the the area type in the magfile even if there are no transistors.

A few gate-level models have Verilog-illegal wire-name-declarations, generally named wire 1;.

(Apologies if these are in the skywater-pdk source material, but I couldn't find them in there.)

From sky130A/libs.ref/sky130_fd_sc_hd/verilog/sky130_fd_sc_hd.v (notable line commented):

// Import user defined primitives.
`celldefine
module sky130_fd_sc_hd__dlxbn (
    Q     ,
    Q_N   ,
    D     ,
    GATE_N,
    VPWR  ,
    VGND  ,
    VPB   ,
    VNB
);

    // Module ports
    output Q     ;
    output Q_N   ;
    input  D     ;
    input  GATE_N;
    input  VPWR  ;
    input  VGND  ;
    input  VPB   ;
    input  VNB   ;

    // Local signals
    wire GATE          ;
    wire buf_Q         ;
    wire GATE_N_delayed;
    wire D_delayed     ;
    reg  notifier      ;
    wire awake         ;
    // wire 1             ; FIXME! This is NOT a comment in the real version 

    //                                    Name     Output  Other arguments
    not                                   not0    (GATE  , GATE_N_delayed                       );
    sky130_fd_sc_hd__udp_dlatch$P_pp$PG$N dlatch0 (buf_Q , D_delayed, GATE, notifier, VPWR, VGND);
    assign awake = ( VPWR === 1 );
    buf                                   buf0    (Q     , buf_Q                                );
    not                                   not1    (Q_N   , buf_Q                                );

endmodule
`endcelldefine

Can haz pls?

I got Xyce working with the sky130 libraries and had to make these changes to sky130_fd_pr:

Change end of line comment form $ to ;

perl -p -i -e "s/\\$/;/" */*.spice
perl -p -i -e "s/\\$/;/" */*/*.spice
perl -p -i -e "s/\\$/;/" */*/*/*.spice

Comment out extraneous dev/gauss params

perl -p -i -e "s/dev\/gauss/; dev\/gauss/" */*.spice

Xyce-only change in how scale works (incompatible with ngspice)

perl -p -i -e "s/option/options parser/" models/all.spice

Extraneous malformed include statement is removed

perl -p -i -e "s/include.*//" cells/nfet_05v0_nvt/sky130_fd_pr__nfet_05v0_nvt.pm3.spice

Match .endl to .lib

The last fix involved changing the .endl cards to .endl to match the .lib . I don't know how to do that with a regex so here's a patch.

sky130.lib.patch.txt

VT is reserved parameter in Xyce

perl -p -i -e "s/vt/local_vt/g" cells/res_iso_pw/sky130_fd_pr__res_iso_pw.model.spice

Hi,

I have tried to follow the instructions for generated a sky130 pdk.
I've checkouted skywater-pdk (commit 4e5e318e0cc578090e1ae7d6f2cb1ec99f363120)
and run the make timing command

Then, in open_pdks/sky130 (commit 282d954), I have run the "make" command - I have EF_STYLE=0 in the Makefile)
magic version is 8.3.33

The  make command ends with the following message: 
# Add correct bounding boxes on Magic layouts
../common/insert_property.py -std_format  `pwd`/sky130A sky130_fd_io sky130_fd_io_top_gpio_ovtv2 \
	"FIXED_BBOX 0 407 28000 40000"
Error:  No layout file in either mag/ or maglef/
(/home/roba/perso/github/open_pdks/sky130/sky130A/libs.ref/sky130_fd_io/mag[lef]/sky130_fd_io_top_gpio_ovtv2.mag)
../common/insert_property.py -std_format  `pwd`/sky130A sky130_fd_io sky130_fd_io_top_xres4v2 \
	"FIXED_BBOX 0 407 15000 40000"
Error:  No layout file in either mag/ or maglef/
(/home/roba/perso/github/open_pdks/sky130/sky130A/libs.ref/sky130_fd_io/mag[lef]/sky130_fd_io_top_xres4v2.mag)
make[1]: Leaving directory '/home/roba/perso/github/open_pdks/sky130'
echo "Ended sky130A PDK staging on "`date` >> sky130A_install.log

(note that the error message is not present in the log file)

When going through the log, the first errir I noticed is :

Writing 'sky130_fd_pr_rf_xcmvpp2_nwell'
Writing 'balun'
Writing '(UNNAMED)'
Must specify name for cell (UNNAMED).
Done.
Error message output from magic:
Can't write file named '(UNNAMED)'
No LEF file install;  need to generate LEF.
Removing existing library /home/roba/perso/github/open_pdks/sky130/sky130A/libs.ref/sky130_fd_pr_base/lef/sky130_fd_pr_base.lef
Searching for supported devices in PDK script /home/roba/perso/github/open_pdks/sky130/sky130A/libs.tech/magic/sky130A.tcl.
PDK library is sky130
Getting GDS file list from /home/roba/perso/github/open_pdks/sky130/sky130A/libs.ref/sky130_fd_pr_rf/gds.
Creating magic generation script to generate magic database files.
No source for abstract views:  Abstract views not made.
Running magic to create magic database files.

Do you have some commit numbers for open_pdks, skywater-pdk and magic that are verified to work together for you so I could try again on my side ?

With google/skywater-pdk#204 being merged, I believe you need to remove the following script https://github.com/RTimothyEdwards/open_pdks/blob/master/sky130/custom/scripts/fix_missing_diodes_lef.py now?

It would be good if when you generated files like the sky130A.tech file, you included the current git revision. The best way to do this is with git-describe --long.

Because so many of the relevant file formats use absolute paths, we should come up with a canonical distribution / install path so that these files are more portable across installations.

Proposals:

• First, define a standard lookup path of /usr/share/pdks/$tech plus /usr/local/share/pdks/$tech plus $XDG_DATA_HOME/pdks/$tech plus $HOME/.local/share/pdks/$tech.
• Tools should define their own per-tech configuration file layout below this directory, with liberty/LEF+DEF/GDS on a standard path
• ... This doesn't actually solve the absolute path problem as stated, but it does open up the path to doing so.

Do not action this issue until after November 30 :)

While the configure script seems to complete, there is a readlink: missing operand error in the output.

tim@desktop:~/github/RTimothyEdwards/open_pdks$ ./configure --with-sky130-source=$HOME/github/google/skywater-pdk/ --with-sky130-local-path=/opt/skywater-pdk
configure: Found technology directories: sky130
configure: Checking whether source path is specified for 'sky130'
configure: Checking specified path for 'sky130' at /home/tim/github/google/skywater-pdk
checking for /home/tim/github/google/skywater-pdk... yes
configure: 'sky130' source path found at /home/tim/github/google/skywater-pdk
configure: Checking whether local path is specified for 'sky130'
configure: Checking whether distribution path is specified for 'sky130'
configure: Option --with-sky130-dist-path=<path> not specified.  Local install only."
readlink: missing operand
Try 'readlink --help' for more information.

In the netgen setup file:

sky130/netgen/sky130_setup.tcl

There are typos for the PNP device names:

lappend devices sky130_fd_pr__php_05v5_W0p68L0p68
lappend devices sky130_fd_pr__php_05v5_W3p40L3p40

Should be (php -> pnp):

lappend devices sky130_fd_pr__pnp_05v5_W0p68L0p68
lappend devices sky130_fd_pr__pnp_05v5_W3p40L3p40

After the maglef generation step, the open_pdks/common/foundry_install.py file has

        # Now list all the .mag files generated, and for each, read the
        # corresponding file from the mag/ directory, pull the GDS file
        # properties, and add those properties to the maglef view. Also
        # read the CDL (or SPICE) netlist, read the ports, and rewrite
        # the port order in the mag and maglef file accordingly.

It looks like the port order is being rewritten here.
From clkbuf_16 mag file before annotation.

flabel pwell 29 -17 63 17 0 FreeSans 200 0 0 0 VNB
port 3 nsew ground input
flabel pwell s 46 0 46 0 0 FreeSans 200 0 0 0 VNB
port 3 nsew default input
flabel nbase 29 527 63 561 0 FreeSans 200 0 0 0 VPB
port 4 nsew power input
flabel nbase s 46 544 46 544 0 FreeSans 200 0 0 0 VPB
port 4 nsew default input
flabel metal1 29 -17 63 17 0 FreeSans 200 0 0 0 VGND
port 2 nsew ground input abutment
flabel metal1 29 527 63 561 0 FreeSans 200 0 0 0 VPWR
port 5 nsew power input abutment

Notice how some flabel lines have 13 fields while others (the ones with 's' as the third field) have 14.
After annotation:

flabel pwell 29 -17 63 17 0 FreeSans 200 0 0 0 VNB
port 3 nsew ground input
flabel pwell s 46 0 46 0 0 FreeSans 200 0 0 0 VNB
port 3 nsew default input
flabel nbase 29 527 63 561 0 FreeSans 200 0 0 0 VPB
port 3 nsew power input
flabel nbase s 46 544 46 544 0 FreeSans 200 0 0 0 VPB
port 4 nsew default input
flabel metal1 29 -17 63 17 0 FreeSans 200 0 0 0 VGND
port 4 nsew ground input abutment
flabel metal1 29 527 63 561 0 FreeSans 200 0 0 0 VPWR
port 4 nsew power input abutment

Looks the port number after the longer lines (the ones with the 's') are propagated to the following shorted lines regardless of the signal name.
From open_pdks/common/foundry_install.py
flabrex = re.compile('flabel[ \t]+[^ \t]+[ \t]+[^ \t]+[ \t]+[^ \t]+[ \t]+[^ \t]+[ \t]+[^ \t]+[ \t]+[^ \t]+[ \t]+[^ \t]+[ \t]+[^ \t]+[ \t]+[^ \t]+[ \t]+[^ \t]+[ \t]+[^ \t]+[ \t]+[^ \t]+[ \t]+([^ \t]+)')
flabrex only matches the longer lines.
So for the unmatched shorter flabel lines, the last port number for a long line is used. If there hasn't been a long line encountered, the port number stays the same.
The following works for long and short lines.
flabrex = re.compile('flabel[ \t]+.*[ \t]+([^ \t]+)[ \t]*')

Drawing 45 degree paths on metal 1 and 2 results in DRC errors but the DRC error states that 45 degree angles are allowed. Therefore I believe the DRC tool is not correctly interpreting the angles.

45degree_test.gds.zip

Simple test case attached.

Hello everyone,

I am newbie to Qflow and open source VLSI flow. I have a question about Qflow and this pdk.

Is there any way to see and use these libraries in qflow_gui "Preparation" part like OSU_035 ?

I believe there is a small typo in the pull request merged on 1/26. I'm looking at line 160 in sky130/Makefile.in:
66e53e5#diff-110f5cdd52092b0ae64eac540e7fdc13a19e212e688d29e5420692503fd21b14R160

When adding the "libraries/" directory on the end of the --enable-sky130-pdk configuration value, it assigns the variable SKYWATER_PATH to itself using recursive assignment. This causes the error "Recursive variable 'SKYWATER_PATH' references itself".

One fix is to change the = to :=

But I think the intended behavior might be to append a copy of the path to itself with the /libraries added. In that case, I think we should change = to += on line 160, and = to := on line 158.

I'd appreciate it if someone more familiar with Makefiles and/or understanding of the intended behavior takes a look at this.

sky130_fd_io__top_power_hvc_wpadv2 is having the wrong LEF class(BLOCK instead of PAD).

So, I am unable to generate padframe,

See https://github.com/RTimothyEdwards/open_pdks/blame/master/README.md#L25-L28

just git cloned and did ./configure --enable-sky130-pdkc
just as the manual says, maybe there is something else that should be added to the documentation? Or is this a bug?

Currently,

# Digital cells (ignore decap, fill, and tap cells)
# Make a separate list for each supported library
#---------------------------------------------------------------
# e.g., ignore class "-circuit2 sky130_fc_sc_hd_decap_3"
#---------------------------------------------------------------

foreach cell $cells1 {
    if {[regexp {sky130_fd_sc_\w\w__decap_[[:digit:]]+} $cell match]} {
        ignore class "-circuit1 $cell"
    }
    if {[regexp {sky130_fd_sc_\w\w__fill_[[:digit:]]+} $cell match]} {
        ignore class "-circuit1 $cell"
    }
}
foreach cell $cells2 {
    if {[regexp {sky130_fd_sc_\w\w__decap_[[:digit:]]+} $cell match]} {
        ignore class "-circuit2 $cell"
    }
    if {[regexp {sky130_fd_sc_\w\w__fill_[[:digit:]]+} $cell match]} {
        ignore class "-circuit2 $cell"
    }
}

Maybe, sky130_fd_sc_[^_]*__fill_ would work better.

There are not any quick start instructions on how to get started with the open_pdks. It needs something like;

git clone https://github.com/RTimothyEdwards/open_pdks.git
cd open_pdks
./configure --with-sky130-source=<directory where you cloned https://github.com/google/skywater-pdk repository>
cd sky130
make tools-a

Unclear to me if the above is correct.

It is unclear to me if anything needs to be done in the google/skywater-pdk repository before using ./configure -- aka do you have to run make timing or?

The make process (ubuntu machine) is stuck in the following step:

Install base device models from vendor files

(NOTE: .mod and .pm3 files should not be in /cells/?)

set -f ; ../common/foundry_install.py -std_format -source /home/santos/Documents/PDKs/skywater-pdk/libraries -target pwd/sky130A
-ngspice sky130_fd_pr_base/v%v/models/* filter=custom/scripts/fixspice.py
-ngspice sky130_fd_pr_base/v%v/cells/.mod filter=custom/scripts/fixspice.py
-ngspice sky130_fd_pr_base/v%v/cells/.pm3 filter=custom/scripts/fixspice.py
|& tee -a sky130A_install.log

property statements should reference circuit being processed

Example:

    if {[lsearch $cells2 $dev] >= 0} {
        permute "-circuit2 $dev" 1 2
        property "-circuit1 $dev" series enable
        property "-circuit1 $dev" series {w critical}
        property "-circuit1 $dev" series {l add}

-circuit1 should be -circuit2 here. There are also cases when -circuit2 should be -circuit1.

PDK_ROOT/sky130A/libs.tech/openlane does not have the corresponding sub folder with the openlane setup files of sky130_fd_sc_lp

Get this error as result from 'make' command in installation step 2. Generate files in staging location:

Install device subcircuits from vendor files

set -f ; ../common/foundry_install.py -std_format -source -target pwd/sky130A
-ngspice sky130_fd_pr/latest/models/*
filter=custom/scripts/rename_models.py
|& tee -a sky130A_install.log
Traceback (most recent call last):
File "../common/foundry_install.py", line 428, in
sourcedir = option[1]
IndexError: list index out of range

Install base device library from vendor files

set -f ; ../common/foundry_install.py -std_format -source -target pwd/sky130A
-gds %l/latest/cells//.gds compile-only
-cdl %l/latest/cells//.cdl compile-only
-lef %l/latest/cells//.magic.lef compile-only
-spice %l/latest/cells//.spice filter=custom/scripts/rename_cells.py
-library primitive sky130_fd_pr |& tee -a sky130A_install.log
Traceback (most recent call last):
File "../common/foundry_install.py", line 428, in
sourcedir = option[1]
IndexError: list index out of range

Custom: Add "short" resistor model and subcircuit to the r+c models file

cat ./custom/models/short.spice >>
pwd/sky130A/libs.tech/ngspice/sky130_fd_pr__model__r+c.model.spice
bash: /edatools/DKs/open_pdks/sky130/sky130A/libs.tech/ngspice/sky130_fd_pr__model__r+c.model.spice: No such file or directory
make[1]: *** [vendor-a] Error 1
make[1]: Leaving directory `/edatools/DKs/open_pdks/sky130'
make: *** [all-a] Error 2<

Previously, the configuration script gave one warning about sources:

[root@hera open_pdks]# ./configure --with-sky130-source=/edatools/DKs/skywater-pdk/libraries --with-sky130-local-path=/edatools/DKs
configure: WARNING: unrecognized options: --with-sky130-source
configure: Found technology directories: sky130
configure: Found tools: klayout magic netgen openlane qflow
checking for magic... /usr/local/bin/magic
configure: Tools enabled for PDK setup installation: klayout magic netgen openlane qflow
checking for a Python interpreter with version >= 3.4... python3
checking for python3... /bin/python3
checking for python3 version... 3.6
checking for python3 platform... linux
checking for python3 script directory... ${prefix}/lib/python3.6/site-packages
checking for python3 extension module directory... ${exec_prefix}/lib64/python3.6/site-packages
checking python3 module: distutils... yes
configure: creating ./config.status
config.status: creating ../sky130/Makefile
config.status: creating ../Makefile
configure: WARNING: unrecognized options: --with-sky130-source
Build configured successfully

Looking at the LEF for the fake diode, it's missing the SITE attribute in its LEF.
(I only checked sky130_ef_sc_hd__fakediode_2 but it's possible other ones in other cell libraries have the same issue)