© 2009 orbital sciences corporation. all rights reserved. may be published with permission by mapld...
TRANSCRIPT
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
1Innovation You Can Count On
DSP development and verification issues
with Matlab generated RTL
Presented by Ely [email protected]
MAPLD 2009
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
2
Outline
DSP Algorithm Development
Matlab, Simulink and RTL Generation Blocksets
QPSK Receiver Example
Simulation Examples
Development Issues
Verification Issues
Conclusions
Questions
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
3
Algorithm Development
Digital Signal Processing (DSP) and other Complex Algorithm development often begins in Matlab or other similar tools
Space targeted RTL is generally hand coded
Moving from simulation to implementation in RTL can have various negative effects introduced from loss of precision and implementation nuances
Significant Time is spent re-implementing the algorithm and getting it to match the original algorithm
Bit Logic based RTL simulators such as ModelSim are poor tools for DSP development
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
4
Matlab and Simulink
Accelerating Digital Signal Processing (DSP) FPGA Design with Mathworks Simulink
Simulink – “Simulation and Model-Based Design” Simulink is a block level simulation environment bundled with
MATLAB Can be described as a SPICE tool for Digital Designs
Simulink can be extended with blocksets by 3rd Party Vendors Blocksets are similar to the various Matlab Toolboxes
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
5
RTL Generation Blocksets
Major 3rd Party FPGA manufacturers provide RTL Generation Blocksets Xilinx Altera Lattice Synplicity (Synthesis Tool Manufacturer)
Most blocksets are targeted to the vendor’s specific gate arrays Individual blocks represent architecture primitives RTL generation supplying the routing to IP or primitives
Synplicity’s blockset stands apart in that it generates generic RTL Can target most manufacturer’s gate arrays Targets Actel including the RTAX family of Anti-Fuse FPGAs Generates RTL without blackbox IP
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
6
RTL Generation Blocks
Each provider’s blockset provides a different assortment of blocks Synplicity’s blockset has all the basic logic elements and primitives
Binary Logic, Registers, Mux, Constants, Adders, Multipliers, etc A few of the more complex blocks are shown below
Counters, State Machine Builders FIR & IIR Filters, Sin Cos Tables, Integrators CORDIC, Sign, RAM, FIFO
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
7
Fixed Point and Parameters
Entire generated design uses fixed point precision managed by the designer
Word Length and Fraction Length for each block can be Full Precision
Alternately, bits can be dropped with optional rounding as needed
Optional Saturate on Overflow Option
Rounding and Saturation adds additional logic
Word Length is one of the key tradeoffs between implementation size and design performance
Additionally each block has specific parameters controlling its operation
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
8
Accurate Simulation
Bit True and Cycle True Simulation Bit changes during individual simulation/cycle steps match RTL
functional simulation
Sample Times / Clock Rates are specified at the Simulink level
Can simulate various real world signals and channel effects including Noise Frequency Shifts, Jitter, and Doppler Interferers Timing Clock Drift and Jitter Non-Linear System Effects
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
9
QPSK Receiver for CHIRP program
QPSK Receiver was developed as the uplink for a technology demonstration payload
Developed by Orbital Sciences Corporation CHIRP (Commercially Hosted Infrared Payload) Launch scheduled for 2010
Innovation You Can Count On™
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
10
What is CHIRP?Commercially Hosted IR Payload
Specific Purpose:Demonstrate Large Format Focal Plane Array and Wide Field-of-
View (WFOV) Staring Sensor Technology for Missile Warning and Missile Defense
Flight Validation Demonstration is Required Before WFOV Staring Technology Can be Confidently Endorsed for the Next Generation Missile Warning Space-Based Architecture
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
11
QPSK Receiver Top Level
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
12
QPSK Receiver Specifications
CMAC
Minimum Maximum
Input IF 15,868,928 Hz 16,131,072 Hz
Carrier Frequency Offset -131,072 Hz 131,072 Hz
System Sample Rate N/A 6 MHz
Dynamic Range N/A 66 dB
Symbol Clock Error N/A 40 kHz
Input Bit Resolution N/A 12 bits
Receiver Bit Delay N/A 20 samples @ System Sample Rate
Symbol Rate N/A 1 Msps
Data Bit Rate N/A 1 Mbps
SNR -5 dB N/A
Eb/N0 -4 dB N/A
Acquisition Time 1 ms 20 ms
Specifications for Digital Implementation Final card level specifications dependent on board performance and
Noise Figure
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
13
Complex Stimulus Generation
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
14
Complex Stimulus Generation
A functional test and debug tool is only as good as the test bench run on it
Design can be driven by generated or real world stimulus Matlab/Simulink generated stimulus Data captured from a logic analyzer and imported into Matlab
Stimulus can be manually or automatically manipulated at runtime
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
15
QPSK Costas Loop
Costas Loop acquires phase lock of carrier signal Entire logic built from
2 Comparators 2 Negate 4 Mux 3 Adders 2 Shifts 1 Register
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
16
Downconverter and DDS
Downconverter frequency shifts the incoming signal from an intermediate frequency (IF) and/or offset to Baseband
Direct Digital Synthesis (DDS) is a component of the Downconverter and provides the accurately tuned sinusoids to match the Carrier frequency and phase
The below implementation is a good example of how the blocks can be used to rapidly develop an algorithm
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
17
RRC Filters
Root Raised Cosine Filters provide noise reduction, pulse shaping, and intersymbol interference (ISI) minimization
Note the use of a Black Box Block These special blocks provide the interface to external IP or RTL
Simulation information for these blocks are available in several ways Simulink block substitution Co-Simulation with Modelsim C code models converted to Matlab S Functions
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
18
Timing Estimator
Timing Estimator synchronizes the transmitter and receiver sample clock
This is a good example of the use of subsystems, each of which is its own component in the generated RTL
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
19
Simulation Capabilities
Simulink Intermediate Signal Analysis is extremely powerful Constellations Eye Diagrams Time Plots Frequency Plots Vector Plots Power Measurements Filtering Equalization Fast Fourier Transform (FFT)
Any algorithm that can be designed in Matlab can be used to analyze any intermediate point in the design
Benefits from additional algorithms such as Equalization or Increased Error coding can be simulated without actually being introduced into the design
Bit Error Rate (BER) Analysis built into Matlab
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
20
Simulation Examples
Constellation and Numeric Probes No Noise Case 20kHz Frequency Offset 5kHz Symbol Clock Offset
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
21
Simulation Examples
Constellation and Numeric Probes EbN0 / SNR = 3dB
EbN0 equivalent to SNR in this case 20kHz Frequency Offset 5kHz Symbol Clock Offset
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
22
Simulation Examples
Spectrum Scopes - Frequency Domain Analysis They can be attached to any intermediate point
In the example below Left Scope connected before RRC Filters Right Scope connected after RRC Filters
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
23
Simulation Examples
Standard Scopes - Time Domain Analysis They can be attached to any intermediate point
Waveform and Numerical Analysis
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
24
Development Benefits and Techniques
Simulation Speed is relatively fast One second can be simulated in a couple of hours for a fairly
complex design
The power and capability of the stimulus generation can help during board level debugging
Board level effects can be simulated Captured data can be inserted into the simulation for debug
The same precautions with standard RTL logic design should be followed All normal design practices translate to logic design at the block
level Logic should be “designed for upsets”
DSP designs often have control states based on combinational logic Mitigation techniques such as range checking have to be practiced
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
25
Development Issues
Multi-Rate and Single-Rate designs available
Multi Rate Designs (Multiple Clock Domains) can be driven in different ways Separate, aligned Clocks can be used Enabled Clocks are also an option Adds additional requirements for clock and reset generation logic
Multiple Clocks Require careful clock alignment and reset generation that can be a weak point for SEU events.
Clock misalignment can break the design
Downsample and Upsample blocks are equivalent to clock domain transitions when using separate clocks (as opposed to enabled clocks)
These transitions must be carefully addressed to avoid metastability The same techniques used in RTL must be practiced in the block level
logic
Single Rate Designs (One Clock Domain) simplify things considerably
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
26
Generated RTL
Design is generated by instantiating and mapping various library components and routing them as needed
The library components are in a supplied RTL library available for review
The Synplify Blockset RTL library along with the User Generated RTL is used for synthesis
Relies heavily on generate statements to allow for variable bit widths Generate statements can be very difficult to follow
Generics are used to control parameters for generate statements These parameters match those entered in the individual Simulink
Blocks
Signal names and comments are reflected in the generated RTL
Inspection of the RTL and Technology view of the Synthesis Output can help in the code analysis
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
27
Verification Issues
Can replace functional level design tools For DSP or other mathematically intensive algorithms
These types of tools will never replace timing analysis simulation tools such as ModelSim
Can go from Simulink functional design straight to Post Place and Route timing simulation
Can generate a RTL testbench complete with stimulus and result comparisons
Stimulus is selected at the input ports Results are selected at the output ports The test bench verifies that output matches at the expected time step
Provides a ready made qualification style test Can be used with post place and route timing data Stimulus and Expected Results could be dynamic to provide for an
automated test setup
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
28
Verification Issues
Weakest point in the methodology is the validation of the generated RTL
Any change in the design can result in an unknown number of changes in the generated RTL
Depending on which RTL generation options are used (e.g. Retiming), changes can occur in sections of the design not modified by the engineer
Can be minimized by not using any RTL generation options
Due to the inherent lack of trust in the reliability of auto generated RTL RTL validation has to reoccur anytime the design is regenerated
This can make design maintenance very tedious especially when changes have cascading effects on the RTL
© 2009 Orbital Sciences Corporation. All Rights Reserved. May be published with permission by MAPLD 2009
29
Conclusions
RTL generation blocksets are an ideal tool for DSP design in FPGAs The features of Matlab and Simulink allow for excellent algorithm verification
Removal of Simulation to Implementation Step gives you large benefits Accelerated development and debugging Fewer errors and performance hits
The benefits of accelerated development is balanced with a more rigorous code review and design validation requirement
Furthermore, design maintenance will require a more extensive re-validation
Synplicity’s blockset requires careful manipulation to map to hardware primitives
Achieving the best timing performance/margin can require the use of the Retiming option during RTL generation, when using complex blocks
Viability with critical payloads will require extremely thorough design verification The methodology is especially useful for non-critical, secondary, or
reconfigurable payloads where design verification can be slightly more relaxed