@Mitch Bailey: If it is installed correctly then yes, files common to more than one variant are symbolic links back to variant "A".

4141980 gf180mcuA
  218944 gf180mcuB
  258400 gf180mcuC
  141864 gf180mcuD
12727296 sky130A
  337312 sky130B

(above:

du -s

run on my installed

/usr/share/pdk

. The base 'A' variant sizes are much larger because I install all essential libraries plus a number of optional ones.)

@Mitch Bailey:

volare

is meant to have self-contained PDKs, though; with volare, you can install and uninstall individual PDKs, so they probably have to be installed the way they are, or if you remove the base variant, then all of the symbolic links would break.

I see. So I can just delete the variants I don’t need.

Or update specific variants, or revert specific variants to a past state to recover the environment in which a chip was generated.

#407 Missing openlane environment variable in gf180mcu. Issue created by d-m-bailey Running

make user_proj_example

with open_pdks version

dd7771c384ed36b91a25e9f8b314355fc26561be

fails with

[INFO]: Running Synthesis (log: ../home/user/gf180mcu/mpw-1/caravel_user_project/openlane/user_proj_example/runs/23_10_15_17_33/logs/synthesis/1-synthesis.log)...
[ERROR]: during executing yosys script /openlane/scripts/yosys/synth.tcl
[ERROR]: Log: ../home/user/gf180mcu/mpw-1/caravel_user_project/openlane/user_proj_example/runs/23_10_15_17_33/logs/synthesis/1-synthesis.log
[ERROR]: Last 10 lines:
ERROR: TCL interpreter returned an error: can't read "::env(SYNTH_CAP_LOAD)": no such variable                                                                            
child process exited abnormally

Running

find $PDK_ROOT/$PDK/libs.tech -type f -exec grep SYNTH_CAP_LOAD {} /dev/null \;

returns nothing, but when set to the sky130 pdk, you can see that each standard cell library has a definition.

$PDK_ROOT/sky130A/libs.tech/openlane/sky130_fd_sc_hd/config.tcl:set ::env(SYNTH_CAP_LOAD) "33.442" ; # femtofarad __inv_16 pin A cap (<https://github.com/google/skywater-pdk-libs-sky130_fd_sc_hd/blob/main/cells/inv/sky130_fd_sc_hd__inv_16__tt_025C_1v80.lib.json>)
$PDK_ROOT/sky130A/libs.tech/openlane/sky130_fd_sc_ms/config.tcl:set ::env(SYNTH_CAP_LOAD) "22.66" ; # femtofarad _inv_8 pin A cap
$PDK_ROOT/sky130A/libs.tech/openlane/sky130_fd_sc_hvl/config.tcl:set ::env(SYNTH_CAP_LOAD) "70.77" ; # femtofarad __inv_16 pin A cap (<https://github.com/google/skywater-pdk-libs-sky130_fd_sc_hvl/blob/main/cells/inv/sky130_fd_sc_hvl__inv_16__tt_025C_3v30.lib.json>)
$PDK_ROOT/sky130A/libs.tech/openlane/sky130_osu_sc_t18/config.tcl:set ::env(SYNTH_CAP_LOAD) "37.357" ; # femtofarad INVX8 pin A cap
$PDK_ROOT/sky130A/libs.tech/openlane/sky130_fd_sc_hs/config.tcl:set ::env(SYNTH_CAP_LOAD) "43.39" ; # femtofarad _inv_16 pin A cap (<https://github.com/google/skywater-pdk-libs-sky130_fd_sc_hs/blob/main/cells/inv/sky130_fd_sc_hs__inv_16__tt_025C_1v68.lib.json>)
$PDK_ROOT/sky130A/libs.tech/openlane/sky130_fd_sc_ls/config.tcl:set ::env(SYNTH_CAP_LOAD) "46.690" ; # femtofarad _inv_16 pin A cap (<https://github.com/google/skywater-pdk-libs-sky130_fd_sc_ls/blob/main/cells/inv/sky130_fd_sc_ls__inv_16__tt_100C_1v80.lib.json>)
$PDK_ROOT/sky130A/libs.tech/openlane/sky130_fd_sc_hdll/config.tcl:set ::env(SYNTH_CAP_LOAD) "33.468" ; # femtofarad _inv_16 pin A cap (<https://github.com/google/skywater-pdk-libs-sky130_fd_sc_hdll/blob/main/cells/inv/sky130_fd_sc_hdll__inv_16__tt_025C_1v80.lib.json>)

RTimothyEdwards/open_pdks

1 new commit pushed to

<https://github.com/RTimothyEdwards/open_pdks/tree/master|master>

