drt: DRC violations due to routing being too strict about following tracks when accessing pins

[titan73]

Describe the bug

After 18 iterations, there are 40 similar drc violations still not fixed.

M2 route follow track when switching to M1 causing DRC.

Expected Behavior

M2 should not strictly follow track if possible to fix DRC.

Environment

v2.0-16855-ga15114a95

To Reproduce

openroad test.tcl with test case below:

drc_pin_access.zip

Relevant log output

No response

Screenshots

No response

Additional Context

No response

[maliberty]

Please don't include proprietary tool output.

[stefanottili]

In the picture it looks as if your stdcell sites are not a multiple of the routing pitch.
This is very unusual and leads to none of the stdcell pins being "on track".

[osamahammad21]

@stefanottili I agree with you, but I don't understand why pin access did not complain about this earlier in the flow. I'll investigate further.

[titan73]

In the picture it looks as if your stdcell sites are not a multiple of the routing pitch. This is very unusual and leads to none of the stdcell pins being "on track".

Yes indeed, the sites for this library is not multiple of the pitch. This library is badly designed. All other sites for other libraries in this techno are correct.

[maliberty]

Do you need to use the badly designed library? I'm not saying we shoudn't look at it but it also seems like its making things unnecessarily hard.

[titan73]

Yes. There is not replacement for this standard cells library (215 cells). It's a mature techno with a lot of products based on it. They unfortunately won't redesign these cells.

[titan73]

Btw, apart from the site width not multiple of pitch, if a library has the correct site but the cells pins are not or badly aligned, that will cause the same issues in OR, right?

[stefanottili]

Why don’t you use a pitch that matches the design of the stdcells ?

[titan73]

Why don’t you use a pitch that matches the design of the stdcells ?

I plan to test this with custom tracks. This could work in that case because there is only one power domain using GO1 cells. With 2 power domains that won't because GO2 cells have a correct site width so if we change the tracks for GO1's ones cells this will break the GO2's ones.

[osamahammad21]

@bnmfw I'm concerned that pin access allows access to this pin while it's impossible with the given access points and the nearby cell. Something is probably going wrong in pa pattern step for generating access patterns for a row of cells.

[maliberty]

While we look at this, a simple workaround is to use

global_placement -pad_left 1 -density 0.8
set_placement_padding -global -left 1

[maliberty]

It looks like the row based search finds the lowest cost set of APs but they are not DRC free. I suppose it hopes that dr will find a solution and accepts it. Really we need to generate at least one AP that is not so close to the edge.

[maliberty]

-min_access_points 5 also fixes the problem.

[maliberty]

@bnmfw I think we should the termination at MINNUMACCESSPOINT_STDCELLPIN to also consider if all APs are so close to the cell edge that such a failure could occur when we do row testing. We should try to find at least one not so close before stopping even if we hit the overall minimum.