Analysis of Control Flow and Data Flow

Data and Control Edges of a C Program

• Fundamental to DFG model is the decomposition of a system into individual nodes
(actors), which communicates through unidirectional, point‐to‐point channels (queues).
• The resulting system model is represented as a graph.
• Such a data flow system is able to express concurrent computations that map easily into
hardware as well as into software.
• So, the data flow model of computation illustrates how we can build system models that
are equally well suited for hardware implementation as well as for software
implementation.
• Our objective in this chapter is to think of a C program in a similar target independent
fashion.
• For a software designer, a C program is always software.
• For a hardware–software codesigner however, a C program may be hardware or
software, depending on the requirements and needs of the application.
Data and Control Edges of a C Program
• Obviously, one cannot make a direct conversion of C into hardware – a major roadblock
is that hardware is parallel by nature, while C is sequential.

• But we can look at a C program as a high‐level description of the behavior of an

implementation, without deciding on the exact nature of the implementation.

• At that point, we become interested in analyzing the C program in terms of its

fundamental building blocks.

• These building blocks are the operations of the C program and the relations between
them.

• We define two types of relationships between the operations of a C program:

data edges and control edges.
Data and Control Edges of a C Program
• Data edge: is a relationship between operations where data produced by one operation is
consumed by another
• Control edge: is a relationship between operations that relates to the order in which the
operations are performed
• Consider for example the following C function, which finds the maximum of two variables.
• This function contains two assignment statements and an if‐then‐else branch.
• For the purpose of this analysis, we will equate statements in C with ‘operations’.
• In addition, we define the entry and exit points of the function as two additional operations.
• Therefore, the max function contains five operations:
 Data and Control Edges of a C Program
• To find the control edges in this function, we need to find what
chains of operations can execute, based on the usual C semantics.
• For example, the operation 2 will always execute after operation
1. Therefore, there is a control edge from operation 1 to operation
2.
• If a > b is true, then operation 3 will follow operation 2, otherwise
operation 4 will follow operation 2.
• Therefore, there is a control edge from operation 2 to each of
operations 3 and 4.
• Finally, operation 5 will follow either execution of operation 3 or
4.
• There is a control edge from each of operations 3 and 4 to
operation 5.
Data and Control Edges of a C Program
• To find the data edges in this function, we examine the data production/ consumption patterns of
each operation.
• The data edges are defined between operations of corresponding production/consumption.
• For example, operation 1 defines the value of a and b.
• Several operations will make use of those values.
• The value of a is used by operations 2 and 3.
• Therefore, there is a data edge from operation 1 to operation 2,
as well as a data edge from operation 1 to operation 3.
Data and Control Edges of a C Program
Implementation Issues
• CFGs and DFGs capture the behavior of the C program graphically
• This leads naturally to the following question:
• What are the important parts of a C program that MUST be preserved in any
implementation of that program?
• Data edges reflect requirements on the flow of information
• Important note: If you change the flow of data, you change the meaning of the algorithm
• Control edges, on the other hand, provide a nice mechanism to break down the algorithm
into a sequence of operations (a recipe)
• They are not fundamental to preserving correct functional behavior in an implementation
• It follows then that data edges MUST be preserved while control edges can be removed
and/or manipulated
Data and Control Edges of a C Program
Implementation Issues
• Parallelism in the underlying architecture can be leveraged to remove control edges, e.g., superscalar
processors can execute instructions out‐of‐order
• On the other hand, parallel architectures MUST always preserve data dependencies otherwise, the
results will be erroneous

 A fully parallel hardware implementation of this program can

in fact carry out both additions in a single clock cycle
 The sequential order specified by the CFG is eliminated in
the hardware implementation
Data and Control Edges of a C Program
Construction of the Control Flow Graph
• Let’s define a systematic method to convert a C program to a CFG assuming:
• Each node in the graph represents a single operation (or C statement)
• Each edge of the graph represents an execution order for the two operations connected by that edge
• Since C executes sequentially, this conversion is straightforward in most cases
• The only exception occurs when multiple control edges originate from a single operation

This statement includes four distinct parts:

• loop initialization
• loop condition
• loop-counter increment operation
• body of the loop
 Data and Control Edges of a C Program
Construction of the Control Flow Graph
The for loop introduces three nodes to the CFG

Dashed components, entry, exit and body, are other CFGs of the C
program which have single-entry and single-exit points
The do‐while loop and the while‐do loop are similar iterative structures
 Data and Control Edges of a C Program
Construction of the Control Flow Graph
Consider the CFG for the GCD algorithm

• A control path is defined as a sequence of control edges that traverse the CFG

• For example, each non-terminating iteration of the while loop will follow the path 2->3->4->2 or else
2->3->5->2

• Control paths are useful in constructing the DFG

Data and Control Edges of a C Program
Construction of the Data Flow Graph
• Let’s also define a systematic method to convert a C program to a DFG assuming
• Each node in the graph represents a single operation (or C statement)
• Each edge of the graph represents a data dependency