by RTimothyEdwards

<https://github.com/RTimothyEdwards/open_pdks/commit/6bf520c6cb96a40bb3d5285dcab17663f690f91a|6bf520c6>

- Corrected the GF tech file, which attempted to assign labels on RTimothyEdwards/open_pdks

#408 Remove base instances from custom cells Pull request opened by mole99 During the refactoring of the standard cell libraries, all base instances were inlined into the respective modules. Unfortunately, this was not done for the custom cells in

open_pdks

. If

sky130_fd_sc_hd.v

is read into Icarus Verilog without specifying a top module, it throws errors due to missing modules. This PR removes the base instances from

sky130_ef_sc_hd__fakediode_2

and

sky130_ef_sc_hd__fill_12

and unifies some of the formatting. The standard cell libraries were built and read with iverilog, which is now happy:

iverilog primitives.v sky130_fd_sc_hd.v

RTimothyEdwards/open_pdks GitHub Actions: Run (all) GitHub Actions: Run (sky130_fd_sc_hvl) GitHub Actions: Run (sky130_fd_sc_ls) GitHub Actions: Run (sky130_fd_sc_ms) GitHub Actions: Run (sky130_fd_sc_hs) GitHub Actions: Run (sky130_fd_sc_hdll) GitHub Actions: Run (sky130_fd_sc_hd) ✅ No checks have passed 0/7 successful checks

2 new commits pushed to

<https://github.com/RTimothyEdwards/open_pdks/tree/master|master>

by RTimothyEdwards

<https://github.com/RTimothyEdwards/open_pdks/commit/310ef1c39e30bfb2dca7770197ed34284a39cf37|310ef1c3>

- Remove base instances from custom cells

<https://github.com/RTimothyEdwards/open_pdks/commit/4f5c1995d629acef895c81bf07c2ba13213d195c|4f5c1995>

- Updated version to go along with the merge of pull request #408 RTimothyEdwards/open_pdks

#409 Symbol calculated resistance on fixed width high poly resistors does not appear correct Issue created by mhommelga There is a large discrepancy between the calculated resistance (from L & W parameters) on the high poly resistor symbols depending on whether the fixed width or custom width symbol is used. Attached picture shows the issue and also shows that xhigh poly resistors match perfectly. Example: Custom Width: Symbol: res_high_po W=1.41um L=10um Rcalc=2251 Ohm FIxed Width: Symbol res_high_po_1p41 (W=1.41um) L=10um Rcalc=1632Ohm In some cases the values differ by 5x and the custom width resistors appear to be more realistic values and better match the simulation model. However for LVS to work on the layout I have, I need to use the fixed width resistors in the schematics. RTimothyEdwards/open_pdks

1 new commit pushed to

<https://github.com/RTimothyEdwards/open_pdks/tree/master|master>

by RTimothyEdwards

<https://github.com/RTimothyEdwards/open_pdks/commit/559a117b163cef2f920f33f30f6f690aa0b47e4c|559a117b>

- Multiple changes to multiple PDKs: RTimothyEdwards/open_pdks

2 new commits pushed to

<https://github.com/RTimothyEdwards/open_pdks/tree/master|master>

by RTimothyEdwards

<https://github.com/RTimothyEdwards/open_pdks/commit/326f64003eaef0c26956508edd22c4f2003e4338|326f6400>

- Added initial support in magic for 16V devices (LDNMOS and LDPMOS).

<https://github.com/RTimothyEdwards/open_pdks/commit/392b92efc2a0be83c1381e739abaf48cc6135c7e|392b92ef>

- Completed the first full implementation of the LDNMOS and LDPMOS RTimothyEdwards/open_pdks

#410 DRC errors using MAGLEF/LEF view with sky130A Issue created by kareefardi def-drc.tar.gz Attached are two test cases. Both runs DRC on a DEF file. One sets MAGTYPE to MAGLEF (

run.tcl

). The other reads the PDK cells LEF files

run2.tcl

). Both produce DRC errors

All nwells must contain metal-connected N+ taps (nwell.4)

. I am trying to understand if this is expected in abstract views in the standards cells. RTimothyEdwards/open_pdks

2 new commits pushed to

<https://github.com/RTimothyEdwards/open_pdks/tree/master|master>

by RTimothyEdwards

<https://github.com/RTimothyEdwards/open_pdks/commit/6e1fcaf572a5ebc99c0683a69c1b7e0691918999|6e1fcaf5>

- Updated references (again) to capture the new commit hash of the

<https://github.com/RTimothyEdwards/open_pdks/commit/69af8420a9013059f10ecdf96e5fbc886fbdacba|69af8420>

