Maintaining Consistency Between SystemC and RTL System DesignsMaintaining Consistency Between SystemC and RTL System Designs

Presenter: Christopher Lennard, PhD.

Authors:

ARM - Alistair Bruce, Andrew Nightingale, Nizar Romdhane, Christopher Lennard

Spiratech – MM Kamal Hashmi, Steve Beavis

IntroductionIntroduction

Testbench re-use is key to bringing system level design into standard SoC engineering practice

ESL has many benefits: Speed Flexibility Ease of design exploration

BUT quick and verifiable transfer to RTL is vital

A unified testbench for all levels guarantees consistency

The verification re-use strategy has 3 main pillars: Re-usable system testbench architecture (XVC Methodology) Interfacing multiple abstraction levels (Generated Transactors) Testbench configuration consistency

(IP-XACT from The SPIRIT Consortium)

Early results support the viability of this strategy

Testbench ArchitectureTestbench Architecture

XVC Methodology

A Modular Testbench ArchitectureA Modular Testbench Architecture

Common testbench architecture . . . Based on XVC Methodology

. . . across all levels of abstraction Using generated transactors

Structuring verification IP (VIP) for re-use

Delivering a VIP environment

Structuring verification IP (VIP) for re-useStructuring verification IP (VIP) for re-use

Architecture for testbench assembly and control

XVCs (eXtensible Verification Components) are containers for verification IP with 2 layers: User extensible library of actions Driver layer integrates transactors to implement

the actions at physical- or transaction-level

Action interface connects to XVC Manager Schedules execution of actions Communication of data and status

DUT interface Abstraction neutral API for Action implementation Choice of abstraction level to interface with DUT

Provides abstraction neutral delivery of: Verification stimulus Constraint information

XVC

Generator

Driver

Action Library

Transactors

Action Interface

DUT Interface

Reference: “Verification Methodology Manual for SystemVerilog”, J. Bergeron, E. Cerny, A. Hunter, and A. Nightingale

XVC Manager

Action Sequence

Parser

XVC(N)

XVC EnvironmentXVC Environment

DUT Response and Action Execution Progress

Action Command and Notification Event Flow

DriverGenerator

1:N

Action

Sequence

Test Scenario

Action

Library

TransactorsAction

Execution List

Action

Queue

Execution

ChannelDUT Interface

Global

Test Log

Golden

Test Log

Stimulus

Vectors for

Directed Tests

Pass/Fail

Delivering a VIP environmentDelivering a VIP environment

XVC Manager Coordinates test scenarios from external plain text files Abstracts away details of VIP environment Test scenarios can encapsulate common sequences of actions

XVCs (eXtensible Verification Components) A foundation for VIP – modular and scalable Re-usable across verification environments Can drive interconnect or external interfaces of DUT Can support other XVCs by monitoring state and

providing notification

Golden test logs

Multi-Level TestbenchMulti-Level Testbench

XVC Methodology

Multi-Level

Transactors

Multi-Abstraction TestbenchMulti-Abstraction Testbench

Goal: The system testbench can be applied to all levels of abstraction without alteration

Implies: Stimulus must be applied to DUT through a driver that can handle multiple abstraction levels

Implementation: Deploy multi-level drivers called Transactors to interface DUT and the system testbench

Driving a DUT through TransactorsDriving a DUT through Transactors

Given: - Interface protocol Abstraction levels Mapping between levels

Can write transactors to bridge between levels

Traditionally, manually written as 2 unidirectional components: Driver Monitor

Need bi-directional transactors for XVCs as they must both drive and monitor

Manually Written TransactorsManually Written Transactors

Tests(abstract)

Scores(abstract)

Driver(high to low)

Monitor(low to high)

DUT(RTL)

A. Current, manually written, Advanced Verification System

Interface SpecificationInterface Specification

Transactors are: Complex to design Time consuming to build and test Often need to connect > 2 levels of abstraction

