SystemC Translation Into Signal

[TGSG05] describes a general approach to extract a behavioral type from a system using the polychronous model of computation (using Signal [BGJ89] as a support language). This applies to languages and ex-ecution models such as Java, SystemC and SpecC. Their starting point is the GNU SSA (static single assignment) [Pro04] form, which is the intermediate representation in GCC, since version 4.0. Compared to the AST structure that we are using, SSA is much simpler, and independent of the source language (complex constructs of the source language have already been broken down into simpler primitives). It has been chosen in GCC because it is a form on which optimizations can be efficiently performed.

We also considered using SSA as a starting point in LUSSY(at that time, SSA was not included in a sta-ble version of GCC, but was already availasta-ble in a development branch). Using it would have considerably eased the translation of the C++ code intoHPIOM(reduced the corresponding code in BISEby a factor 10 probably), but would have made the task much harder, if not impossible, for PINAPA: recognizing a state-ment such asport.write(true);in the SSA form is very difficult, because the simple function call

Matthieu Moy Ph.D Thesis 109/190

Chapter 6. BISE: Semantics of SystemC and TLM Constructs in Terms of Automata

statement has already been broken down into many small operations. The benefit in BISEwould probably not have been worth the trouble since it concerns only the C++ part, whereas most of the effort in BISEis related to SystemC and TLM constructs.

The interesting property of SSA exploited in the translation into signal is the fact that since a variable is assigned once only in each block, the transformation performed by each block can be done in one clock cycle. The translation into a data-flow synchronous language is therefore relatively straightforward. This translation allows checking properties similar to the ones available in LUSSY: termination, dead-locks, concurrent write accesses, . . .

[TBS⁺04] describes an initial version of the application of this method to the case of SystemC. A surprising aspect of this work is that instead ofmodelingthe SystemC scheduler (with, in particular, the notion ofδ-cycle) using the polychronous framework, itreplacesit with the synchronous semantics. Both approaches achieve the same goal (simulate the physical behavior of a circuit), so the resulting behaviors are similar, and actually equivalent on a subset of SystemC. However, it is easy to find a counter-example where theδ-cycles of a SystemC program do not model the fixed-point of a combinational system, and therefore where the approach does not apply. One is provided in Figure6.19(the processside effect::fmay have to be rescheduled several times to compute the fixed-point. If it is executed more than once, then an error is raised instead of recomputing the output based on the input). It is actually the case for most processes with a notion of state and side effects. In practice, in most of the cases, a process with side effect will not be rescheduled several times, and processes relying onδ-cycle to be rescheduled will be purely combinational. However, components like the TAC arbiter implementing an arbitration policy have to rely onδ-cycle.

1 SC_MODULE(side_effect) { 2 bool been_there;

3 sc_in<bool> in;

4 sc_out<bool> out;

5 void f(void) {

6 ASSERT(! been_there);

7 been_there = true;

8 out.write(in.read());

9 }

10 SC_CTOR(side_effect) { 11 been_there = false;

12 SC_METHOD(f);

13 }

14 };

Figure 6.19: A module abusing the notion ofδ-cycle

In the meantime, some work has been carried out to model more precisely the details of the SystemC API. Hopefully, the counter-example mentioned above is no longer a counter-example.

Note however that some process do have the fixed-point semantics, and could be managed in an opti-mized way. Indeed, [KS05] provides sufficient conditions and optiopti-mized treatment for some categories of processes.

6.7 Conclusion

We presented the component BISE of LUSSYthat translates SystemC code intoHPIOM. BISEalso inte-grates different kind of properties to be verified for the platform into the generatedHPIOM. It translates the C++ code, and has a direct semantics of SystemC constructs. Additionally, we also modeled the TAC and BASIC protocols that are not yet standardized in SystemC itself.

110/190 Verimag/STMicroelectronics — 9 d´ecembre 2005 Matthieu Moy

Part III

Utilisation de ^HPIOM pour la v´erification formelle

—

Using ^HPIOM for Formal Verification

111

