How do I figure out valid macro coordinates for manual placement?

[oharboe]

I'm trying to find out valid coordinates to put macros onto. The pins of the macros must align on the routing grid.

From ASAP 7 LEF files, I see that pins are on M4 and M5 layer. From make_tracks.tcl, I see offsets and pitches.

From that information, I should be able to come up with some formulae of valid macro positions....

I just seem to be unable to connect the dots here to what the formulae should be:

M4 is horizontal pins and M5 is vertical pins (or vice versa, I could see in the GUI, but I don't know how to tell from the LEF file):

The pins are from a macro, so I know the pin coordinates below are correct:

  PIN foo[50]
    DIRECTION INPUT ;
    USE SIGNAL ;
    PORT
      LAYER M4 ;
        RECT  144.818 86.208 145.152 86.232 ;
    END
  END foo[50]

  PIN bar
    DIRECTION INPUT ;
    USE SIGNAL ;
    PORT
      LAYER M5 ;
        RECT  101.76 144.818 101.784 145.152 ;
    END
  END bar

from make_tracks.tcl:

make_tracks M4  -x_offset [expr 0.009 * $multiplier] -x_pitch [expr 0.036 * $multiplier] -y_offset [expr 0.012 * $multiplier] -y_pitch [expr 0.048 * $multiplier]
make_tracks M5  -x_offset [expr 0.012 * $multiplier] -x_pitch [expr 0.048 * $multiplier] -y_offset [expr 0.012 * $multiplier] -y_pitch [expr 0.048 * $multiplier]

[yupferris]

@maliberty mentioned in our discussion yesterday that the routing grid is defined in the tech lef for the PDK. For ASAP7 we have to look at the generated tech lef in ORFS which should be OpenROAD-flow-scripts/flow/platforms/asap7/lef/asap7_tech_1x_201209.lef:

LAYER M4
  TYPE ROUTING ;
  DIRECTION HORIZONTAL ;
 PITCH 0.048 ;
 WIDTH 0.024 ;
 SPACING 0.024 ;

 OFFSET 0.003 ;

 AREA 0.008 ;

 PROPERTY LEF58_SPACING "
 SPACING 0.024 ENDOFLINE 0.025 WITHIN 0.04 ENDTOEND 0.04 ; " ;

 PROPERTY LEF58_WIDTHTABLE
 " WIDTHTABLE 0.024 0.12 0.216 0.312 0.408 ; " ;

 PROPERTY LEF58_CORNERSPACING "
 CORNERSPACING CONVEXCORNER CORNERONLY 0.048
 WIDTH 0.0 SPACING 0.04 ;
 " ;

 PROPERTY LEF58_EOLKEEPOUT "
 EOLKEEPOUT 0.025 EXTENSION 0.048 0.02425 0.048 CORNERONLY ;
 " ;

  # spacing table is required for the rule that has wide metal requires a 72nm (288 scaled)
  # spacing between wide and minimum metals 

  SPACINGTABLE
 PARALLELRUNLENGTH 0.0
 WIDTH 0.0 0.024
 WIDTH 0.025 0.072 ;

 PROPERTY LEF58_RIGHTWAYONGRIDONLY "
      RIGHTWAYONGRIDONLY ;
 " ;

 PROPERTY LEF58_RECTONLY "
      RECTONLY ;
 " ;

END M4

From this we can indeed see that M4 is horizontal and M5 is vertical (not shown above but the definitions for M5 are below those for M4 in the file). We can also see that the pitch is 0.048 which lines up with the -y_pitch arg in the make_tracks.tcl code above, among other things. However, I'm also a bit confused at how to use this information.

Some specific questions:

• Where does 0.012 for the -y_offset arg in make_tracks.tcl come from? I would have assumed it would be 0.003 from the OFFSET in the tech lef.
• How does offset/pitch relate to macro position? I would assume that the bottom-left of a macro is the origin (0, 0), and that if we respect PITCH and OFFSET from the tech lef above for IO y-positions (eg. my_io_y = OFFSET + some_integer * PITCH) we can then place that macro at a position which ensures those constraints are still respected (eg. my_macro_y = some_integer * PITCH - OFFSET). Is this correct?

"Bonus" question: What's the difference between the 1x and 4x .lef files in the PDK?

[maliberty]

In the LEF you can see the preferred routing direction from:

LAYER M4
  DIRECTION HORIZONTAL ;

LAYER M5
  DIRECTION VERTICAL ;

If you look at M1 you'll see it has an offset of 0 which makes the first track unusable (a wire would be half outside the bounds if that track were used). So in make_tracks it was setup to make the first track usable by using a 1/2 width offset. Similarly the other layers need adjusting. Its mostly a matter of style and either could have been used.

M2 has a track pattern too complex to express in the LEF format so make_tracks.tcl is required in any case.

If you place a macro a (0,0) the tracks should align since they would be built the way way. Moving the macro by a multiple of the pitch should keep it aligned. You would use the m4 pitch vertically and the m5 pitch horizontally.

You can check your work by turning on m4 & m5 visibility in the GUI, turning on the display of the preferred tracks and look at your pins to see that the tracks go through the center.

[yupferris]

If you place a macro a (0,0) the tracks should align since they would be built the way way. Moving the macro by a multiple of the pitch should keep it aligned.

This appears to work great for aligning IOs, but the power stripes don't align. We tried finding a least common denominator between the metal layer pitches and the routing grid pitches (from https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/master/flow/platforms/asap7/openRoad/pdn/grid_strategy-M2-M5-M7.tcl#L20 and the following line) and using that for the macro placement pitch, but the power stripes appear to have an additional offset applied:

Here (showing the output of the floorplan) the vertical stripes (red) and the horizontal stripes (blue) don't align between the macro and the top-level design.

Looking again at https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/blob/master/flow/platforms/asap7/openRoad/pdn/grid_strategy-M2-M5-M7.tcl#L20, there are offset parameters, but these don't seem to be evenly divisible by the routing pitches for the respective layers, which makes it seem like there's actually no correct placement pitch for these macros, unless we use a custom power strategy throughout the hierarchy. Is this what you would recommend, or did I miss something?

Side note, there seems to be a random bit of metal in the middle of the design, any idea what this might be?

[rovinski]

the horizontal stripes (blue) don't align between the macro and the top-level design.

Macro grids are usually not aligned to the top-level grid. Macros often have different power requirements vs. the top-level grid, so it makes sense. If you want to mess with the macro configuration to align the two grids, then you can do so. I believe you would just have to create a new grid pattern and assign it to the macros.

there seems to be a random bit of metal in the middle of the design, any idea what this might be?

It looks like a healing strap. You can see that the left and right vertical stripes are connected all the way up and down, whereas the center vertical stripe is blocked by the macro and isolated. To ensure better power integrity, an additional horizontal connection between these straps is made.

[yupferris]

Ah, ok, thanks for the info. So, I should really only be concerned with placing macros such that the IOs are aligned on the routing grid and that the power grid, instead of aligning with the power grid of the macros, should instead simply be configured to avoid intersecting the macros?

[yupferris]

(I'm also only looking for a first approximation here; ofc there would need to be something more sophisticated to prevent excessive IR drop etc, which I'm ignoring for the time being)

[maliberty]

I think what you have is sufficient until you want to start looking at IR. The impact of the grid on routing resource probably won't change that much unless you find you need a lot more straps.

[maliberty]

Bonus: 1X and 4X can be ignored as OR is only using 1X. The origin is that some academic users may not have the advanced node licenses for proprietary tools required to use a 7nm process. The 4X library makes it appear like a 28nm library by making all dimensions 4X larger as a workaround. Since OR has no licensing 4X is not required.