Can a routing guide file (generated by a global router) be loaded into OpenROAD, and then perform parasitic extraction followed by STA?

[liangrj2014]

From the scripts here: OpenROAD-flow-scripts/flow/scripts/global_route.tcl at master · The-OpenROAD-Project/OpenROAD-flow-scripts (github.com) we can see that the parasitic extraction followed by STA can be conducted at the global routing stage, and the routing guide can be dumped out after global routing. I wonder whether we can load a routing guide file (generated by other global router) into OpenROAD, and then perform parasitic extraction and STA?

[maliberty]

I would think so but have never tried it.

[liangrj2014]

Thanks! I would give a try :)

[maliberty]

Note the guides need to look like routing - wide areas will not work well.

[liangrj2014]

Actually this is exactly what I did: "write out guides and then read the same back in". But I got different timing :(

[maliberty]

What design did you use?

[liangrj2014]

I used design aes from IWLS 2005 benchmark suits, with ASAP7 library

[liangrj2014]

I could share design files if it would help :)

[liangrj2014]

Hi! Are there any suggestions on this issue? Thanks in advance!

[maliberty]

@eder-matheus would you or @luis201420 take a look

[liangrj2014]

It will be really helpful if we can have such commands! We are helping to organize the ISPD2025 contest on performance-driven global routing and looking for an open-source tool that can evaluate PPA of global routing solutions. It will be wonderful if OpenROAD could load a global routing solution, extract RC and analyze timing/power!

[eder-matheus]

@liangrj2014 Here are the two commands that you can use to write and read the global route segments and perform parasitic extraction from them. Let me know if you have any other questions.

[maliberty]

@eder-matheus 'here' is unclear

[eder-matheus]

@eder-matheus 'here' is unclear

I'm sorry, I forgot to paste the link: https://github.com/The-OpenROAD-Project/OpenROAD/blob/master/src/grt/README.md#write-global-routing-segments

[liangrj2014]

Thanks for the great help! Let me give a try soon :)

[liangrj2014]

Thank you once again for implementing the new commands! I conducted a brief test by writing out a route segments file and then reading it back in. The process ran smoothly, and I observed consistent timing results before and after the read/write operations :)

Upon examining the route segments file, I noticed that its format appears similar to the route guide format. Is it possible to provide a detailed description of the route segments format? Specifically, I am interested in understanding the syntax used and the criteria for valid route segments solutions. This information would be invaluable for participants in the ISPD contest to create route segments files compatible to the OpenROAD flow. Thanks in advance!

[eder-matheus]

@liangrj2014 The main difference between the route guide and route segments format is what is described.

In the route guides, each line represents a rectangle in a specific routing layer: (lower_left_x, lower_left_y, upper_right_x, upper_right_y, routing_layer).

In the route segments, each line describes a vertical or horizontal line, or a via, going from one point to another in a given routing layer: (x1, y1, routing_layer1, x2, y2, routing_layer2).

Some examples:

1. 18000 154800 met4 18000 205200 met4: this segment represents a vertical line in the routing layer met4.
2. 18000 154800 met3 133200 154800 met3: this segment represents a horizontal line in the routing layer met3.
3. 18000 205200 met3 18000 205200 met4: this segment represents a via going from met3 to met4.
4. 133200 154800 met3 133200 154800 met2: this segment represents a via going from met3 to met2.
   Notice that the via segments can go from lower layers to upper layers (like in example 3) or from upper layers to lower layers (like in example 4).

To perform parasitic extraction from the route generated in other global route tools, you would also need to give OpenROAD's global router the pin positions of each net relative to the global routing grid of the external tools. This requires a bit of background on how our global router works, so I'll explain it in a separate comment.

[eder-matheus]

Our global router creates a routing grid based on the size of each GCell. The grid looks like this:

Each square of the grid is a grid point. The specific coordinates of each point are the center of the squares. When the global router parses the nets of the design, each pin of the net is "translated" to a position in the routing grid. In the figure below, we see that the highlighted pin Y have its position in the global routing grid in the yellow dot, the center of the square that contains the larger part of the pin geometry:

This is important because when extracting parasitics from the global route segments, the tool will make connections between the segments and these positions in the routing grid. In other words, the segments must be connected to the position that represents the pins in the routing grid.