- Corrected the resistor device names in the IRSIM parameter RTimothyEdwards/open_pdks

1 new commit pushed to

<https://github.com/RTimothyEdwards/open_pdks/tree/master|master>

by RTimothyEdwards

<https://github.com/RTimothyEdwards/open_pdks/commit/e0f692f46654d6c7c99fc70a0c94a080dab53571|e0f692f4>

- (Re-)corrected the MiM capacitor model names extracted by magic, RTimothyEdwards/open_pdks

#411 Query regarding Qflow Issue created by Lokesh-Sharma26 Hi, Can we install skywater130nm pdk in the open source tool Qflow? RTimothyEdwards/open_pdks

#412 magicrc log change suggestion Issue created by d-m-bailey The

$PDK.magicrc

files currently have

puts stdout "Sourcing design .magicrc for technology sky130A ..."

Which is not actually true. Would something like this be possible?

puts stdout "Sourcing design [info script] for technology sky130A ..."

RTimothyEdwards/open_pdks

#413 Weird cell LEF definitions for sky130 Issue created by donn 1. All EF cells • Lack a

SITE

definition • Are improperly(?) marked

CLASS BLOCK

instead of

CLASS CORE

as normal standard cells are

MACRO sky130_ef_sc_hd__decap_12
  CLASS BLOCK ;
  FOREIGN sky130_ef_sc_hd__decap_12 ;
  ORIGIN 0.000 0.000 ;
  SIZE 5.520 BY 2.720 ;
  PIN VGND
  …

2. All double-height cells in at least

fd_sc_hd

• Have their sites declared as

unithd

instead of the correct

unithddbl

, e.g.

MACRO sky130_fd_sc_hd__lpflow_lsbuf_lh_hl_isowell_tap_1
  CLASS CORE WELLTAP ;
  FOREIGN sky130_fd_sc_hd__lpflow_lsbuf_lh_hl_isowell_tap_1 ;
  ORIGIN 0.000 0.000 ;
  SIZE 6.440 BY 5.440 ;
  SYMMETRY X Y R90 ;
  SITE unithd ;
  …

When manually instantiated, those double-height cells will fail with the message "taller than any row" in OpenROAD for example, unless OpenROAD is instructed to explicitly construct double-height rows to accommodate them.

RTimothyEdwards/open_pdks

#414 Fix `LEF` views of EF cells Pull request opened by donn • Correctly set the

CLASS

property to

CLASS CORE SPACER

instead of

CLASS BLOCK

• Set missing

SYMMETRY

property to

X Y R90

to match

fd_sc_hd

fill cells • Set missing

SITE

property to

unithd

• Created missing

sky130_ef_sc_hd__fill_4.v

• Remove `fakediode`: Maintaining it is no longer worth it * * * Resolves (1) of #413 RTimothyEdwards/open_pdks GitHub Actions: Run (all) GitHub Actions: Run (sky130_fd_sc_hvl) GitHub Actions: Run (sky130_fd_sc_ls) GitHub Actions: Run (sky130_fd_sc_ms) GitHub Actions: Run (sky130_fd_sc_hs) GitHub Actions: Run (sky130_fd_sc_hdll) GitHub Actions: Run (sky130_fd_sc_hd) ✅ No checks have passed 0/7 successful checks

2 new commits pushed to

<https://github.com/RTimothyEdwards/open_pdks/tree/master|master>

by RTimothyEdwards

<https://github.com/RTimothyEdwards/open_pdks/commit/20a97d854debbd43e11046d31e75caedbf1eb706|20a97d85>

- Fix

LEF

views of EF cells

<https://github.com/RTimothyEdwards/open_pdks/commit/2a38e86d557197f06d3eefca0fbc161db9e09924|2a38e86d>

- Updated version to go along with the merge of pull request #414 RTimothyEdwards/open_pdks

#415 Getting Errors in building Issue created by rudro101 I have followed the steps to build open_pdks. ./configure is also done successfully. But in make step, getting this error. I have tried multiple times but each time same error. I am using Ubuntu22.04 distro in WSL2. RTimothyEdwards/open_pdks

@Abhinav Uppal has left the channel

#416 Make repo downloads more persistent Pull request opened by cbalint13 Hi folks, This makes the downloads more persistent. In CI environments a single error bails out the whole setup. Sample failure recovered by the retry pass:

