How V&V is typically approached for ARM-based SoCs?

When dealing with an ARM-based SoC, verification and validation follow the general SoC V&V flow, but with some ARM-specific considerations and best practices due to the licensed cores, standardized IP blocks (e.g., Cortex-A/R/M cores, Mali GPUs, AMBA bus), and the ecosystem. Here's how V&V is typically approached for ARM-based SoCs:

---

Verification Methods for ARM-Based SoCs

 1. IP-Level Verification (Cortex Core, Peripherals)

• ARM provides golden reference models (e.g., Cortex-M3, A72) and assertion checkers.

• Use ARM-supplied test suites and assertions to verify:

  • Correct instruction execution

  • Exception/interrupt handling

  • MMU/Cache behavior (for Cortex-A)

• AMBA AXI/AHB/APB protocol compliance is critical — verified with:

  • UVM testbenches

  • ARM AMBA protocol checkers

Tools: Synopsys VC Formal, Cadence JasperGold, UVM testbenches

---

 2. Subsystem Verification

As ARM SoCs integrate IP like Cortex cores + GPU + DMA + interconnects, subsystem verification is key.

• Verify CPU + bus fabric + memory under load

• Use ARM Fast Models (cycle-approximate models) to simulate SW behavior

• Verify memory-mapped peripheral interaction (UART, SPI, GPIO, etc.)

• Use UVM agents for AXI/APB interfaces

 Example: Booting basic firmware and verifying peripheral register access over AXI.

---

 3. Software-Aware Verification

ARM SoCs typically run bootloaders, RTOS, or full OS (e.g., Linux).

• Use co-simulation or emulation platforms (Synopsys ZeBu, Cadence Palladium) to boot:

  • ARM Trusted Firmware

  • U-Boot

  • Linux or RTOS (FreeRTOS, Zephyr)

 Tests validate:

• Exception vectors

• Boot sequence

• Memory map correctness

• Peripheral initialization

---

 4. Secure World / TrustZone Validation (ARMv8-M / v8-A)

If using TrustZone:

• Validate transition between Secure/Non-Secure worlds

• Ensure secure interrupt routing, memory partitioning, and non-leakage

 ARM provides TrustZone software packages and secure boot checklists.

---

Validation Methods (Post-RTL)

 5. FPGA Prototyping

Use platforms like:

• Xilinx Zynq (Cortex-A9/ARMv7)

• Intel Stratix + ARM cores

• Custom FPGA-based platforms

Benefits:

• Run Linux in real-time

• Debug software and hardware together

• Validate I/O, peripheral drivers, DMA, etc.

---

 6. Post-Silicon Validation

• Use JTAG/ARM DAP (Debug Access Port) for access

• ARM provides tools: DS-5, Arm Development Studio, Trace32

• Validate:

  • Actual CPU clock, cache, and MMU behavior

  • Power and thermal profiles

  • Coherency in multi-core setups

---

 7. Performance & Power Validation

For Cortex-A or application SoCs:

• Use perf counters (PMU) for core profiling

• Use ARM Streamline, CoreSight Trace to analyze execution flow

• Power estimation via Dynamic Power Analysis (DPA) + thermal profiling

---

 Summary Flow for ARM SoC V&V

Stage	Key ARM-Specific Actions
IP-level Verification	Use ARM-supplied assertions and instruction set tests
Subsystem Simulation	UVM for AXI/APB, simulate memory + peripherals
OS Boot Testing	Use ARM Fast Models or Emulation to boot Linux/U-Boot
Secure Feature Validation	Validate TrustZone boundaries and security states
FPGA Prototyping	Real-time firmware + driver validation
Post-Silicon Validation	Use CoreSight, PMU, DAP-based tools for silicon debug
Performance/Power Validation	Analyze cache/MMU efficiency, thermal behavior, system load