Presentation kit
Download
Report
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