pdngen: don't generate stdcell power stripes below macro

[Syndace]

Our design uses a macro that is not made of standard cells and does not need/clashes with the stdcell power stripes that are generated on m1. How do I tell pdngen to not generate m1 stdcell power stripes below those macro instances?

[maliberty]

Do you have a blockages on m1 in your macro?

[Syndace]

I believe so, the lef contains

OBS
    Layer Metal1 ;
        RECT 0 0 width height ;

(where width and height are numbers that match the SIZE declaration). Should that be enough to have pdngen avoid the area?

[maliberty]

It sounds like it. Can you provide a test case?

[Syndace]

I wish I could provide some reproducible state, I'm ashamed to bother you with such low quality issues, but I'm not allowed to share anything.

Anyway, the information that it should probably work is already helpful, because that's not the only "weird" issue we have with that macro. I'll ask the source of the macro to double-check their stuff.

For now, is there a manual way to add a blockage before PDN generation? The macro is placed manually anyway, so I know its exact position (and size).

[rovinski]

Can you also check if the cell sites under the macro are being removed? PDN shouldn't generate M1 rails for areas without cell sites. They are usually removed during the tapcell insertion step.

If there are M1 blockages in the macro, then it shouldn't be an issue with the blockage. Can you confirm that you are placing the macro before running PDN?

[Syndace]

Can you also check if the cell sites under the macro are being removed?

How do I check? Sorry, I'm inexperienced.

They are usually removed during the tapcell insertion step.

That's interesting, because the PDK we use doesn't have tapcells, so the tap/decap insertion step is skipped. Could it be that the site removal is accidentally skipped too?

Can you confirm that you are placing the macro before running PDN?

Yes, the macro is definitely placed before PDN generation.

[rovinski]

Can you also check if the cell sites under the macro are being removed?

How do I check? Sorry, I'm inexperienced.

Start the OpenROAD GUI (openroad -gui), turn on the visibility for "Rows", and see if there are cell rows present under the macro. You would want to turn off visibility for just about everything else so that you can see.

That's interesting, because the PDK we use doesn't have tapcells, so the tap/decap insertion step is skipped. Could it be that the site removal is accidentally skipped too?

Which flow are you using? OpenROAD-flow-scripts? OpenLane? Custom scripts?

[Syndace]

Start the OpenROAD GUI (openroad -gui), turn on the visibility for "Rows", and see if there are cell rows present under the macro. You would want to turn off visibility for just about everything else so that you can see.

Thanks. The rows continue under the macro uninterrupted.

Which flow are you using? OpenROAD-flow-scripts? OpenLane? Custom scripts?

We are using OpenLane.

[rovinski]

Thanks. The rows continue under the macro uninterrupted.

According to the PDN README, this is a known limitation:

https://github.com/The-OpenROAD-Project/OpenROAD/blob/96e57b5b48bfd6ef6874637f2ba2d27edbff026d/src/pdn/README.md?plain=1#L459-L465

The tapcell command calls odb::cutRows() in order to remove cell rows underneath macros. https://github.com/The-OpenROAD-Project/OpenROAD/blob/0c5910df6bfc6e6ef987d836c17c2d75688aba99/src/tap/src/tapcell.cpp#L123

I'm not sure if this function is (easily) callable from the tcl shell. @maliberty thoughts on best solution?

Which flow are you using? OpenROAD-flow-scripts? OpenLane? Custom scripts?

We are using OpenLane.

I don't believe OpenLane is designed to work with non-SkyWater PDKs at this time. You may want to explore using OpenROAD-flow-scripts as an alternative due to it's compatibility with multiple PDKs.

[gadfort]

I think it would be very useful to expose the cutRows command to the tcl interface since I've had to cut rows before without wanting to add the tap cells at that time. maybe something like cut_rows -halo_x -halo_y

[maliberty]

How are your wells tied off in this PDK without any tapcells?

@arlpetergadfort I'm fine with exposing cut_rows but I think it should refuse to cut anything containing a tapcell/endcap to prevent misuse.

[Syndace]

I'll quote this, because I struggle to formulate it myself:

Early days there was no concept of well tap cell, Standard cells were designed in such a way that each standard cell had nwell to VDD and p-substrate to VSS connection within the standard cell. But such a standard cell design had consumed more area and to save the area, later a concept of Tapless cell has evolved.

Guess the PDK we use is "old-school".

[maliberty]

Very old school. We can add a row cutting command but as a workaround you could run tapcell with a small cell just to get the rows cut. You could either leave those "tapcells" or just delete them afterwards.

[Syndace]

Thanks, I've specified a filler cell as the tapcell and it works beautifully.