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 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 Environment DUT Response and Action Execution Progress Action Command and Notification Event Flow DriverGenerator 1:N Action Sequence Test Scenario Action Library Transactors Action Execution List Action Queue Execution Channel DUT Interface Global Test Log Golden Test Log Stimulus Vectors for Directed Tests Pass/Fail

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 XVC Methodology Multi-Level 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) Driver (high to low) Monitor (low to high) DUT (RTL) 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) Transactor (multi-level) System Under Test (mixed – Emulation, RTL, CA, PVT, PV) B. Mixed Level XVC-enabled Advanced Verification System XVC Manager

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  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 XVC Methodology Multi-Level 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 RTL Environment (e.g., Verilog) IP-XACT Description ambaAPB ambaAPB AMBA_Signal AmbaPin ? AMBA_Signal AmbaPin e.g., Published AMBA SPIRIT busDefinitions ESL Environment (e.g., SystemC) AMBA_Port AmbaPort

Applying IP-XACT to System Testbenches 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 Designs XVC Methodology Multi-Level Transactors SPIRIT IP-XACT

Scheduling for Cycle-Based TLM Initialization Execution Termination Create Configure Init Interconnect Reset Communicate Update Terminate Destruct

Asynchronous Shared Memory Interface One of the CASI communication mechanisms Example: driveTransaction communication MyMaster info (common data structure) clk communicate(){ pmem->driveTrans(info);... } update() {... } MySlave FFFF FFFF ValueAddress Slave Port 1 driveTrans(info){... } User-code Standard classes provided by CASI communicate() {... } update() {... } clk pmem: Master port driveTrans(info){ slave->driveTrans(info) }

AXI Protocol mapping to CASI clk AXI_Master info (common data structure) clk communicate(){ AXI_TM->driveTrans(info);... } update() {... } AXI_Slave FFFF FFFF ValueAddress AXI_TS: Slave Port driveTrans(info){... } User-code Standard classes provided by CASI-AXI communicate() {... } update() {... } clk AXI_TM: Master port driveTrans(info){ slave->driveTrans(info) } notifyEvent

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 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