Downloading 7-track standard cell library from ../sources/gf180mcu_fd_sc_mcu7t5v0
Cloning <https://github.com/efabless/globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0> to ../sources/gf180mcu_fd_sc_mcu7t5v0
Cloning into '../sources/gf180mcu_fd_sc_mcu7t5v0'...
fatal: unable to access '<https://github.com/efabless/globalfoundries-pdk-libs-gf180mcu_fd_sc_mcu7t5v0/>':
Failed to connect to <http://github.com|github.com> port 443 after 135991 ms: Couldn't connect to server
Cloning into '../sources/gf180mcu_fd_sc_mcu7t5v0'...
remote: Enumerating objects: 10041, done.
remote: Counting objects: 100% (10041/10041), done.
remote: Compressing objects: 100% (4729/4729), done.
remote: Total 10041 (delta 6196), reused 8959 (delta 5311), pack-reused 0
Receiving objects: 100% (10041/10041), 120.23 MiB | 23.38 MiB/s, done.

RTimothyEdwards/open_pdks

2 new commits pushed to

<https://github.com/RTimothyEdwards/open_pdks/tree/master|master>

by RTimothyEdwards

<https://github.com/RTimothyEdwards/open_pdks/commit/39f9029011b7d3e5edfd5409f1c5733ece4fc5b9|39f90290>

- Make repo downloads more persistent

<https://github.com/RTimothyEdwards/open_pdks/commit/32e8f233b8b920bddfd4c4850c62371283c3e570|32e8f233>

- Updated version to go along with pull request #416 from Cristian RTimothyEdwards/open_pdks

@Harald Pretl has left the channel

volare

is a bit unstable right now. Is not allowing see available commits nor downloading a specific one.

$ volare ls-remote --pdk gf180mcu
Encountered an error when polling version list: 403 Client Error: rate limit exceeded for url: <https://api.github.com/repos/efabless/volare/releases?per_page=100>

$ volare enable --pdk gf180mcu dd7771c384ed36b91a25e9f8b314355fc26561be
Version dd7771c384ed36b91a25e9f8b314355fc26561be not found locally, attempting to download…
Failed to obtain dd7771c384ed36b91a25e9f8b314355fc26561be remotely: <Response [403]>.

It's just me or this affects everyone?

#417 Add `MAX_CAPACITANCE_CONSTRAINT` to OpenLane configs Pull request opened by donn RTimothyEdwards/open_pdks GitHub Actions: Run (all) GitHub Actions: Run (sky130_fd_sc_hvl) GitHub Actions: Run (sky130_fd_sc_ls) GitHub Actions: Run (sky130_fd_sc_ms) GitHub Actions: Run (sky130_fd_sc_hs) GitHub Actions: Run (sky130_fd_sc_hdll) GitHub Actions: Run (sky130_fd_sc_hd) ✅ No checks have passed 0/7 successful checks

2 new commits pushed to

<https://github.com/RTimothyEdwards/open_pdks/tree/master|master>

by RTimothyEdwards

<https://github.com/RTimothyEdwards/open_pdks/commit/01f0e51ec98d3bbb3a0565fd9d73bc414d2fcda2|01f0e51e>

- Add

MAX_CAPACITANCE_CONSTRAINT

to OpenLane configs

<https://github.com/RTimothyEdwards/open_pdks/commit/8c68aca265b7de9491c8369d9d96d5106220ded1|8c68aca2>

- Updated version to go along with the merge of pull request #417 RTimothyEdwards/open_pdks

#419 sky130 chip_io: mag file does not correspond to gds Issue created by d-m-bailey In

3da499bf3cb58e44aa0f2360a672c7187994a08b

, a metal3 resistor was added to separate

VSSIO

and

VDDIO

nets in

sky130_ef_io__vccd_lvc_clamped3_pad.mag

and

sky130_ef_io__vssd_lvc_clamped3_pad.mag

. I can't find the corresponding change in the gds data at

$PDK_ROOT/$PDK/libs.ref/sky130_fd_io/gds/sky130_ef_io.gds

for volare pdk versions after that. The tapeout data for

2311

does not contain metal3 resistors in those cells. This causes an mismatch in all LVS checks that includes

chip_io

and its variants. RTimothyEdwards/open_pdks

#418 add KLAYOUT_DRC_OPTIONS for integration with OpenLane Pull request opened by kareefardi This is a Draft PR. Don't merge yet. Edit: This is good for review and merge now. RTimothyEdwards/open_pdks GitHub Actions: Run (all) GitHub Actions: Run (sky130_fd_sc_hvl) GitHub Actions: Run (sky130_fd_sc_ls) GitHub Actions: Run (sky130_fd_sc_ms) GitHub Actions: Run (sky130_fd_sc_hs) GitHub Actions: Run (sky130_fd_sc_hdll) GitHub Actions: Run (sky130_fd_sc_hd) ✅ No checks have passed 0/7 successful checks

@Sashank Krishna S has left the channel