RIGOROUS COMMUNICATION MODELLING AT TRANSACTION

LEVEL WITH SYSTEMC

Tomi Metsälä

1,2

, Tomi Westerlund

, Seppo Virtanen

and Juha Plosila

2,3

Distributed Systems Design Laboratory, Turku Centre for Computer Science, Turku, Finland

Department of Information Technology, University of Turku, Turku, Finland

Academy of Finland, Research Council for Natural Sciences and Engineering, Finland

Keywords:

Embedded Systems, Formal Methods, Action Systems, SystemC.

Abstract:

We introduce a communication model for ActionC, a framework for rigorous development of embedded com-

puter systems. The concept of ActionC is the integration of SystemC, an informal design language, and Action

Systems, a formal modelling language supporting veriﬁcation and stepwise correctness-preserving reﬁnement

of system models. The ActionC approach combines the possibility to use a formal correct-by-construct method

and an industry standard design language that also includes a simulation environment. Translation of an Ac-

tion Systems model to the corresponding ActionC model is carried out with the means provided by SystemC

and in a way that preserves the semantics of the underlying formal model. Hence, the ActionC framework

allows us to reliably simulate Action Systems descriptions using standard SystemC tools, which is especially

important for validating the initial formal speciﬁcation of a system. Our initial experiments with ActionC have

successfully produced correct-proven simulatable SystemC descriptions of Action Systems.

1 INTRODUCTION

Verifying the correctness of a modern hardware or

HW/SW system design claims more time and effort

than ever before. Veriﬁcation process of complex

multiprocessor and reconﬁgurable systems brings up

new challenges for both researchers and developers

in the industry. Veriﬁcation by testbench simulation is

the prevailing approach to this issue. For this purpose,

there exists a wide variety of recently introduced new

veriﬁcation languages, methods and tools. Another

approach to a system veriﬁcation task includes the use

of formal methods. By specifying system in a formal

design language developer is able to verify the model

in a mathematically rigorous manner. Based on a for-

mal speciﬁcation the design is correct by construction

and its logical behaviour does not need to be veriﬁed

by simulation. However, the industry lacks the type

of comprehensive tools that can be used in formal,

stepwise development of embedded HW/SW systems

throughout the design project all the way from ab-

stract speciﬁcation down to implementable model.

In order to address this challenge we introduce

the idea of ActionC framework, which is the inte-

gration of the formal system speciﬁcation language

Action Systems (Sere and Back, 1994) and the infor-

mal modelling and simulation environment SystemC

(The OSCI, 2005). Action Systems provides a rig-

orous method for specifying and verifying modular

HW/SW systems in addition to the reﬁnement cal-

culus framework (Back, 1988), a stepwise develop-

ment environment for reﬁning an abstract speciﬁca-

tion down to a model that can be translated into a

suitable implementation. On the other hand, Sys-

temC is a programming library that is built on top of

the standard C++ programming language (Stroustrup,

1997). In addition to the object oriented techniques

provided by C++, SystemC offers the system designer

hardware-oriented functionality such as clocks, sig-

nals, reactivity and modelling of parallel processing.

With SystemC it is possible to gradually develop and

verify a HW/SW system design in its entirety without

the need to translate the hardware model into a sep-

arate hardware design language. In ActionC, Action

Systems provides a formal foundation for SystemC

modelling enabling the developer to produce a sim-

ulatable system description from an Action Systems

description while preserving the formal correctness

throughout the model’s reﬁnement process as well as

during the simulation.

Inter-module communication is an essential fea-

ture in Action Systems modelling, and therefore it

will be addressed in this paper. We elaborate the way

in which Action Systems’ procedure based communi-

246

Metsälä T., Westerlund T., Virtanen S. and Plosila J. (2008).

RIGOROUS COMMUNICATION MODELLING AT TRANSACTION LEVEL WITH SYSTEMC.

In Proceedings of the Third International Conference on Software and Data Technologies - SE/GSDCA/MUSE, pages 246-251

DOI: 10.5220/0001900402460251

 SciTePress

cation model is implemented in the ActionC frame-

work with the means provided by SystemC.

Several other papers have also covered the issue

of improving SystemC by incorporating it with for-

mal design and veriﬁcation methods. A general re-

view concerning SystemC and different formal veri-

ﬁcation method has been conducted for example by

Vardi in (Vardi, 2007). The integration of an inde-

pendent formal language into SystemC has been ex-

plored for example by Habibi and Tahar in (Habibi

and Tahar, 2005) and by Patel et al. in (Patel et al.,

2006). In the former a language called AsmL has been

used for the veriﬁcation of transaction level models

of SystemC, while the latter integrates Bluespec and

SystemC in order to create rule-based MoCs for Sys-

temC. On the other hand, a tool for executing action

systems has been tested by Degerlund, Walden and

Sere in (Degerlund et al., 2007), in which they trans-

lated Action Systems models into C++ and executed

the translation with an experimental scheduler tool.

The paper is organised as follows: Action Systems

and SystemC are introduced in Sect. 2 and Sect. 3, re-

spectively, and in Sect. 4 they are viewed together as

the ActionC framework. Section 4 will also address

the implementation of the procedure based communi-

cation. Concluding remarks are provided in Sect. 5.

2 ACTION SYSTEMS

Action Systems is a design framework that can be

used in modelling complex parallel and reactive sys-

tems in a formal, mathematically rigorous manner

(Sere and Back, 1994). The Action Systems formal-

ism was initially proposed by Back and Kurki-Suonio

(Back and Kurki-Suonio, 1983) and it is based on

the guarded command languageby Dijkstra (Dijkstra,

1976). In Action Systems a system modelis described

according to the system’s logical behaviour. The be-

haviour is modelled in terms of atomic actions, which

are guarded commands that perform an operation for

a given set of system variables. Once chosen for ex-

ecution, atomic actions are executed to completion

without interference from other actions in the system.

Only the initial and ﬁnal states of an atomic action are

observable in the environment. Parallelism between

actions can be modelled when they do not share any

variables that either or both of them write onto. In

such cases actions can be executed in any order with-

out affecting the ﬁnal state.

The veriﬁcation of total correctness of actions and

entire systems is based on the concept of weakest pre-

condition: for every action there exists a postcondi-

tion that can be established by properly executing and

sys F ifo ( exp Put(in x: Integer);

exp Get(out x: Integer); )



N : Natural := 8;



|[ variable

q: queue of Integer ; cnt: 0...N;

public procedure

Put(in x: Integer) : (q := q@hxi);

Get(out x: Integer): (x,q := head(q),tail(q));

action

waitPut : (cnt < N → await Put; cnt := cnt +1);

waitGet : (cnt > 0 → await Get; cnt := cnt − 1);

invariant

Range: 0 ≤ cnt ≤ N;

initialisation

q,cnt := h i, 0;

execution

do WaitPut 8 WaitGet od ]|

Figure 1: Description of the action system F ifo.

terminating the action statement. In that case the ex-

ecution of that action is guaranteed to lead the sys-

tem into a state that satisﬁes the weakest precondi-

tion. An initial system speciﬁcation can be reﬁned

into an implementable model using a method called

reﬁnement calculus (Back and von Wright, 1998).

The ﬁnal model is developed in a stepwise man-

ner preserving the veriﬁed correctness of the initial

model. Therefore, the design can be seen as correct-

by-construction at all stages of the process.

2.1 Action Systems Description

An action system is a module structure that offers an

encapsulated environment for local variables and ac-

tions that operate on them. Actions also use interface

procedures and variables in communicating with ac-

tions in other action systems. Private procedures are

used only within the local action system scope. Ex-

ecution of an action system is modelled with an ex-

ecution loop that runs the actions in a speciﬁc order,

which may or may not be deterministic.

As an example of an action system description,

Fig. 1 illustrates a simple transaction level FIFO struc-

ture, in which we can identify the three main sections

of the action system description: interface, declara-

tion and iteration. In this case, the interface part de-

clares communication procedures Put and Get that the

action system F ifo introduces and exports. The use

of communication procedures corresponds to a trans-

action level model with remote function calls. The in-

terface also introduces parameter N, a natural number,

that is set to value eight. The exported procedures are

imported by other action systems that require the ser-

vice that these procedures provide. Procedures are in

general any atomic actions, possibly with some auxil-

iary local variables that are initialised every time the

RIGOROUS COMMUNICATION MODELLING AT TRANSACTION LEVEL WITH SYSTEMC

247

procedure is called. The execution of a procedure is

considered as a part of the calling action, and thus

procedures can be considered as parametrisable sub-

actions. If an action system does not have any com-

munication variables or procedures, it is a closed ac-

tion system, otherwise it is an open action system.

In the declaration part the local variables, actions

as well as private and public procedures are deﬁned.

The F ifo action system deﬁnes the Put and Get pro-

cedures. Put appends (the @-operation) the element,

given as a parameter,at the end of the queue type local

variable q. Get, on the other hand, returns the proce-

dure caller the head (the ﬁrst element) of the queue,

while setting the tail (all elements except the ﬁrst) as

the new value of the queue. Both actions waitPut and

waitGet perform an await command that passively

waits for a procedure call from an action system that

imports the procedure. When a call comes, a proce-

dure is executed with the rest of the statements in the

action. The action waitPut increments the local vari-

able cnt after executing Put, while the action waitGet

executes Get and decrements the variable cnt. Both

actions have their own guard, gd(), that must hold be-

fore the action’s body, bd(), is allowed to execute, e.g.

gd(Put) b= cnt < N and bd(Put) b= await Put; cnt :=

cnt + 1). The declaration part also deﬁnes the con-

straints that the actions must uphold. Here, a range

for the value of the variable cnt is introduced as a sys-

tem invariant. The operation of the action system is

started by initialisation in which the variables are set

to predeﬁned values.

In the iteration part, that is, in the execution loop,

actions are selected for execution based on their com-

position and enabledness. This is continued until

there are no enabled actions, whereupon the computa-

tion suspends leaving the system in a state in which it

waits for an external impact that would enable its ac-

tions again. The operation of the F ifo action system

depends exclusively on the procedure calls coming

from other systems because of the await commands

in both of its two actions.

2.2 Procedure based Communication

As we learned in Sect. 2.1 the procedure based com-

munication model uses interface procedures to model

communication channels between action systems. Let

us consider an action system C lient (Fig. 2) and the

action system F ifo that was introduced earlier. Ac-

tion system C lient now imports the communication

procedure Get, which F ifo exports. The action pop

of the action system C lient uses the imported Get

procedure to retrieve the ﬁrst element from the FIFO

(Fig. 3). The communicating actions pop of C lient

sys C lient (in on: Boolean; out result : Integer;

imp Get(in x: Integer); )

|[ variable

a: Integer;

action

pop: (on → call Get(a); result := a);

initialisation

result := 0;

execution

do pop od ]|

Figure 2: Description of the action system C lient.

F ifo

pop waitGet

Client

call Get await Get

Figure 3: Action system C lient retrieving data from action

system F i f o using the communication procedure Get.

and waitGet of F ifo are:

pop b= (pop

;call Get(a); pop

)

waitGet b= (waitGet

;await Get;waitGet

)

where pop

1,2

and waitGet

1,2

are subactions of

pop and waitGet, respectively. In this example,

pop

b= result := a and waitGet

b= cnt := cnt − 1,

while waitGet

b= cnt > 0 → skip and pop

b= on →

skip, where skip is an empty action. Furthermore,

the local variables of the systems are distinct, l

C lient

∩

F ifo

0, communication variables are a set g

C lient

∩

F ifo

and the initialisations of the communication

variables g

C lient

∩g

F ifo

are consistent with each other.

In general, the body of a communication procedure

can be any atomic action reading from or writing onto

the local variables of the exporting action system. In

this case, the body bd(Get) of Get reads an item from

a queue q: q ∈ l

F ifo

In parallel composition of action systems,

C lient k F ifo, the execution clause of the composed

system is by deﬁnition:

do pop 8 waitGet od

The construct pop 8 waitGet, where pop calls Get

(call command) and waitGet awaits such a call (await

command), is regarded as a single atomic action. Let

us here name this action popGet and deﬁne it by:

popGet b= (pop

;waitGet

;bd(Get)[a/x];

waitGet

; pop

)

where [a/x] substitutes the variable a that is used

as an actual parameter, with the formal parameter x,

and thus Get writes the head of the queue q onto

a, which passes the requested value from F ifo to

ICSOFT 2008 - International Conference on Software and Data Technologies

248

