Test and Verification Solutions. ARM Based SOC Design and Verification

Transcription

1 Test and Verification Solutions ARM Based SOC Design and Verification 7 July

2 7 July March 2 Agenda System Verification Challenges ARM SoC DV Methodology ARM SoC Test bench Construction Conclusion Q&A

3 7 July March 3 System Verification Challenges High Potential Bug Areas in SoC Unexpected access conflict between the shared resources. Complexities arising out of interaction between subsystems which were verified stand alone. Cache coherency in multi-core system. Interrupt connectivity and Priority scheme. Arbitration priority related issues and access dead-locks. Unexpected HW/SW sequencing. Exception handling conflicts and priority scheme. Multiple power domain region, clock domain crossing. Multiple reset and clock region.

4 7 July March 4 ARM Based SoC Architecture Debug & Trace ARM Boot ROM Test I/F Controller Boot Config ARM Core High Speed Pheripheral PLL TIMER External Bus Interface ARM Interconnect DMA Controller Memory SubSystem DDR Cntrl SRAM Cntrl On Chip Memory Bridge UART I2C GPIO Low Speed Pheripheral

5 7 July March 5 ARM SoC DV Methodology This session describe the current verification methodology used in SoC verification. Formal Verification Hardware Software Co Verification FPGA Prototyping

6 Formal Verification Formal verification is a systematic process that uses mathematical reasoning to verify the design. Formal verification works algorithmically and exhaustively explores all possible input values over time. It is sometimes difficult to figure out how stimulate the design or create multiple scenarios to high observability to do that formal will come into the picture. 7 July March 6

7 7 July March 7 Formal Verification Typical Formal Verification Flow-1 ARM Core ARM Interconnect(PL301) IP IP

8 7 July March 8 Formal Verification Typical Formal Verification Flow -2 ARM Core Master side Port binding Model Checking engine ARM Interconnect(PL301) Score Board Slave side Port binding IP

9 7 July March 9 Formal Verification Below is the technique to verify the AXI interface using formal verification tools Construct the CSV file to describing the registers. Runs the conversation script to generate the SVAs. Bind the proof kit to DUT, run the tools to read DUT and SVAs. Prove and Analyse the tool results and logs.

10 Formal Verification Property Check Develop a formal specification of the AXI protocol. Various kinds of components >1 Masters Slave(s) Example:- property (@(posedge ACLK) disable iff (!ARESETn) (ARVALID) =>##n ( RVALID); End property; 7 July March 10

11 7 July March 11 Formal Verification Example: Connectivity/Integrity check connect {clk_in} "CORTEX.CLK" \ connect {clk_out} "SOC.CLK" \ connect {valid_in} "CORTEX.AWVALID && CORTEX.AWREADY \ connect {valid_out} "SOC.AWVALID && SOC.AWREADY"

12 7 July March 12 Formal Verification Limitations of Formal Size limit Not always feasible Good for control checking but not for data

13 7 July March 13 Hardware Software Co Verification In SoC verification, co-simulation provide the facility to verifying hardware and software functionality together. The ability to achieve first silicon and first software success relies on the capabilities of a verification environment to support full-system hardware/software coverification. Software engineer to access hardware design to integrate software functionality with hardware. Hardware engineer by providing additional stimulus.

14 7 July March 14 Hardware Software Co-Verification Flow Software Environment Hardware Environment SW Tools (Compiler, Linker, Debugger) Executable Object file HDL Simulation Tools DUT Memory Model Output for debugger tools

15 7 July March 15 FPGA Prototyping It allows faster simulation and close to real time operation performance which would help in identifying bugs. Comprehensive Verification, Integrated hardware-software testing. Provides rapid debug capability through JTAG and specialized debug infrastructure which is built in to the FPGA.

16 7 July March 16 FPGA Prototyping Microprocessor evaluation board with logic simulation Microprocessor evaluation board Inter-Processor Communication (socket) Bus Transaction read/write BFM Logic Simulation With Hardware Design

17 7 July March 17 FPGA Prototyping Limitations Many FPGAs are required for SoC partitioning, leading to prototype system complexity Only synthesizable modules can be mapped into an FPGA and run for debugging. Unable to partition multiple clocks and reset trees. FPGA provides limited debug capability and visibility during single iteration and hence multiple iterations may be required to narrow down to the specific bug.

18 7 July March 18 ARM SoC Test Bench Construction The system verification environment planned in a way such that it is able to classify the functionality in terms of active and passive components SoC Verification Env ARM ARM Core ARM Core Core Emulation Pins other Pins TB TB configuration DUT Resets clocks Active BFM Active BFM Active BFM Active BFM Active BFM Passive BFM

19 7 July March 19 Active component An active component can be synthesizable or behavioral, typically modeling functionalities required for supporting the DUT. Active component can interact with DUT and influences behavior of DUT. Passive component Passive components are observers in Test bench which does not influence DUT behavior. Passive component are usually behavioral model, extracting information and validating the correctness of design behavior.

20 7 July March 20 Conclusion As with the growing complexity of SoC designs, verification strategies should evolve and mature enough to handle the complex challenges of identifying bugs and functional issue. A robust verification environment planning which starts as early as the design phase coupled with thoughtful usage of latest tools and verification technologies, which help in achieving the desired quality objective.

21 7 July March 21 Q&A Q&A