ICCAD04 -use_cugr [ERROR GRT-0286] Failed to determine parent layer index on net lx1/ejtag/CORE_CLOCK_N

[stefanottili]

Describe the bug

default global_route finished, global_route -use_cugr ERROR's out

[WARNING GRT-0281] Net SYSCLK has a large fanout of 6956 terminals.
design statistics
lib DBU:             1000
die region (in DBU): [x: (0, 959600), y: (0, 959600)]
num of nets :        34032
num of special nets: 0
gcell grid:          159 x 159 x 6
stage 1: pattern routing
[ERROR GRT-0286] Failed to determine parent layer index on net lx1/ejtag/CORE_CLOCK_N.
[ERROR GUI-0070] GRT-0286

Expected Behavior

global_route -use_cugr should work.
global_route without -use_cugr finishes and detail routes.

Environment

MacOS, Tue Mar 10
git a44cc9d6e542308da1947f99b3b5e071f854f3ab

OpenROAD bazel-nostamp 
Features included (+) or not (-): -GPU +GUI -Python

To Reproduce

get lef/def from #5557

openroad -gui -threads max risc2.or

read_lef lef/risc2.lef.gz
#read_def def/risc2.def.gz
#read_def def/risc2.noram.def.gz
read_def def/risc2.first_quadrant.noram.def.gz

#set_routing_layers -signal metal1-metal5
set_global_routing_layer_adjustment * 0.5

#macro_placement

#global_placement_debug -generate_images
#global_placement -density 0.95
global_placement -density 0.8
#global_placement

#set_debug_level DPL legalize 1
#dpl::detailed_placement_debug
detailed_placement
#global_route -allow_congestion -verbose
global_route -use_cugr
detailed_route -drc_report_iter_step 1
#write_db routed.db.gz

risc2.or.gz

Relevant log output

Screenshots

No response

Additional Context

No response

[stefanottili]

Please use the first_quadrant.noram.def, the noram.def.gz fails during dpl

risc2.lef.gz
risc2.first_quadrant.noram.def.gz

[Divinesoumyadip]

Hi @eder-matheus ,I see you've self-assigned this bug, but would you mind if I investigated it locally as a learning exercise? If I find the root cause of the GRT-0286 error, I'd be happy to share my findings or submit a PR if you're busy with other tasks. Thanks

[eder-matheus]

Hi @eder-matheus ,I see you've self-assigned this bug, but would you mind if I investigated it locally as a learning exercise? If I find the root cause of the GRT-0286 error, I'd be happy to share my findings or submit a PR if you're busy with other tasks. Thanks

Sure! Will free to work on it.

[Divinesoumyadip]

Hi @eder-matheus ,I see you've self-assigned this bug, but would you mind if I investigated it locally as a learning exercise? If I find the root cause of the GRT-0286 error, I'd be happy to share my findings or submit a PR if you're busy with other tasks. Thanks

Sure! Will free to work on it.

Hi @eder-matheus ,

I've finished investigating the root cause of this crash.

The Signal 6 (SIGABRT) crash was triggered by an unchecked vector access in GridGraph::rangeSearchRows.When design elements such as pins or ports are located outside the physical coordinates of the pre-computed routing grid, the projection logic may compute an index that exceeds the bounds of the gridlines_ vector. This results in an out-of-range access, which triggers the C++ assertion failure __n < this->size(), causing the process to abort and produce a core dump.To address this issue, I implemented boundary clamping in GridGraph.cpp. The projection indices are now constrained using std::min and std::max to ensure they remain within the valid grid range [0, size - 1].This prevents out-of-bounds vector access and guarantees memory-safe grid lookups.
With this fix, the router no longer crashes when encountering geometric mismatches. Instead, the engine continues execution and reports the handled diagnostic GRT-0286, which identifies the specific net responsible for the issue. This allows users to diagnose and correct the underlying design problem.

The fix has been submitted here:
[https://github.com//pull/9739]

Thanks!

[Divinesoumyadip]

Hi @eder-matheus ,

I have finalized the fix in PR #9739.
Implemented boundary clamping in GridGraph::rangeSearchRows to prevent out-of-bounds access.Added guards for empty gridlines and ensured non-negative index returns.Fixed all CI formatting and DCO requirements.

Also I've verified the fix locally with the risc2 design provided. The tool now handles the geometric mismatch gracefully and prints the GRT-0286 diagnostic instead of triggering a SIGABRT core dump.

[stefanottili]

The tool now handles the geometric mismatch gracefully and prints the GRT-0286 diagnostic instead of triggering a SIGABRT core dump.
[ERROR GRT-0286] Failed to determine parent layer index on net lx1/ejtag/CORE_CLOCK_N.

What is the "geometric mismatch" ? It's a net connecting two stdcell pins inside the placement area.
This particular ERROR doesn't hint at what's going wrong here, should this be improved ?

Instead of fixing the internal cugr out-of-bounds access:
Is there anything actionably wrong with the GCELL's or TRACK's in risc2.first_quadrant.noram.def.gz that OR should warn about ?
I've moved all floorplan coordinates from the original def because that was centered and dpl can't handle that.

[Divinesoumyadip]

The tool now handles the geometric mismatch gracefully and prints the GRT-0286 diagnostic instead of triggering a SIGABRT core dump.
[ERROR GRT-0286] Failed to determine parent layer index on net lx1/ejtag/CORE_CLOCK_N.

What is the "geometric mismatch" ? It's a net connecting two stdcell pins inside the placement area. This particular ERROR doesn't hint at what's going wrong here, should this be improved ?

Instead of fixing the internal cugr out-of-bounds access: Is there anything actionably wrong with the GCELL's or TRACK's in risc2.first_quadrant.noram.def.gz that OR should warn about ? I've moved all floorplan coordinates from the original def because that was centered and dpl can't handle that.

Hi @stefanottili , thanks for the follow-up.
To clarify the 'geometric mismatch' so, In CUGR, the routing engine pre-discretizes the chip area into a GCell Grid. A net's terminals (pins/ports) must be successfully mapped to a specific GCell for the router to understand the connectivity.
The GRT-0286 error occurs when a pin's coordinate (X, Y) resides outside the maximum bounds of this pre-computed grid. This can happen even if the pin is technically inside the 'placement area' if the GCell grid definition in the DEF does not extend far enough to cover the outlier pins.A pin sits exactly on the boundary, and a rounding error during projection pushes it to index = size, triggering the out-of-bounds access.Pins are placed on coordinates that aren't properly aligned with the defined routing tracks.

CUGR’s current implementation treats this as a 'fatal' mapping failure without echoing the offending coordinates. As part of my GSoC proposal for Incremental CUGR, I am specifically looking at improving these diagnostics. My PR #9739 stops the crash (SIGABRT), but the next logical step is to improve GRT-0286 to report the exact (x, y) and layer of the failed pin. This would make it immediately actionable for the user.Also, check the GCELL GRID lines in your DEF file. Ensure that the grid fully encompasses the bounding box of the CORE_CLOCK_N net's pins. If the pins are sitting on a boundary, try shifting them inward by 1 DBU to see if the error clears.

I’m happy to look at the DEF file if you’d like me to pinpoint the exact coordinate mismatch .

[stefanottili]

[ERROR GRT-0286] Failed to determine parent layer index on net lx1/ejtag/CORE_CLOCK_N.
It's a net connecting two stdcell pins inside the placement area.

No need to improve the error message, it’s an internal bug, there is nothing actionable for the user.