share release infra for open_pdks/sky130A

[proppy]

Looking at https://github.com/efabless/volare/blob/a73950436109a27048c68bcd4252214694547b95/volare/common.py#L110 it seems that the PDK tarballs are fetched from https://github.com/efabless/volare/releases, but I couldn't find the corresponding workflow that publish thoose tarball in https://github.com/efabless/volare/blob/main/.github/workflows/ci.yml

As @donn pointed out in #3 (comment), there are conda packages for open_pdks.sky130a with nightly builds: https://anaconda.org/LiteX-Hub/open_pdks.sky130a/files, and the resulting tarball can be consumed without conda using something like:

curl -L --silent https://anaconda.org/LiteX-Hub/open_pdks.sky130a/1.0.304_0_g1491dd7/download/noarch/open_pdks.sky130a-1.0.304_0_g1491dd7-20220330_123635.tar.bz2 | tar --strip-components=2 -C $PDK_ROOT -xvjf  - share/pdk/

Curious if you think there would be advantes to share a common release infra for open_pdks/sky130A?

[donn]

I actually think that's a good idea. Can you link me to your CI infrastructure?

[proppy]

Workflow:
https://github.com/hdl/conda-eda/blob/master/.github/workflows/build-packages.yml#L768

Conda recipe:
https://github.com/hdl/conda-eda/blob/master/misc/open_pdks/meta.yaml

Conda build script:
https://github.com/hdl/conda-eda/blob/master/misc/open_pdks/build.sh

[donn]

Some notes:

• I need to be able to index the package by commit hash. We don't do versions over in OpenLane land.
• The default build needs to include SRAM.
• We need capacity to add other "flavors" down the line, such a full PDK build.

[proppy]

I need to be able to index the package by commit hash. We don't do versions over in OpenLane land.

The short version of the commit hash is in the archive name, see https://anaconda.org/LiteX-Hub/open_pdks.sky130a/files
noarch/open_pdks.sky130a-1.0.303_0_g05af1d0-20220330_123635.tar.bz2

The default build needs to include SRAM.

Filed hdl/conda-eda#203

We need capacity to add other "flavors" down the line, such a full PDK build.

We should be able to add subpackages of open_pdks.sky130a, ex: open_pdks.sky130a.full and build them from the same recipe: https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html#outputs-section

[donn]

The short version of the commit hash is in the archive name, see anaconda.org/LiteX-Hub/open_pdks.sky130a/files
noarch/open_pdks.sky130a-1.0.303_0_g05af1d0-20220330_123635.tar.bz2

I suppose. Is it always 8 characters? git rev-parse --short=8 HEAD, I mean?

This will add a tiny bit of complexity where I'll have to download the list of versions and search for the short rev-parse in the hash, but it's doable.

The rest seems reasonable. Thanks for filing 2 and yes, we can deal with 3 when we get to it.

[proppy]

I suppose. Is it always 8 characters? git rev-parse --short=8 HEAD, I mean?

According to https://git-scm.com/docs/git-describe it's not always a fixed size:

The hash suffix is "-g" + an unambigous abbreviation for the tip commit of parent (which was 2414721b194453f058079d897d13c4e377f92dc6). The length of the abbreviation scales as the repository grows, using the approximate number of objects in the repository and a bit of math around the birthday paradox, and defaults to a minimum of 7. The "g" prefix stands for "git" and is used to allow describing the version of a software depending on the SCM the software is managed with.

This will add a tiny bit of complexity where I'll have to download the list of versions and search for the short rev-parse in the hash, but it's doable.

One low-code alternative could be to maintain an environment.yaml next to https://github.com/The-OpenROAD-Project/OpenLane/blob/master/dependencies/tool_metadata.yml, and ensure that the github hash prefix matches using the CI?

[proppy]

@donn how big is the open_pdks sram install? @mithro was concerned about the package size.

[donn]

xz compressed, the whole thing's about 177 megabytes.

[donn]

Given that we now also build the full PDK and allow users to download the PDK on a library-by-library basis, I don't think this is going to be entirely feasible anymore. :(

That being said, GitHub is not scaling very well for release storage. We may investigate other storage media in the future.