A formal Interface Specification captures: Temporal and behavioural aspects at multiple levels Mapping between levels

Generate transactors from Interface Specification Drive and monitor Automated connectivity between levels of abstraction

Generated Bi-Directional TransactorsGenerated Bi-Directional Transactors

Tests& Scores (abstract)

Transactor(multi-level)

System Under Test(mixed – Emulation, RTL, CA, PVT, PV)

B. Mixed Level XVC-enabled Advanced Verification System

XVCManager

Transactors for Standard TLM InterfacesTransactors for Standard TLM Interfaces

SystemC method calling interface for each level of abstraction For cycle-accurate, built on the ARM RealView® ESL APIs

CASI : Cycle-Accurate Simulation Interface Cycle-based TLM transport layer supporting any

bus protocol http://www.arm.com/products/DevTools/RealViewESLAPIs.html

For progammers-view, would support PV / PVT OSCI proposal Event-based TLM transport layer for abstract models

Multi-level transactor for AXI built on top of theTLM transport layer Passes pointer to generic container Populated and manipulated during transaction lifetime Transactor can pack/unpack between container and RTL signals This bridges between SystemC TLM and RTL

DUT and Testbench ConfigurationDUT and Testbench Configuration

Multi-abstraction design flow requires automatic alignment of testbench with design configuration e.g., register map used by integration test may change

Alignment achieved using design meta-data Describe design configuration Automate design and verification set-up

Common meta-data needed to support multi-vendor flow

The SPIRIT Consortium is providing specifications to help standardise meta-data

Testbench ConsistencyTestbench Consistency

XVC Methodology

Multi-Level

Transactors SPIRIT IP-XACT

The SPIRIT Consortium SpecificationsThe SPIRIT Consortium Specifications

IP-XACT is an XML schema and semantics providing: Unified authoring, exchange and processing of design meta-

data Complete API for meta-data exchange and database querying

An IP-XACT enabled design environment has: Libraries of component descriptions Definitions of component interfaces

Design meta-data describes: Component instances Connectivity

Generator plug-ins support automated design configuration LGI (Loose Generator Interface) meta-data dumping mechanism TGI (Tight Generator Interface) API based on SOAP

Applying IP-XACT to the System TestbenchApplying IP-XACT to the System Testbench

Current version of The SPIRIT Consortium Spec, v1.2 Complete for RTL design and verification component descriptions Released as IP-XACT into IEEE 1685 process

It enables the automated composition, integration and configuration of an RTL verification environment

Testbench specified as Component instances (design and verification) Connections between components

Supports verification components (at RTL) Monitor interfaces White-box interfaces

IP-XACT enabled meta-data provides language (and vendor) independent description of the testbench configuration and connection to DUT

Describing System Architectures with IP-XACTDescribing System Architectures with IP-XACT

IP Supplier (External / Internal) System Integrator

RTL Environment

(e.g., Verilog)

IP-XACT Description

<spirit:busInterfaces>

<spirit:name>ambaAPB</spirit:name>

<spirit:busSignal=“PADDR”>

</spirit:busSignal>

</spirit:busInterfaces>

<spirit:busInterfaces>

<spirit:name>ambaAPB</spirit:name>

<spirit:busSignal=“PADDR”>

</spirit:busSignal>

</spirit:busInterfaces>

AMBA_Signal AmbaPin?

AMBA_Signal AmbaPin

e.g., Published AMBA SPIRIT busDefinitionsESL Environment

(e.g., SystemC)

AMBA_Port AmbaPort

Applying IP-XACT to System TestbenchesApplying IP-XACT to System Testbenches

DUT

XVC Manager

XVCAMBA Master

AMBAInterconnect

AMBAPeripheral

XVCPeripheral Test Block

AMBAPeripheral

XVCPeripheral Test Block

XVCAMBA Master

XVCAMBA Master

AMBAPeripheral

XVCPeripheral Test Block

XVCPeripheral Test Block

SPIRIT TLM Extensions

verification component instance

XVCMonitors

