https://open-source-silicon.dev
Join Slack
Working a bit more on my combined OpenLANE+sky130 PDK docker image. Right now digging through the Ma...
# sky130
o
Working a bit more on my combined OpenLANE+sky130 PDK docker image. Right now digging through the Makefile rules for generating the PDK. A question. What is sky130_fd_pr? It is used when installing skywater-library, but not when using all-skywater-libraries. Is this an oversight or am I missing something?
l
It is a library with all primitive devices, such as the transistors, capacitors, resistors and diodes.
o
Thanks. What parts of the flow would benefit from those? Is it like spice simulations?
Also, just saw from git blame that @User added it to the skywater-library target in September. Donn, should it be in all-skywater-libraries as well?
Sorry @User Didn't realize until just now that your real name is Mohamed. Totally missed that :)
d
Yeah's it's to make ngspice files- 100% should've been in the full pdk as well
Thank you for catching that
l
For analog flow, they are really essential, as everything we do is spice simulation. For the digital design flow, they are needed only for standard cell characterization. They are not needed for synthesis.
d
I'm also working on including the skywater pdk in the base openlane image btw, in case you want to save some time
o
Thanks @User Got it. Trying to take the opportunity to learn about the individual part as I come across them
d
making decent progress, although now I'll have to rebuild the image to include the _pr library
lol
o
@User Yes. No need to duplicate the effort. I did a openlane+pdk image that I've been using for github actions for the past year but that one didn't build the pdk. I did that as a manual step before
d
Yeah, the way I'm doing it open_pdks is a first-class OpenLane tool installed like any other, and part of the CI.
o
Right. And the skywater-pdk?
d
It's cloned and used by open_pdks.
o
hmm... that's not what it looks like in the openlane Makefile
d
here's a WIP dockerfile
Untitled.dockerfile
That Makefile isn't necessarily anything to use as a model. I'd wager it causes more problems than it solves.
o
Awesome. Hapyp to do a test and help out where I can
Happy to hear because that was pretty much the same conclusion I came to 🙂
Any recommended SKY130_COMMIT if I want to test the image?
Ah, I see there are a lot of args now
d
Copy code
--build-arg OPEN_PDKS_REPO=<https://github.com/rtimothyedwards/open_pdks> --build-arg OPEN_PDKS_COMMIT=476f7428f7f686de51a5164c702629a9b9f2da46 --build-arg SKY130_REPO=<https://github.com/google/skywater-pdk> --build-arg SKY130_COMMIT=c094b6e83a4f9298e47f696ec5a7fd53535ec5eb --build-arg MAGIC_REPO=<https://github.com/rtimothyedwards/magic> --build-arg MAGIC_COMMIT=0bb6ac1fa98b5371c73156b6e876925397fb7cbc
yeah, lots. open_pdks has a lot of dependencies
o
Probably copied your file at a bad point. Last line seems to be broken
d
yes, sorry, just get rid of it
o
Alright. Will report back. Please keep me in the loop on this. Been hoping to get this done for some time now
d
👍
o
ah.. pull access denied for openlane-build-base, repository does not exist or may require 'docker login': denied: requested access to the resource is denied
Private image?
d
Err to build it go to 
<openlane_root>/docker
and 
make build_base_image
o
Any particular version of the openlane repo I should use?
d
latest
o
make: *** No rule to make target 'build_base_image'.  Stop.
Is it just 
base_image
d
no, it's build_base_image. are you using efabless/openlane or The-OpenROAD-Project/OpenLane?
o
efabless.
d
The efabless one is a time-frozen fork for the MPW projects- all the fun happens in 
The-OpenROAD-Project/OpenLane
o
Got it. I knew there was supposed to be a switch-over but the mpw4 tag was only in the efabless version when I checked last time so I thought the switch was postponed
Base image building now, FYI
d
I wouldn't hold my breath, this is easily a one-hour build
o
Done 🙂
d
wow
oh to be precise i meant the open_pdks build
o
Building the openlane+pdk imnage now
ah ok
Biggest problem right now is that I'll probably run out of diskspace before it's done
d
yep.
we need to invest in optimizing the PDK build process, it's far too time and space inefficient as-is
l
http://opencircuitdesign.com/open_pdks/install.html Open PDKs is large because it install all digital libraries. Some modules can be ignored. If you plan to make your project smaller, you should comment some libraries.
d
yeah, but considering I'm including it in the OpenLane Docker container, it really should have all libraries
o
I never fully understood what is actually building. I subconciously assumed it was just a bunch of data files describing various aspects of the components
d
make timing
extracts the timing data into liberty files. open_pdks does a lot: from stitching the cell lef structures and models (which are disjoint) into larger files, patching erroneous cell structures, providing configuration files for common EDA tools, etc.
o
From what I have seen there's a lot of overhead because they are mostly ascii files. I guess quite a bit of space could be saved if we could store them compressed and have the tools uncompress them on the fly, but that perhaps require a bit much cooperation from the tools
d
yeah
it's really just the sheer volume of files that's the problem
l
A Lite version would be great. We from the analog camp also could benefit form a Docker image. I use Open PDKs only, but some designers could use a Docker image with all tools and the PDK ready to go. I'm a Docker noob, so I can't help.
What is the actual size of the LEF cells and timing files?
d
Altogether? Just south of a gigabyte post-processing.
Copy code
donn@Celebi:/usr/local/pdk/sky130A% du -hd0
881M	.
l
It is still relatively small. The full PDK is about 10 GB, I think.
d
This is the "default" OpenLane PDK build, which doesn't have everything. If you want, you can grab builds using https://github.com/Cloud-V/sky130-builds
Please note that this is not an efabless project
(to be precise, this includes sky130_fd_sc_hd, sky130_fd_sc_hvl, sky130_fd_io and sky130_fd_pr.)
o
@User About openpdk build, is anyone ever using the files that go into the make timing thing, or is just the output used? If so, wouldn't it make sense to store the output as the actual source?
l
I'l try that. Thanks!
o
And those erronous cells, are they supposed to be fixed upstream somewhere? Just trying to understand the flow
l
The docker OpenLane image includes Magic, ngspice and Xschem, doesn't it?
d
I believe so yes
@User Yes. Ideally. skywater-pdk upstream is very idiosyncratic
We'd fork it and do some fixes but the Efabless chip designers are busy with MPW 4
o
Alright then. Finally managed to change the docker image storage location. Time for a new attempt
@User Ah, so open_pdk isn't any PDK data in itself but a tool to convert an existing PDK (like skywater's 130nm) to a conforming layout?
d
yup
o
Are there any other PDKs conforming to this standard?
Oh, it's finished now
Let's use this in the Edalize launcher and see if we can rebuild the subservient SoC
d
tell me if the liberty files built successfully, im having a couple issues getting them to
o
How would I know?
d
if you try to synthesize something and the liberty files are missing, that would be it :)
o
Ah 🙂
Is flow.tcl in path?
d
should be
o
Could be something else then
Started a shell in the docker image to dig a bit deeper. Do you know where flow.tcl is supposed to be?
d
/openlane
o
aha! There is not openlane dir in the image
d
oh this image has just the pdk,
for the full build, try the branch at https://github.com/donn/openlane/tree/pdk_build
o
Which docker file should I use?
d
cd docker && make openlane
o
I didn't set any env vars now. Was I supposed to do that first?
d
not really no
o
Good. Let's see how this goes then
It looks like it uses the base_image I built last time, but then there's also a run_base_image step. What does that do?
d
There are two base images: one for running and one for building.
o
I see
Getting an error now though
Copy code
python3 ./utils.py pull-if-doesnt-exist --repository efabless/openlane-tools --os centos-7 open_pdks
efabless/openlane-tools:open_pdks-476f7428f7f686de51a5164c702629a9b9f2da46-centos-7 not found, pulling...
Error response from daemon: manifest for efabless/openlane-tools:open_pdks-476f7428f7f686de51a5164c702629a9b9f2da46-centos-7 not found: manifest unknown: manifest unknown
d
make build-open_pdks
first
sorry, this is a WIP: the experience is not going to be smooth
o
Yeah, I get that. At the same time it seems like I should have all the parts I need already. My previous attempt used the efabless/openlane image and extended it by pulling in a pre-built PDK. Shouldn't I just be able to use efabless/openlane as my base image and then use the dokerfile that successfully build the PDK to extand taht?
Ah, I can't build the PDK using that image
Ok, now I'm confused. I ran 
make open_pdks
and got 
efabless/openlane-tools   open_pdks-476f7428f7f686de51a5164c702629a9b9f2da46-centos-7
and then I ran 
make openlane
and got 
efabless/openlane:current
but is there an easy way to combine them now?
I guess I just want to pull /pdk from the first image into the second
Ah! It's in /build/pdk
@User Is this what you're seeing with the missing liberty files as well? 
FileNotFoundError: [Errno 2] No such file or directory: '/build/pdk/sky130A/libs.ref/sky130_fd_sc_hd/lib/sky130_fd_sc_hd__tt_025C_1v80.lib'
And is there supposed to be a file called 
(UNNAMED).spice
in the spice dir
?
Ok, so I don't understand why it's happening but my guess right now is that this for loop https://github.com/google/skywater-pdk/blob/main/Makefile#L84 is empty
d
Sorry for the late reply- I fell asleep. I think I messed up a sed. Working on it
o
Sleeping is the best. I do that all the time
I suck at sed and regex. What is that command supposed to do? Add /latest/ to the end of the strings matching libraries in the Makefile?
Also, what kind of sorcery is in those things being run by 
make timing
that requires a full-on virtual conda environment?
I just removed the sed and it looks like it's building a lot of .lib files now FYI
Building the stuff done by make timing works fine without the conda environment after a couple of minor fixes. But it looks like we're building several versions of each library (e.g. v0.01, v0.02 and latest) Is that good for anything?
Aha, those are only built if the correspongind submodules are initialized
Ok, so I think we can replace 
make timing
with
Copy code
pip3 install --user -e scripts/python-skywater-pdk
python -m skywater_pdk.liberty libraries/sky130_fd_sc_hd/latest
python -m skywater_pdk.liberty libraries/sky130_fd_sc_hd/latest all
python -m skywater_pdk.liberty libraries/sky130_fd_sc_hd/latest all --ccsnoise
python -m skywater_pdk.liberty libraries/sky130_fd_sc_hdll/latest
python -m skywater_pdk.liberty libraries/sky130_fd_sc_hdll/latest all
python -m skywater_pdk.liberty libraries/sky130_fd_sc_hdll/latest all --ccsnoise
python -m skywater_pdk.liberty libraries/sky130_fd_sc_hs/latest
python -m skywater_pdk.liberty libraries/sky130_fd_sc_hs/latest all
python -m skywater_pdk.liberty libraries/sky130_fd_sc_hs/latest all --ccsnoise
python -m skywater_pdk.liberty libraries/sky130_fd_sc_hvl/latest
python -m skywater_pdk.liberty libraries/sky130_fd_sc_hvl/latest all
python -m skywater_pdk.liberty libraries/sky130_fd_sc_hvl/latest all --ccsnoise
python -m skywater_pdk.liberty libraries/sky130_fd_sc_ls/latest
python -m skywater_pdk.liberty libraries/sky130_fd_sc_ls/latest all
python -m skywater_pdk.liberty libraries/sky130_fd_sc_ls/latest all --ccsnoise
python -m skywater_pdk.liberty libraries/sky130_fd_sc_ms/latest all --leakage
python -m skywater_pdk.liberty libraries/sky130_fd_sc_ms/latest
python -m skywater_pdk.liberty libraries/sky130_fd_sc_ms/latest all
python -m skywater_pdk.liberty libraries/sky130_fd_sc_ms/latest all --ccsnoise
and get rid of all the conda stuff
d
Sorry, I missed these: yeah, but at the same time, I'd like to not mess with the PDK build process as much as I can
Can you help me convince Ansell that conda is a blight
o
He knows my feeling towards conda very well by now 🙂
I understand that you want to keep it as close to upstream as possible. Best thing, as you say, would be to get rid of conda there. But in the meantime I think it could be a very good alternative to cut down build times, complexity and image sizes
d
Conda is ultimately not very impactful here, it's like 5 minutes. It's the skywater_pdk.liberty that could use a faster rewrite, primarily
o
Ah yes. You got a point
Awesome! It works now. I can rebuild the subservient SoC through FuseSoC and Edalize with the new image!
🎉 1
2 Views
Open in Slack
PreviousNext
Powered by

What is Linen?

Linen is a search-engine friendly community platform. We offer integrations with existing Slack/Discord communities and make those conversations Google-searchable.

Powered by