External Use

TM

Early Software Development Through Palladium Emulation for a Complex SoC

Raghav U. Nayak | Senior Validation Engineer

CDNLive 2014

TM

External Use 2

Agenda

• Design, size, complexity and life stage• Challenges with the multicore SoC integration from

scratch• Emulation and its benefits • How to parallelize hardware and software design

activities− Compile phase− Run phase− Debug phase

• Session summary• Thinking ahead• Acknowledgements

TM

External Use 3

Design, Size, Complexity, Life Stage

• Digital networking device based on Freescale Layerscape architecture

• Key Architecture Features− Dual ARM® Cortex A7− DDR3L/4 interface− 3-port GigE with IEEE® 1588− 2x PCI Express® Gen2− 4-Lane multi-protocol SerDes PCIe-2, SATA3, SGMII

• Key Integration Features− Low-cost NAND/NOR flash interfaces− QSPI support− USB2 / 3 support− Audio networking and motor control− ARM TrustZone Architecture

TM

External Use 4

Design, Size, Complexity, Life Stage

TM

External Use 5

Multicore SoC - Integration from Scratch

• It’s a challenge to integrate hardware AND validate software early in a design cycle

• Design may not be mature and might not have reuse options because:− More third-party IP's− Upgraded internal IP’s − New SoC integration− Change in Instruction Set Architecture (ISA)

• Goals are same like any other SoC

TM

External Use 6

What is Emulation?

Emulator used was Cadence Palladium XP and PD3 Verification System

• The Palladium Verification System provides a converged environment for Simulation Acceleration (SA) and In-Circuit Emulation (ICE)

• Increases verification throughput, and verifies ASICs, SoC systems and hardware/software interactions with the real-time environment and/or testbenches

• Sometimes can reproduce bugs in design which cannot easily be recreated or debugged in the SoC verification testbench

TM

External Use 7

Why Do We Need Emulation?

• Helps verification engineer resolve hardware and software integration issues

• Helps software engineer perform critical software activity • Bridges the gap between hardware and software by providing

reasonable speed

TM

External Use 8

Compile Phase

TM

External Use 9

Parallelizing Hardware and Software Design Activities

• Stage 1− Performed Test Port Read/Write as ARM® core was not brought up− Generating data and address preloads for Test Port Buffer

Test Port Buffer

Interconnect

Slave (Memory,

Peripherals etc)

TM

External Use 10

Parallelizing Hardware and Software Design Activities

Stage 2• Assembly based tests

• Checked basic functionality of− Processor Subsystem − Memory Interface− Peripherals

• Built with “arm-none-linux-gnueabi-as” Assembler

TM

External Use 11

Parallelizing Hardware and Software Design Activities

• Stage 3− Bare Metal Infrastructure clubbing both C and Assembly

ARM® Vector Table Initialization

ARM Boot Sequence(Modes, Stack, MMU, Cache, FPU

etc)

DDR Controller Initialization

Testcase Section

Assembly

Assembly

Assembly

Assembly, C, C++

TM

External Use 12

Parallelizing Hardware and Software Design Activities

• Script ware to compile the code, generating preloads for memory and to run− Stage 4a ( Unix Prompt )− Makefile Infrastructure to compile the code

TM

External Use 13

Parallelizing Hardware and Software Design Activities

• Stage 4b ( Unix Prompt )− Generating preloads for Memories like DDR, NOR, NAND, SBROM− Example Snippet for creating preloads for DDR

TM

External Use 14

Parallelizing Hardware and Software Design Activities

• Stage 4c ( Palladium Prompt )− Run Script Generation

• The main tcl procedure (call it rtc) for run-test-case would have multiple arguments such as the following :-

-help Prints this usage message

-testcase_dir <path to bin files> Testcase Directory

-tc_timeout [time in seconds] Default 60s

-trace_enable [true/false] Default false

-trace_start_at_state [name of state] (typically tcExec)

-pre_run_tcl <pre_run.xel> Sourced if file exists

-post_run_tcl <post_run.xel> Sourced if file exists

-sdl_file <file.tdf> Default $scripts_dir/tc_sdl.tdf

-trace_file <trace_file> Default trace; uses sst2 database

-results_file <results.txt> Default REGRESS_RESULT.txt

-log_file <log_file.txt> Default stdout

-reset_memories [true/false]

TM

External Use 15

Parallelizing Hardware and Software Design Activities

• Stage 5− We have used Design Sync Command Interface to create Baseline− This in-turn helped to bring all the team members under the scope of this

baseline

• Stage 6− Regression Environment for every Design Release

TM

External Use 16

Run Phase

TM

External Use 17

Parallelizing Hardware and Software Design Activities

• Downloading and running the model on Emulator− Booking time and domains on PDBS− Logging into the Linux® host − Starting an interactive, or submitting a batch job on the Palladium server− Sourcing a run script to download the model, load memories and

initialize the target platform− Interacting with the active runtime environment using commands at the

QEL prompt (Interactive Mode)

TM

External Use 18

Parallelizing Hardware and Software Design Activities

• Validating SoC Internal Functionality ARM®, DMA, Multi-Master

Emulation System Infrastructure

TM

External Use 19

Parallelizing Hardware and Software Design Activities

• Validating Key External Interfaces DS5/CCS Tool, UART

In-Circuit Set Up and Connectivity Model

TM

External Use 20

Debug Phase

TM

External Use 21

Parallelizing Hardware and Software Design Activities

• Hardware Debug through better signal visibility

TM

External Use 22

Parallelizing Hardware and Software Design Activities

• Software Debug through software development tool

TM

External Use 23

Parallelizing Hardware and Software Design Activities

• More complex software activities have started taking place− Enabled more complex software activities to start Parallely

− “Mini and Many” tests have been tried upon to accomplish the goal of Verification and Software Development

− Initiation of early software development, has helped build confidence and reliability on the device and we are now in a position to get BootROM, Uboot and Linux up on pre-silicon emulation environment

TM

External Use 24

Session Summary

• Challenges involved in the hardware integration and software validation

• Methodology to be followed for setting up Emulation Environment to help start the software activities early

• Ease of Debug - as we have options to go with Verification Test Method or Software Test Method

• Learning's derived out of the feedbacks given by Tools Team, BootROM Team, Software Team

• Parallelizing hardware and software design activities by efficient use of an emulator, so we can have boot code, board support packages, and operating system applications available by the time the device tapes out

TM

External Use 25

Thinking Ahead

• Reuse of developed drivers for post-silicon validation

• FPGA-based emulation

• Setting up environment to validate high-speed interfaces like PCI, USB, etc

• Embedded processor in test bench

• Virtual UART and JTAG

TM

External Use 26

Acknowledgements

− Cadence Palladium Support Team

− Entire QorIQ LS1 family design team for their support

− QorIQ LS1 family BootROM, Uboot, Linux teams for sharing the information

TM

External Use 27

Questions and Answers

TM

© 2014 Freescale Semiconductor, Inc. | External Use

www.Freescale.com