Automated HW/SW Co-Design of DSP Systems Composed of Processors and Hardware Accelerators

We begin by measuring the performance of the pure software AES algorithm running on the Xtensa processor. The Xtensa Xplorer Integrated Development Environment (IDE) allows you to view the profiling results generated by the Tensilica pipelineaccurate ISS. Using the Xplorer IDE, we measure the performance of the pure software AES algorithm at 270k clock cycles for 128 encryption steps.

Reconfigure the Xtensa processor to include ports for input and output queues used for passing data to and from the external AES accelerator. These queues will be connected to the AES accelerator. In addition, the software running on the processor must be modified to remove the AES algorithm code and replace it with code that reads and writes data to and from the newly added queue ports. This will pass data to the external accelerator and read the results back to the processor.

The AES algorithm code that we removed from the Xtensa core is reused in this step. We take this behavioral C++ implementation of the AES algorithm and run it through Stratus’ bdw_import utility, which will:

The designer will then modify the Stratus project file to specify parameters such as clock frequency, reset mode, and technology libraries.

The Stratus bdw_import function creates a stub testbench, which requires user modification to define functional tests for the HW accelerator. The testbench should include reset, I/O handshaking, input stimulus, and expected results.

Using a testbench at this point is not required; however, it allows the user to test the AES hardware implementation independently of the Xtensa core and automatically simulate and gather event activity for power analysis using Stratus’ Joules RTL power analysis integration.

Identifying an optimal micro-architecture requires design space exploration. Exploration is the process of applying optimization settings and constraints and performing HLS optimization and execution of a user-defined tool chain to perform various analyses (e.g., Genus logic synthesis for timing and area, Joules for power analysis, etc.).

With our chosen technology library and a specified clock frequency of 500MHz, the initial Stratus implementation yields a design requiring 313 processor clock-cycles for 128 encryption steps at a silicon area cost of 19k square microns. While this implementation is four orders of magnitude better than the processor-resident implementation, we observe that the processor supplies 1 input every 2 clock-cycles in this implementation. This corresponds to an input initiation interval of 2 (II-2) vs. the default II-1. As pipelining with Stratus is fully automated, you can simply redefine the pipelining initiation interval constraint to 2 and re-run Stratus. The II-2 implementation does not affect performance but allows Stratus to perform more aggressive resource sharing, resulting in an area of 11k square microns. The complete turnaround time for this new implementation was 20 minutes, demonstrating a significant productivity improvement over hand-coding the RTL.

Continuing our design space exploration to improve system performance, we experiment with a different mechanism for communication between the Xtensa core and the hardware accelerator. Experimenting with new interfaces in Stratus is extremely productive, and the coding changes are minimal.

In this case, we explore a shared memory architecture with two memories—each with two banks. This shared memory architecture removes a performance bottleneck in accessing the memory and should deliver improved performance. This change requires a small SW change (on the processor), as we must fill the shared memory before initiating the encryption step (as opposed to writing and reading the queue interfaces). Figure 6 shows this architecture as follows:

Performing HLS optimization with these changes (i.e., II-1, shared memory interface) results in the highest performance implementation of 141 processor clock-cycles for 128 encryption steps. This comes at a small area increase to 20k square microns vs. the previous 11k square microns for the TIE-queue-based architecture.

Our explorations have yielded four architectures with a wide range of performance and silicon area costs. Now the system designer can determine the architecture that best meets their system requirements. The implementation time of these different scenarios is very low and significantly less time-consuming than hand-coding a single RTL implementation. We did compare these HLS implementations to a hand-coded RTL implementation (with II=1) of the accelerator, and the Stratus implementation was marginally smaller. This is consistent with what Stratus users typically report with respect to productivity and PPA vs. hand-coded results—Stratus delivers significant productivity gain with equal-to or superior PPA.

One of the most important values that Stratus customers tout is the ability to explore different micro-architecture implementations easily—putting this capability into the hands of Xtensa users, along with tool automation and compatible interface classes, multiplies that value. Xtensa users are generally more experienced in writing C++ than RTL, so the ability to quickly move parts of their software algorithms, described in C++, off the processor, and implement them as hardware accelerators in RTL, adds a whole new dimension to overall system design. Rather than trying to guess the impact of such HW/SW partitioning tradeoffs, users can actually implement and measure the impact of their HW/SW partitioning candidates.

The Stratus and Xtensa integration is a major step toward true hardware-software codesign. Users can quickly move “the slider” back and forth between HW and SW domains and choose the best implementation that meets their needs based on precise PPA measurements.