Differences in CGRAFL expected DFG and CGRA Mapper generated DFG,json
lite-david opened this issue · comments
Hi,
I'm using the https://github.com/tancheng/CGRA-Mapper to map some new kernels to this, but the dfg.json generated has the following field names changed:
opt -> JSON_opt
in -> pre
out -> succ
and the predicate fields removed altogether. The DFG class requires these fields and so the CGRAFL fails as a result. Should I be using a particular version of the cgra-mapper?
Hi,
Both the mapper and the generator (OpenCGRA) have been updated but the integration (i.e., new format of json) has not been implemented. For now, you can use the two tools separately. The mapper for the cycle performance and the OpenCGRA for the HW power/area/timing stats.
I am working on a push-button solution for the end-to-end integration test.
I see, thanks for clarifying. The cycle numbers that the mapper gives is typically for one iteration of the loop that has been mapped to the CGRA right?
No prob. The mapper gives two numbers related to two "cycles". The first cycle number shown at the beginning of the debug info indicates the number of inter-iteration dependencies (i.e., the 0->8->9->10->0 and 7->1->7 in the DFG figure). The cycles shown at the end of the debug info give the exact mapping of the DFG on CGRA. The mapper maps the DFG based on modulo scheduling and the performance is indicated by II. You could say it is one iteration's mapping, but actually, it works in a pipelined fashion, which means the second iteration can start before the first iteration completes. The mapping figure shows II = 4 (repeat every 4 cycles) and the DFG node 7 on cycle 5 holds the first valid result and the DFG node 0 on cycle 5 start the second iteration. Note that the DFG node 7 on cycle 1 does not valid as its inputs are not ready. Let me know if there is anything not clear.
Thanks for the clarification! This is helpful. Closing