Chapter 7

B ^IRTH : Back-end Independent

Reduction and Transformations of

HPIOM

Contents

7.1 Introduction . . . 113 7.2 Results ofBIRTHon Some Examples, Without Optimization . . . 114 7.3 Semantic Preserving Transformations . . . 115 7.3.1 Abstract Addresses Expansion . . . 115 7.3.2 Non-Deterministic Choices Expansion . . . 115 7.3.3 Reducing the Number of Variables and Inputs . . . 115 7.3.4 Reduce the Number of States by Parallelizing Transitions . . . 119 7.4 An Approximation Conservative for Safety Properties: Abstracting Away

Numeri-cal Values . . . 120 7.5 Non-conservative Approximations . . . 120 7.5.1 Initialize variables deterministically. . . 121 7.5.2 Limit the Depth of the Proof . . . 121 7.5.3 Specify the Initial State Manually. . . 121 7.6 Conclusion . . . 122

7.1 Introduction

While transforming automata into LUSTRE or SMVcode, one of the goals of LUSSYis to generate the most optimized code possible for a given semantics. Most optimized means for example as few variables as possible, as few inputs as possible.

Many optimizations can be performed at the time theHPIOMis generated. We have already described some of them in section5.5.3. But incorporating too many optimizations in the generation itself would make the code more complex. Some optimizations are global and could hardly be performed before the complete system, or at least a complete automaton is generated. We preferred a good separation of the

HPIOM generation and the optimizations. This way, BISE can concentrate on the correctness of the se-mantics, and another component, will transform the generatedHPIOM, focusing on the optimizations them-selves, independently from the semantics of the source language. In the future,HPIOMmay be used outside LUSSYfor purposes other than analyzing SystemC code. With a separate software component for the op-timizer, any tool generatingHPIOMcan benefit from the optimizations. The same reasoning applies for the

113

Chapter 7. BIRTH: Back-end Independent Reduction and Transformations ofHPIOM

back-ends: any optimizations performed prior to the back-ends is done once and for all, while any opti-mization performed in the back-ends has to be duplicated for each of them. The optiopti-mizations presented here are therefore both independent from the source language (SystemC) and from the target language (LUSTRE,SMV).

We have therefore implemented optimizations as a separate component, BIRTH, that performsHPIOM

toHPIOMtransformations.

Some of the optimizations presented here are usual optimization techniques that have simply been adapted to our structure (live variable analysis for example). Others are more original, for example, setting the initial value of an initially inactive variable to a fixed value is exactly the opposite of what a traditional compiler does after live variable analysis.

The symbolic model-checking techniques that we will use to prove properties onHPIOMsystems have performances that are directly linked with the size of the system. An optimization that reduces the number of variables and the number of inputs of the system will usually improve the performances (but it is always possible to find corner-cases where a the prover will find a good variable ordering to make small BDDs with the unoptimized system, and where the optimized system will have fewer variables, but bigger BDDs).

Our goal will be to reduce the number of variables and the number of inputs. In the results we give, we also provide the performances of the provers, using the back-ends described in the next chapter, to get an idea of the impact of the modifications we made on the global tool-chain.

We will give numerical results for the EASY platform that we described in section2.5.2. Unfortunately, even with all optimizations enabled, no back-end was able to lead to a successful proof for the generated

HPIOM system (SMVstarts iterating but hangs after a few hours of computation). We can therefore give results only in terms of size of theHPIOMsystem, but not in terms of proof performance for this platform. In addition, we give the results for the example platform introduced in section2.4.3.6, which is much smaller and allows us to complete the proof with both LUSTREandSMVback-ends, with or without optimization.

Some of the transformations implemented in BIRTH are not optimizations, but reductions of some high-level constructs to lower-level constructs (like abstract addresses transformed into Boolean variables, expansion of non-deterministic choices into unknown values, . . . ).

This chapter will present several transformations: first, the semantic preserving, in section 7.3, then, the conservative approximations in section7.4. Section7.5will give some examples of non-conservative approximation.