Title Name? and address? · analog Safety & reliability Low Power design AMS IP Digital IP Security Hardware dependent software Embedded AMS system Identification products Automotive

Virtual Prototyping 45th System Architecture Study Group

Jos Verhaegh

June 5th 2012

Virtual Prototyping/ NXP Design Methodologies / Jos Verhaegh, June 5th 2012

2

Contents

NXP Semiconductors

Virtual platforms

Modeling Methodology & Libraries

Application of Virtual Platforms in NXP

Conclusions


3

Contents

NXP Semiconductors

Virtual platforms



Conclusions


4

NXP Semiconductors

President & CEO: Rick Clemmer

Headquarters: Eindhoven, The Netherlands

Established in 2006 (formerly a division of Philips)

50+ years of experience in semiconductors

Focus: High Performance Mixed Signal products

Businesses:

– Automotive

– High Performance Mixed Signal

– Identification

– Standard Products

Owner of NXP Software, a fully independent

software solutions company


5

System Design Challenges – Examples

RFA

RFB

DP

VSS VDD SA SB SDA SCL IO2 IO1

CLK

DM

AMS IP Digital IP

Baseband

USB controller

RF PHY

RF PHY Central Processing

Unit (CPU)

HW accelerator

Memory

Power Management Unit ADC I2C

HSIO contr. Clock

generation

USB PHY

bridge

HSIO PHY

Identification products

Automotive products


6

System Design Challenges – Examples

RFA

RFB

Baseband

DP USB controller

VSS VDD

RF PHY


Unit (CPU)

Memory

Power Management Unit

SA SB

ADC

SDA SCL

I2C

IO2 IO1

HSIO contr. CLK Clock

generation

DM

HW accelerator

USB PHY

bridge

HSIO PHY

Multi-standard

Digital-assisted analog

Safety & reliability

Low Power design

AMS IP Digital IP

Security

Hardware dependent software

Embedded AMS system

Identification products

Automotive products


7

Contents

NXP Semiconductors

Virtual platforms



Conclusions


Virtual platforms

8

Baseband

USB controller

RF PHY


Unit (CPU)

Memory

Power Management Unit ADC I2C

HSIO contr. Clock

generation

HW accelerator

USB PHY

bridge

HSIO PHY

AMS IP

Digital IP

Simulation model of real hardware at high abstraction level


Instruction Set Simulator (ISS) Simulation model of embedded processor

– Typically provided by core vendor ( ARM,

Tensilica,… )

Executable software image identical to final

image running on silicon (Binary compatible)

Allows to connect to SW debugger ( ARM

Realview, Keil uVision, Lauterbach,…)

9


Transaction Level Modelling

10


Reference platform generation

11

Initial SystemC platform automatically generated from system register map (consistent with RTL)

Generated SystemC reference platform contains ISS

The Reference platform is ready for basic SW development (register read/write behavior)

Behavior can be added to SystemC IP model

templates

System Memory map specification

Toplevel/module generator

Toplevel/module sources

Manually refined modules


IEEE 1666-2005 SystemC

a set of C++ classes and macros which enables hardware description constructs in C++

provide an event-driven simulation kernel in C++

OSCI TLM 2.0

Transaction level modeling of communication between digital modules

Function calls abstract away pin level signals

SystemC Modeling Library (SCML)

Reduce the modeling effort and learning curve

Enable model reuse and refinement

OSCI SystemC-AMS 1.0

To abstract analog behavior and communication

SystemC standards & libraries

12


13

Contents

NXP Semiconductors

Virtual platforms



Conclusions


14

Modeling paradigm

Multidimensional problem

How to model for maximum speed?

How to model for full accuracy?

How to minimize the modeling effort?

How to make models reusable?

How to deal with legacy models?

… and how to achieve all this in a simple way?

Different kind of models with different properties:

Processor models

Interconnect models

Memory subsystem models

Peripherals

► Need for clear modeling strategy based on standards

Speed

Accuracy

Effort

Reusability Availability Simplicity

Observability Controlability

….


15

Minimizing the modeling effort (…and making models available earlier)

