3.5 Modelling Hardware Parallelism in C
3.5.3 Task Level Pipelining
Task level pipelining involves analyzing data flow/stream in a series of distinct non-inlined functions without feed-backs having producer-consumer relation and inserting first-in-first- out (FIFO)/Ping-pong (PIPO) buffers between their synthesized hardware modules so that multiple modules can execute in parallel. If the data is written into an array in producer module in the same order that is read from the array in consumer process, the array is implemented using FIFO. If it is not the case or Vivado HLS cannot determine it, then the memory is implemented using PIPO. The PIPO consists of two blocks of data, each of size of the original array. One of the block can be written by the producer process while the other block is read by the consumer process. The ping-pong ensures that the reading and writing of each block of data alternates in every execution of the tasks. In PIPO, the data can be written to or read from in any order. Whereas, the data is produced and consumed in the same order in FIFO.
In HLS, each module will be implemented as a distinct FSM and task level pipelining helps in the parallel execution of multiple FSMs. In Vivado HLS, the task level pipelining is implemented using the directive: #pragma HLS dataflow. By applying this pragma,
Modelling Hardware Parallelism in C
void model_flow(int A[LIMIT], int F[LIMIT]) {
int B[LIMIT], C[LIMIT], D[LIMIT], E[LIMIT];
#pragma HLS dataflow //HLS STREAM pragma is //applied to B, C, D and E
module_1(A, B, C);
module_2(B, D);
module_3(C, E);
module_4(D, E, F);
}
void module_1(int A[LIMIT], int B[LIMIT], int C[LIMIT]) {
int i;
for(i=0; i< LIMIT; i++){
B[i] = A[i] * 9;
C[i] = A[i] * 2;
} }
void module_2(int B[LIMIT], int D[LIMIT]) { int i;
for(i=0; i< LIMIT; i++) D[i] = B[i] * B[i];
}
void module_3(int C[LIMIT], int E[LIMIT]) { int i;
for(i=0; i< LIMIT; i++) E[i] = C[i] * C[i];
}
void module_4(int D[LIMIT], int E[LIMIT], int F[LIMIT]) {
int i;
for(i=0; i< LIMIT; i++) F[i] = D[i] + E[i];
}
Figure 3.22: Sample function “model flow”
Figure 3.23: “model flow”: Task level pipeline
coarse-grain parallelism is achieved by overlapping computation with communication using a PIPO style buffer. As a result, all modules are running in parallel on a different set of data. Let denote this task-level parallelism as FSMD-level parallelism. For streaming applications implemented with FIFO, the producer and consumer process interactions are interleaved on the same set of data while maintaining synchronization. Let denote this task-level parallelism as data flow optimization. The dataflow directive can be combined with the pipeline directive within each loop in the producer and consumer modules to form fine grained parallelism of the operations on each data element. A typical example of data flow optimization, (function: model flow) is presented in Fig. 3.22 and the corresponding data flow structure of model flow generated by Vivado HLS is depicted in Fig. 3.23. After
FastSim: A Fast Simulation Framework for High-Level Synthesis
Figure 3.24: Control flow of RTL-C: Task level pipeline
evaluation of an iteration ofModule 1, the output is pushed intoFIFO B.module 2 will start processing its first iteration using this element while module 1 processes the next element of array B. The module 3 andmodule 4 follow a similar execution pattern. A module stalls its execution either when its input buffer is empty or if its output buffer is full.
Unlike any form of parallelism discussed earlier, task level parallelism requires actual parallel simulation of multiple states of distinct FSMs. For cycle accurate simulation of the task level pipelining, our basic idea is to simulate a single FSM state of each module in each clock. To achieve this, a current state is maintained for each module. In each clock, the current state of each module is executed, and then the current state is updated according to the FSM transition of that module. Both FSMD-level parallelism and data flow optimization are modeled in a similar manner. Specifically, we design an additional global FSM main as shown in Fig. 3.24 with two states, the required FIFO/PIPO buffer instances, and other variables. At the global FSM, we cycle accurately handle FIFO/PIPO transactions between different modules whose equivalent C code is generated separately using our proposed RTL to C conversion. The synchronization in PIPO and FIFO is handled differently since reading and writing happen to two different buffers in PIPO whereas reading and writing occur in the same buffer for FIFO.
Themainmodule has to be handled separately since it has an additional global controller
Modelling Hardware Parallelism in C
FSM. The design of the main module is as follows:
• Extract the parallel module instances and FIFO/PIPO instances shared between the modules from the AST representation.
• Extract the global control signals and initial values.
• Create a two state controller FSM and map the operations as follows:
– S1: Termination Statements.
– S2: All parallel module function calls and micro-operation depends on the module execution.
• Generate the C code and write to the output file.
state_1:
if(ap_done) goto end;
else goto state_2;
state_2:
module_1(&m1_start, &m1_done, &is_empty_B, &is_empty_C...);
module_2(&m2_start, &m2_done, &is_empty_B, &is_empty_C...);
module_3(&m3_start, &m3_done, &is_empty_B &is_empty_C...);
module_4(&m4_start, &m4_done, &is_empty_B &is_empty_C...);
/* Following code segments ensure that a module starts only if the input FIFO isn’t empty */
m2_start = !is_empty_B;
m3_start = !is_empty_C;
m4_start = (!is_empty_E & !is_empty_D);
ap_done = (m1_done & m2_done & m3_done & m4_done);
end:
Figure 3.25: Representative RTL-C code structure of main
The C code for the global FSM main corresponding to sample function model flow is shown in Fig.3.25. State S1 of main checks if all the modules have finished execution and either concludes the execution or proceed to state S2. At state S2, all the four modules are invoked sequentially as shown in Fig. 3.24. Note that the modules can be invoked in any order in state S2. Since a single state represents a single clock cycle and the buffers are updated post execution of all the modules, the model effectively emulates the parallel execution of all four modules. The sample C code of themodule 2 is given in Fig. 3.26. As
FastSim: A Fast Simulation Framework for High-Level Synthesis
// All variables are declared static if(resume_state == 1) goto S21;
else if(resume_state == 2) goto S22;
else if(resume_state == 3) goto S23;
S21:
if (m2_done == 1 || m2_start == 0) return;
else resume_state = 2; return;
S22:
// Activate fifo_B handshakes for read
fifo_B(ce_B, we_B, &done_B, &is_empty_B ....);
resume_state = 3; return;
S23:
if (is_full_D) { // check if fifo_D is full resume_state = 3; return;
}
// Code statements to Calculate D[i]
// Activate fifo_D handshakes for write fifo_D(ce_D, we_D, &done_D, &is_empty_D ...);
resume_state = 1; return;
Figure 3.26: Representative RTL-C code structure of module 2
shown in Figs.3.26and3.24, only a single state of each parallel module is executed on every invocation of that module, and the control returns to state S2 of main and the execution state of each module is persisted globally (static variables) for clock synchronization.
The FastSim generates either an FSMD as shown in Fig. 3.12 for non-data flow case (where task level pipelining is not applied) or an FSMD as shown in Fig. 3.25for data-flow case (when task level pipelining is applied) based on user inputs. In both cases, the FastSim identifies distinct FSMD modules from the RTL code. In a non-data flow case, FastSim creates a function call for such FSMD in the state where the function is scheduled. The tool then generates C equivalents corresponding to each FSMD module using the flow discussed in Section3.3.4. In the data-flow scenario, it also extracts the structural FIFO/PIPO instances and models the FIFO/PIPO transactions using FIFO/PIPO module function call. FastSim then cycles accurate models of each module from its FSMD as discussed above. It then generates a global main module for controlling the transactions between the distinct FSMDs.
The current version of FastSim cannot handle a nested task level pipeline where individual modules can be further pipelined in a hierarchical manner. It would be an interesting future work to explore how the strategy proposed in this work can be enhanced to accommodate a nested task level pipeline.
Debug Framework and Performance Estimation