• Note that the CFG and the DFG will contain the same set of nodes ‐‐ only the edges will
be different
• While it is possible to derive the DFG directly from a C program, it is easier to create the
CFG first and use it to derive the DFG
• The method involves tracing control paths in the CFG while simultaneously identifying
corresponding read and write operations of the variables
• Our analysis focuses on C programs that do NOT have arrays or pointers
Data and Control Edges of a C Program
Construction of the Data Flow Graph
• The procedure to recover the data edges related to assignment statements is as follows:
1. In the CFG, select a node where a variable is used as an operand in an expression.
• Mark that node as a read‐node.
2. Find the CFG nodes that assign that variable.
• Mark those nodes as write‐nodes.
3. If there exists a direct control path from a write‐node into a read‐node that does not pass
through another write‐node, then you have identified a data edge.
• The data edge originates at the write‐node and ends at the read‐node.
4. Repeat the previous steps for all variable‐read nodes.
• This procedure identifies all data edges related to assignment statements, but not those
originating from conditional expressions in control flow statements.
 Data and Control Edges of a C Program
Construction of the Data Flow Graph
• Let’s derive the DFG of the GCD program
• We first pick a node where a variable is read

Consider statement 5:
• There are two variable-reads in this statement, one for a and one for b Consider b first
• Find all nodes that reference b by tracing backwards through predecessors of node 5 in the CFG -- this
produces the ordered sequence 3, 2, 1, 4, and 5
• Both nodes 1 and 5 write b and there is a direct path from 1 to 5 (e.g. 1, 2, 3,5), and from 5 to 5 (e.g. 5, 2, 3, 5)
• Therefore, we need to add data edges for b from 1 to 5 and from 5 to 5
 Data and Control Edges of a C Program
Construction of the Data Flow Graph
Incoming data edges for
• A similar process can be carried out for variable‐read of a in node 5 in the GCD program
node 5
• Nodes 1 and 4 write into a and there is a direct control path
from 1 to 5 and from 4 to 5
• Hence, data edges are added for a from 1 to 5 and from 4 to
5
• To complete the set of data edges into node 5, we also need
to identify all conditional expressions that affect the
outcome of node 5
• From the CFG, node 5 depends on the condition evaluated
in node 3 (a > b) AND the condition evaluated in node 2 (a
!= b)
 Data and Control Edges of a C Program
Construction of the Data Flow Graph
The final DFG for all nodes and all variable-reads for GCD is shown below

Note: this DFG leaves out the data edges originating from conditional expressions
Translating C to Hardware
• As mentioned, control and data flow analysis can be helpful in translating C into
hardware
• Translating data structures and pointers from C to hardware can get tricky
• For the purpose of this course, we restrict our analysis as follows
• Only scalar C code is used (no pointers, arrays or other data structures)
• We assume each C statement executes in a single clock cycle
• We first create the CFG and DFG for the C program
• The control edges translate to signals that control datapath operations
• The data edges define the interconnection of the datapath components
 Translating C to Hardware
Data Path Design:
With the CFG and DFG available, the following rules will define the implementation of the hardware
datapath.
1. Find the C expression embedded in each node of the CFG, and create an equivalent
combinational circuit to implement the expression.
• For example, if a node in the CFG corresponds to the C statement a = b ‐ a;, then the C expression embedded in
that statement is b ‐ a.
• The combinational circuit required to implement this expression is a subtractor.
• Conditional expressions generate datapath elements, too.
• The outputs of these expressions become the flags used by the hardware controller of this datapath.
2. Each variable in the C program is translated into a register with a multiplexer in front of it.
• The multiplexer is needed when multiple sources may update the register.
• By default, the register will update itself.
• The selection signals of the multiplexer will be driven by the controller.
3. The datapath circuit and the register variables are connected based on the nodes and data
edges in the DFG.
• Each assignment operation connects a combinational circuit with a register.
• Each data edge connects a register with the input of a combinational circuit.
• Finally, we also connect the system‐inputs and system outputs to inputs of datapath circuits and register outputs,
respectively.
Translating C to Hardware
Data Path Design:
• The datapath and the registers are connected consistent with the DFG
• Assignments connect combinational circuit outputs to register inputs, while the
• data edges connect register outputs to combinational circuit inputs.
• System I/O is connected to datapath inputs and register outputs resp.
• Let’s convert the GCD program to a hardware implementation
• The variables a and b are assigned to registers
• The conditional expressions for the if and while stmts require an equality‐ and greater‐than
comparator circuit
• The subtractions b ‐ a and a ‐ b are implemented using subtractors
• The connectivity of the components is defined by the data edges of the DFG
• The resulting datapath has two data inputs (in_a and in_b), and one data output (out_a)
• The circuit needs two control variables, upd_a and upd_b (outputs of controller)
• and it produces two flags, flag_while and flag_if (inputs to controller)
Translating C to Hardware
Translating C to Hardware
• The directed edges in the DFG correspond to the connections in the schematic
• Schematic representations of a circuit are low‐level representations with lots of detail
(similar to assembly code in programming languages)
• We will learn how to create HLS and behavioral VHDL descriptions that synthesize to
schematics similar to the one shown here
Translating C to Hardware: Control Path Design
• Controller Design: The design of the controller can
be derived directly from the CFG and translated
into a finite state machines (FSM)
• How do we create the controller for this datapath
such that it implements the GCD algorithm?
• This control information is present in the C
program and is captured in the CFG.
• In fact, we can translate the CFG almost straight
into hardware by considering it to be a finite state
machine (FSM) specification.
• Each of the transitions in this FSM takes 1 clock
cycle to complete.
• The activities of the FSM are expressed as
condition/command tuples.
Translating C to Hardware: Control Path Design

