DRT not converging after 64 iterations #1767
Comments
|
@gkamendje |
|
I have updated the permission. Please try again.
G
…On Thu., Jan. 18, 2024, 01:33 vijayan ***@***.***> wrote:
@gkamendje <https://github.com/gkamendje>
Have you restricted drive access ?
—
Reply to this email directly, view it on GitHub
<#1767 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ANSN5BVDF7OGCQB7WQCJYTLYPDF55AVCNFSM6AAAAABB7OG4W2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJXHE2DMOJTGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
|
The config file is missing |
|
strangely enough the issue script is not putting everything in the tar archive. I have added the following file https://drive.google.com/file/d/129Iw7Lt5ZcEny8rx2vbRk3wjI9IrZAwK/view?usp=sharing that contains the config.mk, the def file used and some other stuff |
|
Also the config file for the platform is missing |
|
@osamahammad21 I have added some platform files here. |
|
The placement of the pins is making it hard for the detailed router to reach them. The pins are of min width and their centers are not aligned with the tracks. is there a reason you're placing them that way? |
|
There is no particular reason why they are like that. The position/size of the pins was given by the DEF file provided by the analog team that owns the other macros the block communicates with. This can easily be changed if that improves the convergence. |
|
The warnings look like this: As you can see, the pin's center is not aligned with the routing track. This results in a Non sufficient metal violation when the net tries to access the pin vertically. I took the liberty of changing all Metal4 pins sizes to 350x350 and it converged after 4 iterations. PA finds a horizontal access point for that pin, but DRT is short on understanding the access point direction. It sees no issue with accessing it vertically which is violating. I am working out a fix for that issue but that shouldn't stop you from modifying pin placement |
|
FWIW, this is a problem commercial routers struggle with too. I had a tapeout last year where this was an issue (analog team gave us a block with many off-grid pins, router couldn't create clean connections). We asked the analog team to align the pins to the routing grid and it did significantly better, but still had errors due to congestion. We then asked them to spread out some of the pins (we had tens of thousands of pins) so they weren't at 100% density, and then the violations finally went away. |
|
@osamahammad21 indeed changing the pin size for M4 pins does lead to a very quick convergence. However, changing the size of all pins M1 to M4 to 350x350 (which removes the all the @rovinski any idea why |
|
|
The M2 access is not strange because the center of the M2 pin is not aligned with the M2 track. If the net tries to access it directly vertically, it will get a Non sufficient metal violation. So it tries to access it horizontally by doing this weird hock shape. I am working on a fix that makes such pin access a bit smoother. As for the remaining violation, it went under my nose. One of the cells is placed very close to a PDN via. It makes it impossible for the router to access this cell pin without creating a spacing violation with the M2 PDN via enclosure. There is an option in the detailed_route command to ignore such violations and remove the violating PDN vias at the end of routing, do you think this could be a good solution or you don't want to lose any of the PDN vias? |
Getting rid of the violating PDN via could certainly be an option to explore. Could you please remind me how to activate this option? |
|
This is purely placement luck. Matt pointed out that this is should be an issue in the placer to use a site so close to a PDN via, which makes hard for the router to reach the placed cell. but again, this a design with a 100% utilization, so I am not sure if we're asking too much from the placer. |
|
After discussion, we found that removing pdn vias is a bit risky and going to lead in IR drop. you said when you started the issue that the DRC can be easily fixed, Could you specify how you could manually fix it. |
|
In our use case, the GDS file is imported into Virtuoso by the analog Team.
The violating nets are manually re-routed within Virtuoso.
…On Sun., Feb. 11, 2024, 15:02 Osama Hammad ***@***.***> wrote:
After discussion, we found that removing pdn vias is a bit risky and going
to lead in IR drop. you said when you started the issue that the DRC can be
easily fixed, Could you specify how you could manually fix it.
Screenshot.from.2024-01-23.19-33-46.png (view on web)
<https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts/assets/56893454/c87b99d6-0adc-4d33-a96e-1021123a5fc1>
—
Reply to this email directly, view it on GitHub
<#1767 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ANSN5BTNULZHQBYMKQQHIHLYTDFNRAVCNFSM6AAAAABB7OG4W2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZXG43DGMJUGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***
com>
|
|
I'm interested in how these "easily fixed manually" violations are resolved in Virtuoso. What do you change to make these legal? Are you moving the cells? Changing the pdn? Neither seems trivial and I'm wondering if there is something easy we aren't seeing. |
|
@maliberty feedback from analog team is that they are essentially moving cells around. Agreed that this might not be "trivial" at all! I had certainly misunderstood the statement of the analog team when they said that they had been able to "easily" fix the issue. |
|
Better handling of the interaction between placement and pdn vias is an area for improvement. It isn't 'easy' but we have it on the list. The placement engine needs some 'mini-drc/pin-access' check to look for pins that are being blocked. |
Subject
[Stage]: Detail Router.
Describe the bug
After approximately 5 iterations, the number of violations is down to 1 or two (spacing violations on M2). However, although these violations can be easily fixed manually, DRT most of the time runs until the 64th iteration and most of the time fails to fix the single violation remaining. The behavior has been reproduced on Ubuntu 22 as well as on CentOS7 machines. Sometime however, DRT will run until the ~50th iteration or so and fix the violation.
Expected Behavior
DRT should be able to fix those violations (specially when thy can be easily fixed manually)
Environment
To Reproduce
Download and untar the following file https://drive.google.com/file/d/125sPK0yOeynKy30qLSbE2zCuWgajuA7S/view?usp=drive_link and run
make clean_all finishRelevant log output
INFO DRT-0195] Start 64th optimization iteration. Completing 10% with 1 violations. elapsed time = 00:00:00, memory = 960.48 (MB). Completing 20% with 1 violations. elapsed time = 00:00:00, memory = 960.48 (MB). Completing 30% with 1 violations. elapsed time = 00:00:01, memory = 960.48 (MB). Completing 40% with 1 violations. elapsed time = 00:00:01, memory = 960.48 (MB). Completing 50% with 1 violations. elapsed time = 00:00:01, memory = 960.48 (MB). Completing 60% with 1 violations. elapsed time = 00:00:01, memory = 960.48 (MB). Completing 70% with 1 violations. elapsed time = 00:00:01, memory = 960.48 (MB). Completing 80% with 1 violations. elapsed time = 00:00:01, memory = 960.48 (MB). Completing 90% with 1 violations. elapsed time = 00:00:01, memory = 960.48 (MB). Completing 100% with 1 violations. elapsed time = 00:00:01, memory = 960.48 (MB). [INFO DRT-0199] Number of violations = 1. Viol/Layer METAL2 SpacingTableTw 1The text was updated successfully, but these errors were encountered: