gdsfactory / skywater130

skywater 130nm pdk
https://gdsfactory.github.io/skywater130/
MIT License
26 stars 11 forks source link

:construction: Automatic compilation of raw efabless PDKs into a gdsfactory-compatible PDK #92

Closed daquintero closed 6 months ago

daquintero commented 6 months ago

Related to https://github.com/gdsfactory/gplugins/issues/390, and inspired by the ehtos of making this gdsfactory library mapped to the updated raw efabless pdks https://github.com/efabless/skywater-pdk-libs-sky130_fd_pr, https://github.com/gdsfactory/skywater130/pull/67

I think the ideal interim solution in relation to having an updated gdsfacotry-efabless PDK eg https://github.com/efabless/skywater-pdk-libs-sky130_fd_pr would be to have the fixed as a submodule and gdsfactory recursing though them to get the cell declarations. Ultimately, this is an application repository that builds onto the existing pdks. As such, and given that most users are using volare etc to install the PDKs, I'm not sure this is the most straightforward strategy on including the gdscells onto the package. WHat we can do, rather than pip installing possibly, would be to include the source PDK repositories and simply add the gdswrapper functionality on top of that. However, this comes at a packaging complexity problem.

Thought to open the draft PR since it's starting to work per the basic example I'm working on, and in case there's any feedback before I start consolidating the files and structure.

Will rebase when I cleanup the commits and code.

daquintero commented 6 months ago

@joamatab ready for review I think, however I am not sure how you want to manage the component setting updates for those tests to pass with the new structure. Lmk to update accordingly. I suspect in the pyproject.toml the submodule dependencies will have to be added to we can upload this to pypi, but since you're the package manager keen to see what you think before implementing that?

daquintero commented 6 months ago

Sounds good, then I'll keep on this direction! I'll update the package build to make sure it can still upload to pypi and get the tests to pass and then I believe it'll be ready to merge - and add other functionality on another PR.

Also, if you want someone else to more constantly manage this repo happy to be a repo collaborator and on top of maintaining it - maybe let's see how much more functionality I'll add here too.

daquintero commented 6 months ago

Hi @joamatab , good news :tada:, I think it is ready for at least a minor release. I have fixed the build issues, and pip installed the built-package locally successfully, tests are passing on the actions, and seems to be working pretty slickly locally.

I don't think there's another sky130nm package that can get installed so easily and completely by pip, so quite exciting to make this more accessible especially using gdsfactory. Further upgrades to come :rocket: with more spice integration.

EDIT: ok possible issues when uploading this to pypi since it contains large binaries. This will be an issue with this approach, really. Hmm, thinking of alternative solutions. I guess we could ask them to increase the size limit. The build size is big but relatively small compared to the AI ones (and this one has a lot of value in accessible microelectronics)

-rw------- 1 daquintero daquintero 196M may 23 13:36 sky130-0.11.1-py3-none-any.whl
-rw-rw-r-- 1 daquintero daquintero 180M may 23 13:35 sky130-0.11.1.tar.gz

https://github.com/pypa/packaging-problems/issues/86

The alternative is having this package upload to conda instead which have 1Gb limits? I'm inclining towards this option. It's a bit like jaxlib host their own binaries etc.

joamatab commented 6 months ago

amazing job! thank you Dario, lets merge and try to release to see if this works