drt/ta creates disconnected iroutes

[antonblanchard]

Describe the bug

With #2528 applied so we can graph iroutes, we see drt/ta creating iroutes with discontinuities. An example, using the attached test case is clknet_leaf_50_clk. There are a number of breaks in the net, and also two segments that overlap (but do not connect) on the left:

In the end drt resolves these issues, but I wonder if creating better iroutes would help drt do a better job.

Expected Behavior

One connected graph per net.

Environment

os: Fedora Linux 36 (Workstation Edition)
cmake version 3.24.2
gcc (GCC) 12.2.1 20220819 (Red Hat 12.2.1-2)
clang version 14.0.5 (Fedora 14.0.5-1.fc36)

To Reproduce

Test case: ta-issue.tar.gz

Relevant log output

No response

Screenshots

No response

Additional Context

No response

[maliberty]

When I run with your branch and this test case I don't get the same results in the GUI:

the crossing edges in your leftmost circle are not crossing in my run.

[maliberty]

If I show the instances being connected (and the gcell grid) its more apparent what is going on:

The breaks are where an edge ends and a new edge begins within a gcell. As the instances are on different tracks the router will have to change tracks which is what the breaks represent. As the edge in the other direction is local to a single gcell there is no need to create an iroute for it.

[maliberty]

I see the cross appears on the 2nd iteration.

[maliberty]

At iter 2 I see:

I'm not convinced that the crossing matters as it is entirely inside one gcell. It is interesting that the met2 segment extends.

[maliberty]

Is there a negative effect in dr that you observe?

[antonblanchard]

Is there a negative effect in dr that you observe?

Nothing concrete, it was just something that the TA paper didn't go into detail on (it only talks about multiple pins in a gcell). I'm happy to just document this and move on.

[maliberty]

The interesting question to me is does the track assigner consider local nets (ie single gcell) when computing the assignment. Its similar to the question of local nets during congestion calculation in grt.

[antonblanchard]

I looked at a few local nets, and it doesn't appear to be doing the right thing. Looking at net _11533_ (a local 2 pin net) in the above test case:

detailed_route_debug -net _11533_ -ta

We end up with a square of li1 surrounding one of the access points, and nothing else.

[maliberty]

The out.guide only has

_11533_
(
365700 151800 372600 158700 li1
)

so there is nothing for ta to do. The problem is upstream in guide post-processing as the incoming route.guide has

_11533_
(
365700 151800 372600 158700 li1
365700 151800 372600 158700 met1
)

[maliberty]

I would guess the A* search sees the met1 is unneeded and removes it. Probably it needs to be smarter about routing layers.