Altera Nios II C2H Compiler - Manual (Page 20)

1–14 9.1 Altera Corporation
Nios II C2H Compiler User Guide November 2009
C Code Appropriate for Hardware Acceleration
Example 1–1. Checksum Calculation
u16_t standard_chksum(void *dataptr, int len)
{
u32_t acc;
/* Checksum loop: iterate over all data in buffer */
for(acc = 0; len > 1; len -= 2)
{
acc += *(u16_t *)dataptr;
dataptr = (void *)((u16_t *)dataptr + 1);
}
/* Handle odd buffer lengths */
if (len == 1)
{
acc += htons((u16_t)((*(u8_t *)dataptr)&0xff)<< 8);
}
/* Modify result for IP stack needs */
acc = (acc >> 16) + (acc & 0xffffUL);
if ((acc & 0xffff0000) != 0)
{
acc = (acc >> 16) + (acc & 0xffffUL);
}
return (u16_t)acc;
}
Accelerating this function could have a significant impact on execution
time, especially the amount of time spent in the
for loop. The remaining
code executes once per call to format the result and check boundary cases.
Accelerating the code outside the loop has little benefit, unless the entire
standard_chksum() function is a called from another function that is
also a good acceleration candidate. The most efficient hardware
accelerator for this code would replace only the
for loop. To accelerate
the for loop only, you need to refactor the code to isolate the loop in a
separate function.
Poor Acceleration Candidates
Accelerating some code can have negative performance impacts, or can
unacceptably increase resource utilization, or both. Use the following
guidelines to identify functions not to accelerate:
■ Code that contains many data or control dependencies must perform
many sequential operations, and is a poor candidate for acceleration.
A large number of dependencies makes it difficult for the
C2H Compiler to fully optimize loops. Processors are designed to
perform such operations efficiently.