[WARNING DRT-0225] CFG_LBCSYNCMODE 10 pin not visited, fall back to feedthrough mode
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
@osamahammad21 please do a quick triage. I'm not sure if this is a drt issue or a grt one.
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.
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?
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.
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.
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?
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:
- GRT again miscalculates M1 resources. @eder-matheus https://github.com/The-OpenROAD-Project/OpenROAD/issues/5696
- in DRT, we should either get rid of the warning or make it more informative. In guides processing, we do 3 iterations of graph traversals.
- First Iteration:
- M1 guides are treated only as via guides.
- Pins are considered one-way terminals (not bidirectional).
- This iteration fails because pins cannot be reached when M1 guides are only for vias.
- Second Iteration:
- M1 guides are treated as segment guides.
- Cross-GCell routing on M1 is not allowed which means that the M1 guide from the left pin to the center pin doesn't connect to the M1 guide from the right pin to the center pin.
- This failure triggers the warning.
- Third Iteration:
- Pins are considered as feedthrough (bidirectional) terminals.
- The center pin now successfully connects the M1 left guide to the M1 right guide.
- First Iteration: