【Inkjet】🧪 03. Why GF180MCU × OpenLane Does Not Work — Confirmed by Real-World Verification

topics: [“semiconductor”, “openlane”, “pdk”, “gf180”, “vlsi”, “mixed-signal”, “high-voltage”, “layout”]

📌 Conclusion (Up Front)

The GF180MCU Open PDK is not compatible with OpenLane (which assumes an OpenPDK-based flow),
and an automatic flow from synthesis to P&R to GDS generation does not work.

This is not speculation.
It is a conclusion confirmed through hands-on verification in a real environment.

As a direct result of this verification,
this project abandoned the automatic digital flow and transitioned to a layout-driven design approach,
centered on high-voltage MOS (HVMOS) devices.

🧭 Background

GF180MCU is published as an Open PDK suitable for:

It appears well aligned with applications such as
inkjet printhead drivers, which require HV + mixed-signal circuitry.

This led to the hypothesis:

“Perhaps we can push GF180MCU through OpenLane all the way to GDS.”

To validate this, we performed direct verification in a real execution environment.

🖥 Verification Environment (Key Points)

❗ What Actually Happened (Facts)

When running OpenLane,
the flow always failed at the prep stage with the following error:

couldn't read file
.../libs.tech/openlane/config.tcl

This failure was reproducible and unavoidable.

🧠 Technical Root Cause

OpenLane assumes an OpenPDK-style directory structure,
specifically requiring:

libs.tech/openlane/config.tcl

However, this structure does not exist in the GF180MCU Open PDK.

This is not a missing configuration file or a simple setup issue.
It reflects a fundamental mismatch in PDK design philosophy.

📊 Technical Comparison

Item Sky130 GF180MCU
Official OpenLane support ✔ ✘
OpenPDK directory structure ✔ ✘
Automatic GDS generation ✔ ✘
HV / mixed-signal suitability △ ✔

In short:

GF180MCU is not “unsupported” in general —
it simply does not align with OpenLane’s assumptions.

🔍 Why This Is Not a “Failure”

What this verification conclusively established:

This is a critical design boundary,
and one that cannot be reliably determined from documentation alone.

Confirming it through real execution was essential.

🚧 What We Did Next (Critical)

After abandoning the automatic flow, the project moved forward by:

As a result, we successfully generated actual GDS data
for a high-voltage MOS switch unit (HV_SW_UNIT).

🧩 HVMOS Layout Result (Real GDS)

Below is the actual GDS generated in this project:
a GF180MCU-based high-voltage MOS switch unit (HV_SW_UNIT).

GF180 HV_SW_UNIT GDS (DNWELL + Guard Ring + HVMOS)

At this point, the state is no longer:

“OpenLane failed to generate GDS”

but rather:

“By selecting the appropriate design methodology,
we reached real, manufacturable GDS.”

🛠 Practical Implications

When Using GF180MCU

When Using OpenLane

“HV mixed-signal × automatic digital flow” rarely intersects.

🧩 Relation to This Project

This verification and the resulting layout work are part of the following exploration project:

gf180-inkjet-driver

🔗 Links

🧾 Summary

GF180MCU × OpenLane does not work.
This is not a failure, but a crucial result in selecting the correct design flow.

GF180MCU is not:

but rather:

And once that assumption is accepted,
this verification also shows that real HVMOS-based GDS is achievable.

📎 Final Note

Hopefully, this record will help reduce the number of designers
who lose time due to the same misunderstanding.