Transcript Presentation kit

Maintaining 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
Introduction
 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 Architecture
XVC Methodology
A 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-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
Action Interface
XVC
Generator
Action Library
Driver
Transactors
 Provides abstraction neutral delivery of:


Verification stimulus
Constraint information
Reference: “Verification Methodology Manual for SystemVerilog”, J.
Bergeron, E. Cerny, A. Hunter, and A. Nightingale
DUT Interface
XVC Environment
Action
Sequence
Test Scenario
Global
Test Log
Pass/Fail
Golden
Test Log
Generator
Directed Tests
Driver
1:N
Action
Action
Execution
List
Vectors for
XVC(N)
XVC Manager
Action Sequence
Parser
Stimulus
Queue
Action
Library
Execution
Channel
Transactors
DUT Interface
Action Command and Notification Event Flow
DUT Response and Action Execution Progress
Delivering 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 Testbench
Multi-Level
XVC Methodology
Transactors
Multi-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 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 Transactors
Tests
(abstract)
Scores
(abstract)
DUT
(RTL)
Driver
(high to low)
Monitor
(low to high)
A. Current, manually written, Advanced Verification System
Interface 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 Transactors
Tests
& Scores
(abstract)
XVC
Manager
System Under Test
(mixed – Emulation,
RTL, CA, PVT, PV)
Transactor
(multi-level)
B. Mixed Level XVC-enabled Advanced Verification System
Transactors 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 the
TLM 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 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 Consistency
Multi-Level
XVC Methodology
Transactors
SPIRIT IP-XACT
The 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 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-XACT
IP Supplier (External / Internal)
ESL
Environment
System Integrator
e.g., Published AMBA SPIRIT busDefinitions
AmbaPort
AMBA_Port
(e.g.,
SystemC)
<spirit:busInterfaces>
<spirit:busInterfaces>
<spirit:name>ambaAPB</spirit:name>
IP-XACT
Description
<spirit:busSignal=“PADDR”> AMBA_Signal
<spirit:name>ambaAPB</spirit:name>
<spirit:busSignal=“PADDR”> AmbaPin
</spirit:busSignal>
</spirit:busSignal>
</spirit:busInterfaces>
RTL
Environment
(e.g., Verilog)
AMBA_Signal
</spirit:busInterfaces>
?
AmbaPin
Applying IP-XACT to System Testbenches
Design
IP-XACT
XVC
Manager
Test
Scenario
SPIRIT TLM
Extensions
v1.4
monitor interface
XVC
Monitors
XVC
Scoreboard
DUT
XVC
AMBA Master
AMBA
Peripheral
XVC
Peripheral
Test Block
XVC
AMBA Master
Design
Configuration
AMBA
Interconnect
designRef
Generators
XVC
AMBA Master
AMBA
Peripheral
AMBA
Peripheral
XVC
Peripheral
Test Block
Memory Map
Instance views
Vendor extensions

DUT-to-testbench connectivity

Declares Monitor Interfaces
Bus Opaque Bridge
Address Space
Loose Generator
Interface
Component
Memory map
Chosen EDA
Environment
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
Configured Testbench
Generator
IP-XACT v1.2


XVC
XVC
Peripheral
Peripheral
Test Block
Block
Test
Configurations for: Platform meta data
DUT architecture

verification component
instance
SPIRIT enabled
meta data
White-box
interface

Maintaining Consistency Between SystemC and RTL System Designs
XVC Methodology
Multi-Level
Transactors
SPIRIT IP-XACT
Scheduling for Cycle-Based TLM
Initialization
Create
Configure
Init
Execution
Interconnect
Reset
Communicate
Termination
Update
Terminate
Destruct
Asynchronous Shared Memory Interface
 One of the CASI communication mechanisms
 Example: driveTransaction communication
clk
communicate(){
pmem->driveTrans(info);
...
}
update()
{
pmem: Master port
driveTrans(info){
...
slave->driveTrans(info)
}
}
Slave Port 1
driveTrans(info){
...
}
info
(common
data structure)
MyMaster
User-code
Standard classes provided by CASI
clk
Address
Value
0
0000
1
FFFF
2
FFFF
3
0001
4
FFFF
5
FFFF
6
FFFF
7
FFFF
8
FFFF
communicate()
{
...
}
update()
{
...
}
MySlave
AXI Protocol mapping to CASI
clk
clk
communicate(){
AXI_TM->driveTrans(info);
...
}
update()
{
AXI_TM: Master port
driveTrans(info){
...
slave->driveTrans(info)
}
}
info
(common
data structure)
AXI_Master
User-code
Standard classes provided by CASI-AXI
AXI_TS: Slave Port
driveTrans(info){
...
}
notifyEvent
clk
Address
Value
0
0000
1
FFFF
2
FFFF
3
0001
4
FFFF
5
FFFF
6
FFFF
7
FFFF
8
FFFF
communicate()
{
...
}
update()
{
...
}
AXI_Slave
Unified 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 Designer
Executing 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 Simulation
Conclusions and Futures
 Three key concepts enable a unified system testbench:
1.
2.
3.
XVC Methodology
Transactor Technology
The SPIRIT Consortium IP-XACT meta-data specifications
 Is in use today
XVCs Transactors IP-XACT
 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