C lient. Hence, communication is based on sharing an

action in which data is atomically passed from system

to system by executing the body of a procedure.

3 SYSTEMC

SystemC (The OSCI, 2002) can be used in designing

cycle-accurate models of software algorithms, hard-

ware architectures and interfaces of SoC and system-

level designs. It is a suitable tool for hardware mod-

elling, even though it is built on a high-level, object-

oriented software programming language. Being

able to replace actual hardware description languages,

such as VHDL and Verilog, in hardware design Sys-

temC makes it possible to model entire HW/SW sys-

tems in a single description language. With SystemC

designer can use all the object-oriented features and

development tools of C++ (Stroustrup, 1997) in ad-

dition to the system architecture constructs, such as

hardware timing, concurrency and reactive behaviour,

which are not included in standard C++. Both soft-

ware and hardware partitions that are written in Sys-

temC can also be tested using the same test bench,

provided by SystemC, without any need for language

conversions between different abstraction levels. Sys-

temC models can be reﬁned down to lower abstraction

levels ending up with an implementable design. The

reﬁnement process may be performed part by part so

that one design may consist of system parts at several

different abstraction levels. Nevertheless, the design

remains simulatable.

A SystemC model consists of modules that break

the design into several independent components.

Modules implement data encapsulation by hiding lo-

cal data and algorithms from the environment. Mod-

ules may contain also hierarchies of other modules.

Modules’ inner functionality is produced by running

processes that are triggered by events. Processes

of different modules communicate with each other

via channels that are accessed through ports and in-

terfaces. A port communicates with its designated

channel through an interface, which introduces the

methods that the port can use to access the chan-

nel. Channels are either primitive channels or hier-

archical channels depending on their complexity. A

primitive channel does not contain any other SystemC

structures, whereas hierarchical channels may contain

other modules and channels as well as internal pro-

cesses. In practice, hierarchical channels may be as

complex structures as modules.

The SystemC scheduler acts as a system kernel

that controls the SystemC simulation. The sched-

uler handles the timing and order of the processes

ActionC

Language constructs

& Programming style

Veriﬁed, implementable

& simulatable model

Formal, behavioural model

(System speciﬁcation)

Action Systems

description

SystemC

code

Figure 4: The concept of ActionC.

running in the system and updates the communica-

tion channels when needed. The scheduler catches

and manages the events that processes raise. This

way the scheduler acts as an intermediate in inter-

process communications triggering processes by re-

quest of other processes. Concurrency of actions is

modelled using the notion of delta delay. Simula-

tion time remains stopped while the scheduler man-

ages the events, process operations and channel up-

dates of the simulation time point in question. Com-

munications may be modelled in the simulation syn-

chronously or asynchronously depending on the spec-

iﬁcation.

4 ACTIONC

ActionC can be considered as the implementation of

the Action Systems formalism in the SystemC envi-

ronment but ActionC is also a design method that fol-

lows the programming style and structure of Action

Systems descriptions (Fig. 4). The objective of this

merger is to utilise the best parts of both system mod-

elling languages. Action Systems is a ﬁne language in

system speciﬁcation and veriﬁcation throughout a de-

sign process but it lacks the kind of commercial tools

that would spread the use of the language beyond the

borders of the academic world and promote the ac-

ceptance of the language in the industry. On the other

hand, SystemC is a powerful tool in system model

simulation, reﬁnement and testing but it is short of a

rigorous method that would ensure the correctness of

the model in the initial system description and also

preserve it during the reﬁnement process. The idea

of ActionC is to combine the formal features of Ac-

tion Systems with the beneﬁts of the SystemC envi-

ronment, thus creating a framework for writing exe-

cutable and reﬁnable speciﬁcations that are veriﬁed

in a formal manner.

The focal point of this paper is the ActionC im-

plementation of the Action Systems type of proce-

dure based communication model. In Action Sys-

tems, communication between systems is an essen-

tial issue when modelling complex embedded sys-

tems with multiple modules and processors. The pro-

cedure based communication model of Action Sys-

RIGOROUS COMMUNICATION MODELLING AT TRANSACTION LEVEL WITH SYSTEMC

249

Table 1: Matching language constructs between Action

Systems and SystemC.

Action Systems SystemC

action system ⇔ Module

in variable ⇔ sc_inhi

out variable ⇔ sc_outhi

inout variable ⇔ sc_inouthi

(local) variable ⇔ private C++/

SystemC variable

private procedure ⇔ private C/

C++ void method

public procedure ⇔ SystemC hierarchical

channel

function ⇔ private C/C++

non-void method

action ⇔ Module member

execution loop ⇔ SystemC thread

process

tems corresponds to the abstraction level of transac-

tion level modelling, which is also the most usual

modelling level in SystemC design. Therefore, com-

munication modelling must be properly handled also

in the ActionC framework. Before going further into

the issues of inter-module communication, we will in-

troduce the more obvious similarities between Action

Systems and SystemC languages.

4.1 Matching SystemC and Action

Systems Elements

SystemC and Action Systems share several language

constructs as can be concluded from their short intro-

ductions in the previous sections. The directly map-

pable constructs are gathered in Table 1. Both lan-

guages use modularisation in creating local scopes:

SystemC uses modules while an action system is the

corresponding structure in the Action Systems for-

malism. In ActionC we call this structure an ActionC

module. This structure also has an interface that it

uses in the communication with the environment. The

atomic actions of Action Systems are implemented

as member functions of the ActionC module. The

member functions may be either normal C++ meth-

ods or SystemC processes. These member functions

are called ActionC actions and they are executed by

performing action calls.

The execution loop of each of the Action Sys-

tems module is also implemented as a thread pro-

cess that runs the local actions one at a time. The

thread is suspended while local actions and actions in

imp ch if channel exp ch if

readX()

get()

virtual

SystemC scheduler

event notiﬁcation

trigger pro cess waitGet

7. 3.

exp get port

getCompleted()

writeX(x)

getCompleted()

virtual

readX()

get()

virtual

F ifo

waitGet

call

writeX(x)

trigger pro cess pop

event notiﬁcation

imp

get port

Client

pop

call

Figure 5: FIFO and its client communicating through a pub-

lic procedure.

other modules are executed. When inter-module com-

munication in Action Systems uses only basic data

types, the SystemC primitive channel ports

sc_in<>

sc_out<>

and

sc_inout<>

match directly with the

in, out and inout variables of the Action Systems for-

malism. When the channel structure is more complex,

a SystemC hierarchical channel is a more practical so-

lution. For example, the procedure based communi-

cation model of Action Systems can be implemented

in ActionC using the SystemC hierarchical channel.

This implementation will be elaborated in Sect. 4.2.

4.2 Procedure based Communication

The possibility to hide detailed communication prim-

itives at high abstraction levels allows a designer to

concentrate on the functionality of the system un-

der design. In Action Systems, as introduced in

Sect. 2.2, the implementation of communication ac-

tivities is hidden into a procedure based communica-

tion model. In the ActionC framework the procedure

based communication is modelled by using a combi-

nation of SystemC’s hierarchical channels, ports and

interfaces at the transaction level of abstraction. With

the combination of these artefacts we are able to con-

ﬁne the functionality of communication procedures

and to have one channel per communication proce-

dure. Ports and interfaces are used to connect a hier-

archical channel to a system that exports it and to sys-

tems that call it, that is, in both ends of a hierarchical

channel we have a port-interface couple. The func-

tionality of an interface depends on its type: exported

or imported communication channel. At the imported

side the interface has a minimum amount of methods

because the properties of the imported channel is in-

troduced by a system that exports it. At the exported

side the system has a wide-ranging set of methods to

use the channel. Communication channels are intro-

duced in and exported by a callee and imported by

a caller, as in Action Systems. The implementation

follows the blocking wait practice in which the call-

ing action waits until the callee is ready to form the

communication channel between the two modules.

ICSOFT 2008 - International Conference on Software and Data Technologies

250

The operation of the ActionC procedure based

communication channel, in terms of the Action Sys-

tems communication procedure call, is illustrated in

Fig. 5, which returns us to consider the FIFO struc-

ture we used as an action system example in Sect. 2.

Again, action system C lient needs to extract data

from the F i fo using the public procedure Get ex-

ported by F ifo and imported by C lient. In general

the data integrity during a communication call, as re-

quired by the Action Systems model, is ensured in

the ActionC model by seven (7) or eight (8) commu-