Simplify modeling

Methodology and guidelines

Separation of concerns

Predefined building blocks (Modeling libraries)

Standards based modeling

TLM2.0 compliancy for Interoperability between models (released std)

CCI compliancy for standardized configuration, control & inspection of models (under dev)

To enable building of re-usable models (model portfolio)

To enable easy integration of 3rd party models

Automatic generation

Translate RTL into CA SystemC (SL) by using Carbon tooling – Suitable for verification & performance analysis,

but too slow for SW development use case

Generate modeling template (user only fills specific functionality)

Generation/wrapping from functional tools/model – CoWare SPD, Matlab Simulink, legacy C++


16

Modeling for speed

speed

Cycle-Accurate ISS

Instruction-Accurate ISS

Code-Morphing ISS

Host Code Emulation

100-10 KHz

10-1 MHz

100 MHz

Minimize the number of events/context switches

Coarse grain communication – Model cycle-by-cycle communication only when strictly required

Coarse grain computation – Group timed operations, call wait(…) only when synchronization is required

Careful usage (strategy) of sc_threads, sc_methods, sc_events, etc

Avoid (at all) using sc_clocks

Efficient code

Profiling tools (gprof, vtune)

Efficient SystemC kernel

Parallel/distributed implementation


17

Modeling accuracy

Functional accuracy is not an issue

Test strategy is mandatory (qualification)

Loosely timing can be modeled easily

Time can be estimated or extracted from existing models

For many use cases is enough!

Approximate and Cycle Accurate timing is very hard to achieve

Manual modeling (it can be as hard as RTL)

Automated techniques (extraction from RTL to TLM)

Define accuracy windows, window size depends on the use-case

Verification requires 100% accuracy, i.e. window size is 1 cycle

Window size for bus exploration should be 1-10 cycles, accuracy >90%

Window size for software performance measurement can be >100k cycles, accuracy >90%


18

Coding Styles

Loosely-timed – Only sufficient timing detail to boot O/S and run multi-core systems

– Processes can run ahead of simulation time (temporal decoupling)

– Each transaction has 2 timing points: begin and end

– Uses direct memory interface (DMI)

Approximately-timed – aka cycle-approximate or cycle-count-accurate

– Sufficient for architectural exploration

– Processes run in lock-step with simulation time

– Each transaction has 4 timing points (extensible)

Guidelines only – not definitive


19

time 0 1 2 3 4 5 6 7 8

UT

T1 T2

(T) transaction (function call)

LT T1 T2

AT request1 request2

response1 response2

CA

address1

data1

address2

data2

status1 status2

OSCI transaction level Modeling styles (II)

No timing only ordering

2 timing points No pipelining

4 timing points Pipelining

one-to-one correspondence

between the states of the model and a

RTL reference


20

Use Cases, Coding Styles and Mechanisms

Blocking interface

Non-blocking interface

DMI Sockets Quantum Generic payload

Mechanisms

Use cases

Software development

Architectural analysis

Hardware verification

Software performance

Loosely-timed

Approximately-timed

TLM-2 Coding styles

Phases


21

Objectives modeling libraries:

Reduce the modeling effort and learning curve

Enable model reuse and refinement

Improve configurability of models

Align with industry standards – OSCI TLM 2.0 & CCI

SystemC AMS extensions library available

IEEE 1666 SystemC

TLM 2.0 SCV

SCML

IF adaptors monitors

SCML – CoWare SystemC modeling Library • Separation of behavior, communication & timing

• Focus on communication refinement generic interfaces + specific adaptors

TLM 2.0

IEEE 1666 SystemC

AMS

Layered modeling approach


22

SystemC Modeling Library (SCML)

SystemC v2.2

• Hardware focused

• Modules

• Channels

• Threads

• Signals

SCML

• Raise modeling abstraction

• Minimize modeling effort

• Memory map focus

• Functionality visible to SW developers

Virtual Platforms

• Fast processor models

• Debugging

• SW analysis


23

Why SCML?

SCML goals

Simulation speed – Enable ‘backdoor’ access (supported by TLM2.0 DMI)

