Implementing Digital Signal Processing Algorithms in Actel’s RT54SX-S Family

1. MAPLD 2005 Presentation Implementing Digital Signal Processing Algorithms in Actel’s RT54SX-S Family Ken Stevens Laboratory for Atmospheric and Space Physics University of Colorado, Boulder

2. Problem Definition Background • FPGAs allow the designer to optimize between performance and power by precisely tailoring the processing logic to mission requirements. This is especially true when implementing custom DSP functions. • The tool flow for Actel’s RT54SX-S family does not inherently support translation from a high-level analysis tool to gate-level implementation. • To provide reasonable algorithm performance with the resources available in the RT54SX-S family often requires a highly-optimized VHDL-based implementation. • As designs provide more functionality, significant attention must be devoted to expedient verification of the algorithms in addition to the emphasis on VHDL coding style, board-level issues, etc. Problem Statement • Given the combination of advantages and constraints described above, a methodology that effectively combines the use of a high-level analysis tool for algorithm characterization and refinement with VHDL simulation and in-circuit testing of the FPGA logic implementation is essential. This presentation describes such a methodology that was used to successfully develop the FPGA-based digital signal processing functions on NASA’s THEMIS project.

3. THEMIS Project Background • Functions Required • Digital Filtering • Vector Rotations to Align Instrument Coordinate Systems • Extraction of parallel & perpendicular signal components • Spectral Analysis using Fourier Transform

4. DSP Functions and Data Products

5. Digital Signal Processing Architecture • Algorithms • FIL - Digital Filtering • DER - Coordinate System Alignment and Cross/Dot Product Calculation • FFT - Spectral Analysis using Fourier Transforms • Infrastructure • ADI - Control of Analog to Digital Conversion • MAC - SRAM Interface • CTC - Post-processing and compression of data products • CTC - Command and Telemetry interface controller

6. Development Process Objectives • Quality • Multiple verification and test paths to maximize coverage • Maximize the “time on the hardware” • Visibility • Good schedule visibility • Want to know immediately if the design gets off track • Maintain a “working” board at all times • Efficiency • Development multiple DSP Algorithms in parallel • Identify and resolve board-level issues early • Identify and resolve algorithm issues early • Smooth integration of sub-components into the system • Collaboration • Encourage interaction between the science and engineering teams • Natural synchronization of team efforts

7. Development Process Overview • After algorithm analysis and design, data-handling infrastructure (and PCB design) can be pursued in parallel with the algorithms. • Isolates external interfaces and timing issues to the infrastructure elements to help identify board-level issues early. • Infrastructure provides a kernel to which the algorithm packages can be attached using a well-defined interface. • Allows incremental development for good schedule visibility and reduces undesirable interactions between components. • Pitfall: Because this methodology implies a conscious decision to pursue the FPGA infrastructure and the algorithm development as discrete, parallel items it is especially important to maintain a common, clear specification of the interface between the two or system integration will be painful and time-consuming!

8. Development of Ideal Algorithm • Start with Science Requirements and Objectives • Produce the ideal algorithm and relevant test/use cases. • Test cases are carried forward through all subsequent phases of the development process and so the file formats should be compatible with all simulation and test environments.

9. Design of HW-constrained Algorithm • Constraints • Clock frequency • Logic resources available • Algorithm RAM usage/bandwidth – RTSX parts don’t have onboard RAM • Logic optimization trade-offs – clock cycles vs. size • HW-constrained algorithm • Number formatting - floating vs. fixed point, bit width, round-off error, etc. • Generate initial logic estimates • RAM map for data storage • Arbitration scheme if more than one algorithm shares the RAM storage • Is performance acceptable and can the algorithm be implemented in the target technology?

10. Design of HW-constrained Algorithm • The ideal and HW-constrained algorithms can differ significantly and still provide a valid comparison. For instance… • FFT data is much easier to interpret if it is in a field-aligned coordinate system. • Once the power spectrum is performed, the data cannot be re-rotated • FPGA rotates the vectors prior to the FFT • Want two components: 1 field-aligned 1 perpendicular, in spin plane B Spin plane

11. Design of HW-constrained Algorithm • On the ground, the easiest way to find the parallel and perpendicular components is: • Problem: expensive in logic, especially square roots • Can provide the same result with CORDIC rotations using a fraction of the logic.

12. Design of HW-constrained Algorithm B 2 rotations are required: 1. Rotate about spin axis. 2. Rotate about E34' . E56 E34 E12 B E56 E12' B E_par E34' E_perp E34'

13. Implement & Verify HW-constrained Algorithm • Simulation testbench for this component replicates the data-handling infrastructure interface to ensure easy integration. • Use functional simulation to identify and fix algorithm errors.

14. Implement & Verify HW-constrained Algorithm • Simulation log files of each processing stage allow fast debug of issues. • Tight coupling between design and IDL routines comes in handy… • VHDL simulations checked directly against IDL • Bit-level testing available • Discrimination between algorithmic and implementation bugs • Fast feedback • Example: This IDL/VHDL interaction was used to quickly identify an error in the power calculation algorithm by plotting the IDL and VHDL results to ensure that they match…

15. Develop Functionally Verified FPGA • Since the data-handling infrastructure was developed and verified separately, it is available for board-level testing in parallel with algorithm simulations.

16. FPGA Development Iterations • Reprogrammable Prototype  ASX  RTSX • Timing analysis and simulation become progressively more stringent the closer you get to flight…balance simulation and lab testing to optimize coverage. • Iterations do not mean to use a “code and fix” methodology. • Pitfall: Due to schedule concerns, there is often a desire to “go to flight form-factor” before the reprogrammable prototype has been thoroughly tested and appropriate lessons have been learned. Doing so can impose unnecessary overhead that actually exacerbates schedule concerns, especially when the issues being addressed are purely functional or algorithmic in nature.

17. LabVIEW Test Fixture for In-Circuit Test • Files are the same format as simulation, allowing yet another cross-check of the test cases. • Top-level VHDL test-bench logic emulates test fixture which means that simulation equals real world as much as possible.

18. Fourier Transform Pass-through Analysis A logarithmic chirp waveform from a signal generator is passed through the system unaltered and is processed using IDL. The IDL result is automatically compared against the FPGA generated data product and the difference is computed. IDL Result FPGA Result Difference

19. Derived Quantities Pass-through Analysis • This example shows a set of inputs that results in extracted parallel and perpendicular components that are an amplitude modulated chirp signal. • A pass/fail metric of error (in bits) between ideal and HW-constrained algorithms was applied in this case. • Another noteworthy test was a Monte Carlo mode to really stress out the algorithms (especially the vector interpolation algorithm) and provide comprehensive coverage of the 3-dimensional space.

20. Conclusion • The Board and Flight FPGAs have been delivered to THEMIS project for integration into the rest of the system. • Perhaps the most desirable result of the process was the collaboration between the science and engineering teams.