How do I trace global routing congestion to net?

[oharboe]

How can I trace global routing congestion to the net that is causing the problem?

I have routing congestion on top of my macro, but I'm struggling to find out which net is causing the problem.

I think the problem is that some pin is on the wrong side of the macro and that a net is being routed around the macro.

Clicking on the routing congestion doesn't leave me with much of a clue to track down the net that is causing the problem:

[maliberty]

Short term I would select all nets and see if you can spot the one crossing the macro. Then go to one end and see what pin it is coming from

@eder-matheus @luis201420 can we add the set of nets in the gcell to the congestion marker?

[oharboe]

I see. Sounds like some nice features there...

[oharboe]

I think in my case(testing with a 64 bit datapath for mock-array-big), I should be able to identify the pathology that I see above by selecting all nets in make gui_place and then see that nets are not crisscrossing where they shouldn't...

I believe the problem I am having is that a horizontal/vertical route has a buffer or hold cell place somewhere else than between the macros. This causes a net to be sent out of the mock-array-big to a hold/buffer cell outside of the array instead of just a vertical/horizontal route.

The pathology is either too little space to place the buffer between the macros or something to do with large blobs of hold cells due to misconfigured .sdc file for the array configuration I'm working with.

[oharboe]

Hmmm... that almost works.... make gui_place and select a bunch of nets I know the name of, looks good horizontal/vertical routes:

However, selecting *, gives me solid yellow.

The rays is the clock, so that's healthy:

But the solid yellow is hard to make much of:

Using *ces*, I get:

So what is all that solid yellow stuff? Power? How do I exclude power nets from ctrl-f?

[oharboe]

Hmm... I can't guess all the names from the verilog code, because some of these nets get new computer generated names when buffers are inserted. These new net names don't resemble the original Verilog net names. io_insDown here gets the name net123 after the buffer.

I think I saw a pull request with "select all buffertrees". Perhaps that could be useful during make gui_place to see that there aren't any pathological routes after placement.

[oharboe]

Short term I would select all nets and see if you can spot the one crossing the macro. Then go to one end and see what pin it is coming from

@eder-matheus @luis201420 can we add the set of nets in the gcell to the congestion marker?

I filed: #3422

[oharboe]

Some tips and some ideas for new features to improve this experience, so I think this is answered.