Use of C/C++ Models for Architecture Exploration and Verification of DSPs

1. Use of C/C++ Models for Architecture Exploration and Verification of DSPs David Brier July 25, 2006

2. Presentation Outline • Introduction • Modeling Activities • Design Description • Validation of C Model • RTL Verification • Test Environment • Problems Encountered • Test Case Creation • Directed Testing • Random Testing • Methods Looking Forward

3. Introduction • Primary Product Line • Imaging and Audio Products • Digital Still Cameras • Digital Camcorders • Cellular Multi-media Attachment • Catalog Products • Typical IP Module • Video Processing Accelerators • Fixed Function • Programmable • Audio Processing Accelerators • Programmable • Special Purpose Programmable State Machines

4. Modeling Activities • Fixed Function • Primarily Limited Flexibility • Parameterization of Function • Zoom Factor • Filter Coefficients • Set Data Processing Sequence • Programmable Platforms • Targeted Arithmetic Processing Units • Computations Under Instruction Control • Normally VLIW (Very Long Instruction Word) • Multiple Computational Sequences • Intra-Instruction • Inter-Instruction

5. Modeling Activities (cont.) • Commonalities • Defined Computation to be Accomplished • Quality Level of Result • Examination of Artifacts of Computation • Fixed Function • Models Precise Algorithm • Explores All or Part of State Space • Programmable Platforms • Models Example Functions • Explores All Instructions • Explores All or Part of State Space

6. Modeling Activities (cont.) • C++ • Provides Rich Programming Environment • Suitable for Complex Programming Tasks • C • Simple Constructs • Limited Abstraction Possible • SystemC • Emerging Standard at Time of Project • Suitable for High Level Modeling of Hardware • Models Written in C • Close Emulation of Hardware • Models Contained Low Level Structure

7. VERT VERT Data Mux HORZ EDGE LINE STOR OUTP VERT RAM VERT Design Description • Horizontal and Vertical Polyphase Filter Stages • Under Damped Edge Enhancement Filter • Data Input DMA and Mux • Line Memory Interface • Output DMA

8. . . . C30 C20 C00 C10 . . . C1n C0n C3n C2n Polyphase Filter for Horizontal and Vertical • Filter Composition • Multiple Accessible Coefficients Per Tap • Otherwise Standard FIR Filter Implmentation • Coefficient Selection by Phase Offset Computation for (k = 0; k < num_cols; k++) { for (j= 0; j < num_rows; j++) { for (i = 0; i < 4; i++) { y = C[i+ p]*x[k][i+j]; } Yout[k][j] = sat(y); } } X Z-1 Z-1 Z-1 Z-1 X X Y + X X

9. 4 Tap 8 Phase Polyphase • Multiple Phase Output • Adjustment of the Coefficients Permits Interpolation • Adjustment of the Coefficients Permits Decimation • One Filter Structure for Both Operations • Example 1:2 Zoom In • Output Phase Does Not Align With Input Samples • Sync Mask Utilized Output (phase0) Output (phase1) Luma Input Y Y Y Y Y Y Y Y Y Y Y Y Luma Output Y

10. Validation Of C Model • Visual Validation • Primary Method of Validation • Known Artifacts from Zoom Operations • Level of Validation • Actual Validation Done • Sampling of Zoom Factors • Sampling of Key Input Images • Golden Level Validation, Why not? • Zoom Range from 4X to 0.25X in Steps of 0.0001 • Phase Alignments Derived from Zoom Factor • Using Visual Validation Represents Overwhelming Effort • Largely Subjective When Considering Trade Offs • Other Validation Options Possible • Perform Zooms in “Standard” Tool i.e. Photoshop • Absence of “Industry Standard” Image Databases

11. Example:Zoom Artifact • Edge Effect In Zooms • Sharp Edges Become Blurred • Stair Step Effect • Exaggerated for Demonstration “Most Probable View” “Magnified View” ZOOM

12. RTL Verification • C Model and RTL Architecture Aligned • Function Calls In C Model were Modules in RTL • Frame Based Design • No Dependency on Prior or Next Frame Data • Each C Function operated on a Frame of Data • RTL Streamed on a per Row Basis • Single Input Frame and Single Output Frame • C Model Input Data Array, RTL Input from Memory • C Model and RTL Test Bench Read Same Data File • C Model and RTL Output Separate Data Files

13. RTL Verification: Testbench • Test Point Insertion • Output • Intermediate C Monitor Logs RTL Monitors C MODEL HORZ EDGE VERT Pre RTL MODEL VERT VERT Pre Data Mux HORZ EDGE LINE STOR OUTP VERT RAM VERT

14. ….. ….. ….. RTL Verification: Data Flow • RTL Flow Is Serial • Pixel Values are Shifted Through Filter One Pixel at a Time • Serialized Output • C Model Operates On 2D Arrays • Input is Array, Output is Array RTL Filtering Input Image Array(Charged Coupled Device “CCD”) 4 TAP FILTER . . . . . . . . .

