IPTR-C2H-NIOS Altera, IPTR-C2H-NIOS Datasheet - Page 89

• Manufacturer Part Number: IPTR-C2H-NIOS
• Description: IP CORE Renewal Of IPT-C2H-NIOS
• Manufacturer: Altera

Specifications of IPTR-C2H-NIOS

• Software Application: IP CORE, NIOS Processor And Functions
• Core Architecture: Nios II
• Features: ANSI C Compliance, Straightforward C-to-Hardware Mapping, Reporting Of Generated Results
• Core Sub-architecture: Cyclone
• Rohs Compliant: NA
• Lead Free Status / RoHS Status: na

Altera Corporation
November 2009
Loop Latency and Cycles per Loop Iteration (CPLI)
There are two metrics that determine the efficiency of an accelerated loop:
loop latency and cycles per loop iteration (CPLI).
Loop latency is the amount of time required for the first iteration of a loop
to complete, assuming one clock cycle per state of the loop's state
machine. An iteration completes when it passes from the first state
through the last state, and so the loop latency is equal to the number of
states in the loop's state machine.
CPLI is the minimum possible period for issuing successive loop
iterations. A new iteration of the loop state machine is issued every CPLI
clock cycles, assuming one clock per state. After initial loop latency is
overcome, a loop's state machine produces results for each successive
iteration every CPLI clock cycles. CPLI is determined by the loop-carried
dependencies present in a loop.
In general, the goal of optimizing C code for the C2H Compiler is to
reduce both loop latency and CPLI to as close to 1 as possible for all loops
in the accelerator. Loop latency and CPLI values assume no stalling,
however, which is not always realistic (see section
page
cause stalling at runtime, which cannot be reflected in CPLI and loop
latency. Conceptually, C2H optimization techniques are similar to
traditional C compilers: Focus effort on minimizing loop latency and
CPLI for critical inner loops first; reduce execution time of subfunction
calls; and use fast memory for performance-critical sections of code.
Subfunction Pipelining
Each subfunction is implemented as a state machine, and a subfunction
call translates to a particular state within the containing function or loop.
In other words, a subfunction translates to a state machine within a state
machine. The fact that it is a distinct state machine allows it to be a shared
resource within the containing function.
If the subfunction does not contain loops or shared data dependencies,
the C2H Compiler can pipeline the subfunction. The subfunction has its
own state machine, but the datapath is pipelined as if it were the body of
a loop. When the outer state machine reaches the state to call the
subfunction, it can continue to execute other operations in parallel with
the inner state machine. Data sets from multiple subfunction calls are
pipelined in the subfunction’s state machine.The code in
contains a subfunction which is pipelined by the C2H Compiler.
3–39). Inner loops, subfunction calls, and slow memory accesses all
9.1
C-to-Hardware Mapping Reference
Nios II C2H Compiler User Guide
“Stalling” on
Example 3–38
3–49