https://open-source-silicon.dev logo
Join Slack
Powered by
<@U020J2W6Q84> I'd like to add `gdstk` in the nix ...
# openlane-2
t
@donn I'd like to add 
gdstk
in the nix environment of OL2 ( so that 
nix-shell
has it ). But I know nothing about nix and just adding 
gdstk
randomly didn't work 😅
d
uuuuuuuuuuuuhh let me check
t
I was hopeing just adding it to requirements.txt would work but no 😢
d
no python packages have to specifically be packaged for nix which is as fun as it sounds
we (read: @Leo Moser) packaged gdsfactory for nix but not gdstk
t
Ok, maybe I can use it as a example to see how to do it 😅
d
ill just package it real quick
one sec
t
Ah thanks.
For a bit of context, the klayout lvs for TT top level isn't working, so I ended up writing a GDS -> Spice extractor using gdstk and then using netgen with the preliminary setup file from Tim and that's how we're doing the LVS for TT on iHP ATM.
l
I did package gdsfactory, but not with all dependencies because it's a pita, just enough to run the sky130 Pcells in KLayout 😄
@tnt I thought gdstk would be for your ROM compiler, maybe as a plugin for OL2 😉
t
@Leo Moser Hehe, yeah, when the time comes, that would be useful there too 😁
d
which version of openlane 2 are you based on right now? @tnt
t
2.0.4 😅
d
oh lordy
t
Yeah, updating to the latest is the first thing after 2411 tapeout ...
d
that version still used Nixpkgs 23.11 too dear god
hang on im making a patch
🙌 1
gdstk.patch.diff
gdstk.patch.diff
Make sure to 
git add -N
the newly created file -- Nix flakes ignore untracked files
t
Copy code
error:
       … while calling the 'derivationStrict' builtin

         at //builtin/derivation.nix:9:12: (source not available)

       … while evaluating derivation 'openlane-shell'
         whose name attribute is located at /nix/store/w6qscasrm9g56nwgz9xv6nwcpcm2fjz8-source/pkgs/stdenv/generic/make-derivation.nix:348:7

       … while evaluating attribute 'PYTHONPATH' of derivation 'openlane-shell'

         at /nix/store/6wy4dfpw5833v5zbavdbq9g8wqhb45kz-source/nix/create-shell.nix:63:5:

           62|
           63|     PYTHONPATH = "${openlane-env-sitepackages}"; # Allows venvs to work properly
             |     ^
           64|     shellHook = ''

       (stack trace truncated; use '--show-trace' to show the full trace)

       error: undefined variable 'gdstk'

       at /nix/store/6wy4dfpw5833v5zbavdbq9g8wqhb45kz-source/default.nix:120:7:

          119|       klayout-pymod
          120|       gdstk
             |       ^
          121|
d
uuuuuuh
t
Ah, adding it at the beginning too helped.
d
the patch should have added that, weird
but yeah
oh i `pbcopy`'d the patch before i fixed that
oops
t
Copy code
ERROR Missing dependencies:
        oldest-supported-numpy; platform_system != "Darwin"
error: builder for '/nix/store/m7w48x5bqsrbhl3xlcp5apvxlzxinbrq-python3.11-gdstk-0.9.52.drv' failed with exit code 1;
       last 10 log lines:
       > updateAutotoolsGnuConfigScriptsPhase
       > configuring
       > no configure script, doing nothing
       > building
       > Executing pypaBuildPhase
       > Creating a wheel...
       > * Getting build dependencies for wheel...
       >
       > ERROR Missing dependencies:
       >       oldest-supported-numpy; platform_system != "Darwin"
       For full logs, run 'nix-store -l /nix/store/m7w48x5bqsrbhl3xlcp5apvxlzxinbrq-python3.11-gdstk-0.9.52.drv'.
