L. Maillet-Contoz, STMicroelectronics
Workshop - November 2011 - Toulouse
System Platforms Group
 10 years experience in SoC modeling
 Definition of ESL methods and tools
 Deployment in ST & ST-Ericsson product groups since 2003
 Contributions to projects of the various products groups
 Drive standards
 Corporate Member, OSCI and Accellera
 Represents ST at both Boards of Directors
 Several donations to the Technical Working Groups


TLM1 & TLM2, CCI
IP-Xact
 Former Chair of OSCI board & TLM WG, current Chair of OSCI
Verification WG
 Current chair of Accellera IP-Xact TSC
 Vice Chair of IEEE 1666-2011 Technical Committee
Workshop - November 2011
© STMicroelectronics
2
Agenda
 Motivations for SoC TLM modeling
 Languages and abstractions for System Level
Design
 Current standards for interoperability
 ST TLM Framework
 Discussion and conclusion
© STMicroelectronics
3
Objectives: face SoC increasing complexity
 A camera-telephone?
Version 1998
Version 2008
© STMicroelectronics
4
Motivations for Virtual Prototyping
SoC architecture exploration
- Too late
- Too costly
+ Accurate
- Too late
- Too slow
+ Accurate
HDL simulation
FPGA prototype
Functional validation environment
Pre-silicon software development
Soc
Virtual Prototype
© STMicroelectronics
5
SoC Virtual Prototyping
SW
SW
Input devices
Transaction Level
Models
(HW blocks)
SW
SW
Output devices
H.M.P. SoC
© STMicroelectronics
6
Agenda
 Motivations for SoC TLM modeling
 Languages and abstractions for System Level
Design
 SystemC and IP-Xact
 Loosely and Approximately Timed modeling styles
 Impact on modeling effort and simulation speed
 Current standards for interoperability
 ST TLM Framework
 Discussion and conclusion
© STMicroelectronics
7
Different platforms for different use models
 All activities do not
require cycle accuracy
 Engineering effort to be
balanced with benefits
 Fast / precise trade-off
© STMicroelectronics
8
Languages for System Level Design
General Purpose
Languages
Well known
 Standard
 Not appropriate for
hardware modeling
C, C++, Java, …
Dedicated
Languages
Well defined semantics
 Proprietary
 Lack of support
 No model exchange
SpecC, HardwareC, …
Hardware
Description
Languages
VHDL, Verilog, …
 Nice for hardware modeling
 Not appropriate for high level modeling
Slow
© STMicroelectronics
9
Different abstraction levels
AL
Algorithmic Model
Level of Abstraction
PV – Loosely Timed
Programmer’s View
PVT – Approximately Timed
Programmer’s View + Timing
CA
Cycle Accurate Level
RTL
Register Transfer Level
• prior to HW/SW partition
• post HW/SW partition
• models bit-true behavior, register bank, data
transfer, system synchronization
TLM supported
• PV plus timing annotation
abstraction levels
• timed IP models
• refined communication models
• models state at each clock edge
• ASIC flow entry point
• synthesizable model
© STMicroelectronics
10
Transaction Level Models (LT)
 Model IPs/subsystems at the transaction level
 Bit true behavior
 Bit true communication
 System synchronization points
 No clock/cycle, but functional timing (e.g. timer)
 Fast to implement and simulate
 Details of interconnect are abstracted
 TAC router
 TLM models often built using
 C reference model
 TLM wrapper


Model registers
serve read/write accesses
© STMicroelectronics
11
Transaction Level Models (AT)
 Targetting performance evaluation
 Hardware architecture
 Software
 Captures micro-architecture information/timing
 Several technical options
 LT Model refinement -> rewriting
 LT Model annotation


Intrusive
Lightweight effort
 Composition of LT and T models
© STMicroelectronics
12
Comparing abstraction levels
TLM LT
Same functional
behavior
Same functional
behavior
TLM AT
Same timed
behavior
RTL
© STMicroelectronics
13
Options for processor models (1/2)
 Native compilation
 Compile the embedded software on the workstation
 No model of the core micro-architecture/Instruction set
 No assembly code for target processor, nor binary code
 Source code level compatibility
 Sometimes requires to use a HAL
 Advantages & drawbacks
 Fast execution
 No dependency on low level processor dependent features
 Can not be used for performance evaluation
© STMicroelectronics
14
Options for processor models (2/2)
 Instruction Set Simulator
 Instruction Accurate


Captures the Instruction Set
Suitable for LT modeling style
 Cycle Accurate


Represents the micro-architecture of the core
Suitable for AT modeling style
 Various simulation technologies
 Instruction interpretation

