misc/open_pdks.sky130a build should include sram

[proppy]

• flag: ./configure --enable-sram-sky130
• upstream: https://github.com/efabless/sky130_sram_macros
• branch: main

[mithro]

These files are fairly large, maybe they should it be in a separate package or "extras" (https://peps.python.org/pep-0508/#extras) in some way?

[proppy]

maybe simply a subpackage of open_pdks.sky130a? open_pdks.sky130a.sram.

[mithro]

open_pdks.sky130a.sram could work...

[donn]

Altogether, xz compressed, it's 177 MB. That's nothing.

[proppy]

we could do both!

We could have individual subpackages for each of the invidual cells library, as well as higher level variants that capture popular combinations (high density, low voltage, high voltage, everything)

[tdene]

I came to this thread because I wanted the end-user to have the other standard cell libraries exposed.

So what I was thinking was, whether it'd be possible to modularly install different libraries.

With an usual build environment, you'd do by that cloning the different libraries first, as desired, then running open_pdk's make. Clearly that's not an option in this case, with the intent being that everything is pre-packaged and doesn't require user build time.

What's the worst that can happen if we commit the blasphemous solution of:

• Have a baseline conda package that has cloned the sky130 models and open_pdks, has run the open_pdks Makefile, and has packaged all that up nicely.
• Have additional conda packages, one for each library. They have cloned their respective library, run the open_pdks Makefile, but only packaged up the libs.ref/sky130_fd_* folder that corresponds to the library in question.
• End-user can install these additional conda packages as desired.
• Each one of these packages is copied over on top of the pre-existing open_pdks install.

This assumes things like that the user does not change install path (or if they do, they change it for all packages). It can lead to over-written files. That sounds bad.

Is it that bad though? Can it be an acceptable solution?

EDIT: Changed wording slightly to reduce confusion

[proppy]

yep, that's what I was leaning toward too with #203 (comment)

the current set we have with open_pdks.sky130a is:

• sky130_fd_sc_hd
• sky130_fd_sc_hvl
• sky130_fd_io
• sky130_fd_pr

are there other popular combinations that can be used as an alternative base? or are the following always installed individually?

• sky130_fd_pr_reram
• sky130_fd_sc_hdll
• sky130_fd_sc_hs
• sky130_fd_sc_lp
• sky130_fd_sc_ls
• sky130_fd_sc_ms

[proppy]

This assumes things like that the user does not change install path (or if they do, they change it for all packages). It can lead to over-written files. That sounds bad.

We could make the individual library packages conflict with the one that define sets to avoid this; so that user are forced to either pick an existing set + individual libraries that are not part of this sets or list all libraries explicitly.

[tdene]

Personally, I would see the following packages being useful.

• Base: sky130_fd_pr, sky130_fd_sc_hvl, sky130_fd_io, sky130_fd_sc_hd.
• All cells with 3.33um height: sky130_fd_sc_hs, sky130_fd_sc_ms, sky130_fd_sc_ls, sky130_fd_sc_lp
• Stand-alone sky130_fd_pr_reram
• Stand-alone sky130_fd_sc_hdll
• Stand-alone sky130_fd_sc_hs
• Stand-alone sky130_fd_sc_ms
• Stand-alone sky130_fd_sc_ls
• Stand-alone sky130_fd_sc_lp
• Full: everything together in one package.

[proppy]

And I'd assume you'd also recommend for sram and fonts to be separate package?

[tdene]

For sram, yeah, I believe that would be best (?)

fonts I am not familiar with.