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 555 forks source link

[WARNING DRT-0225] CFG_LBCSYNCMODE 10 pin not visited, fall back to feedthrough mode #5554

Open stefanottili opened 3 months ago

stefanottili commented 3 months ago

Describe the bug

DRT is spewing DRT-0225 messages util it hits the limit, so there is no way of knowing whether this is for every single pin or not. This is from the ICCAD2004 testcase, IBM 130nm, artisan stdcell lib. Routes cleanly.

Expected Behavior

What is this warning all about ? The pins look normal to me, all of them are on track, easy to route to.

Environment

Mac M1
OpenROAD v2.0-15115-g20ac1be86 (Aug 11th 2024)
Features included (+) or not (-): +Charts +GPU +GUI +Python

To Reproduce

Please get lef/def, risc2.or and Makefile from https://github.com/The-OpenROAD-Project/OpenROAD/issues/5548

Relevant log output

379 [INFO DRT-0028]   Complete metal6.
 380 [WARNING DRT-0225] CFG_LBCSYNCMODE 10 pin not visited, fall back to feedthrough mode.
 381 [WARNING DRT-0225] CFG_MEMZEROFIRST 2 pin not visited, fall back to feedthrough mode.
...
1379 [WARNING DRT-0225] lx1/CE0/macd/macfile/n358 4 pin not visited, fall back to feedthrough mode.
1380 [WARNING DRT-0225] message limit reached, this message will no longer print

Screenshots

No response

Additional Context

No response

maliberty commented 3 months ago

@osamahammad21 please do a quick triage. I'm not sure if this is a drt issue or a grt one.

osamahammad21 commented 2 months ago

Feedthrough mode means that we are using the pins as nodes to connect the net guides. Forexample, if we have a pin that has shapes on layers M1 M2 and M3, and 2 guides reaching in/out that pin on M1 and M3, then we use the pin as a connection between the M1 guide and M3 guide.

titan73 commented 2 months ago

So this mode prevents to use a guide in M2 right? And the pin not visited is the shape in M2? It's a kind of optimization?

osamahammad21 commented 2 months ago

I wouldn't say it's an optimization. Before going through detailed routing we have to verify the ocrrectness of the global routes first. This is what we are doing here. We are traversing the guides for each net to make sure that all pins are covered. If not, then we issue an error and do not go into detailed routing. Ideally the guides should be all connected together without the need of using pins as feedthrough nodes in graph. But some global route solutions consider the pins as part of net guides graph. In that case we warn the user. In all cases we don't attempt to fix the global routes.

titan73 commented 2 months ago

I've taken a look at one of the warning I have: [WARNING DRT-0225] STUSB_ISO_i/command_blk_prt_reset_pulse 1 pin not visited, fall back to feedthrough mode.

The warning seems to come from the pin connection in the middle as the left and right ones are standards. The cell is reconfigurable and has 2 pins Q connected in M2 (The M2 connection sis part of the cell) and the router created a route in M3 and connects to M2. What are the pin not visited? I would say there should the 2 M1 pins. How should the warning be interpreted in that case.

feedthrough

Btw, the route guide is in M1 and the route in M3. Is there an issue with the global route? It teems there are a PR for that.

Other question why is route guide in the middle gcell opaque compared to its neighbours? Are there 2 route guides overlapping in this gcell?

osamahammad21 commented 2 months ago

Ok I see the problem now, the global router is using metal1 as the bottom routing layer. As far as a user's concern, you should set the min routing layer to be M2 as the cells are placed on M1. However, this has other implications for the tool developers: