CHREC F3: Target Tracking

1. Rafael Garcia 11/26/08 CHREC F3: Target Tracking

2. F3 Goals, Motivations, & Challenges Goals Develop applications & design strategies for scalable architectures from case-study Analyze & examine available multi-FPGA platforms and tools for scalable system design Motivations Meet performance requirements in HPC/HPEC scenarios by mapping across multiple FPGAs Exploit multi-FPGA platforms to develop larger, complex designs and algorithms Increase understanding of performance prediction, power, and usability for scalable apps Challenges Perform multilevel algorithm partitioning, analysis, and optimization for multi-FPGA systems Determine influence of application characteristics on selection of platforms, tools and languages Formulation F3 Insights Execution Design Translation 2

3. Kalman Filter Overview • Traditional Kalman filters estimate the state of a dynamic system in a noisy environment • Commonly used in target prediction and can be extended to multiple dimensions, targets, and models • Excellent target tracker when an accurate model is known • Useful even if an accurate model is not known

4. Current Architecture • 4 tightly coupled FPGAs mapped to 4 quadrants • System is driven by two global clocks • 100MHZ inter-FPGA communication links • 50MHz data-processing clock • 2-step processing cycle returns results at 25MSa/s • Inter-FPGA communication occurs when target crosses a quadrant boundary • Current state of target is passed along • Non-pipelined design • 2-step cycle where one cycle depends on the previous one and the other cycle depends on pseudo-sensor data from host CPU • Low frequency and lack of pipeline registers is expected to lower power consumption • 2-cycle design simplifies communication network

5. Current Architecture • Continuously receiving pseudo-sensor data and returning condensed information • Limited to a single target per quadrant • Set sensor sampling rate of 25MSa/s

6. Simplified Algorithm RCML Representation • Assumes steady-state operation • Target must closely follow given movement model for accurate results • Allows for precomputed covariance and Kalman-gain terms • Model tracks four parameters • Horizontal position • Vertical position • Horizontal velocity • Vertical velocity • Algorithm Changes • Remove the hardcoded terms, increasing prediction accuracy during non-steady-state situations • Modify model to include Z-axis parameters for airborne targets New Module Types

7. Kalman Filter • Estimates state of a dynamic system in a noisy environment • In this case, the ‘dynamic system’ is a moving target • Commonly used in target prediction and can be extended to multiple dimensions, targets, and models • Assumes sensor noise is white Gaussian noise • Requires a pre-programmed model describing the target’s motion • Works in a continuous 2-cycle loop • Developed in 1960 by Rudolf E. Kalman (A UF professor from 1971-1992!)

8. Kalman System Models • Kalman Filter can be viewed as a simple black box • An input stream of samples measuring a target’s position is contaminated with noisy samples • The output is a stream of samples with most of the noisy samples filtered Noisy Samples Kalman Filter Mostly Accurate Samples NE wind at 23mph -9.8 m/s Accurate Samples Follows Road

9. Reasons for sensor noise • Battery Power • variable battery voltage • voltage regulators cost money, draw power, and are not perfect • Sensors • low quality sensors • cost-cutting for mass production sometimes requires cheap sensors • incorrectly deployed sensors • bad orientation, obstructed sensor • Environment • environmental conditions • rain, dust, night-time tracking, snow • Multiple targets • misinterpreted samples from neighboring targets during multiple-target tracking • Sensor processing stage must ensure proper target isolation • Wireless signal • bad data from neighboring sensors due to a weak wireless signal

10. Kalman Filter example

11. PR Virtual Architecture with Kalman Filters • Sensor records samples • Image processing step extracts specific features • Target size, vertical position, horizontal position, target bearing, elevation, etc. • Kalman filters extract sensor noise • Results are sent to a central location to be displayed VLX25 Communication architecture Sensor Interface Display Interface Switch 5 Switch 1 Switch 2 Switch 3 Switch 4 Module interface Module interface Module interface Module interface Module interface Kalman filter Kalman filter Kalman filter Kalman filter Kalman filter

12. FPGA and PR benefits for the Kalman Filter • FPGA amenable features • Low memory requirements • Simple filter with streaming inputs and outputs • Can be implemented using only logic and MAC units • Requires only multiplication and addition • No complex time-consuming operations such as division, square-root, differentiation, etc. • Low bandwidth requirements • Filter receives/produces a stream of coordinates, not a stream of images • PR amenable features • Optimum resource usage • The right filter type for the right job • Swapping modules does not halt execution • Active filters are never disturbed

13. Experimental FPGA Power Measurements

14. Experimental Setup • GiDEL Host Specifications • Dual Xeon 3.00 GHz processors (Pentium 4 era) • 2GB RAM • Single 500GB hard drive • CD Drive • 600W max power supply • (Kappa clone) • ProcStar II Power Characteristics • Main board supply rated at 7.6A at 3.3V • 7.6A × 3.3V = 25.08W maximum power available to: • Stratix II EP2S180 FPGA (4x) • 2GB SODIMM DDR memory(2x)(only 1 used for tests) • 64MB SRAM memory (8x) • Miscellaneous oscillators, peripherals, controllers, etc. • This means roughly 5W max available to each FPGA • Test Design Characteristics • Kalman tracking filters • Heavy multiplier usage, no block rams, minimal logic usage (w/ dedicated multipliers) • In all cases, design runs at 33MHz

15. Methodology • GiDEL host system measured without FPGA board • P3 Kill-A-Watt AC power meter used for measurements • 0.2% documented accuracy • Accurate to within 1 Watt • 7 different test cases with varying power utilization • GiDEL host system measured with FPGA board • Same 7 test cases were used (without loading an FPGA design) • This provides minimum power-use baseline for ProcStar II • GiDEL board is loaded with FPGA-computationally intensive design • CPU is kept idle • Power consumption under regular design is measured (@ 33 MHz) • 2% logic use (per FPGA) • 15% multiplier use (per FPGA) • 1 filter instance per FPGA • Power consumption under maximum-multiplier-use design is measured (@ 33 MHz) • 4% logic use • 88% multiplier use • 7 filter instances per FPGA • Power consumption under maximum-logic-use design is measured (@ 33 MHz) • 77% logic use • 0% multiplier use • 34 filter instances per FPGA Design 1 Design 2 Design 3

16. Results: Baseline ProcStar II • Threads are simple while(1) loops • Although only 2 cores are present, 4 threads were used to bypass Hyper-threading and OS scheduling • HDD load is an exception since defrag requires its own thread to be effective

17. Results: Kalman Filters on ProcStar II • Power estimates • 12.5% toggle rate assumed @ 33 MHz • Experimental numbers below assume FPGAs consume all power (ie. ProcStar II memories, glue logic, etc. consume 0W) • Design 1 • 140 W total power • ~3.25 W per FPGA • 15% mult., 2% logic • 1 filter instance, high Fmax • Design 2 • 140 W total power • ~3.25 W per FPGA • 88% mult., 4% logic • 7 filter instances, high Fmax • Design 3 • 152 W total power • ~6.25 W per FPGA • 0% mult., 77% logic • 34 filter instances, low Fmax Design 1 Design 2 Design 3

18. Results: Kalman Filter in ProcStar II • *Measured power is derived by subtracting baseline power consumption on ProcStar II board from measured power consumption and dividing by 4 • Power consumed from board components not accounted for, actual FPGA power consumption is lower

19. Questions?