error: 1 dependencies of derivation '/nix/store/2848li4fqgdi69s9ad0acy4rr82xqf2x-python3-3.11.6-env.drv' failed to build
d
let me just sed that line out
what i get for testing on a mac
@tnt Add this below the other sed in `gdstk.nix`: 
sed -i.bak '/oldest-supported-numpy/d' pyproject.toml
t
Yup, that worked, thanks !
That probably saved me like a day of messing with nix so thanks a lot !
d
Cheers!
t
👋 @donn
d
hi
t
Remember this ? I'm trying to apply the patch on latest openlane but it seems nix has changed stuff 😅
d
I'm in a meeting rn, let's chat on Discord after
👌 1
t
Sure, no hurry !
l
Hi Sylvain, is this still for top-level LVS? Extraction with magic seems to work fine now if you would like to give this a try. I created two new branches on GitHub with your patches (the ones that still seemed necessary) and my changes: - IHP PDK: https://github.com/efabless/IHP-Open-PDK/commits/ol2/ - OpenLane2: https://github.com/efabless/openlane2/commits/ihp/ I still need to push a few changes, but locally I can get simple counter to run through the Classic OL2 flow. There is one DRC rule that magic wasn't happy with, and Tim and I have been trying to figure out if the issue is on our end or KLayouts (or the docs): https://github.com/IHP-GmbH/IHP-Open-PDK/issues/343 Also, XOR fails because KLayout uses the wrong layer:datatype pair for `DIEAREA`: https://github.com/IHP-GmbH/IHP-Open-PDK/issues/345 Let me know if you want to give this a try, and I'll prioritise cleaning up the remaining patches.
t
@Leo Moser ATM I'm just trying to move over what I have now to newer OL2. Then I'll try to see if I can remove some of the "hacks" 😅
l
I see! My branch is currently based on the OL 
dev
branch. (but I didn't need gdstk)
t
Oh very cool that you can get a simple project all through the default flow now 🙂
Means we'll probably be able to use OL2 for the next ihp shuttle ( it's in September ... )
l
Yeah, thanks to all the groundwork already done it was quite easy 😉 But I still need to test larger designs to see if any hurdles come up. That's for sure! 🙌 Hm, I see that there are a few earlier shuttles: https://ihp-open-ip.readthedocs.io/en/latest/ Or should digital projects only target the CMOS variant?
t
Yeah we're going on the CMOS one because we have to host 512 projects on that one so it'll be like 30 sq mm ... so we'd take up the whole space of earlier shuttles.
Did you fixup the CTS stuff ? I know I hadn't configure anything yet in the PDK openlane tech dir for it ...
l
That makes sense! Yeah, that's one of the changes I still need to push. I'll do that in the next days 👍 Btw. since ihp does not have dedicated clock buffers, I just used normal ones.
t
Oh yeah, I hadn't even noticed that.
I didn't check their buffer but maybe the default ihp logic is just more balanced by default .... the sky130 pmos are really duds 😅
l
Yeah, it's what the OpenROAD-flow-scripts does, so I figured it would be okay 😄 Maybe they are using strain on their pmos? Or it's just a slightly different process 🤷‍♂️
d
Or maybe they just didn’t bother making unbalanced buffers in the IHP SCL
l
Now I have to look, I think 
cell_rise
and 
cell_fall
would be the correct entries in the LIB? Here's the first row of the 
cell_rise
table for `sg13g2_buf_1`:
Copy code
"0.0498944, 0.115637, 0.159174, 0.231014, 0.351089, 0.551484, 0.884922"
And here the first row of `cell_fall`:
Copy code
"0.0530651, 0.108407, 0.143335, 0.200824, 0.296681, 0.456355, 0.722692"
Not bad, but also not exactly balanced 😁
d
Watch the sky130hd balanced cells somehow be even worse than that
😆 2
lol
l
Funny story, I had a meeting today with Steffen Reith, who as it happens actually drew the buffers for ihp-sg13g2. To my question as to why there are no clock buffers, he answered: "Möchtest du vielleicht einen zeichnen?" Meaning, if I would like to draw one 😆 So they just haven't been created yet, and there was no particular reason other than they were aiming for a minimal set of standard cells.
🤣 1
6 Views
Open in Slack
PreviousNext
Powered by