Early Software Development Through Emulation for a Complex SoC

Transcription

1 Early Software Development Through Emulation for a Complex SoC FTF-NET-F0204 Raghav U. Nayak Senior Validation Engineer A P R TM External Use

2 Session Objectives After completing this session you will be able to: Know about Freescale Emulation System Architecture Methodology followed to integrate multicore SoC from scratch Procedures used to simplify debug on both hardware and software aspects Understand how the concept of many number of mini test cases has helped the development of Freescale QorIQ LS series project using Emulator Platform External Use 1

3 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 Demonstration Acknowledgements and references External Use 2

4 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 x 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 External Use 3

5 Design, Size, Complexity, Life Stage External Use 4

6 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 External Use 5

7 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 realtime environment and/or testbenches Sometimes can reproduce bugs in design which cannot easily be recreated or debugged in the SoC verification testbench External Use 6

8 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 External Use 7

9 Compile Phase External Use 8

10 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) External Use 9

11 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 External Use 10

12 Parallelizing Hardware and Software Design Activities Stage 3 Bare Metal Infrastructure clubbing both C and Assembly ARM Vector Table Initialization Assembly ARM Boot Sequence (Modes, Stack, MMU, Cache, FPU etc) Assembly DDR Controller Initialization Assembly Testcase Section Assembly, C, C++ External Use 11

13 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 External Use 12

14 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 External Use 13

15 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 -testcase_dir <path to bin files> -tc_timeout [time in seconds] -trace_enable [true/false] -trace_start_at_state [name of state] -pre_run_tcl <pre_run.xel> -post_run_tcl <post_run.xel> -sdl_file <file.tdf> -trace_file <trace_file> -results_file <results.txt> -log_file <log_file.txt> -reset_memories [true/false] Prints this usage message Testcase Directory Default 60s Default false (typically tcexec) Sourced if file exists Sourced if file exists Default $scripts_dir/tc_sdl.tdf Default trace; uses sst2 database Default REGRESS_RESULT.txt Default stdout External Use 14

16 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 External Use 15

17 Run Phase External Use 16

18 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) External Use 17

19 Parallelizing Hardware and Software Design Activities Validating SoC Internal Functionality ARM, DMA, Multi-Master Freescale Emulation System Infrastructure External Use 18

20 Parallelizing Hardware and Software Design Activities Validating Key External Interfaces DS5/CCS Tool, UART Freescale In-Circuit Set Up and Connectivity Model External Use 19

21 Debug Phase External Use 20

22 Parallelizing Hardware and Software Design Activities Software Development Tool Debug through better signal visibility External Use 21

23 Parallelizing Hardware and Software Design Activities Software Debug through software development tool External Use 22

24 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 External Use 23

25 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 External Use 24

26 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 External Use 25

27 Demonstration External Use 26

28 Acknowledgements and References Acknowledgements Entire QorIQ LS1 family design team for their support QorIQ LS1 family BootROM, Uboot, Linux teams for sharing the information Palladium support team References External Use 27

29 Questions and Answers External Use 28

30 Freescale Semiconductor, Inc. External Use