# A Novel Reconfigurable Vector-Processed Interleaving Algorithm for a DVB-RCS2 Turbo Encoder
## 6 Simulations and Results  
Performance analysis was carried out using the CEVATOOLBOX profiler designed for CEVA's DSPs. The profiler creates a table detailing (1) the cycle count of each function in the code and total cycle count results and (2) the number of _Read_/_Write_ operations performed in each function and total _Read_/_Write_ results. Unlike the approach of enhancing each function of a code/algorithm individually, the proposed vector implementation revises the whole permutation process. Hence, serial and vector algorithms are fundamentally incompatible; therefore, we consider only the overall results of the permutation stage detailed in Table 2.  
The simulations were executed for 11 vector sizes and matching parameter sets given in Table 2. For each parameter set, we compared the serial and vector-wise results and calculated the speedup using  
\[Speedup=\frac{L_{old}-L_{new}}{L_{new}}\cdot 100\%.\]  
where \(L_{old}\) and \(L_{new}\) are the counts of read, write, and total cycles of the serial- and vector-wise implementations, respectively.  
Figure 11 illustrates the measured speedup factors for read, write, and total cycle counts across eleven vector sizes ranging from 56 bits to 2396 bits. Each cluster of three bars corresponds to a single vector size on the x-axis, with the height of the blue, orange, and green bars indicating the speedup achieved in the read operations, write operations, and overall cycle count, respectively.  
Several trends are apparent:  
* Read speedup grows rapidly with the vector size, peaking at 734.5\(\times\) for N = 1192 bits before tapering off at the largest size.
* Write speedup also increases, with its maximum of 484.4\(\times\) again at N = 1192 bits, reflecting the efficiency of coalesced vector writes.
* Total-cycle speedup shows substantial gains, exceeding 296\(\times\) at N = 492 bits and remaining above 124\(\times\) at the maximum vector size.  
\begin{table}
\begin{tabular}{c c c c c c c} \hline
**Vector Size** & \multicolumn{2}{c}{**Parallel**} & \multicolumn{2}{c}{**Speedup**} & **Parallel** & **Speedup** \\ \hline
**N [Bits]** & **Read** & **Write** & **Read** & **Write** & **Total Cycles** & **Total Cycles** \\ \hline
56 & 761 & 666 & 11.7 & 109.6 & 172,239 & 6.000 \\
152 & 621 & 570 & 82.1 & 158.6 & 132,264 & 63.70 \\
236 & 739 & 802 & 200.0 & 143.8 & 175,387 & 87.70 \\
384 & 822 & 719 & 284.7 & 230.4 & 178,026 & 141.7 \\
432 & 988 & 1042 & 383.8 & 199.0 & 238,599 & 153.1 \\
492 & 1279 & 997 & 623.4 & 409.5 & 270,537 & 296.2 \\
520 & 998 & 1042 & 438.5 & 222.2 & 238,599 & 177.8 \\
776 & 1217 & 928 & 589.9 & 406.4 & 255,186 & 284.1 \\
1056 & 1487 & 1109 & 307.1 & 229.8 & 313,108 & 134.9 \\
1192 & 1487 & 1109 & 734.5 & 484.4 & 313,108 & 339.9 \\
2396 & 1612 & 1189 & 295.2 & 219.6 & 339,651 & 124.7 \\ \hline \end{tabular}
\end{table}
Table 2: Read, write, and total cycles profiler results.  
The non-monotonic variations particularly in total-cycle speedup stem from parameter-dependent algorithm phases (e.g., number of blocks per transpose) rather than the vector size alone. Overall, even at the smallest vector length, the parallel interleaver consistently outperforms the serial baseline, confirming the effectiveness of our vector-wise implementation.  
As shown, the algorithm maintains linear complexity \(O(n)\) with respect to vector size, and the performance improves due to the efficient memory access patterns enabled by the vectorized architecture. In particular, the ratio of read/write cycles to the total execution cycles remains stable, demonstrating the model's predictable scaling behavior. This efficiency makes the proposed solution viable for real-time applications, even as data payload sizes grow.  
The memory footprint was also monitored during these runs and remained bounded due to the fixed-size permutation buffers reused across iterations, which supports practical implementation in embedded environments.