early software development through palladium emulation for a complex soc
Post on 11-Aug-2015
64 Views
Preview:
TRANSCRIPT
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
top related