Closed growly closed 1 year ago
Questions about how the router founds legal routes:
I have made the access pins comically large and comically far apart but I still get pin access errors. Currently, i1_r (input 1 on the right):
[INFO DRT-0033] Metal5 shape region query size = 0.
[INFO DRT-0165] Start pin access.
[ERROR DRT-0073] No access point for bfg_mux/i1_r.
Error: droute.tcl, 38 DRT-0073
LEF: gf180_mux.lef.zip
The cell is DRC clean according to the magic, but the LEF is a bit of a hack job so might be the problem?
Leaving the right-side disconnected, the router succeeds in connecting to the other nets but with violations. I'm not sure what's different about the right-hand side?
Here are the routes (with 1 violation allegedly) in the openroad gui:
It would be helpful to package this as a standalone test case.
pa access issues can depend on the relative placement of the instance to the routing pattern
Thanks -
When attempting to connect only the right-hand pins the pin access failures occur and the flow automatically creates this issue_reproducible
package:
bfg_mux_test_right_pins_access_failure.tar.gz
When attempting to connect only the left-hand pins, pin access seems to have been figured out but there is a violation and the flow ends prematurely. I have attempted to package the artefacts manually, but I'm not sure I got the right script or right input DEF: bfg_mux_test_left_pins_routed_but_violating.tar.gz
The left pins test is off:
set ::env(CURRENT_ODB) {./tmp/routing/16-global.def};
a .def is not a .odb.
There is no lef included so I can't even piece it together.
Your cell gf180mcu_mux has bad shapes in its i1_r pin:
MANUFACTURINGGRID 0.005 ;
MACRO gf180mcu_mux
PIN i1_r
PORT
LAYER Metal1 ;
RECT 11.455 1.975 11.795 2.17 ;
RECT 11.455 2.17 11.795 2.899 ;
RECT 11.455 2.899 11.795 4.584 ;
RECT 15.69 4.529 16.08 4.584 ;
RECT 11.455 4.584 16.08 4.814 ;
RECT 15.69 4.814 16.08 4.869 ;
your shapes are off the manufacturing grid. All the above coordinates need to be a multiple of 0.005. All attempts at pin access always yield an off-grid violation because the cell itself is bad.
Ah, thank you! So by fluke it seems the working pins are all on the grid. So then this isn't DRC clean, possibly because the magic checks don't include it and I needed to run the klayout DRC checks too.
PS.
The example in the instructions specifies a DEF, not an ODB, so that's what I gave it. Here is the repackage: bfg_mux_test_left_pins_routed_but_violating.tar.gz
LEF was attached to a previous comment ( gf180_mux.lef.zip) but I think you've got a post-rectangle-covering version anyway
Likely or_issue directions were not update for the switch from def to odb. You could file an OL doc bug.
I would expect magic to check off grid
I had expected that too. Probably my error, I'll look.
I can confirm that with all units snapped to a 0.005 um grid routing completes successfully:
I can also confirm that magic does not catch this error!
Describe the bug
During detailed routing, pins on my custom cell cannot be accessed and I'm unsure why. For example, I get errors like this:
The cell has many pins, shown in this lef (also attached): gf180_mux.lef.zip
Some of them are clearly trickier than others to get to, but some of them (including i1, i3) seem pretty simple. I get an error for i1 but z seems to work:![Screenshot 2022-12-06 at 10 59 45 AM](https://user-images.githubusercontent.com/125257/205752004-0aa8adf7-2950-4758-a116-c4f90a0bcba5.png)
Expected Behavior
I'd like to understand how the router negotiates access so that I can design the cell to be accessible by it.
OpenROAD Environment
OpenLane Environment
To Reproduce
I invoke this through the
caravel_user_project
Make scripts. It seems to just be running OpenLane. The initial and final config.tcl are attached. config.tcl.zipRelevant log output
No response
Screenshots
No response
Additional Context
No response