wafer.space Community - Connecting analog pin in librelane flow

Last night, I thought I'd try taking @Matt Venn's R2R DAC he just submitted on TT 0p3 and add it to TinyQV. I've got the macro in and the digital inputs + ground are connected OK (could probably do with buffers on the input, but one thing at a time). However, librelane won't route the output from the DAC to the analog pin - possibly quite sensibly as in general it probably shouldn't touch analog things. How should I deal with making that connection? I guess I could add it manually to the gds after the librelane flow has finished, but that seems not ideal. Can I add a step to the flow to describe the connection? Or can I just tell the router to connect it somehow? My repo is here, see the dac branch: https://github.com/MichaelBell/ws02-tinyQV/tree/dac

GitHub - MichaelBell/ws02-tinyQV at dac

TinyQV for Wafer Space run 2 on gf180mcuD. Contribute to MichaelBell/ws02-tinyQV development by creating an account on GitHub.

Interested to see how you solve it!

This is an issue I encountered last run as well, give me a minute to remember the fix

9:16 a.m.

Librelane does not like that the pad’s layout does not have a port named "PAD". That’s it.

9:16 a.m.

That’s all I did. Copy the files for the analog pad and define a port named "PAD" in magic

9:17 a.m.

https://github.com/AvalonSemiconductors/ws-submission-2025/tree/main/macros/Analog/AnalogPad

ws-submission-2025/macros/Analog/AnalogPad at main · AvalonSemicon...

Multi-project die. Contribute to AvalonSemiconductors/ws-submission-2025 development by creating an account on GitHub.

9:18 a.m.

Its not even different electrically. The analog pad just provides a straight connection to the outside, the ports "ASIG5V" and "PAD" are electrically shorted, but LibreLane needs "PAD" to exist.

9:18 a.m.

Otherwise it goes "whoa, this is useless!" and optimizes it out, since all it sees is a cell with only an input and no output (I believe)

The issue is that OpenROAD's detailed router does not route any pins with the SPECIAL attribute. This makes sense for power supplies, as they are handled by a dedicated pdngen call.

9:22 a.m.

Here you can see that ASIG5V has SPECIAL set to True.

9:22 a.m.

Looking at the LEF for gf180mcu_fd_io__asig_5p0.lef, I don't see the SPECIAL attribute set for ASIG5V. However, OpenROAD probably sets it when making the bondpad a BTerm (top-level pin) with place_io_terminals.

9:25 a.m.

I had a similar issue with HeiChips: in IHP, the bondpads are separate from the I/O cells and place_bondpad also makes the pin SPECIAL. My solution (workaround) was to edit the LEF to add a second port for the core-facing pin of the I/O cell.

9:25 a.m.

afaik sky130 doesn't have this issue since the I/O cells have separate ports for bondpad and core side.

I noticed that SPECIAL appeared in the def on the OpenROAD.PadRing step, and suspected that might be the reason the router ignored it

9:27 a.m.

But couldn't work out where that was coming from (or even if it was sensible to try and avoid it!)

iirc @tnt recently found a workaround that doesn't require to edit the LEF file? It involves placing a macro with two ports, which is essentially just a short, next to the core-facing pin of the I/O cell.

9:30 a.m.

However, Tholin's solution is also fine.

Yesh, I putting a small macro doing the split connection which works better for me than editing the pads in the PDK :

No need for modifying PDK
Because the short is in a separate block with just that in it, it actually doesn't mess with full LVS/GDS check, both the "schematic" and "layout" side of that block will have a single 0R resistor in them, no ambiguity.
That also allowed me to connect all the split Metal2 traces on the core side, join them together for better connection and bring them to Metal3 where I needed them, avoiding me to have to deal with via at all when routing them

9:38 a.m.

Ends up looking like this :

Cool, that sounds like a good solution. I assume I can find that in the TT gf0p3 project?

But the routing is still done manually though ODB scripts, I don't leave it up to the auto-router.

9:40 a.m.

You can't find it anywhere, that's WIP which is not pushed publically anywhere yet.

9:42 a.m.

But the macro is 2 squares of metal with via between them

just positioned right where it needs to be. (edited)

And if you want to leave it up to the auto-router, you can now add NDRs directly via the LibreLane config

https://github.com/FPGA-Research/heichips25-tapeout/blob/d555bbc58aad6cc54e0bc9ce81b75936db2df0d8/librelane/config.yaml#L253

Thanks all, I’ve got tnt’s solution working and it’s building with no errors