Get documents about "Presentation kit
Document Sample
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
Action Interface
XVCs (eXtensible Verification Components) are
containers for verification IP with 2 layers:
User extensible library of actions
XVC
Driver layer integrates transactors to implement
the actions at physical- or transaction-level
Generator
Action interface connects to XVC Manager
Action Library
Schedules execution of actions
Communication of data and status
Driver
DUT interface
Abstraction neutral API for Action implementation Transactors
Choice of abstraction level to interface with DUT
Provides abstraction neutral delivery of:
Verification stimulus
Constraint information DUT Interface
Reference: “Verification Methodology Manual for SystemVerilog”, J.
Bergeron, E. Cerny, A. Hunter, and A. Nightingale
XVC Environment
Action Stimulus
Global Golden
Sequence Pass/Fail Vectors for
Test Log Test Log
Test Scenario Directed Tests
XVC Manager XVC(N)
Action Sequence Generator Driver
Parser
1:N
Action Execution Transactors
Action Action
Queue Channel
Execution Library DUT Interface
List
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 Scores
(abstract) (abstract)
DUT
(RTL)
Driver Monitor
(high to low) (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 XVC
(abstract) 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) System Integrator
ESL e.g., Published AMBA SPIRIT busDefinitions
Environment AMBA_Port AmbaPort
(e.g.,
SystemC)
<spirit:busInterfaces> <spirit:busInterfaces>
<spirit:name>ambaAPB</spirit:name> <spirit:name>ambaAPB</spirit:name>
IP-XACT <spirit:busSignal=“PADDR”> AMBA_Signal <spirit:busSignal=“PADDR”> AmbaPin
Description </spirit:busSignal> </spirit:busSignal>
</spirit:busInterfaces> </spirit:busInterfaces>
RTL
Environment
(e.g., Verilog)
AMBA_Signal ? AmbaPin
Applying IP-XACT to System Testbenches
Design
DUT architecture
IP-XACT XVC Test SPIRIT TLM
White-box
Manager
v1.4
Scenario Extensions
interface
DUT-to-testbench connectivity
monitor interface XVC
Monitors
XVC
Scoreboard
Declares Monitor Interfaces
verification component Added and deleted without
instance DUT
XVC AMBA
XVC changing connectivity
Peripheral
SPIRIT enabled AMBA Master Peripheral
Test Block
meta data
XVC Declares White-box Interfaces
AMBA Master
Design
Configuration
AMBA Controlled access to
Interconnect
designRef
AMBA
Peripheral
XVC
XVC
Peripheral
Peripheral component internals
Test Block
Test Block
Configurations for: -
Platform meta data XVC AMBA
XVC
Peripheral
Configure Design &
AMBA Master Peripheral
Generators
Memory Map
Test Block
Testbench
Instance views
Component
Bus Opaque Bridge
Vendor extensions
Address Space
Memory map
Generation scripts use LGI to
Loose Generator
Interface
Configured Testbench generate testbench for a given
configuration and tool
Generator environment
IP-XACT ESL extensions will
Chosen EDA
Environment enable verification testbench
IP-XACT v1.2 assembly
Maintaining Consistency Between SystemC and RTL System Designs
Multi-Level
XVC Methodology SPIRIT IP-XACT
Transactors
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
Address Value
communicate(){
pmem->driveTrans(info); 0 0000
clk
... 1 FFFF
} 2 FFFF
update() 3 0001
{ pmem: Master port Slave Port 1 4 FFFF
... driveTrans(info){ driveTrans(info){
5 FFFF
} slave->driveTrans(info) ...
} } 6 FFFF
7 FFFF
info 8 FFFF
(common communicate()
data structure) {
...
clk }
MyMaster update()
{
...
User-code }
Standard classes provided by CASI MySlave
AXI Protocol mapping to CASI
Address Value
communicate(){
clk
AXI_TM->driveTrans(info); 0 0000
clk
... 1 FFFF
} 2 FFFF
update() 3 0001
{ AXI_TM: Master port AXI_TS: Slave Port 4 FFFF
... driveTrans(info){ driveTrans(info){
5 FFFF
} slave->driveTrans(info) ...
} } 6 FFFF
7 FFFF
info 8 FFFF
(common communicate()
data structure) {
notifyEvent ...
clk }
AXI_Master update()
{
...
User-code }
Standard classes provided by CASI-AXI 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. XVC Methodology
2. Transactor Technology
3. 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