15. ….. ….. ….. ….. ….. ….. RTL Verification: Vertical Filter • Largest Variation Between C Model and RTL • C Model Has 2D Array • Runs Down Columns • Completes Column, Moves to Next Row • RTL Has Serial Row Input • Saves 3 Rows • Computation Starts On Input of 4th Row • Proceeds by Row, then Column Cycle 1 Cycle 2

16. RTL Verification: Problems Encountered • Waveform Viewing Just Does Not Work! • C Model Output Format Is Tabular • RTL Waves Are Serial, Don’t Line Up Logically • Design is Pipelined • Values In C Model are Staggered In RTL • Tabular Output Works Best for Data Path • Data Output • Post Processing in PERL • Side by Side Tabular Comparisons ….. ….. ….. ….. ….. C Model Tabular View RTL Waveform View

17. Test Case Creation • Directed Tests • Primary Methodology • Requires Creation of Detailed Test Plan • Tests Written to Cover Features • Manual Effort to Obtain Coverage • Deterministic Results • Random Tests (Constrained Random) • Augmentation of Directed Tests • Tests Written to Span Features • Replication of Some Directed Tests • Two Scopes or Ranges of Variation • Control Parameters • Data

18. Directed Testing: Example • Poly-Phase Filter Phase Alignment • 8 Phases, 4 Taps • Test for Each Phase • Counter Controls Phase Alignment of Coefficient Z-1 C0 C1 X C2 C3 C4 C5 Phase Selection Sequence C6 C7 0 0 0 0 0 0 0 0 0 0 4 0 0 0 0 3 0 0 0 4 0 0 0 0 …. Counter

19. Directed Testing: Example • Accessing Phases • Explanation of Zoom Phases • 1:2 Zoom Has Two Phases • Phase 0 and Phase 4 • One Input Data Set, Two Output Pixels • Output Sequence is {0,4,0,4,0,4,0,4,0,4,……} • Odd Zoom is Not as Predictable • Deterministic Phase Access • Input Parameter of Start Phase • May be set to any value 0-7 • Permits Walking of Phases • Sufficient Control to Verify Coefficient Usage • Pick Target to Verify and Build Specific Test Caseto Obtain Coverage

20. Directed Testing: Summary • Significant Coverage Obtained • Greater Than 95% of Found Bugs • Beginning with Preliminary BugsThrough Advanced Bugs • Easily Identified Coverage • Each Test Written With Covering of Featureas Objective • Known Setup States • Test Cases Analyzed for Ancillary Coverage • Look for Features Covered in Addition to Objective • Coverage Points in Test Plan Accounted for byTest Creation

21. Random Testing • More Appropriately Constrained Random • Zoom from 0.25 to 4X • Resolution of 0.001X • 4,250 Zoom Settings • Controlling Steps Based Upon KnownPoints of Interest • Good at Catching the Unthought-of of or Overlooked • Deterministic Test Creation Requires Complete Coverage Point Elaboration • Corner Case Declaration is Sometimes Difficult

22. Random Testing: Overlooked Case • Saturation Function Coverage • Saturates at +1.0 and – 1.0 • Deterministic Testing Covered 0.0 Point andPositive Saturation • Negative Saturation Testing Was Omitted • from Deterministic Testing • Negative Saturation Bug Found ByRandom Data Testing • Scope of Testing Must Always Be Considered • Data Field Required Constraining • Horizontal Line Limit is 1280 pixels • Vertical is Infinity, but Practically 720 Rows • Attempting to Simulate This Results in Simulator Crash

23. Methods Looking Forward • Consideration Must Be Given to Resources Available • Detailed and Accurate C Models • RTL Model • Standardized Chip Level Interfaces • C or System C Interface Models • Emergence of C to RTL Formal Verification Tools • Pilot Verification Performed Using Formal Tool • Requires Wrapper in System C Around Models • Requires Setup Scripts Written • Will Require Coding Guides for C Models

24. Formal Methods: Experience • Capacity • Initial Runs Were Very Capacity Limited • Result of “Odd” Views of Arithmetic Operators in RTL • Tool Could Not Access Word Solver • Once Vendor had RTL, Educated Word Solver • Setup • Some Learning Curve Associated with Flow • Wrapper Generation May be Automated • Constraint Script Creation May be Automated • Control of Inputs was Intuitive • Results • Short Time to First Bug • Inserted into Known Good Design • Output Simulation Capable Test Driver • Falsification May be Archived and Regressed

25. Closing • Verification Methodologies Constantly Evolving • Reference Model Based Methodologies • Bit for Bit Comparison • Formal Proof Methods • Objective Remains the Same • Either Directed or Directed Random • Cover Corners of Design • Zero Defect Objective • Of Course Strive for Zero Defects • Sometimes Trade-off Schedule for Completeness • Paranoia and Verification