We presented PINAPA, a front-end for SystemC. Unlike traditional compiler front-ends, it executes a part of the program before parsing it, and the main work presented in this paper is the way to make the link between the source code representation and the runtime information.
This technique allowed us to write a SystemC front-end with very few limitations, with a minimal effort. It reuses megabytes of source code from GCC and SystemC, but counts itself less than 4,000 lines of code. The performances are reasonable: most of the time is spent in GCC, so parsing a model with PINAPAtakes almost the same time as compiling it with GCC. It already manages the TLM TAC and TLM BASIC extensions of SystemC, and other could be added in the future depending on our needs.
The parser is already operational and used in two formal verification back-ends and a prototype of visualization tool.
70/190 Verimag/STMicroelectronics — 9 d´ecembre 2005 Matthieu Moy
Chapter 5
HPIOM : Heterogeneous Parallel Input/Output Machines
Contents
5.1 Introduction . . . 71 5.1.1 The Need For an Intermediate Formalism. . . 71 5.1.2 Design Choices . . . 72 5.1.3 Contents of the chapter . . . 72 5.2 HPIOMBasic Concepts . . . 73 5.2.1 Syntax ofHPIOM . . . 73 5.2.2 Semantics ofHPIOM. . . 76 5.2.3 Non-determinism . . . 78 5.3 Additional constructs . . . 78 5.3.1 Convenience constructs . . . 78 5.3.2 Abstract Addresses . . . 79 5.4 Expression of Properties inHPIOM . . . 83 5.5 Implementation of and Manipulation ofHPIOM . . . 84 5.5.1 HPIOMExpressions and the Composite Design Pattern . . . 84 5.5.2 HPIOMExpressions and the Visitor Design Pattern . . . 85 5.5.3 On-the-fly Optimizations . . . 90 5.5.4 Future improvements . . . 92
5.1 Introduction
The previous section presented PINAPA. From the source code of a TLM model, it is able to provide an abstract representation of the syntax and architecture of the model. At this point, no transformation involving the semantics of the program has been applied to the model.
5.1.1 The Need For an Intermediate Formalism
To be able to apply any kind of formal methods to the model, we need to transform the output of PINAPA
into a structure with a well-defined, formal semantics.
Starting from the abstract representation of the model provided by PINAPA, our final goal is the con-nection to a formal verification tool. A direct concon-nection would be possible, but not desirable: first, mixing the interpretation of the semantics of SystemC and the generation of the target language in the same piece
71
Chapter 5. HPIOM: Heterogeneous Parallel Input/Output Machines
of code would lead to complex and unmaintainable code, and most of all, this would require a complete rewrite for each back-end tool to manage.
We need therefore an intermediate formalism. The requirements are the following:
Well defined formal semantics: The transformation of SystemC into this formalism is a way to give a semantics to SystemC. It only makes sense if the semantics of the destination language is itself clear;
Powerful enough: The formalism should of course be expressive enough to represent the semantics of the model;
Simple to manipulate: The idea is to perform as much as possible of the work before the intermediate formalism in the transformation flow. Any transformation of a complex structure into a simpler one done before the intermediate representation is done once and for all. Any transformation coming after it in the flow may have to be re-written for each back-end;
Executable: To get confidence in our algorithms, a good solution is to test the generated code against the official SystemC execution engine. The formalism being executable is crucial to allow validation and easy debugging of the generated code;
Provable: Our final goal is to perform formal verification. The proposed formalism should therefore allow it. This requirement is not very different from the “Well defined formal semantics” one.
For a more general discussion about the expected qualities of a formal language, see appendixB.
5.1.2 Design Choices
5.1.2.1 Reusing an Existing Format
We experimented the IF toolkit [BGO+04], but quickly realized that the effort to learn, and adapt the toolkit to our needs, was much higher than redeveloping an automata manipulation library from scratch.
We did not find another flexible enough automata library under reasonable license conditions, and decided to develop our own formalism and manipulation library. This formalism is called HPIOM, for Heterogeneous Parallel Input/Output Machines. It is inspired from synchronous languages like Es-terel [Ber00] and Argos [MR01].
5.1.2.2 Expressiveness Choices
The above-mentioned requirements are sometimes contradictory, and some choices have to be made. In particular, “Provable” is not always compatible with “Powerful enough”. The more expressive a language is, the less provable it is. For example, proving properties like code reachability and termination on a Turing-equivalent language is not decidable, while it can be decidable, or even trivial on less expressive languages. In our context, it would not really make sense to privilege expressiveness: Having a more expressive intermediate formalism would allow us to translate more source programs with a complete preservation of the semantics, but would not allow us to prove more properties if the proof engine does not support those constructs. We have chosen to designHPIOM as a finite automata formalism, without any dynamic process creation and dynamic data-structures.
5.1.2.3 Limitations ofLUSSYdue toHPIOMDesign
The choice of a limited expressiveness forHPIOMhas some consequences on the possibilities of LUSSY. Since we have no dynamic data-structure inHPIOM, and no easy way to simulate it (we have unbounded integers on which we can encode anything in theory, but that’s not reasonable in practice), any SystemC program using dynamic data structure or non-terminal recursive calls will have to be approximated during the conversion. We’ll manage to perform the approximation in a way that preserves the properties we want to verify.
5.1.3 Contents of the chapter
This chapter will define an intermediate formalism called HPIOM. It is a simple model of communicat-ing automata, simple enough to be manipulated easily, and powerful enough to express the semantics of a
72/190 Verimag/STMicroelectronics — 9 d´ecembre 2005 Matthieu Moy