Dynamic translation
 Advantages and drawbacks
 Uses the target tool chain
 Binary code compatibility
 Slow for interpreted ISS
© STMicroelectronics
15
1st dimension: precision
TIMING PRECISION
RTL
CA
TLM-Timed / AT
TLM / LT
bit-true
PAPER EXEC.
SPEC SPEC
TIME OF PROJECT
FIRST COMPLETE RTL
DESIGNING RTL
RTL EVOLVES UNTIL PG
© STMicroelectronics
16
2nd dimension: effort
Effort
RTL
CA
TLM/LT
PAPER EXEC.
SPEC SPEC
AT
AT
PVT
optional
Optional
Time of project
FIRST COMPLETE RTL
DESIGNING RTL
RTL EVOLVES UNTIL PG
© STMicroelectronics
17
3rd dimension: speed
SoC Speed
x100
RTL
CA
AT+
X10-x100
AT
TLM / LT
Chip reference speed
x10
© STMicroelectronics
18
Agenda
 Motivations for SoC TLM modeling
 Languages and abstractions for System Level
Design
 Current standards for interoperability
 Supporting and adopting ESL standards
 SystemC/TLM
 IP-Xact
 ST TLM Framework
 Discussion and conclusion
© STMicroelectronics
19
Motivations
 Complex Virtual Platform integration requires
 Model to model interoperability
 Model to tool interoperability
 A certain level of interoperability is achieved by
standards…
 But full interoperability is not reached though…
 And user layers are required to have operational
solution taking concrete benefits from bare
standards
© STMicroelectronics
20
Rationale to support standards
 Model-to-model interoperability
 Integrate models coming from different IP
suppliers
 Deliver subsystems and/or virtual
platforms to customers
 Model-to-tool interoperability
 Benefit from CAD tools support
 Benefit from best-in-class tools from
various providers without migration
campaigns
 SystemC and IP-XACT standards are
required and complementary
© STMicroelectronics
21
Adopting
standards
 OSCI/SystemC
 A single language for modeling hardware/software
systems
 Support multiple abstraction levels
 An object-oriented approach built on top of C++ as a set
of classes
 SPIRIT/IP-Xact
 Covers
HW IP interfaces, register
configurations
 Support RTL and TLM abstractions
 Based on XML
banks
and
 Benefits of standards
 Enable competition between suppliers
 Avoid dependency to proprietary format of suppliers
 Enable adoption of new approaches inside the company
© STMicroelectronics
22
SystemC standards evolution
OSCI TLM2
OSCI TLM1
PV, PVT
Core TLM I/F
transport
put, get
Payload
REQ, RESP
LT, AT
TLM I/F
b_transport
nb_transport
Payload
tlm_transaction
Extension
Complements
IEEE 1666-2011
Incl TLM1 and TLM2
IEEE 1666-2005
2005
2008
2011
© STMicroelectronics
23
SystemC TLM: Just add water?
 Models and tools
 Must be compatible
 But not dependent
 ESL tool selection
CCI
TLM2
TLM2
 Depending on added value
perceived by users
 No need to validate a model
against all tools
 No-tool / minimal tool option to
be considered as baseline?
TLM2
Interrupt
TLM2
TLM2
TLM2
Memory
Map
 Model-to-model interfaces
 TLM2
 Mem map, interrupt, etc tbd
 Model-to-tools interfaces
 CCI (on going)
 Other to be defined
 Progress still to be done in
standards arena
© STMicroelectronics
24
IP-Xact objectives
 Ensure delivery of compatible component
descriptions from multiple component vendors,
 Enable exchanging complex component libraries
between electronic design automation (EDA) tools
for SoC design (design environments),
 Describe configurable components using metadata
 Enable the provision of EDA vendor-neutral scripts
for component creation and configuration
(generators, configurators)
© STMicroelectronics
25
A standardized XML description
 Component/Protocol identification and versioning
mechanisms
 Component interface descriptions
 Bus interfaces (ports)
 Model parameters (to provide at instantiation)
 Software interface: IP register bank descriptions
 Hierarchy description
 Enable component instantiation and interconnection in
standard compliant Design Environments
 Enables interconnect description
© STMicroelectronics
26
A standardized XML description
 Verification
 Defines the possibility to plug monitors in the design
 Design Automation
 XML IP descriptions can include references to IP
specific executable configurators/generators

Example: bus matrix interconnect generator
 The standard also includes a language agnostic
communication interface between CAD tools and the
generators

