About the runtime of archived TritonRoute and TritonRoute in OpenROAD

[gilgamsh]

I have tried both of them and running the same ispd19 benchmark. I have noticed that the runtime of TritonRoute in OpenROAD is quite larger than that in archived TritonRoute.
The specific data is
In ispd19_testcase1 , with single thread
TritonRoute in OpenROAD : Elapsed Time: 643.091s
archived TritonRoute. :Elapsed Time: 236.032s

I have noticed that, in TritonRoute in OpenROAD ,the pin analysis time and design rule checking time increase dramatically.
pin analysis time in OpenROAD, about 300s, pin analysis time in archived TritonRoute, about 10s.
Is there a normal situation? Maybe there is something wrong about my scripts.

I use the openroad scripts like below

read_lef ../benchmarks//ispd2019/ispd19_test1/ispd19_test1.input.lef
read_def ../benchmarks//ispd2019/ispd19_test1/ispd19_test1.input.def
read_guides ../benchmarks//ispd2019/ispd19_test1/ispd19_test1.guide
detailed_route
write_def ispd19_test1.solution.def
exit

[gilgamsh]

another question, If i want to learn the code of TritonRoute-WXL: The Open Source Router with Integrated DRC Engine. Can i use the archived TritonRoute, thinking it implemented the functions mentioned in this paper(not including the gr)?

[maliberty]

Have you enabled a similar number of threads in both runs? In OR use set_thread_count <n>

The archived version should match the paper but any further improvements will not be present.

[gilgamsh]

I use openroad -threads 4 cmd_file, Is that OK?

[maliberty]

That should be fine. Are you using a similar number of threads in standalone TR?

[gilgamsh]

yes. I tested them with single thread.

[antonblanchard]

Are you running a recent version of OpenROAD with the following fix: 0cf1996

That issue isn't in the original TritonRoute source, and can cause significantly more runtime in the pin access code.

[gilgamsh]

yes, i use the latest version of OR

[antonblanchard]

@vijayank88 did you mean to close this? I just checked, and we are spending significantly more time in genInstRowPattern vs TritonRoute.

[vijayank88]

@antonblanchard
I was closing only answered discussion.
Maybe by mistake closed this. Sorry about that.
But we can Re-open and continue the same.

[antonblanchard]

Most of the problem appears to be 5fada4c. Start up time for ispd19_test1 goes from 17 seconds to 280 seconds. I haven't got far enough to understand if all that overhead is required. FYI @maliberty @osamahammad21

[maliberty]

Its not obvious to me how that change triggers the issue but its @osamahammad21 change so he might have an idea.

[antonblanchard]

I'm not sure why, but the problem is caused by filtering out other instances when generating our preferred access points:

-  hasVio = !genPatterns_gc({prevInst, currInst}, objs, Edge);
+  // hasVio = !genPatterns_gc({prevInst, currInst}, objs, Edge);
+  hasVio = !genPatterns_gc({}, objs, Edge);

I would have expected this to take less time, unless the act of filtering out other instances is taking lots of time.

[oharboe]

@gilgamsh It would be interesting to see a profile of both cases to see where the difference in time is. That should tell us something of the nature of the difference to corroborate the suspicions on what differences in code that can cause this.

[maliberty]

Note that a fair number of enhancements and bug fixes have gone into the OR version. It is possible you are not observing equivalent results.