Ease of modeling – Abstraction through modeling objects

– Configuration through properties

Debugging & analysis – Visualization in VPA

– Standardized modeling style

Interoperability – Source code version of library available

Reuse – Support multiple use cases

Maintainability – Enforced modeling style to guarantee maintainability


24

TLM2.0 LT use case related

SCML overview

Target objects

memory

alias

register

bitfield

router

adapters

Initiator objects

dmi_handler

socket

post interface & port

array

fifo

pool

Clock objects

Clock

divided_clk

clk_counter

clk_gate

Utilities

Commands

Loader

Properties

Property server

Task modeling

Event

Task

Scheduler

Processing model


25

SCML overview

initiator target

TL

M2

GP

LT

bu

s

dmi_handler

Quantum keeper Initiator socket

target socket

target adapter

memory

memory_alias register


26

SCML Target Modeling Pattern

TLM Target

timing

behavior TLM2.0 target

adapter

timing

storage and synchronization

TLM2.0 interface

TLM2.0 GP interface

TLM2.0 GP interface

TLM2.0 bus

transaction processing

behavior1

behavior2

behavior3

storage alias


27

Automated System Integration

IP Delivery Design Environment

• IP packaging • Design integration

• RTL/TLM netlist generation • Verification software generation

• PSL assertion generation

• Documentation generation • Build and simulation automation • Third party IP and tool integration

System Integration Automation

Design Views

RTL

VERIFICATION

METADATA

DOCUMENT

SLMODEL

Mixed Language VHDL Verilog

SystemC

Mixed Level RTL & TLM

Mixed Signal Verilog-AMS


28

Contents

NXP Semiconductors

Virtual platforms



Conclusions


Early SW development on SystemC platform Introduction

NXP products contain both hardware and software

The software is executed by the hardware

Different types of software development in NXP

Firmware, driver software, middleware, …

Traditionally software development starts when

hardware is available

RTL, FPGA, silicon,…

29

System Design HW Design HW

Implementation SW Design

SW Implementation


Early SW development on SystemC platform Our contribution & added value

Our contribution is virtualization of hardware platforms

Early availability of hardware models for software development

Existing software development environment can be used with virtual platform

Our added value is to reduce product development times

Software development can start before hardware RTL model is available

30

Virtual platform SW Design SW

Implementation


Implementation


Implementation SW Design

SW Implementation


31

Early SW development on SystemC platform

advantages Shorter TtM

Early SW development when RTL/Si is not available yet

Concurrent HW/SW development

Real High speed SW development environment

Fast ARM/Keil models

Binary compatible with final SW on Si

SW debug capabilities using RVD/Keil uVision

Better product quality

Synchronized debug environment between Hard- and Software

Full visibility inside SW on CPU (ARM RVD/Keil uVision), inside RTL (SimVision) and TLM testbench

Ability to simulate complete system


32


ARM Cortex-M0

IA ISS

APB bridge

IP1

IP2

IP3

Analog

intf

Clock Gen

Mode Contr

UART

GPIO

I2C

Scan tst

contr

AHB Bus Mtrx

ROM RAM SC register view

IA ISS

SystemC TLM2.0 Loosely timed model

RTL DUT

CA ISS

APB Bus

reg view reg view reg view

reg view reg view reg view reg view reg view reg view reg view

Initial SystemC platform and target peripheral register views are automatically generated from system register map information

Generated SystemC reference platform contains ISS of ARM Cortex M0 – Keil ISS connected to uVision (windows only) – Fastmodel ISS connected to RVD (both windows and linux)

An OS can be booted on the SystemC reference platform

The Reference platform is ready for basic SW development (register read/write behavior)


33


ARM Cortex-M0

IA ISS

APB bridge

IP1

IP2

IP3

Analog

intf

Clock Gen

Mode Contr

UART

GPIO

I2C

Scan tst

contr

AHB Bus Mtrx

APB Bus

IP1

reg view

IP2

reg view

IP3

reg view

Analog

intf

reg view Clock Gen

reg view Mode Contr

reg view

UART

reg view

GPIO

