TLM and its evolution Copyright © 2007 Tata Elxsi Ltd. Shwetha Pai.

TLM and its evolution

Copyright © 2007 Tata Elxsi Ltd.

Shwetha Pai

Agenda

Transaction Level Modeling

Modeling

OSCI

Support Tools

Case studies

FutureChallenges


MODEL A

MODEL A

MODEL B

MODEL B

Transaction

Exchange of data or event between two components of a modeled or simulated environment.

Model

• A representation of a person or thing, typically on a smaller scale• Something used as an example• A simplified mathematical description of a system or process used to assist calculation and prediction• A figure made in clay or wax which is then reproduced in a more durable material.

Model

• A representation of a person or thing, typically on a smaller scale• Something used as an example• A simplified mathematical description of a system or process used to assist calculation and prediction• A figure made in clay or wax which is then reproduced in a more durable material.

TLM evolution

Evolution

A process by which something passes by degrees to a different stage, especially to a more advanced or matured stage

Evolution

A process by which something passes by degrees to a different stage, especially to a more advanced or matured stage

2000 AD: Presentation of communication mechanism of a system

2000 AD: Presentation of communication mechanism of a system Developed into

SystemC 2.0 standard

Developed into SystemC 2.0 standard

“Transaction based modeling”

concepts was showcased

Level was introduced later on in order to follow Register Transfer LevelBehavioral Level

Level was introduced later on in order to follow Register Transfer LevelBehavioral Level

Birth of Transaction Level Model

Agenda


Modeling

OSCI

Support Tools

Case studies

FutureChallenges

• Why modeling?• Different abstraction models• Why SystemC?

• Testing• Functional validation

• Enable quantitative comparison of alternatives• Guide engineering trade-offs

• Making design decisions• Narrow the design space• Establish credible and feasible alternatives

Why modeling?

• Required during all the phases of system development• Required during all the phases of system development

High level design

Micro-architecturaldefinition

DesignImplementation

• Better debug capability

• 3 – 6 months time frame

• Software development is the critical path• Moves software development and debugging earlier in the project life cycle• Reduce overall development cycle

Why modeling?

Early software development

Quick prototype of the hardware

Determine correctness and efficiency of design

Agenda


Modeling

OSCI

Support Tools

Case studies

FutureChallenges

• Why modeling? Different abstraction models• Why SystemC?

A B

F

Un-timed

Un-timed

Approximate-timed

Cycle-timed

Approximate-timed

Cycle-timed

COMPUTATION

COMMUNICATION

D

C E

A. ALGORITHMIC MODEL SPECIFICATION MODELUNTIMED FUNCTIONAL MODEL

A

B. COMPONENT ASSEMBLY MODELARCHITECTURAL MODEL TIMED FUNCTIONAL MODEL

BA

C. PROGRAMMER’S VIEW MODEL (PV) BUS ARBITRATION MODELTRANSACTION MODEL

C

B

D. PROGRAMMER VIEW TIMED MODEL (PVT) BUS-FUNCTIONAL MODELCOMMUNICATION MODELBEHAVIOR LEVEL MODEL

D

C

E. CYCLE ACCURATE COMPUTATION MODELPIN ACCURATE MODEL

E

D

F. IMPLEMENTATION MODEL

F

E

Abstraction models

CORE SYS

BUS

MEMORY GIO TIMER

CLOCK

RESET

IOPINS

ADDR

nRW

DATA

INTR

TLM for an example system

Computation

Communication

A B

C

D F

Un-timed

Approximate-timed

Cycle-timed

Un-timed

Approximate-timed E

Cycle-timed

Core Sys

GIO Timer

Variables

Variables

Variables

Variables

Implementation

• Functional implementation of modules

• Intercommunication is through shared variables

• Execution and data transport in 0 time

Abstractions done

• No state

• No memory

• No address decoding

Modules not present at this stage

• Bus

• Memory

Algorithmic model

Core Sys

GIO TimerMemory

CH1

CH2 CH3 CH4

Computation

Communication

A B

C

D F

Un-timed

Approximate-timed

Cycle-timed

Un-timed

Approximate-timed E

Cycle-timed

Implementation

• Models are concurrently executing entities

• Wait statements are implemented

• Intermodule communication is through channels

Abstractions done

• Channels are message passing channels without any bus / protocol implementation

• Communication is un-timed

• Computations are approximately timed


• Bus

Component assembly model

Core Sys

GIO TimerMemory

BUS ARBITER

Computation

Communication

A B

C

D F

Un-timed

Approximate-timed

Cycle-timed

Un-timed

Approximate-timed E

Cycle-timed

CH3CH2 CH4CH1

Implementation

• Simplified bus protocol

• Address decoding

• Bus priority implementation

Abstractions done

• Bus implementation is not cycle accurate

• Wait states are inserted between transactions

• Computations continue to be approximately times


• Bus

Programmer view model

Core Sys

GIO TimerMemory

BUS ARBITER ADDRDATAnRW

INTR

Computation

Communication

A B

C

D F

Un-timed

Approximate-timed

Cycle-timed

Un-timed

Approximate-timed E

Cycle-timed

Implementation

• Precise bus protocol – time / cycle accurate

• Data transferred following accurate protocol sequence

Abstractions done

• Computations continue to be approximately times


• Bus

Programmer view timed model

Computation

Communication

A B

C

D F

Un-timed

Approximate-timed

Cycle-timed

Un-timed

Approximate-timed E

Cycle-timed

Timer

BUS ARBITER

CH3

CH2

CH4

CH1

MEMORY GIO

SYSCOREImplementation

• Computation models are pin accurate and execute cycle accurately

• Wrappers that convert data transfers from high level abstraction to low level abstraction are inserted to bridge the arbiter and other modules

Abstractions done

• Bus implementation is not cycle accurate

• Wait statements are inserted between transactions

• Some modules can only be computational

Cycle accurate computation model

SYS

BUS ARBITER ADDRDATAnRW

INTR

Computation

Communication

A B

C

D F

Un-timed

Approximate-timed

Cycle-timed

Un-timed

Approximate-timed E

Cycle-timed

CORE

TimerMEMORY GIO

Implementation

• Cycle accurate computation

• Cycle accurate communication

• Modules can be re-used from earlier models

Implementation model

Models Communication time

Computation time

Communication scheme

A. Algorithmic model

No No Variable

B. Component-assembly model

No Approximate Variable

C. Programmer view model

Approximate Approximate Abstract bus channel

D. Programmer view timed model

Time/cycle accurate

Approximate Protocol bus channel

E. Cycle accurate computation model

Approximate Cycle accurate

Abstract bus channel

F. Implementation model

Cycle accurate

Cycle accurate

Bus (wire)

Models B, C, D and E can be classified as transaction level models

Characteristics of abstraction models

Objects

TLM:Made of Compositions&

Computation objects

Communicationobjects

Read/Write Abstract Data Types

Thus helping in

Object independence- each object can be modeled independently

Abstraction independence -different objects can be modeled at different abstraction level

TLM definition

Agenda


Modeling

OSCI

Support Tools

Case studies

FutureChallenges

• Why modeling?• Different abstraction models Why SystemC?

Challenges faced in regular high level language

• Notion of time

• Concurrency

• Hardware data type: ‘Z’ value for tri-state busses

• Reactivity

• Hierarchy

• Synthesis

Solution provided by SystemC

• System design language for HW/SW co-design

• A library of C++ classes that address the challenges faced

• Processes for concurrency

• Clocks for timing

• Hardware data types

• Waiting and watching: reactivity

• Modules, ports, signals: hierarchy

• Abstract ports and protocols

• A light weight simulation kernel

Why SystemC?

Agenda


Modeling

OSCI

Support Tools

Case studies

FutureChallenges

• OSCI SystemC TLM standards• OSCI SystemC TLM roadmap

OSCI TLM WGOSCI TLM WG

OCP-IPOCP-IP

June 2004: OSCI / OCP-IP TLM standardization allianceJune 2004: OSCI / OCP-IP TLM standardization alliance

May 2005: OSCI releases SystemC TLM standard 1.0May 2005: OSCI releases SystemC TLM standard 1.0

TLM kit, whitepaper, examples publicly available at www.systemc.orgTLM kit, whitepaper, examples publicly available at www.systemc.org

TLM standards already in use in the industryTLM standards already in use in the industry

TLM 2.0 draft 2 in progress for public reviewTLM 2.0 draft 2 in progress for public review

IEEE standardization process on cardsIEEE standardization process on cards

OSCI SystemC TLM standards

Focus on SystemC interface class

• Generic reusable TLM interface• Different components implement same interface• Same interface can be implemented

• Directly within a c/C++ function• Via communication with other modules / channels in system

Object passing semantics

• Similar to sc_fifo, effectively pass-by-value• Avoids problems with raw C/C++ pointers• Leverage C++ smart pointers and containers where needed

Unidirectional vs. bi-directional data flow

• Unidirectional interfaces similar as sc_fifo• Bi-directional can be easily and cleanly layered on unidirectional• Separates requests from responses

Blocking vs. non-blocking

OSCI SystemC TLM standardsKey concepts

Modeling with OSCI TLM standard API

Modeling with OSCI TLM standard API

Courtesy :

OSCI SystemC TLM progression

Agenda


Modeling

OSCI

Support Tools

Case studies

FutureChallenges

• OSCI SystemC TLM standards OSCI SystemC TLM roadmap

Courtesy :

OSCI SystemC TLM roadmap

Courtesy :

OSCI SystemC TLM roadmap

Agenda


Modeling

OSCI

Support Tools

Case studies

FutureChallenges

Error Injection Mechanism

Channel In

terfa

ce

Host In

terfa

ce

Protocol Operation Control

Frame & Symbol Processing Clock synchronizing process

CODEC Timers

Media Access Control

TEL FlexRay TLM – Automotive IP

Timed model with respect to data transactions in the channels.Complete clock synchronization implemented.Inter-module communications done with the TLM techniques.Pin-level channel interfaceThe host side is API interface to provides configuration pointsAdd-on to normal behaviour capable of generating error frames and conditionsCapable of generating random packets/scenariosError logic is capable of generating all the errors present in conformance test specsThe model is capable to do the synchronizations with the DUT.

Case Study1: TLM IP development & usage

Use case scenario – RTL verification

Verification environment

FlexRay RTL model

(DUT)

Channel A

Channel B FlexRay TLMVerification IP

Host interface

Test case / Configuration

Score board

• FlexRay TLM • can be configured using function calls.• provided error injection • function calls that can be used by the score board to compare the transmitted and received frames.

Case Study1: TLM IP development & usage

Bus Model

ISS - 1 ISS - 2

IP TLM - 1 Memory DMA IO

Vendor bought

TEL developed

Multiprocessor OCP based system prototype for image processing

•Memory•Memory architecture – cache/ ram/ rom details•Memory size & type – shared/ distributed•Data size•Data Traffic

•Bus•Bus Bandwidth•Bus throughput•Bus hierarchy & priority

•Number of cores required•Hardware software partitioning•Types and number of DMAs•Interrupt type and latency details

Complete architecture analysis and design decisions

Case Study2: TLM to build a system

Agenda


Modeling

OSCI

Support Tools

Case studies

FutureChallenges

Compilers

• All C++ compilers

Simulators

• SystemC simulator

• Most of HVL simulators

• VCS

• Modelsim

• NCS

• SuperC

Converters

• Verilator – Verilog to SystemC converter

• VHDL – SystemC converter

Support tools

Agenda


Modeling

OSCI

Support Tools

Case studies

FutureChallenges

•More standardization from modeling perspective•IP sales of systemC models •Cost effective licenses required for systemC support.•Simulator for TLMs•Standardized interfacing into HVL•OS scheduler modeling•Synthesizable systemC

Future challenges

Thank You

TLM and its evolution Copyright © 2007 Tata Elxsi Ltd. Shwetha Pai.

Documents