The-OpenROAD-Project / OpenROAD

OpenROAD's unified application implementing an RTL-to-GDS Flow. Documentation at https://openroad.readthedocs.io/en/latest/
https://theopenroadproject.org/
BSD 3-Clause "New" or "Revised" License
1.51k stars 528 forks source link

AntennaRepair inserts diodes within blockage around hard macros #1868

Closed angl-dev closed 1 year ago

angl-dev commented 2 years ago

Problem

Function AntennaRepair::insertDiode places antenna-fixing diodes and avoids overlapping with existing insts. If a "legal" location is found, the inserted diode is placed in "FIRM" status (src/grt/src/AntennaRepair.cpp:299) and therefore will not be legalized by detailed placement. However, if the existing insts are hard macros, this function does not check for the blockages around the macros. As a result, the diodes may be inserted next to a hard macro where no power straps are available due to the blockage. Such diodes will fail placement checking later during the antenna fix.

Temporary Solution

Comment out src/grt/src/AntennaRepair.cpp:297-300, 302 . All inserted diodes are thus always legalized by the detailed placer. I have a fork that implements this fix, but I assume this is not the ideal solution, so I did not create a PR.

Context

I was working on a MPW-5 project (now carried over to MPW-6) which contains a 2-level hierarchical user design (not counting the caravel wrapper). In my openlane config.tcl for the top-level user design, I tried different antenna fixing strategies and none worked well. Strategy 3 using the FastRoute antenna fixer seems the most promising and reasonable strategy, yet it always fails and reports illegal placements during antenna fixing. The temporary solution worked for me, although there are still a few hundreds of violations left at the end of the flow (other strategies either end up with thousands of violations, or insert a ton of diodes so the design is not routable).

maliberty commented 2 years ago

Please provide a test case demonstrating the issue.

angl-dev commented 2 years ago

Hi @maliberty, sure I would be happy to create a reproducable test case. I am unsure what to include though. Could you give me some instructions on how to create a reproducable test case?

In addition, our repo is available publicly (https://github.com/getziadz/caravel_mpw5_prga). The problem can be reproduced by running make prga at the root of the repo.

maliberty commented 2 years ago

See https://github.com/The-OpenROAD-Project/OpenLane/blob/master/docs/source/using_or_issue.md

angl-dev commented 2 years ago

Great! Here is the auto-generated reproducible package. Let me know if you need any other files.

openroad_issue_reproducible.tar.gz

maliberty commented 2 years ago

The rows are cut around the macro according to the halo so there are no legal placement sites inside the halo. I can't see any instances of an antenna diode inside the halo. Would you provide an example of what you mean in your test case.

maliberty commented 2 years ago

Diodes in yellow: image

maliberty commented 2 years ago

The diode must in a row to be marked FIRM:

  legally_placed = legally_placed && diodeInRow(inst_rect);
...
  if (core_area.contains(inst_rect) && !sink_inst->getMaster()->isBlock()
      && legally_placed) {
    antenna_inst->setPlacementStatus(odb::dbPlacementStatus::FIRM);
angl-dev commented 2 years ago

Hi @maliberty thanks for looking into this. The error I got was the following:

[INFO GRT-0012] Antenna violations: 2181
[WARNING GRT-0054] Placement of diode ANTENNA_138 will be legalized by detailed placement.
...
[INFO GRT-0015] 2912 diodes inserted.
[WARNING DPL-0004] Placed in rows check failed (2).
[ERROR DPL-0033] detailed placement checks failed.

Due to the error I did not get the def with the inserted diodes, so I cannot verify if the diodes are indeed placed in the halo. Is there any way to get the def with the illegal diodes?

One thing to note is that I was using commit 8d53e9b018dec98fa63e907ddeb6c5406f035361 since that is what MPW-6 uses in their docker image.

maliberty commented 2 years ago

8d53e9b018dec98fa63e907ddeb6c5406f035361 is from Feb 17. When I run with the current OR head I don't see the above errors. Why is MPW-6 so far behind? @donn

maliberty commented 2 years ago

I see the mpw-6b tag points at a slightly later version.

vijayank88 commented 1 year ago

@angl-dev Please test with latest commit, re-open an issue if problem repeats means with reproducible test case.