Run the C Simulation - 2022.2 English

With the source code and testbench added to the project, you can now run the C simulation.

TIP: For more information about the features of a well-written test bench, refer to Writing a Test Bench in the Vitis HLS Flow of the Vitis Unified Software Platform Documentation (UG1416).

1. From the Flow Navigator, select C-Simulation > Run C Simulation.

   The C Simulation Dialog is displayed.

   

2. Select the Enable Pre-synthesis Control Flow Viewer check box to produce a control flow view of your design after C simulation.

   NOTE: This option is not available on Windows.

3. Click OK.

   After the simulation completes, the tool displays the dct_csim.log file with the results of simulation, and also displays the Pre-synthesis Control Flow graph. The log file displays print statements from the executed testbench, and information that the test passed.

   The Control Flow graph, as shown in the following figure, offers some insight into the control structure of your code. Take a look at to see how Vitis HLS understands your code.

   NOTE: Control structure here refers to the branches in your code caused by various kinds of loops and conditional statements like if and switch statements.

   

4. Zoom in on the graph and examine the structure of the DCT function. It includes the following elements:

   • read_data: Reads the data from the DDR, as an array, and reformats it into a matrix.

   • dct_2d: Processes the matrix of values, applying the cosine transform to the matrix values.

   • write_data: Writes the results back to DDR, converting the matrix back into an array.

5. Look at the Loops view below the graph.

   This view shows the loops found in the code, and displays some basic statistics related to the loop iterations, and timing. Vitis HLS automatically applies names to unlabeled loops, and associates these names with the loop. These names can then be used in the Tcl Console view to refer to the loop. If you select a loop in the view, the loop is also cross-selected in the control flow graph and the source code.

   Some of the key highlights of the Control Flow graph are as follows:

   • Shows the control paths in your C/C++ code (as indicated by the red arrows and is an artifact of code profiling).

     • The percentages on the red arrows indicate the percentage of time that particular branch is taken versus the other branch. This gives you an idea of where the time is spent inside the design and the areas to focus on.

     NOTE: Because this path is derived by running the testbench, this path is specific to your test.

   • Allows you to see where the memory reads/writes are in the control flow graph. This allows you to get a sense for memory port contention issues.

     • If memory accesses are on different branches, then these accesses would be considered mutually exclusive (and therefore no conflict can occur).

     • If however, the memory accesses are on the same branch, then loop II violations can occur because of multiple memory accesses in the same sequential portion of the code.