Since IPXACT 1.4, the interface is based on Web Services technologies that
enables inter-application remote procedure calls
© STMicroelectronics
27
IP-Xact roadmap
 December 2004: first release of the schema
 Made for RTL descriptions
 1.2 : added verification information, but still RTL specific
 1.4:
 Added ESL (TLM) description capabilities
 Defined new tool/generator communication interface: TGI
 1.5: basis for the IEEE standard
 Evolutions mainly concern register bank descriptions
 December 2009: IEEE P1685 standard
 Now: the Spirit consortium has merged with Accellera
 A new technical committee has been created (chaired by
ST)

Progress on recognized limitations and possible new evolutions
© STMicroelectronics
28
Agenda
 Motivations for SoC TLM modeling
 Languages and abstractions for System Level
Design
 Current standards for interoperability
 ST TLM Framework
 Brief history
 Use models
 TLM Toolbox with SystemC and IP-Xact
 Discussion and conclusion
© STMicroelectronics
29
Where do we come from?
cycle
accurate
models
coverification
platforms:
RTL models
Transactional
Level Modeling
@ST
TAC v1
TLM
models
2005
2008
OSCI TLM 1.0
Standard
OSCI TLM 2.0
Standard
TAC v2
TLM
models
TAC v3
TLM
models
Performance/
temporal
models
1998 – 2000
2001
2003
2005
2010
Various
Experiments
TLM
Development
Proposal of
TLM 1.0
Standard
to OSCI
Alignment to
OSCI TLM 1.0
Standard
Alignment to
OSCI TLM 2.0
Standard
© STMicroelectronics
30
Virtual Prototypes with TLM
 Applied in the industry for complex SoCs
 System architecture exploration
 Anticipation of RTL functional verification
 Pre-silicon software development
Functional
Verification
Functional
Embedded
Software
TLM/RTL
Co-simulation
LT Models
IPTG
Architecture
Analysis
LT: Loosely Timed
AT
Models
Embedded
Software
Optimization
AT: Approximately Timed
© STMicroelectronics
31
Functional verification
Testbench
TB
Master
TLM IPs
Memory
Input
C/C++
expected
Abstract interconnect
Adapter
Adapter
TLM DUT
IP Verification
In-system Verif.
RTL DUT
© STMicroelectronics
32
TLM for functional verification
Home Video Ips
(by IPs Verification Manager)
About 10 chips have now benefited from the TLM approach, resulting in
about 4 times less bugs in our designs. Our improved efficiency relies on
faster simulations, reuse of test vectors during the whole verification
process (TLM, RTL, co-emulation, emulation), and the ability to quickly
develop system-oriented functional tests.
© STMicroelectronics
33
Pre-Silicon software development
 Enable early development of functional embedded
software
 Same model is used for verification activities and
software development
 Hardware blocks modeled with bit true behaviour
and communication
 Processor models wrapped in SystemC
 Native compilation
 Instruction accurate
 Cycle accurate
 Debugger connection
© STMicroelectronics
34
Advantages of virtual prototypes
for software development
 Full control on simulation execution
 Full observability
 Non regression tests
 Easy deployment over large software development
teams
 Easy evolutions
© STMicroelectronics
35
TLM for firmware development
Mobile Video Accelerator
(by Video Subsystem Verification Manager)
For 2nd generation subsystem, we saved 30% of our verification time (in
months) by anticipating the firmware verification on TLM platform before any
RTL platform, and by concentrating our verification effort only on pure HW
© STMicroelectronics
36
TLM Modeling Framework
Platform automation kit
Ip-Xact flow
VSoC STudio
TLM model
portfolio
Transaction
Monitoring
Messaging and
configuration
Build
environment
TLM modeling
methodology
Repository
TLM modeling kit
Infrastructure kit
© STMicroelectronics
37
TLM key technology items
TLM platform
assembly
IPXact IEEE 1685
TLM modeling
methodology
SystemC IEEE 1666
Register bank
support
Configuration
capabilities
OSCI CCI
TLM communication
protocols
OSCI TLM 2
TLM
Model
Monitoring
capabilities
SCV
Build infrastructure
(tlm_infra)
© STMicroelectronics
38
SystemC Add-ons : modeling layers
and IP models libraries
CPU models
TLM IP Library
ST IPs
TAC Protocol
External IPs
ST Cores
(STxP70, ST40,
etc)
External
Cores
(ARM, etc)
OCB Models
OSCI TLM Standard
SystemC Channels
SystemC
© STMicroelectronics
39
VSoCSTudio
Platform compilation
VSoC
Platform assembly
Resource browser
40
udio
Configuration editor
Process Activation Chart
© STMicroelectronics
What is TAC Protocol?
TAC stands for Transaction Accurate Communication
 A useful protocol for functional verification and embedded
