Transaction-level Modeling

Acknowledgments: F. Ghenassia (Ed.). Transaction-level Modeling with SystemC, Springer, 2005

Terminology
Each basic block in a design is modeled as a module Functionality is modeled inside each module by one or more
concurrent 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 interfaces through 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 serves transactional requests System synchronization is an action at least between 2 modules that need to coordinate their behavior

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 details

should be included A complete SoC TLM platform is built by instantiating and binding different modules and channels together

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

Synchronization: TLM vs. RTL

No clock: fewer context switches involved

Clocked processes that represent the microarchitecture: lots of context switches

State and sync point

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

Modeling accuracy of various approaches

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 called programmers view (PV) The granularity of the data transferred should correspond to the modeling level of the target application (in case of video processing: frame level)

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

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

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

Untimed TLM: system sync (conted)

TLM implements all of the system synchronizations as

interrupts, 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 the

assurance of memory or data consistency If an untimed TLM generates deadlocks or failures, it means that the system synchronization has been badly designed

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)

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

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

Untimed TLM: functional delay (example)

Untimed TLM: practical suggestions

1) think of exploiting reusability when writing modules 2) determine the data granularity according to the algorithmic

accuracy and the expected precision 3) think in a functional way, do not include micro-architectural and clock-based information 4) model explicitly the system synchronization that affects the IP behavior 5) use events and specific synchronization protocols to model inter-module synchronization 6) avoid process-activation based on regular basis

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 as programmers 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)

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

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

Timed TLM: standalone timed model

All the timing behavior is here modeled during the execution
of 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 the untimed TLM

Timed TLM: standalone timed model (example)

Timed TLM: inter-execution of untimed and timed models

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

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: the TLM 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