ARC VPX Vector DSPs: Digital Signal Processing Goes Floating Point

To speed application software development, the VPX family is supported by Synopsys’ ARC MetaWare Development Tools, which provide a comprehensive and vector-length agnostic software programming environment that enables code portability among all members of the VPX family.  The tool suite includes an optimizing C/C++ vector compiler, debugger, instruction set simulator, as well as DSP, machine learning inference and linear algebra libraries.

Figure 2: Ready-to-use library functions, optimized for the VPX architecture and implemented in floating point

Each VPX DSP core has up to three parallel floating point processing pipelines, including two optional IEEE-754 compliant vector floating point units (VFPUA, VFPUB) that support both full- (32-bit) and half- (16-bit) precision floating point operations. The VPX cores also have the option to add a dedicated vector floating point pipe that accelerates an extensive set of linear and non-linear algebra math functions (VFFC) including div, √x, 1/√x, sin(x), cos(x), log2(x), 2x, ex and arctan(x). Such operations can be started every four cycles, and execute in parallel to the standard math operations, as illustrated in Figure 4.

“Optional” refers to the fact that the VPX processor can be configured by the user to match the specific PPA requirements of the target application. This configurability allows for a profiling-based comparison of configurations with and without native floating-point support, which will be used for the following PPA analysis.

Figure 3: Non-blocking pipeline executes three floating point operations in two issue slots

Area implications

Table 1 shows the results for two configurations, one without the VFPU units, the other with both VFPUA and VFPUB enabled. Both were synthesized for TSMC 12nm FFC. Adding the floating-point units results in an area increase of 10% - 15% when considering the cell logic only, and an increase of 5.6% - 11% if reasonable RAM size is taken into account. It is up to the designer to judge whether this moderate area increase is acceptable for the given application.

Table 1: Relative area numbers comparing VPX variants with and without floating point units added

Performance implications

In this context, performance refers to the elapsed time it takes to complete the execution of a certain algorithm. It is the number of cycles required for such an algorithm, divided by the clock frequency. For VPX, the maximum frequency (Fmax) is not impacted, whether or not the VFPU units are included – thanks to the optimizations that went into the floating-point hardware units. Therefore, the performance will only depend on the number of cycles it takes to execute a certain algorithm. If key kernels require floating-point arithmetic (e.g. to cover the dynamic range), a fixed-point processor has to emulate the floating-point behavior. This results in a significant performance degradation. The impact on the overall performance will then depend on the relative cycle count of these kernels vs. the overall cycle count of the entire application. 

Power / energy implications 

Especially for battery powered devices, energy might be the more relevant metric to look at. It takes into consideration the number of cycles it takes to complete a certain task, and the power per cycle. For example, reducing the cycle count by 50%, thanks to sophisticated instructions, might result in energy savings of up to 50%, while peak power remains the same. That said, power remains, of course, an important parameter, as it determines thermal effects, and the need for special cooling. 

As mentioned before, when you have to emulate floating point using a fixed-point architecture, the cycle count will increase significantly, and so will the energy consumption. The more relevant case is a scenario where the algorithm designer spent the effort to convert the floating-point code into fixed-point code, so the comparison is about fixed-point code executing on a fixed-point architecture vs. floating-point code executing on a floating-point architecture.

Table 2: Total dynamic energy comparing float32 and int32 

Table 2 shows some benchmarking results, featuring real application kernels provided by customers. It distinguishes between ALU intensive kernels (which are dominated by logical operations) and MAC intensive kernels (dominated by multiple / accumulate kernels). Fixed point operations use int32 data types, floating point operations use float32 data types. 

For MAC-intensive operations, integer results in a 2.7% higher energy consumption than floating point. Why is this? Integer takes about 9% more cycles than floating point, mainly due to the cycles necessary for shifting and rounding. On a normalized scale, per cycle, integer is slightly more energy efficient than floating point, which might be due to the energy spent in multipliers. 

For ALU-intensive operations, the picture is slightly different. Integer results in an 8% higher energy consumption than floating-point while taking 0.5% fewer cycles than floating point. As the cycle count is almost equal for both int and float, the energy difference indicates that floating point operations consume less power for the given instructions.

Depending on the application, the ratios between float and int might differ. And there will be algorithms that can be implemented with Int16 data types, or with half-precision (HP) floating point, or any mix of those. Yet these benchmarks show that thanks to the very sophisticated floating-point units of VPX the difference in energy consumption will be very limited.