https://open-source-silicon.dev logo
Join Slack
Powered by
Hi all. Is anybody working on supporting `ihp-sg13...
# ieee-sscs-dc-24
a
Hi all. Is anybody working on supporting 
ihp-sg13g2
pdk? I'm adding rules to the 
grulesobj
matrix and almost all of the metalization rules are ready but there's some stuff that I'm not understanding. • Is the 
grulesobj
matrix symmetric? 
grule[L1][L2] == grule[L2][L1]
? • Where's the complete list of grules? I thougth it was only 
min_width (width)
, 
min_enclosure
, 
min_separation
. but there's also 
overhang
and I needed to extend the list with 
min_area
I'm sorry for having interrupted my participation in this chipathon. I think if I can help in give basic support for this pdk and validate it with some examples it could be a useful contribution to this project.
m
@Ali Hammoud Can you take this question?
@aquiles viza We aren't supporting ihp for now.
a
Hello @aquiles viza you only need to implement the grules in one direction (it is a symmetric matrix). When you pass it to the pdk the pdk class will look for both and return the one that it finds (when you use pdk.get_grule) There are some simplifications/shortcuts that we make with the rules. There is no min area rule for example but you can add it if you want. Actually as you may have noticed the grules return a dictionary so you can put anything you want in the grules. For the sky130 and gf180 implementations we have, it is not possible to do validation for min area (you may also find that is a rare violation to get especially when doing analog design, and might only happen in edge cases) You can add min area if you want by just adding it as a key in the grules dictionary you define and you will be able to directly access it through pdk.get_grule
a
I'm not sure what happens when there's differences between 
grule(l1, l2)
and 
grule(l2, l1).
Should both always be equal or equivalent? I've created a function to update the object, avoiding this kind of problems
a
If you define only one in your dictionary they will always be the same
a
I've manage to add a bunch of rules into the dictionary and it seems to work. The main issue is that the use of 
pdk.activate()
makes that the boxes drawn on klayout have size 0, 0. If all the instances of 
pdk.activate()
are removed from 
glayout
, it works. The use of 
@cell
doesn't seems to fix anything. Maybe your team had this issue before
a
Have you defined gds_write_settings precision?
a
Yep, in the same way that sky130 and gf180 does. The difference is that I was defining 
sg13g2_mapped_pdk.gds_write_settings.unit = 5 * 10**-9
. Removing it makes the code work, Thanks @Ali Hammoud
🙂 1
a
Nice, Good to hear! please consider making a GitHub PR with the new pdk and we could add it to the package
a
Integrating this pdk requires some changes to the code, taking into account the 
min_area
rule, for instance. That's the difficult part but the idea is to share it eventually
a
Ok no problem, Also you may want to try adding min_area to your dictionary. I think you will be able to use it without changing the code
a
I was struggling with offgrid errors. After commenting the line 
sg13g2_mapped_pdk.gds_write_settings.precision = 0.005e-6
the offgrid problem disapear. Is there any problem in not having that parameter set?
Also, I'm working on the PR but ihp requires to modify 
via_stack
to take the 
min_area
in consideration. The minimum area is not equal to minimum width^2, so there's always drc errors
m
@Ali Hammoud Thanks for the explanations.
Hello @aquiles viza you only need to implement the grules in one direction (it is a symmetric matrix).
Just to clarify, for
Copy code
grulesobj["A"]["B"] = {"min_enclosure": 0.06}
does this rule check both the enclosure of 
A
by 
B
and 
B
by 
A
? I suppose you could use a symmetric matrix if one layer only exists inside the other. One exception is 
poly
and 
diff
where the gate extension beyond 
poly
may be different from the minimum diff overlap of 
poly
(source/drain width). Maybe this is handled with derived layers. Could you clarify? While the documentation mentions 
min_enclousure
, `min_width`/`width` and 
min_separation
as valid parameters,
Copy code
The keys are one of the three rule names "min_enclosure", "min_separation", or "min_width" / "width" (depending on the context).
looking at the `sky130` grules, I see there’s an 
overhang
parameter for 
active_diff
and 
poly
and an 
extension
parameter for 
poly
- 
poly
. Are these special use parameters? Also, could you explain the difference between the 
min_width
and 
width
parameters? For 
sky130
, 
via2
has a 
min_width
= 
0.21
but a 
width
of 
0.15
.
a
@aquiles viza the via stack does not meet min area requirement for any pdks we have, but we don’t usually run drc on just the via stack as it is almost always placed into a larger design. When you place a via between metal layers it will almost always meet drc. That is why we assumed this is a rare violation. However it is good that we are adding support for more pdks so that we can more rigorously verify this tool. Could you check if a primitive such as the nfet is producing min area or any other drc errors in ihp? If so we should update the rules and the generators to explicitly check for this.
@Mitch Bailey documentation is outdated, we actually have several more rules than this. For the implementation on how we use the rules take a look under primitives/fet.py specifically look at the “multiplier” function. Ideally we hide most of the complexity in that function and the other primitive generators so that end users don’t have to deal in that much detail with the feol rules We made a lot of simplifications when writing glayout to make the coding a little easier. (You may notice that the primitives are already fairly messy) For cases where a rule can have several meanings we take the max value There are probably many cases we did not consider. We have only verified the generators in sky130 and gf180, so it is likely that adding another pdk may expose more cases that we did not consider. This is good because we can more rigorously verify the generators.
👍 1
a
This is a link with the fork with a lot of additions and some changes on 
primitives.via_gen.py
• Fork: https://github.com/akiles-esta-usado/OpenFASOC • Tests: https://github.com/akiles-esta-usado/OpenFASOC/tree/main/openfasoc/generators/glayout/tests/ihp-sg13g2 The basic tests works without drc errors (via, via_stack, via_array, tapring) but fets are not working as expected. On nmos, a layer of 
pwell
and 
n+s/d
is added always, despite the parameters. I don't know if that happens on sky130 or gf180 (I apologize for my ignorance) but it's avoiding lvs recognition.
27 Views
Open in Slack
PreviousNext
Powered by