XVCScoreboard

monitor interface

White-box interface

ComponentMemory map

Bus Opaque Bridge

Memory Map

Address Space

Design

Design Configuration

designRef

Platform meta data

Generators

Instance views

Vendor extensions

Configurations for: -

TestScenario

Generator

Configured Testbench

Chosen EDA Environment

Loose Generator Interface

SPIRIT enabled meta data

DUT architecture

DUT-to-testbench connectivity

Declares Monitor Interfaces Added and deleted without

changing connectivity

Declares White-box Interfaces Controlled access to

component internals

Configure Design & Testbench

Generation scripts use LGI to generate testbench for a given configuration and tool environment

IP-XACT ESL extensions will enable verification testbench assembly

IP-XACT v1.2

IP-XACT

v1.4

Maintaining Consistency Between SystemC and RTL System DesignsMaintaining Consistency Between SystemC and RTL System Designs

XVC MethodologyMulti-Level

TransactorsSPIRIT IP-XACT

Scheduling for Cycle-Based TLMScheduling for Cycle-Based TLM

Initialization

Execution

Termination

Create

Configure

Init

Interconnect

Reset

Communicate

Update

Terminate

Destruct

Asynchronous Shared Memory InterfaceAsynchronous Shared Memory Interface One of the CASI communication mechanisms

Example: driveTransaction communication

MyMasterMyMaster

info(common

data structure)

clk

communicate(){ pmem->driveTrans(info); ...}update(){ ...}

MySlaveMySlave

FFFF8

FFFF7

FFFF6

FFFF5

FFFF4

00013

FFFF2

FFFF1

00000

ValueAddress

Slave Port 1driveTrans(info){ ...}

User-code

Standard classes provided by CASI

communicate(){ ...}update(){ ...}

clk

pmem: Master portdriveTrans(info){ slave->driveTrans(info)}

AXI Protocol mapping to CASI AXI Protocol mapping to CASI

clk

AXI_MasterAXI_Master

info(common

data structure)

clk

communicate(){ AXI_TM->driveTrans(info); ...}update(){ ...}

AXI_SlaveAXI_Slave

FFFF8

FFFF7

FFFF6

FFFF5

FFFF4

00013

FFFF2

FFFF1

00000

ValueAddress

AXI_TS: Slave PortdriveTrans(info){ ...}

User-code

Standard classes provided by CASI-AXI

communicate(){ ...}update(){ ...}

clk

AXI_TM: Master portdriveTrans(info){ slave->driveTrans(info)}

notifyEvent

Unified Testbench in PracticeUnified Testbench in Practice

Techniques applied to a subsystem testbench PL190 Vectored Interrupt Controller modelled at RTL AHB interconnect modelled at PVT, with RealView

ESL APIs interfaces

Building the System and Testbench Meta-data design file specifies required components and

VIP environment Parameters of design and verification components

(e.g. bus_width) Design configuration file

Creating and inserting the Transactors Select and instantiate transactors as required by abstraction

level selections in meta-data Transactors generated and configured using parameters

captured in meta-data

Testbench in AMBA DesignerTestbench in AMBA Designer

Executing a SimulationExecuting a Simulation

Example shows an integration test

Consistency of levels demonstrated by comparison of results at each level

Simulation speed in mixed level simulations dominated by RTL (~95% spent in RTL)

Tenison VTOC Generate Abstracts RTL to cycle accurate C++ Minimises impact of RTL on simulation speed

An alternative is to run the RTL on an emulation platform

Multi-Level SimulationMulti-Level Simulation

Conclusions and FuturesConclusions and Futures

Three key concepts enable a unified system testbench:1. XVC Methodology2. Transactor Technology3. The SPIRIT Consortium IP-XACT meta-data specifications

Is in use today

Future industry standardisation SystemC PV level interfaces IP-XACT for abstract design specification

Methodology will soon be applicable across the entire system-level modelling and verification flow

XVCs Transactors IP-XACT