StanfordAHA/Halide-to-Hardware

Generated Designs are Huge

hofstee opened this issue · 6 comments

A lot of the designs coming out of the master branch are extremely large, the resulting bitstreams have around the order of 10x more configuration that prior to whatever codegen changed happened. It seems like a lot of the extra things are unnecessary control logic that doesn't need to be synthesized, is there some set of optimization passes that can be run to shrink the resulting designs?

old.txt
new.txt

@hofstee Ill take a look. My guess is that some counters are not getting constant folded away.

@hofstee also what app is the one that included the files for? And which other apps are way bigger?

This is conv_1_2 after running @joyliu37's BufferMapping. I used to be able to map conv_3_3 or pointwise onto a small CGRA but that's no longer the case. I didn't look at other apps besides those 3.

Thats odd. I just ran the apps on master (commit 0109fc8) and the pre buffer mapping json looks the same as always.

Even pointwise is too large to map? I just re-generated it using:

 ./test/scripts/run_app.sh pointwise

and DesignTop only contains one multiplier and one constant.

Kuree commented

In the current hardware design counters are very expensive so my guess this is where the issue coming from.

@jeffsetter and I looked at the mapped files from @norabarlow and the new ones are using linebuffer mode, instead of unified buffer. Since unified buffer mode offers extra counters, I believe we should use that instead. However, this issue could be caused by buffer mapping, not the current H2H, since the diff is before the mapper.

Might be an issue with cleaning up things before they're sent to the mapper, closing for now, will reopen if it becomes apparent again.