https://open-source-silicon.dev logo
Join Slack
Powered by
Hi, After several trials with different macro pla...
# openlane
b
Hi, After several trials with different macro placement combinations, our eFPGA design can not pass DRT (detailed routing) stage. We waited hours, but after a dozens of iterations still no progess on violations. I added placement image and detailed.log files. Do you have any suggestion? Regards,
14-detailed.log
We fully utilized external IOs and LA pins
m
@Burak Aykenar not much experience with GRT, but it looks like your first iterations took around 3 minutes and progressed to about 15 minutes an iteration without much reduction in the number of violations. Is this a public design? Can you add more space between your macros? Do your macros have internal or external pins? How are your power rails? Are you using 4 pairs (caravel/caravn) or just one (openframe). Can you look at the routing congestion in the openroad gui?
b
Sorry by the way it is DRT not GRT. Unfortunately this is not a public design. I added more space (60 um) between macros and set FP_PDN_ENABLE_RAILS to '0', which was '1'. Only outer macros have connections to external pins. Internal macros just connect internally to each other. For power rails, I only used 1 pair, but pitch value is 50 um. I don't know if I can see routing congestion in OR gui, since I can only open placement results, I don't have routing results. I checked log and it is now in 5th iteration and still has 6785 violation I can try increasing the distance between macros but then there is a risk to be too near to right and left edges.
I added config file
config.json
I have found data for global routing
image.png
Here is the routing odb file
11-global.odb
I dont understand why routing can't finish, I am not sure but I dont see any congestion
is it because of high pin utilization ?
image.png
The distance between pins seems to be 2-3 um for macros
The distance between pins is measured as exactly 2.121 While FP_IO_MIN_DISTANCE is 3 by default. Does this cause DRT routing problems?
Well now I am trying 75x150 and 150x150 um macros with distance between macros 40 um. With these configurations, pin distance is more then 3 um. But DRT still cant finish routing
After nearly 4 hours and 53 iterations no progress
14-detailed.log
When I check for met3 congestion, I see some as in the picture below. Does this can be the issue?
m
@Burak Aykenar I think there should be a way to look at the actual shorts. Can you try to limit (maybe 5?) the detail routing iterations with 
DRT_OPT_ITERS
? The resulting 
odb
database might have the shorts.
Looking at your config file, there are a couple suggestions for simplification. 1. wildcard characters are acceptable.
Copy code
"FP_PDN_MACRO_HOOKS": [
        "grid_io_bottom_* vccd1 vssd1 vccd1 vssd1,",
        "grid_io_left_* vccd1 vssd1 vccd1 vssd1,",
        "grid_io_right_* vccd1 vssd1 vccd1 vssd1,",
        "grid_io_top_* vccd1 vssd1 vccd1 vssd1,",
        "grid_clb_* vccd1 vssd1 vccd1 vssd1,",
        "cby_* vccd1 vssd1 vccd1 vssd1,",
        "cbx_* vccd1 vssd1 vccd1 vssd1,",
        "sb_* vccd1 vssd1 vccd1 vssd1,",
        "constant_assignments_i vccd1 vssd1 vccd1 vssd1"
    ],  
...
    "VERILOG_FILES_BLACKBOX": [
        "dir::../../verilog/gl/cbx_*.v",
        "dir::../../verilog/gl/cby_*.v",
        "dir::../../verilog/gl/grid_clb.v",
        "dir::../../verilog/gl/grid_io_bottom.v",
        "dir::../../verilog/gl/grid_io_left.v",
        "dir::../../verilog/gl/grid_io_right.v",
        "dir::../../verilog/gl/grid_io_top.v",
        "dir::../../verilog/gl/sb_*.v",
        "dir::../../verilog/gl/constant_assignments.v"
    ],
    "EXTRA_LEFS": [
        "dir::../../lef/cbx_*.lef",
        "dir::../../lef/cby_*.lef",
        "dir::../../lef/grid_clb.lef",
        "dir::../../lef/grid_io_bottom.lef",
        "dir::../../lef/grid_io_left.lef",
        "dir::../../lef/grid_io_right.lef",
        "dir::../../lef/grid_io_top.lef",
        "dir::../../lef/sb_*.lef",
        "dir::../../lef/constant_assignments.lef"
    ],
    "EXTRA_GDS_FILES": [
        "dir::../../gds/cbx_*.gds",
        "dir::../../gds/cby_*.gds",
        "dir::../../gds/grid_clb.gds",
        "dir::../../gds/grid_io_bottom.gds",
        "dir::../../gds/grid_io_left.gds",
        "dir::../../gds/grid_io_right.gds",
        "dir::../../gds/grid_io_top.gds",
        "dir::../../gds/sb_*.gds",
        "dir::../../gds/constant_assignments.gds"
    ],
2. Many 
GRT_OBS
are defined. This corresponds to your macros, right? Do you change this every time you reposition your macros? Is it possible to move these definitions to the lef files for each macro instead? 3. Looks like you’re just connecting the macros with this config. No buffer insertion for timing or fanout, right?
m
I would add "-drc_report_iter_step 5" to your call to drt. Then you'll get a drc report every 5 iterations. You can look at where the markers are to get some idea of what the issue is.
👍 1
My first guess would be that you have macros placed with their pins off the routing tracks. Of course it could be something else
😬 1
b
Thanks for your comments @Matt Liberty and @Mitch Bailey I immediately tried by limiting iterations to 5 and get odb for routing. Sharing now to gain time. Now I am also inspecting. If you find out anything please let me know. But my first impression is something is going on in the pins. All violations seem to be there. Some images from OR gui DRC Viewer:
user_project_wrapper.odb
image.png,image.png
m
@Burak Aykenar if your macros have a lot of closely spaced pins that are on the routing grid (macro placement is important), I imagine you'd run into a lot of problems as @Matt Liberty said.
b
Hımm, so sense pins on the macro is the problem, I didn't know about routing grids. I checked slack and found that thread below: https://open-source-silicon.slack.com/archives/C016H8WJMBR/p1691799291036709?thread_ts=1691761744.451129&cid=C016H8WJMBR
Is this the solution:
e
Hi @Burak Aykenar, we had a similar problem with routing to the pins. Are the left edge of the ports right on the very edge of the bounding box? It looks like that dark red vertical strip of 100 is an obstruction area, which means openlane won't go in there to reach the ports. This could be caused by a tiny piece of Metal overhanging the pin boundry somewhere else in the design? Secondly can your ports be reached from all angles (n,s,e,w)? In Magic you can define this so the router can route to the West edge of the pins?
I think that all those squares with '100' in are caused by an obstruction area defined in the LEF, meaning the router isn't allowed in.
m
In the GUI there is an option to show the routing tracks. If you turn that on and select the single layer that contains the pins for visibility it is easy to see if the pins are on track or not. Also, what sort of violations are they that you are getting?
b
I think @Matt Liberty is right. I mean I checked the errors and in the DRC view they are "NS Metal" and "Short. When I clicked the first NS Metal DRC violation, as you said the net is on the track but not alligned with the pin. Also there are short DRC errors and they are at the pins. So I thought that openlane can handle pin locations according to routing tracks, but that is not the case here.
m
@Matt Liberty What is an 
NS Metal
error? The short error looks like a metal3 to obstruction error. Is the overlap only valid in the pin area (ie. if the macro pin were centered on the routing grid - no error)?
m
Non-Sufficient Metal - the overlap area is too small. Really the macro placements need to be fixed and things will go much better in routing
👍 1
Are these manually placed by a script of some sort?
b
well I have written a python script to center the macros and define some constants such as length and height of the macros, distance between macros and also generate GRT_OBS texts for config.json
calc_macro_positions.py
calc_macro_positions.py
m
https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/tree/master/flow/designs/asap7/mock-array is a similar array style design where they have taken care to put the macros on the routing grid. It might be useful
b
Oh thanks I will look at it, otherwise I think I need to manually adjust all macro positions, from OR GUI I can see and calculate the value that need to be modified for macro positions to align with track grid. I will return after I tried, thanks a lot
I manually adjusted the macro positions for the lowest 6 macros to align pins to routing tracks by looking at DRC View and the DRC errors gone. So, it seems it is working for now. I will tell the results whenever possible to run the flow after adjusting each macro.
👍 2
I talked to @jeffdi, he said that I dont need to add GRT_OBS if I harden a macro in openlane and the macro is all digital. GRT_OBS is needed if the macro is a custom designed module. The problem with pins are not related to tracks but GRT_OBS. When I deleted GRT_OBS from config, GRT finishes even in 2 or 3 iterations. I also tried precheck and it passed.
👍 1
@Ellen Wood Thanks, you were right. After I removed GRT_OBS routing step finished and the flow completed
👍 1
e
Hi @Mitch Bailey, i try with this:
Copy code
"FP_PDN_MACRO_HOOKS": [
        "grid_io_bottom_* vccd1 vssd1 vccd1 vssd1,",
        "grid_io_left_* vccd1 vssd1 vccd1 vssd1,",
        "grid_io_right_* vccd1 vssd1 vccd1 vssd1,",
        "grid_io_top_* vccd1 vssd1 vccd1 vssd1,",
        "grid_clb_* vccd1 vssd1 vccd1 vssd1,",
        "cby_* vccd1 vssd1 vccd1 vssd1,",
        "cbx_* vccd1 vssd1 vccd1 vssd1,",
        "sb_* vccd1 vssd1 vccd1 vssd1,",
        "constant_assignments_i vccd1 vssd1 vccd1 vssd1"
    ],
but i get a the error "No regex match found for constant_assignments_i defined in FP_PDN_MACRO_HOOKS" this just happen when i connect multiples modules e.g.
Copy code
// this generate an error
"FP_PDN_MACRO_HOOKS": [
        "grid_io_bottom_* vccd1 vssd1 vccd1 vssd1,",
        "grid_io_left_* vccd1 vssd1 vccd1 vssd1,"]
But if i try using it with one module it works, e.g.
Copy code
// this generate an error
"FP_PDN_MACRO_HOOKS":"grid_io_bottom_* vccd1 vssd1 vccd1 vssd1"
How can i solve this problem?
m
These are regular expressions not file globbing. Try using the 
.
wildcard before the 
*
repeat.
Copy code
"FP_PDN_MACRO_HOOKS": [
        "grid_io_bottom_.* vccd1 vssd1 vccd1 vssd1,",
        "grid_io_left_.* vccd1 vssd1 vccd1 vssd1,",
        "grid_io_right_.* vccd1 vssd1 vccd1 vssd1,",
        "grid_io_top_.* vccd1 vssd1 vccd1 vssd1,",
        "grid_clb_.* vccd1 vssd1 vccd1 vssd1,",
        "cby_.* vccd1 vssd1 vccd1 vssd1,",
        "cbx_.* vccd1 vssd1 vccd1 vssd1,",
        "sb_.* vccd1 vssd1 vccd1 vssd1,",
        "constant_assignments_i vccd1 vssd1 vccd1 vssd1"
    ],
✅ 1
e
Thank you, it works and save me a lot of time.
👍 1
17 Views
Open in Slack
PreviousNext
Powered by