reg view

I2C

reg view Scan tst

contr

reg view

ROM RAM

ROM intf

RAM intf

ROM RAM

reg view reg view

Behavior can be added to SystemC IP model templates

The Reference platform is ready for further (driver/application) SW

development

SC register view

IA ISS


RTL DUT

CA ISS



HW/SW co-debugging

34

PN547 virtual platform

Test environment

HW model debugger (Visual Studio)

SW debugger (ARM RVD/Model debugger)

Test database

HW register values


35

Architecture exploration on SystemC platform

Performance metrics based on transactions rather than signals

Simplifies performance analysis

Need monitors that translate signal level to TLM

Fast modeling of traffic generators and other IPs

Generic IP models can be used

IP models can be highly configurable

Abstract behavior sufficient

Easy debug of HW/SW

Full visibility inside SW on CPU (ARM RVD/Keil uVision), inside RTL (SimVision) and TLM testbench

C++ debugging of IP models

Higher simulation speed than RTL

Abstracted behavior simulates faster


36

AHB Bus Mtrx

ROM intf

RAM intf

ROM RAM

reg view reg view

ARM Cortex-M0

IA ISS

IP1

IP2

IP3

Analog

intf

Clock Gen

Mode Contr

UART

GPIO

I2C

Scan tst

contr

Architecture exploration on SystemC platform

ARM Cortex M0 Instruction Accurate ISS is replaced by Carbon Cycle Accurate ISS

Critical components for Performance analysis are replaced by their RTL counterpart

Performance analysis is done through co-simulation

ARM Cortex-M0

CA ISS (Carbon)

APB bridge

APB Bus

reg view reg view reg view


ROM interf

RAM intf

AHB Bus Mtrx

ROM RAM

AHB TX

Mon.

SC register view

IA ISS


RTL DUT

CA ISS


37

IP1

IP3

Analog

intf

Clock Gen

Mode Contr

UART

GPIO

I2C

Scan tst

contr

RTL IP verification using SystemC platform

RTL IP functional verification through

Reuse of SystemC platform for SW development

Reuse of co-simulation setup for architecture exploration

ARM Cortex-M0

IA ISS

ROM interf

RAM intf

APB bridge

AHB Bus Mtrx

ROM RAM

APB Bus

reg view reg view

reg view

IP2

reg view

reg view


IP2

TLM2SL TX

SC register view

IA ISS


RTL DUT

CA ISS


RTL System verification with Reusable Test

Infrastructure (RTI)

ARM FastModel Cortex-M3 (Instruction-accurate ISS)

– Includes interrupt controller

– Includes software compilation tool chain

– Includes software debug solution

TLM bus

TLM memory (ROM and RAM)

TLM timer (WDG and TIM)

TLM-to-AHBlite signal slave transactor – Includes AHB clock and reset

TLM clock generator

TLM reset generator

TLM CREG I/O

38 *TLM: Transaction Level Model

*IRQ: Interrupt request

BUS ARM irq

RAM

WDG

AHB

AHB

AHB

CREG

TIM

ROM


RTL System verification with Reusable

Test Infrastructure (RTI)

39

Coproc1

CoProc2

RAM 32KB

RAM 32KB

RAM 16KB

SSP

UART

I2C

ARM M3

RAM 16KB

ARM RTI

ahb2vpb

ahb2vpb

ahb2vpb

usart ip

ssp ip

i2c ip

RTL Design

RTI

DMA

msg

msg

1

msg

msg

2

3

4

5

CH

EC

K!!


40

Contents

NXP Semiconductors

Virtual platforms



Conclusions


41

Conclusions

BL usage in different projects shows the added value of

virtual platforms (TtM, TtV, quality)

Standards based SystemC modelling methodology enables

easy creation and maintainability of abstract system level

models

IP-XACT based Automatic System Integration and

Generation is key

Virtual platforms serve a wide variety of use-cases


THANKS

Questions?

42

Documents

Title Name? and address? · analog Safety & reliability Low Power design AMS IP Digital IP Security Hardware dependent software Embedded AMS system Identification products Automotive