Questions about running CGRACL_FIR_demo_test.py

[Siberia-yuan]

Hi, sorry to bother you. I have configured the running environment and run pytest on script CGRACL_FIR_demo_test.py and then I get the following live out result. CL simulation outcome FL simulation outcome source kernel

My question is how can I correspond the final live out result of FL simulation and CL simulation with the variable value of the cpp source kernel code and I do not understand the meaning of outcome tile bits value. Appreciate it a lot if you can help!

[tancheng]

Hi Siberia-yuan, Thanks for your interest. Which version are you in? I got 0x4b instead of 0x12 from the latest version.

• How to indicate a live out in FL: The live_out variable need to be indicated in the dfg_fir.json by live_out_val attribute. You can see only the id1 Phi node has the attribute of live_out_val, which holds the final results.
• How to indicate a live out in CL: This needs to be done manually. Specifically, we notice CGRA Tile 9 holding the final output, so we explicitly return it to check the value with the golden FL model. The CL's configuration is in the (config_fir.json)[https://github.com/pnnl/OpenCGRA/blob/master/cgra/test/config_fir.json].
• How to recognize the relation between the .cpp with the CL/FL mapping: If you look into the generated kernel.ll (generated by the compiler), you can figure out phi1 and fadd7 should hold the final live out value (look into the compiler-generated dfg).
• Meaning of the generated tile bits value: The latest version should print out everything that happened in each tile at every cycle. You can look into the line_trace() to see what is supposed to be printed out and modify it if you want.
• Overall: Normally, we shouldn't check the correctness of the model using live out. Instead, we should use the data memory that holds the stored value. However, such verification is not maintained well in this repo. In addition, you can see the leveraged dfg even has no store operation because it is generated from the outdated compiler. You can use the latest compiler support to generate more accurate DFGs.
• Suggestions: You can use the latest compiler to generate DFG/mapping and obtain the performance. Then you can use this repo to generate Verilog to get the area/power stats. This repo also has well support in different levels of unit/integration tests. But for the application level verification, it is outdated and might need help to be supported in the future.

[Siberia-yuan]

Yes, I have already found out the version differences of the output. I have one more question, I have read the source code of newest CGRA mapper and I found out that some param changes in the generated dfg.json compared with the old version and the generated dfg.json is not supported by FL level simulation in OpenCGRA since the differences of Json parameters. Is there any way to solve it?

[tancheng]

If you really want to use FL, we have to add the support for the param changes in the FL, which might take some time. Another idea is just wrapping the c++ as a python call and it would do exactly the same thing as FL model (i.e., functionality).

[Siberia-yuan]

Appreciate it much! I have no more questions,your works and answers help me a lot