[INFO DRT-1000] Pin u_sram_2kb/din0[15] not in any guide. Attempting to patch guides to cover (at least part of) the pin.

[dineshannayya]

Is this information is saying any specific issue here ? I see u_sram_2kb/din0[15] connected to mem_din_b[15] and this signal information is available inside guide file : 16-fastroute.guide

openroad version: OpenROAD v2.0-1285-g92dd19146

Attached the setup exp3.tar.gz

Run command: run_cmd

In the MPW-3 Efabless openroad version: OpenROAD 1 fb8ae93b6c7a5eb0e6fac83360a8a48d76c41885 This reported as ERROR below:

[WARNING DRT-0215] Pin u_sram_2kb/din0[15] not covered by guide.
[WARNING DRT-0215] Pin u_sram_2kb/din0[15] not covered by guide.
[WARNING DRT-0225] mem_din_b\[15\] 2 pin not visited, fall back to feedthrough mode.
[WARNING DRT-0224] mem_din_b\[15\] 2 pin not visited, number of guides = 7.
[ERROR DRT-0218] Guide is not connected to design.
Error: or_droute.tcl, 34 DRT-0218
[ERROR]: during executing: "openroad -exit /openLANE_flow/scripts/openroad/or_droute.tcl |& tee >&@stdout /project/openlane/user_project_wrapper/runs/13-10_09-31/logs/routing/18-tritonRoute.log"

[maliberty]

This indicates that grt produced a bad guide for the net that drt won't accept. I've assigned it to @eder-matheus to look at in grt.

[eder-matheus]

@dineshannayya I've run the attached testcase on a CentOS 7 machine and I see the [INFO DRT-1000] Pin u_sram_2kb/din0[15] not in any guide. Attempting to patch guides to cover (at least part of) the pin. message, but it is not failing with the latest OpenROAD. Could you try it with the latest version of OpenROAD?

[dineshannayya]

@eder-matheus yes, in the latest version OPENROAD I see this as only [INFO] .. Question is what is the impact of this info ?
Design wise I don't see any special on u_sram_2kb/din0[15] over rest of the u_sram_2kb/din0 32 bits ? Why tool showing info only on [15] bit ?

I have used same SRAM memory in one more OPLANE project and even in older version of OPENROAD, I don't find issue their?

[dralabeing]

This sounds like an Openlane bug as well based on the initial version reported on MPW-3. @maliberty @eder-matheus Should this also be submitted against OpenLane to fix against that OR version too since that is the latest shuttle version?

[eder-matheus]

@eder-matheus yes, in the latest version OPENROAD I see this as only [INFO] .. Question is what is the impact of this info ? Design wise I don't see any special on u_sram_2kb/din0[15] over rest of the u_sram_2kb/din0 32 bits ? Why tool showing info only on [15] bit ?

I have used same SRAM memory in one more OPLANE project and even in older version of OPENROAD, I don't find issue their?

@dineshannayya I'm not sure about what this message from the detailed router means, but my guess is the route guide is partially covering this pin of the macro and the detailed router only completes the coverage of the pin. Also, since the routing ends with no DRCs, I think this message doesn't have a great impact on the final result. @maliberty does it make sense?

[eder-matheus]

This sounds like an Openlane bug as well based on the initial version reported on MPW-3. @maliberty @eder-matheus Should this also be submitted against OpenLane to fix against that OR version too since that is the latest shuttle version?

@dralabeing: Do you mean they have to update their OpenROAD version with the latest OR to avoid the drt error? I think it makes sense.

[maliberty]

@eder-matheus it is the same issue with grt producing a guide that doesn't cover the pin but we added code recently to drt to try to repair the problem rather than fail (expanding the guide). It is still worth seeing why grt produces the guide that doesn't cover the pin.

@dralabeing yes they should try to move to a later version with the drt fix.

[eder-matheus]

@maliberty I've revisited this issue and found out why we have the DRT warnings for the route guides. The pin that has the warning is not aligned with a routing track, as shown in the figure below:

In such cases, GRT looks for the nearest track and uses the track coordinate (in this case, the X coordinate) to assign the pin to a position in the global routing grid. This track is on the grid position adjacent to the pin grid position. The figure below shows that the guide boundary is aligned with the track:

Running pin_access before GRT solves the warning because GRT will use the AP of the pin to compute the on-grid position.

[maliberty]

Couldn't you have the same issue with pin_access? It seems it is more about snapping than aps.

[eder-matheus]

Couldn't you have the same issue with pin_access? It seems it is more about snapping than aps.

No, because when we use the pin_access results grt will not snap the pin position.

[maliberty]

Perhaps we should not snap in the non-pa case if doing so would move the point onto the edge of the shape.