nication phases. The number of the phases is deter-

mined by the existence of a return value. In this case

the phases are: (1) The Action system C lient begins

the communication procedure by calling the chan-

nel’s interface method as it would call the imported

procedure in the Action Systems model. Then the

method stores its parameters into the channel’s local

variables before (2) sending an event notiﬁcation to

the SystemC scheduler, which (3) triggers the process

waitGet. The process waitGet is sensitive to the par-

ticular event. The concept of sensitivity in SystemC

corresponds to the function of the await command in

the Action Systems model. After being invoked (4)

the process waitGet calls the writeX() method pro-

vided by its interface to write the ﬁrst element of the

queue into the channel’s local variables. After the

writeX() method has returned (5) process waitGet em-

ploys the channel interface method getCompleted(),

which (6) sends an event notiﬁcation to the SystemC

scheduler. (7) As a result from the notiﬁcation, the

SystemC scheduler informs process pop of the com-

pletion of the communication procedure, that is, con-

tinues its execution from the point of last suspension.

(8) By calling the interface method readX() process

pop collects the value written to the channel by wait-

Get, thus ﬁnalising the communication procedure.

This implementation follows the atomicity con-

cept of the procedure based communication model in

Action Systems. The SystemC scheduler ensures that

the entire procedure call from phase (1) to phase (8)

is a continuous operation that is advanced and com-

pleted without interruptions.

5 CONCLUSIONS

We have taken the initial steps in creating a for-

mal framework for modelling and verifying embed-

ded computer systems with the SystemC environ-

ment. Using the presented ActionC framework de-

signer is able to reliably simulate Action Systems de-

scriptions. At the present phase of development Ac-

tionC still is more of a coding style than a fully im-

plemented class library to be used with SystemC. In

this paper we elaborated the ActionC implementation

of the procedure based communication model used by

the Action Systems formalism. The resulting model is

a transaction level model of a communication method

that uses remote function calls and blocking wait.

REFERENCES

Back, R.-J. (1988). A Calculus of Reﬁnements for Program

Derivations. Acta Informatica, 25:593–624.

Back, R.-J. and Kurki-Suonio, R. (1983). Decentralization

of Process Nets with Centralized Control. In PODC

’83: Proc. of the second annual ACM symposium on

Principles of Distributed Computing, pages 131–142.

ACM.

Back, R.-J. and von Wright, J. (1998). Reﬁnement Calculus:

A Systematic Introduction. Springer-Verlag.

Degerlund, F., Walden, M., and Sere, K. (2007). Implemen-

tation Issues Concerning the Action Systems Formal-

ism. In PDCAT ’07: Proc. of the 8. Int. Conference

on Parallel and Distributed Computing, Applications

and Technologies, pages 471–479. IEEE.

Dijkstra, E. W. (1976). A Discipline of Programming.

Prentice-Hall, Inc.

Habibi, A. and Tahar, S. (2005). Design for Veriﬁcation of

SystemC Transaction Level Models. In Proceedings

of the conference on Design, Automation and Test in

Europe, pages 560–565. IEEE.

Patel, H., Shukla, S., Mednick, E., and Nikhil, R. (2006). A

Rule-Based Model of Computation for SystemC: Inte-

grating SystemC and Bluespec for Co-Design. In For-

mal Methods and Models for Co-Design, 2006. MEM-

OCODE ’06. Proc. 4. ACM and IEEE International

Conference on, pages 39–48. IEEE.

Sere, K. and Back, R.-J. (1994). From Action Systems to

Modular Systems. In FME’94: Industrial Beneﬁt of

Formal Methods, pages 1–25. Springer-Verlag.

Stroustrup, B. (1997). The C++ Programming Language.

Addison-Wesley, USA, 3. edition.

The OSCI (2002). SystemC Version 2.0 User’s Guide. Up-

date for SystemC 2.0.1.

The OSCI (2005). IEEE Std 1666-2005, SystemC Language

Reference Manual. IEEE.

Vardi, M. Y. (2007). Formal Techniques for SystemC Veri-

ﬁcation. In Proceedings of the 44th annual conference

on Design automation, pages 188–192. ACM.

RIGOROUS COMMUNICATION MODELLING AT TRANSACTION LEVEL WITH SYSTEMC

251