search

The-OpenROAD-Project / OpenROAD

OpenROAD's unified application implementing an RTL-to-GDS Flow. Documentation at https://openroad.readthedocs.io/en/latest/
https://theopenroadproject.org/
BSD 3-Clause "New" or "Revised" License
1.6k stars 556 forks source link

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

Open titan73 opened 1 week ago

titan73 commented 1 week ago

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.

or_pin

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 commented 1 week ago

Please don't include proprietary tool output.

stefanottili commented 1 week ago

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 commented 1 week ago

@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 commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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

titan73 commented 1 week ago

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 commented 1 week ago

@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 commented 6 days ago

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 commented 6 days ago

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 commented 6 days ago

-min_access_points 5 also fixes the problem.

maliberty commented 6 days ago

@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.