wafer.space Community - project-template

heya, i noticed that magic and klayout have different DRC errors, and this is reproducible in the upstream template https://github.com/wafer-space/gf180mcu-project-template/actions/runs/22961298626/job/66652405640

3503
* DRC
Failed 𐄂
KLayout DRC errors: 0
Magic DRC errors: 126743
Check the report directories of KLayout.DRC and Magic.DRC.

is this an issue? do we trust klayout or magic?

chore: update to LibreLane dev (#55) · wafer-space/gf180mcu-projec...

Project template for wafer.space MPW runs using the gf180mcu PDK - chore: update to LibreLane dev (#55) · wafer-space/gf180mcu-project-template@1152862

monkey on keyboard

heya, i noticed that magic and klayout have different DRC errors, and this is reproducible in the upstream template https://github.com/wafer-space/gf180mcu-project-template/actions/runs/22961298626/job/66652405640

3503
* DRC
Failed 𐄂
KLayout DRC errors: 0
Magic DRC errors: 126743
Check the report directories of KLayout.DRC and Magic.DRC.

is this an issue? do we trust klayout or magic?

In my experience at "corporate semiconductor", different tools reporting differently can either be real runset issues, or just differences in how they report errors

Leo Moser (mole99) started a thread. 2026-03-16 8:05 a.m.

I'm seeing a lot of warnings like

Error while reading cell "METAL1_FILL" (byte position 144857526): Warning: cell "Metal1_fill_cell" placed on top of itself.  Ignoring the extra one.

that I don't see in the github actions #55

is there no layerprops/layermap in klayout format (usually lyp, I think)?

5:41 a.m.

ah i got it

the seal ring is interesting, in that the vias are not drawn to be hermetic... I guess GF is swapping that part of the database after they tape-in

nmz787

is there no layerprops/layermap in klayout format (usually lyp, I think)?

If you open the layout through librelane (make librelane-klayout), they layer map will already be loaded.

nmz787

the seal ring is interesting, in that the vias are not drawn to be hermetic... I guess GF is swapping that part of the database after they tape-in

No, that's just the structure of the seal ring as specified by the PDK documentation.

I am fairly positive the fab is swapping out the via layers under the sealring ID

7:05 a.m.

they are not hermetic as-is

7:05 a.m.

(Intel does this)

7:06 a.m.

in that case, depending on the node, they do or do not show the customer the real design... due to process churn and violating DRC

7:07 a.m.

unless they have some other very different way of ensuring hermeticity

7:09 a.m.

has anyone delayered one of these?

I can guarantee you, they don't - I saw the final mask data. Why would they specify the exact placement of vias in the guard ring documentation and have custom DRC rules for them when they're going to replace it anyway?

Intel does the same

7:14 a.m.

but cross-section and teardown show 100% continuous perimeter rings on every level, metal and via

Leo Moser (mole99)

I can guarantee you, they don't - I saw the final mask data. Why would they specify the exact placement of vias in the guard ring documentation and have custom DRC rules for them when they're going to replace it anyway?

you saw post-OPC database?

yes

including synthesized layers, etc?

The final mask data for the complete reticle, yes.

huh, I feel like I'm missing something now

7:24 a.m.

GPT says there's orders of magnitude less risk of "moisture-induced Vt drift" for such a large planar process, hmm

Leo Moser (mole99)

I can guarantee you, they don't - I saw the final mask data. Why would they specify the exact placement of vias in the guard ring documentation and have custom DRC rules for them when they're going to replace it anyway?

I suppose you have a point about PDK rules for vias... Intel doesn't have those, they supply X/Y/corner cells for customer to place

nmz787

unless they have some other very different way of ensuring hermeticity

Don't know where you get the hermeticity requirement for the vias in the seal ring from ? AFAIK main purpose of seal ring is to protect the design from cracks and stress caused by wafer sawing. This can be done with normal sized vias in a ring. (edited)

Chips4Makers aka Staf Verhaegen

Don't know where you get the hermeticity requirement for the vias in the seal ring from ? AFAIK main purpose of seal ring is to protect the design from cracks and stress caused by wafer sawing. This can be done with normal sized vias in a ring. (edited)

I am on team that owns seal ring collateral design. Crack arrest is only once function for us

@nmz787 - This process is from the late 1990's / early 2000's -- I'm pretty things have changed a lot since then.

Project Template Update! Version 1.4.0 has been tagged, which includes an upgrade to LibreLane 3.0

Read the blog post to find out more about LibreLane 3.0: https://www.librelane.org/blog/2026-03-25-website_release_3-0

Project Template 1.4.0

1

1

Leo Moser (mole99) pinned a message to this channel. 2026-03-26 2:09 p.m.

kinda related, started to work on a dashboard to make my life easier in the next time I tape something out. right now it's mostly just spewing out the saved metrics, but I'd like it to be my centralized "build manager". Kick off new builds, "fork" existing builds with new settings, investigate performance and metrics, help manage ECO steps, comparisons, etc

1

as an aside, it's kinda tragic how OpenRoad is close to being a nice set of modular tools... but then they baked it all into one binary and duct tape it all together with tcl and odb monstrosity

BreakingTaps

as an aside, it's kinda tragic how OpenRoad is close to being a nice set of modular tools... but then they baked it all into one binary and duct tape it all together with tcl and odb monstrosity

The problem they had was spending so much time serialising and deserialising information between commands.

10:28 p.m.

Because it was a "nice set of modular tools" and it was completely unusable.

aha, interesting! i should do some more reading on the history/context so i'm less judgmental

10:31 p.m.

You can battle serdes cost with mmap'ing zero-copy serialization though

10:32 p.m.

(which isn't far from what odb is doing anyway from my understanding)

BreakingTaps

aha, interesting! i should do some more reading on the history/context so i'm less judgmental

For the sake of a thought experiment, how would you imagine openroad should be split up?

well in a nice world where everything behaves, all the modules (rsz, gpl, ifp, tap, etc) would be individual tools that LibreLane can bolt together at will. and if you wanted to say develop a new rsz you just drop in your own version that speaks to the shared odb backend. But right now if you wanted to do that you have to rebuild the whole thing. and the whole orchestration between librelane and openroad seems very fraught. python -> env variables -> tcl -> openroad binary and back That said, I recognize it's not a nice world and most things don't behave as we'd like

so just grumping

BreakingTaps

well in a nice world where everything behaves, all the modules (rsz, gpl, ifp, tap, etc) would be individual tools that LibreLane can bolt together at will. and if you wanted to say develop a new rsz you just drop in your own version that speaks to the shared odb backend. But right now if you wanted to do that you have to rebuild the whole thing. and the whole orchestration between librelane and openroad seems very fraught. python -> env variables -> tcl -> openroad binary and back That said, I recognize it's not a nice world and most things don't behave as we'd like

so just grumping

Well, I would argue the most core part of openroad is actually sta, because everything needs to reference sta for timing calculations. But there are a lot of rather intricate connections between the two; if you've ever looked at things like LL's Odb.InsertECOBuffers, it relies on being able to modify a pre-placed/routed netlist, insert netlist modifications, and then incrementally re-place and route only the new buffers, rather than ripping up the whole run and starting from scratch.

Lofty

Well, I would argue the most core part of openroad is actually sta, because everything needs to reference sta for timing calculations. But there are a lot of rather intricate connections between the two; if you've ever looked at things like LL's Odb.InsertECOBuffers, it relies on being able to modify a pre-placed/routed netlist, insert netlist modifications, and then incrementally re-place and route only the new buffers, rather than ripping up the whole run and starting from scratch.

I haven't to be fair, will take a look! Good points about how intertwined things can be, and not so easy to "just" modularize everything

BreakingTaps

well in a nice world where everything behaves, all the modules (rsz, gpl, ifp, tap, etc) would be individual tools that LibreLane can bolt together at will. and if you wanted to say develop a new rsz you just drop in your own version that speaks to the shared odb backend. But right now if you wanted to do that you have to rebuild the whole thing. and the whole orchestration between librelane and openroad seems very fraught. python -> env variables -> tcl -> openroad binary and back That said, I recognize it's not a nice world and most things don't behave as we'd like

so just grumping

I did ask donn about this; there's a native python API for OR, but it's something of a second-class citizen to the main Tcl API, so it has missing things.

1

Lofty

I did ask donn about this; there's a native python API for OR, but it's something of a second-class citizen to the main Tcl API, so it has missing things.

My understanding is that multiple groups have been pushing for the Python API to be the first class citizen and the TCL API to be an afterthought - but I don't know the current state of that.

BreakingTaps

well in a nice world where everything behaves, all the modules (rsz, gpl, ifp, tap, etc) would be individual tools that LibreLane can bolt together at will. and if you wanted to say develop a new rsz you just drop in your own version that speaks to the shared odb backend. But right now if you wanted to do that you have to rebuild the whole thing. and the whole orchestration between librelane and openroad seems very fraught. python -> env variables -> tcl -> openroad binary and back That said, I recognize it's not a nice world and most things don't behave as we'd like

so just grumping

The great thing about open source is that you can help fix them unlike with the proprietary tooling where groups like Google who are paying hundreds of millions can barely get anything fixed.

hehe part of my grumping is because I've been trying a few experiments, and in the process slowly working "down" the stack discovering how things work and how tightly coupled everything is

huh interestig bit in OpenSTA. What's the story around Parallax SW? Their website is quite bare (http://www.parallaxsw.com/)

However, OpenSTA is not supported by a public community of developers as many other open source projects are. The copyright and development are exclusive to Parallax Software.

Welcome to Parallax Software: Static Timing Analsyis (STA) for EDA ...

Parallax Software provdies static timing analysis software for EDA software.

Both TCL and python are swig generated bindings, it's not that hard to add things if something you need is missing, I had to go through it a couple of times. ( Although both times it was missing in both TCL and python, I think in general when adding things they try to add bindings for both at once to keep them in sync ).

7:11 a.m.

And yeah, in MPW1 times, OpenRoad was different tools ... and it was a nightmare

I much prefer the current version. AFAIU They need to pass quite a bit of info between tools to get good QoR, a lot of which doesn't "map" to standard format, so you ended up with needing the exact right combination of tools so they could talk properly to each other.

BreakingTaps

huh interestig bit in OpenSTA. What's the story around Parallax SW? Their website is quite bare (http://www.parallaxsw.com/)

However, OpenSTA is not supported by a public community of developers as many other open source projects are. The copyright and development are exclusive to Parallax Software.

OpenSTA is used in a number of proprietary solutions. The full test suite for the tool is sadly closed source as well.

rude

5:58 p.m.

never heard of a closed test suite before. I guess maybe they have snippets / test cases from customers under NDA In there?