You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 20, 2024. It is now read-only.
I've noticed that a few FIRRTL transforms take a good amount of time to run (depending on the design, of course). One of the most expensive ones is consistently DedupModules, which runs before High FIRRTL is emitted.
Now, since GenerateTopAndHarness run the FIRRTL compiler twice (once for the top, once for the harness), I was hoping that the harness run would be much quicker, since there's not a lot of complexity to the harness circuit compared to most top designs. However, it looks like DedupModules takes about the same amount of time for both runs. It appears that the root cause of this is that ConvertToExtMod is running afterDedupModules, rather than before. Thus, all of the top circuit components are still being de-duplicated, even though they won't be emitted by the harness invocation of the FIRRTL compiler.
Looking at the pre-reqs for ConvertToExtMod, it takes in High FIRRTL, which means this will run after DedupModules. Is there any reason we can't move ConvertToExtMod earlier in the transform order? Is there any feature of High FIRRTL that it depends on? I'm happy to submit a PR once we come to a solution.
Normally, `DedupModules` spends a lot of time working on modules that
this pass removes. Having this run before `DedupModules` significantly
speeds up FIRRTL compile time for the Harness block in Chipyard.
Resolvesucb-bar#119
I've noticed that a few FIRRTL transforms take a good amount of time to run (depending on the design, of course). One of the most expensive ones is consistently
DedupModules
, which runs before High FIRRTL is emitted.Now, since
GenerateTopAndHarness
run the FIRRTL compiler twice (once for thetop
, once for theharness
), I was hoping that theharness
run would be much quicker, since there's not a lot of complexity to theharness
circuit compared to mosttop
designs. However, it looks likeDedupModules
takes about the same amount of time for both runs. It appears that the root cause of this is thatConvertToExtMod
is running afterDedupModules
, rather than before. Thus, all of thetop
circuit components are still being de-duplicated, even though they won't be emitted by theharness
invocation of the FIRRTL compiler.Looking at the pre-reqs for
ConvertToExtMod
, it takes in High FIRRTL, which means this will run afterDedupModules
. Is there any reason we can't moveConvertToExtMod
earlier in the transform order? Is there any feature of High FIRRTL that it depends on? I'm happy to submit a PR once we come to a solution.FWIW, I ran a quick experiment with this change:
This drastically sped up
DedupModules
for me.The text was updated successfully, but these errors were encountered: