untimed timed tlm

7/28/2019 Untimed Timed TLM

1/25

Transaction-level Modeling

Acknowledgments: F. Ghenassia (Ed.). Transaction-level Modeling

with SystemC, Springer, 2005


2/25

Terminology

Each basic block in a design is modeled as a module

Functionality is modeled inside each module by one or moreconcurrent processes (threads or methods)

Communication between modules is handled using channels,that implement some interfaces

Interfaces are responsible to make the separation between

communication and computation possible

Modules are bound to and access channels interfacesthrough ports

A transaction represents the data being exchanged

A master (initiator) is a module that starts a transaction

A slave (target) is a module that receives and servestransactional requests

System synchronization is an action at least between 2

modules that need to coordinate their behavior


3/25

Modeling approach

The main goals in TLM are:

modeling the internal functionality of a hardware block at the

functional or behavioral level

Propose a standard way to handle communication

None of the micro-architectural implementation detailsshould be included

A complete SoC TLM platform is built by instantiating and

binding different modules and channels together


4/25

Modeling approach (conted)

One of the key points in doing TLM is understanding where

and when to implement system synchronization

Too many sync points: too slow, too close to CA or RTL

Too few sync points: risk of incorrect system execution


5/25

Synchronization: TLM vs. RTL

State and sync point

Clocked processes that

represent the micro-

architecture: lots ofcontext switches

No clock: fewer

context switches

involved


6/25

Modeling accuracy

There are 2 main factors to determine the degree of modeling

accuracy:

Granularity of communication data

Application packet (ex. frame-by-frame transfer for a video)

Bus packet (ex. macro block transfer made of lines and columns)

Bus size (ex. pixel-based transfer for a video)

Timing accuracy

Untimed

Approximately timed

Cycle-accurate


7/25

Modeling accuracy of various approaches


8/25

Untimed TLM: introduction

It is an architectural model done for early functional

development and functional verification

Timing annotations can be ignored

Objective here is high simulation speed It is used mainly by programmers and verification engineers: it

can also be calledprogrammers view (PV)

The granularity of the data transferred should correspond to

the modeling level of the target application (in case of videoprocessing: frame level)


9/25

Untimed TLM: model of computation

There is no clock in an untimed TLM system

All processes are executed concurrently to access any of the

system resources at the same time instant

The correct system behavior must be guaranteed though Model of computation has the following characteristics:

Concurrent execution of independent processes

Respect for causal dependencies between processes using system

synchronization


10/25

Untimed TLM: system synchronization

Causal relationship between processes must be characterized

in order to assure deterministic behavior

Only a partial order of execution is implemented through

synchronization points

There is a small degree of indeterminism

Any execution order is permitted as long as their causal

dependencies are well respected


11/25

Untimed TLM: system sync (example)

Full execution order is local to each process

Partial execution order is instead used for the system

There are also 2 system synchronization points between P1 and P2

Examples of different possible execution orders


12/25

Untimed TLM: system sync (conted)

TLM implements all of the system synchronizations asinterrupts, mailbox or polling

There are 2 kinds of synchronizations:

Emit-synchronization: a process sends out a synchronization that may

influence the behavior or state of other processes Receive-synchronization: a process waits for an incoming event that

may influence its behavior or state

An important employment of system synchronization is theassurance of memory or data consistency

If an untimed TLM generates deadlocks or failures, it meansthat the system synchronization has been badly designed


13/25

Untimed TLM: process execution

The concurrent execution of independent processes is one of the major

features of the untimed TLM For the way the SystemC kernel is implemented, it is not possible to

predict in which order processes are executed

Once the simulation is executed, the kernel will repeat the same execution

order

Due to that, it is possible to miss the bugs hidden in other execution

orders

We must make sure that any execution order conforms to the system

functional specification

Coverage can be increased by using a random function that shuffles all of the legal

process interleaves

Such coverage could produce a huge and useless number of combinations: alternative is

introducing successive constraints to limit amount of useless combinations (ex. timing

constraints: only related to functional constraints (ex. 30 frames per second), not to

micro-architecture constraints)


14/25

Untimed TLM: modeling of interrupts

System synchronization is very often implemented by an

interrupt

In the untimed view, an interrupt is an impulsive event

without any persistence: it should not be modeled using a

signal!

A dedicated TLM protocol is employed, with the following

features:

Immediate propagation of interrupts from initiator to target

Notice of potential IP internal state change


15/25

Untimed TLM: insertion of functional delay

Functional delays can be introduced when they are part of the

system specification (e.g. video decoder decoding 30 framesper second)

This becomes an intermediate level between purely untimed

TLM and timed TLM

It must be possible to enable and disable such delay constraint

Functional delays are not referred to the micro-architecture

Functional delays do not influence the model of computation

By introducing functional delays, we limit the choices of

process interleaves at a given time instant


16/25

Untimed TLM: functional delay (example)


17/25

Untimed TLM: practical suggestions

1) think of exploiting reusability when writing modules

2) determine the data granularity according to the algorithmicaccuracy and the expected precision

3) think in a functional way, do not include micro-architecturaland clock-based information

4) model explicitly the system synchronization that affects theIP behavior

5) use events and specific synchronization protocols to modelinter-module synchronization

6) avoid process-activation based on regular basis


18/25

Timed TLM: introduction

It is a micro-architectural model containing essential time

annotations for behavioral and communication specifications

It is less abstract than untimed model

It provides the required simulation accuracy for real-time

embedded SW development and architecture analysis

It is also know asprogrammers view plus timing (PVT)

The timing behavior of a component specifies the delay

between each activation and synchronization-suspension It allows to establish a full order of execution (compare to

untimed TLM)


19/25

Timed TLM: modeling approach

We distinguish 2 time consumptions

Computational delay: time required to perform calculations occurring

when executing system functionality

Communication delay: total time consumed in accessing and

transferring data

Time consumption of a component in timed TLM is modeled

according to 2 methods

Annotated model Standalone timed model


20/25

Timed TML: annotated model

Timing delays are here inserted into an untimed model

Such delays are the timing information of the micro-

architecture level (compare to functional delays for untimed

TLM)

This approach is good if the structure of the untimed model

already matches the structure of the micro-architectural

model

Annotations will be simply waitstatements related to the computation

time of a specific functionality

Annotations should be within preprocessing directives (e.g.

#ifdef ANNOTATED_MODEL), so that it is easy to switch back

to the untimed model


21/25

Timed TLM: standalone timed model

All the timing behavior is here modeled during the executionof a standalone, detached timing model

This approach is suitable when the structure of the algorithm

is very different from the structure of the micro-architecture

there are therefore 2 components in this approach: Untimed TLM: it executes the pure untimed behavior, but it must be

instrumented to generate traces of functional events to feed the timed

model

Standalone timed model: it can represent the time behavior down to

CA accuracy. They are fed with functional traces generated in theuntimed TLM


22/25

Timed TLM: standalone timed model (example)


23/25

Timed TLM: inter-execution of untimed

and timed models


24/25

Timed TLM: inter-execution of untimed

and timed models (conted)

The functional behavior of the untimed model is

executed until it reaches a synchronization point

Execution is then passed to the standalone timedmodel

This cyclic behavior is repeated

Advantage of inter-execution Several standalone timed models can be implemented for the same

untimed model, which allows investigating several micro-architecture

scenarios


25/25

Timed TLM: inter-execution (detail)

Observe:

TS will handle transactions received from channels in 2 ways:

Insensitive access: transaction is received from C and continues directly in TS: theTLM transaction is propagated in advance compared to actual occurrence in the

silicon

Sensitive access: transaction emitted from TI is rejected: early accesses are not

granted. TI must regenerate the transaction by transferring it through the timed

channel TC, in order to include the related communication time delay

untimed timed tlm

Documents