Routing Congestion Too High With SRAMs
Closed this issue · 3 comments
When hardening the SOC macros, OpenRoad fails the flow saying that congestion is too high (ex. 4a9dd15). By dramatically decreasing the number of SRAMs (max 3 so far), I am able to get the flow past routing without flagging congestion failures (ex. 289de7c). 3 macros is not really enough to get the design working as desired, and finding placement and configurations to increase the number of SRAM blocks possible is very desirable.
When an SRAM macro is placed at 0 rotation, pins lay on the following sides:
- N: dout1[31:0], addr1[1:0], clk
- E: addr1[6:2]
- S: addr0[0], mask[0:3], din0[0:31], dout0[0:31], addr1 [8:7]
- W: addr0[8:1], cs, we0
If SRAM blocks are tiled in the same orientation (or with 180 degree rotations) matching the common signals between the blocks such as address, clock, din0, we, etc, a lot of extra routing congestion would be created for each block to route common signals around to the other side or flip ordering.
In manual_macro_place.py, there are values that appear to correspond to mirroring, though I can't find any documentation on their use. I am attempting to flip a single macro in 492d6a7.
LEF2OA_MAP = {
"N": "R0",
"S": "R180",
"W": "R90",
"E": "R270",
"FN": "MY", # Mirror Y ?
"FS": "MX", # Mirror X ?
"FW": "MXR90", # Mirror Y + rotate 90 ?
"FE": "MYR90", # Mirror X + rotate 90 ?
}
By mirroring alternating SRAM blocks and placing into two mirrored columns, I was able to get 12 SRAM blocks to complete routing and reach the signoff stage in 1938991. By looking at the density of the chip at this stage, I am doubtful that many more SRAMs can be placed.
