ARM Based SoC Verification - v1
ARM Based SoC Verification - v1
Abey Thomas
Agenda
About ARM and ARM IP ARM based SoC Verification challenges Verification planning and strategy IP Connectivity verification Performance verification Low power verification Clock domain crossing verification H/W-S/W co-verification concepts Tracking verification maturity Tape out readiness guidelines Q&A session
Cambridge, UK based Design centres in Cambridge, Austin, Bangalore and Sophia Antipolis
Popular range of products RISC processor cores for portable devices and mobile phones Peripheral and fabric IP products Software tools, models products
ARM7
More than 10 billion devices sold Used in simple microcontroller devices
ARM9
Advanced microcontrollers and industrial SoC Low-end application processors (ARM926EJ-S) DSP, Java, VFP, MMU/MPU
ARM11
High-end application processors SIMD, DSP, Java, VFP, Multi-core, Thumb-2, MMU/MPU
MMU for OS and multi tasking Highest performance at low power TrustZone and Jazelle-RCT
Real-time profile (ARMv7-R) - R4/R5/R7 Protected memory (MPU) Low latency and predictability
Microcontroller profile (ARMv7-M) M3/M4 and ARMv6-M) M0/M1 Lowest gate count entry point Deterministic and predictable behavior
Other IP products
Memory controllers and system controllers L2 Cache Controller, DMA Controller etc
Multiple clock domains, multi master Complex system IP with coherency extensions
DVFS
IP level complexity AMBA specifications support IP interoperability issues IP interface signals compatibility
Software based simulation -Using HVL tools or any other RTL simulator
Modeled using concepts in ABV, OVM, VMM, UVM, system Verilog, C, Verilog /VHDL etc.
In-circuit Emulation - Hardware based The DUT is operated with embedded software drivers and operating systems, similar to that in a real system
FPGA Prototyping - Hardware / FPGA based Maps the entire design or the strategic areas of the target SoC into an FPGA gives an accurate and fast representation
Static formal verification Provided by industry standard tools supporting formal verification
IP Connectivity verification
Involves verifying the sanity of the connections between various IPs in the ARM eco system
Outputs and inputs of all IP and subsystem are connected to intended target recipients correctly All the sideband signals and the unused inputs and outputs are appropriately connected Chip level connectivity to pad rings are proper with TAP controller and JTAG connectivity with IO pin level multiplexing, pin level direction control etc Clock and reset connectivity is established. Top level glue logic is correctly in place and functionally tested Asynchronous interfaces are appropriately designed to take care of metastability issues
Performance verification
Verifying whether the design meets (or exceeds) the product operational requirements Helps to determine optimal system mode configuration & Software settings for achieving functionally operational requirements
Dhrystone, AXI Adaptive Verification IP (AVIP) and Virtual performance exploration (VPE) approaches
VPE from ARM allows targeted testing with minimum development effort and allows real IP & SW to be used for complete system test and benchmarks AVIP is an ARM VIP which is a unified solution for AMBA 3 AXI SoC platform architectural and functional verification
Performance verification can happen in parallel with integration and functional testing
Clock gating Multi-switching (multi-Vt) threshold transistors Multi-supply multi voltage (MSMV) Power gating with or without state retention Dynamic voltage and frequency scaling (DVFS) Substrate biasing
Power gating areas power domains or power islands verified using power aware simulations Power specification data of the SoC provides the low power design intent of the system
Perform register/latch recognition from the RTL design. Perform identification of power elements and their power control signals. Perform shut-down and turn on the power of each IP which can be controlled according to its power-modes. Shut-down and turn on system memories, with and without value retention. Shut-down and turn on registers, with and without value retention. Evaluate the isolation cell outputs when IP is in shutdown. Ensure that the active logic is protected from the turned-off IP by the isolation cells.
Failure to retain sufficient state information Dependency on output values due to failure of isolation between interfaces. Problems when interacting state machines in different power domains restore to states that create deadlock or live lock situations in the design. Improper sequencing of save and restore operations by the power management block. Failure to reset a block upon power-on to a known good state for non-retentive blocks.
Industry trend shows increased multi clock designs in ARM based SOC Varying clock frequencies for non critical IP blocks depending on performance requirement Some IPs need clock rates higher than system clock rate and hence asynchronous. Ex: GPU CDC verification helps identify metastability issues Check for the presence of valid synchronizers in all asynchronous clock domain crossings and synchronous clock domain crossings Check for the presence of separately synchronized signals which are converging. Verify zero data loss and cross check special synchronizing schemes
Pre-empts verification done with real hardware prototype Software engineers have much earlier access to the SoC hardware design for S/W design and test Results in additional system improvements being incorporated Provides additional testing for the hardware design with the help of software infrastructure EDA ISS or ARM Fast models used Tools available to run complex designs, capable of exposing hidden cycles. Limited visibility with memory partitions
Number of bugs identified on a definite measurable time Indicates the trend of bug discovery
Completeness of all test cases as per plan. Involves periodic review and recording of testing progress
RTL rate of change RTL rate of change determines the rate at which design changes and bug fix rates evolve. Declines with design maturity
Completion of the code coverage targets Completion of the functional coverage targets Completion of the targeted checker Coverage Completion of the correlation between functional coverage and checker coverage list Completion of review of all the exclusions and waivers Completion of review all known bugs, issues and waivers All test cases passed, with no new bugs observed in defined regression period
Q&A session
Conclusion
Thank you