https://open-source-silicon.dev logo
Join Slack
Powered by
Hi <@U020J2W6Q84> <@U01680FK487>. I've found a wei...
# openlane
m
Hi @User @User. I've found a weird issue with MPW3 tooling failing to route a design with lots of space. It succeeds or fails if I move a macro by 20um.
image.png
this works
image.png
this fails
image.png
the failure is that TritonRoute fails with 40 violations after 64 iterations and the flow stops
I have no idea why a 20um shift in a macro could cause this
here's the floorplan
odd, no floorplan. here's the pdn
plenty of room
final routed design with the first macro config
My best guess is that it might have something to do with the way the routing spilled out of the macros
image.png
see on the right? maybe that causes issues with the router?
that is all local interconnect
so shouldn't be a problem,
I force the router not to use local interconnect in my caravel config.tcl
I tried deleting all that local interconnect on the right but get the same unroutable error with tritonroute
m
What size are the pins? Is this maybe a routing grid alignment issue?
From what I understand, tritonroute isn't good for off grid. So the solution is to make pins 2x the grid which are easier to route to.
I'm not sure what they do for default pins in OpenLane
Or, you can place the macros so they are a multiple of the routing grid
m
interesting!
where can I get info about the routing grid?
maybe it's this one
GLB_RT_TILES
well reducing that from default of 15 to 10 makes a difference. Now the routing succeeds very quickly on the original broken macro position
m
I meant for detailed routing. That controls the coarseness of the global router which wouldn't be the issue
You can't change the detailed router pitch as that is based on the design rules
m
it does work though. Changing it to 10 resulted in a complete flow with no errors
this is so interesting, I wonder if I ran into this with MPW1 & 2 and didn't realise it was to do with macro positioning
how do you know what the routing grid is set to?
m
Each layer has a pitch that is based on the minimum wire width plus spacing. The routers use the "center line method" where if you divide into a grid of that size, it reduces routing to just finding a path
The challenge is when pins aren't on the grid
Most standard cells are made with on grid pins
m
This is at the user wrapper level, so Im putting together already hardened macros
m
So while the pins of that macro may be on grid, if you place the macro off grid they will become off grid
Standard cells must be placed on a grid to keep their pins on grid as well
m
if you move by a fixed distance you might be putting the pins off the routing grid. We could look at it further with a test case.
m
@Matt Liberty that would be good
but I'm still confused, I thought the pins were basically equally spaced around the perimeter
so have I just been lucky before that it has routed OK?
m
it depends on the context and congestion. Its hard to be sure without seeing
It does sound odd though
m
I can give you a test case easily
m
what does the floorplan look like in the failing configuration?
In particular what is the macro spacing?
m
see the images at the top of this thread
moving the top macro up by 20um will make the router work or fail
@Matt Liberty here's a test case: https://github.com/mattvenn/zero_to_asic_mpw3
I hope I've added everything you need to reproduce, pls let me know if there's anything missing
just run make user_project_wrapper after cloning
m
Here's one of the DRVs and you can see the pin is off track:
zoomed out:
I think we should be able to fix this but in general it is a good idea to avoid off track pins on macros (here there is little density but in a more realistic design it can get much harder)
👀 1
btw, have you used the DRC browser in OR?
m
@Matt Liberty how would I avoid off track pins on macros? These were hardened with no pin config and no settings related to the pins. so openlane put the pins off track on its own.
no, I haven't used DRC browser - any docs?
m
@Matt Venn we don't have great gui docs but what we have is at https://github.com/The-OpenROAD-Project/OpenROAD/tree/master/src/gui. For drc you can either use the command line
Copy code
gui::load_drc filename
or you can do it graphically by 1. Choose Windows-> DRC Viewer" 2. Click Load I learned yesterday that OL writes the drc report with a .drc extension while OR expects a .rpt. I enhanced OR to support either but it probably hasn't shown up in OL yet so you'll have to rename the file for now.
It can also load drc from klayout in json format [ORFS provides a script to dump it]
m
@Matt Liberty it looks like I have different pitches for pins on met2 and met3
are these lines from fastroute.log showing the pitch?
if the macro has different pin pitches on either side then it seems it's going to be hard to get both on the grid
anyway to show the routing grid with klayout? or only with OR gui?
I made sure the 0,0 point of the macros is on a 0.23 divisible number, and that routes ok for 2 macros
Open in Slack
PreviousNext
Powered by