How to use isStaticElasticCGRA feature

[sampsu]

Hello,
Thanks for your public CGRA mapper repository.
I am trying to use your git repo for elastic CGRA (isStaticElasticCGRA parameter=true).
Is static-elastic-CGRA feature still supported with the latest commit? I see that your HPCA version works for a simple kernel, but the same kernel does not get mapped successfully with the latest branch.

I have a few naive questions, if you would be kind enough to shed some light on.

1. Should the CGRA size be larger than (or equal to) the number-of-instructions in DFG for static-elastic-mapper?
2. What is necessary for the default mapper (isStaticElasticCGRA=false) to have "elastic" loads/stores?

Thank you,
Sam

[tancheng]

Hi Sampsu,
I have not updated the elastic feature for years... Now it is more focusing on dynamic CGRA, which allows the operation can be changed in each cycle.
The "latest" elastic mapper is maintained in Cornell but it seems it is not open-source. But I will try to look into my version to see how to make it work with the simplest kernel.
To answer your questions:

• Yes. For a static CGRA, the CGRA nodes count should be at least the same as the number of DFG nodes. The mapping algortihm is heuristic-based (if I remember correctly). So it is better to provide more CGRA nodes to increase the routing opportunities and guarantee a valid mapping.
• The elastic feature is DVFS-related. I am not an expert in that field but I guess we don't need to do anything for elastic load/store as they are treated as basic operations that are nothing different from add/mul from the perspective of a compiler.

[sampsu]

Thank you for your kind reply, Tancheng.
When you say that load/store operations are treated as basic operations, does it mean that the schedule generated by dynamic CGRA mapper tolerates flexible memory latency?

[tancheng]

I think the schedule generated by the static/elastic CGRA mapper could tolerate flexible memory latency. The dynamic CGRA must have fixed per-cycle configurations, which cannot change during the execution and does not tolerate flexible latency (e.g., computation latency and memory latency).

[sampsu]

Then dynamic+tolerating flexible memory latency would be a better feature probably compared to static+flexible memory latency. Thanks again for the clarifications.

[tancheng]

Hi @sampsu, I have enabled static mapping and it should work by renaming the param_static.json to param.json.
Based on your last comment, I don't think you need it anymore, but I still make it runnable :)
What you suggested is correct. There are different types of coarse-grained spatial accelerators with specific tradeoffs between compiler implementation and hardware cost/engineering effort.
But please keep in mind that the elastic feature proposed in HPCA'21 requires manipulating the clock trees (yes, it requires multiple clock trees) to enable DVFS, which is a plus or orthogonal to dynamic/static CGRAs.

[sampsu]

Great. This is very helpful.