• Unlike CFGs, the edges in FSMs are

labeled with condition/command
tuples
• The “_” in _ /run1 means don’t care,
i.e., the transition is unconditional

• For example, _ /run1 means that during this clock cycle, the value of the condition flags is a don’t‐
care, while the command for the datapath is the symbol run1.
• Similarly, flag_while/_ means that this transition is conditional on flag while being true, and that the
command for the datapath is a hold operation.
• A hold operation is one which does not change the state of the datapath, including registers.
• The command set for this FSM includes ( _, run1, run4,run5).
• Each of these symbols represents the execution of a particular node of the CFG.
• The datapath control signals can be created by additional decoding of these command signals.
Translating C to Hardware: Control Path Design

• Each clock cycle, the controller

generates a new command based on
the current state and the value of
flag_while and flag_if.
• The commands run1, run4, and run5
are decoded into upd_a and upd_b.
• The combination of the data path
and controller is referred to as a
finite state machine with datapath
(FSMD)
Translating C to Hardware: Control Path Design
The table shows an example execution, where each row of the table corresponds to one clock cycle:

Note that this solution is sub‐optimal, in paricular:

• The resulting implementation limits parallelism
• it executes a single C statement per clock cycle and does not share datapath operators.
• For example, only one subtractor is needed in the implementation because only one is ever used
in any given clock cycle
Single‐Assignment Programs
• Converting into hardware with one C‐statement/clock is not very efficient
• This one cycle‐per‐statement is similar to what microprocessors do when they
execute a program
• A more lofty goal is to devise a translation strategy that allows the execution of
multiple C statement/clock
• But our original variable‐to‐register mapping strategy creates a performance
bottleneck
• This is true because only one storage location exists for each variable and
therefore, sequential updates to it will each require one clock cycle
• We fix this problem by converting the C code to a single‐assignment program
• This is done by creating new variables for each sequential assignment statement
Single‐Assignment Programs
• Consider a simple example:
a = a + 1;
a = a * 3;
a = a ‐ 2;
• Our previous strategy requires 3 clock cycles to execute these
statements
Let’s re‐write this as:
a2 = a1 + 1;
a3 = a2 * 3;
a4 = a3 ‐ 2;
• This code allows a2 and a3 to be mapped to wires and a4 to a
register, reducing the clock cycle count to 1
Single‐Assignment Programs
• Note: care must be taken that all assignments are taken into account,
which might be difficult to determine
a = 0;
for (i = 1; i < 6; i++)
a = a + i;
• After conversion to single‐assignment, it remains unclear what
version of a should be read inside of the loop
a1 = 0;
for (i = 1; i < 6; i++)
a2 = a + i; // which version of a to read
• The answer is that both a1 and a2 are needed and it depends on the
iteration, i.e., a1 is needed on the first iteration and a2 on
subsequent iterations
Single‐Assignment Programs
• The solution is to introduce a new merge variable that selects from
the two versions that are available
a1 = 0;
for (i=0; i<5; i++)
{
a3 = merge(a1, a2); // merge two instances.
a2 = a3 + 1;
}
• In a hardware implementation, the merge operation is mapped into a
multiplexer, with the selection signal derived from the test of (i == 0)
• Using these transformations, we can reformulate any program into
single assignment form
Single‐Assignment Programs
• Consider the GCD program The equivalent single‐assignment form:
int gcd (int a, int b) int gcd (int a1, int b1)
{ {
while (a != b) while ((a3 = merge(a1, a2)) != (b3 = merge(b1, b2)))
{ {
if (a > b) if (a3 > b3)
a = a ‐ b; a2 = a3 ‐ b3;
else else
b2 = b3 ‐ a3;
b = b ‐ a;
}
}
return a2;
return a;
}
}
 Single‐Assignment Programs
The implementation of this single-assignment version might look like

• Here, a2 and b2 are mapped into registers while the other variables are replaced with wires
• This type of manipulation allows multiple C statements to be executed per clock