[Testing] Add test cases for issues related to data movement

[hecmay]

Issues on deprecated features

• [x] Removed metaclass in devices.py. Should fix #339
• [x] HCL runtime switched from shared memory to JSON. Should fix #241 and fix #290

Issues already fixed in #332

• [x] Duplicate data movement commands will be ignored automatically. Should fix #270

Issues/requests for new features

• [x] Added config attribute in tool class. Users can parameterize EDA tool options. Should fix #326
• [x] Added tests for dataflow() primitive. Should fix #317
• [x] Added tests for burst memory loading/storing to/from on-chip buffers. Should fix #277
• [x] Added FIFO access pattern checking logic. Should fix #288 and fix #284

[hecmay]

The range of max_id in digitrec is not known until runtime, so the ExtractIndices is not able to restore the multi-dimensional indices we want even if the Mod expression is simplified...

Here is the index I got after updating Simplify @seanlatias

knn_mat_on_device[(((max_id - (max_id % (ap_uint<49>)3)) + x1][(max_id % (ap_uint<49>)3)]

[hecmay]

I was mistaken... this PR did not introduce the fix for #194 and issue #261. I just removed that from the description. Will add that part in a separate PR.

I added test cases for #276 and #270.

[hecmay]

I did not find a good way to fix the #276. Simply returning mod_op->a will cause an issue for the loop fusion test case. The originally expected output for the loop fusion test case is

for (x_fused, 0, 100)
  B[x_fused/10][x_fused%10] = ...

But if we over-simplify the mod operator, the generated output would be

for (x_fused, 0, 100)
  B[0][x_fused] = ...

A workaround to fix #276 (without breaking the fusion test case) is to update the itervar's range map. but I guess maybe we can just leave as it is and fix it when we introduce multi-dim representation in MLIR? @seanlatias

But right now, at least for digitrec and kmeans, we can generated expected multi-dim array.

[seanlatias]

Just leave it then. That's one reason I did not quote #276.