software development
communications
 Characteristics:
through
transaction-accurate
 Dedicated to memory mapped bus communication
 point-to-point with no broadcast
 requires address and data
 supports single and block transfers
 supports byte-enable for single and block transfers
 provide control operations
 routers are often used in conjunction with TAC models
© STMicroelectronics
41
Register map support
 Increase model developer productivity
 No standard available yet for simulations
 Register map is constructed
 From IP-Xact description
 Manually
 Main features
 Register decoding
 Register and bitfield access control, setters & getters
 Register meta data (synchronization points)
 Unified reporting mechanism (using tlm_message)
 Interactions with
 bus interface
 Model
 Tools
© STMicroelectronics
42
TLM Model/tool interactions
Bus model
Bus Interface
Register bank
Trans.
Monitoring
Transaction
database
Register
introspection
CAD
Tool
Model
Configuration
Upcoming
OSCI CCI
standard
SystemC
Kernel
© STMicroelectronics
43
TLM SoC Analysis and
Debugging Tools
Software
Analysis
Platform
assembly
Hardware
Analysis
Statistics
© STMicroelectronics
44
Using IP-Xact description
as the reference
SoC
Top
Arch
IP
Functional
Spec
IP-Xact
descriptions
Datasheet
export
Board
spec
package
IP
verification
testcase
(.h & .c)
Netlist
RTL
Design
Validation
(.h)
Software
(.h)
TLM model
skeleton
(.h & .cpp)
© STMicroelectronics
45
TLM model generation and platform assembly
IP Functional
Specification
Register
Description
Existing
Model
IP-Xact
Description
Other inputs
Other
output
Behavior
TLM Model
Skeleton
TLM model generation
TLM/RTL platform assembly
Header files
Register
tests
SW development
Validation
HLS
RTL
© STMicroelectronics
46
Questions related to IP-Xact and HDS
 Consistency of descriptions?
 Specification
 IP-Xact
 TLM model & software
 Level of modularity
 Separate deliveries?
 Expressivity of the description
 E.g. Side effects for registers
 Connection to
higher level information?
 E.g. end user scenarios,
IP/SoC
Functional
Specification
IP-Xact
IP/SoC
Description
TLM
Model
Software
Driver
non functional properties
© STMicroelectronics
47
Agenda
 Motivations for SoC TLM modeling
 Languages and abstractions for System Level
Design
 Current standards for interoperability
 ST TLM Framework
 Discussion and conclusion
 ESL Ecosystem
 TLM value chain
 Conclusions
© STMicroelectronics
48
ESL ecosystem
CAD Tools
 Standards and Tools for
CAD Tools
 Model developers
 Virtual Platform integrators
 Virtual Platform users
 ESL doesn’t mean only
Standards & Examples
EDA!
License cost
SW Tools
SW Tools
HW
OSS
SW
Open Source tools
# of users
© STMicroelectronics
49
From enablers to mass market
License cost
Experts:
- Very focused needs
- Sensitive setup
- Niche market
Mass market:
- Functional
- Affordable
Enablers:
- Early adoption
- Assess migration effort
from in house solutions
#
of users
© STMicroelectronics
50
Transaction Level Model Value Chain
IP
Specification
High
Modeling
Engineers
Expertise
added value
TLM
Modeling
on top of standards
Methodology
TLM
TLM1.0, TLM 2.0 incl. Communication
in IEEE 1666-2011
APIs
revision
IEEE 1666-2005
C++ class library
SystemC
SOC
Specification
TLM Model
Bit accurate
Register accurate
Functionally correct
Communicates
through transactions
IP
IP
IP
Interconnect TLM model
IP
IP
SoC
Virtual Prototype
Variable timing
accuracy
© STMicroelectronics
51
Conclusion
 Virtual platforms are key for
 pre-silicon software development
 Functional verification
 Automation of the IP-Xact based flow
 Generation of TLM model skeleton
 Generation of software header files
 Connection to other sources of high-level
information still to be done
© STMicroelectronics
52
More about it
 Read the book:
 Ghenassia, F. (ed.): 2005,
Transaction-Level Modeling with SystemC. TLM
Concepts and Applications for Embedded
Systems.
Springer. ISBN 0-387-26232-6
 Several publications in international
conferences and PhD thesis (Moy 2005,
Fiandino 2007, Helmstetter 2007, Cornet
2008, Revol 2008, Funchal 2011)
© STMicroelectronics
Questions?
(C) STMicroelectronics, 2010
Workshop - November 2011 - Toulouse
54