Contract-Based Coordination of Hardware Components for the Development of Embedded Software

Bouhadiba, Tayeb; Maraninchi, Florence

doi:10.1007/978-3-642-02053-7_11

Cited by 3 publications

(9 citation statements)

References 13 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Each macro-step is considered to start in the state where the contract was, at the end of the previous macro-step. In [1] we presented a more general version of contracts, with internal variables and conditional data dependencies, but this simple version is sufficient here.…”

Section: Control Contractsmentioning

confidence: 97%

“…The core of the paper is the description of the structural correspondence between a SystemC/TLM-PV model, and a 42 model that has two properties: (i) it has exactly the same component structure; (ii) executing it with a dedicated 42 controller produces the same observations as the SystemC standard executions. For the latter point, we will recall and extend the control contract execution mode of 42 as defined in [1]. To our knowledge, this is the first formalization of SystemC/TLM-PV components, i.e., we do not only formalize the SystemC language, we also formalize what a TLM-PV component is (interface, contract, and the model of computation and communication corresponding to TLM-PV).…”

Section: Contributions and Structure Of The Papermentioning

confidence: 99%

“…The asynchronous simulation consists in repeatedly activating the global system via its control input op, which is then non-deterministically translated into A.op or B.op, respecting the data dependencies (a component whose contract specifies that input data id is needed, cannot be activated if id is not available, i.e., has not been produced by another component). We could write this controller directly, but in [1], we described how to obtain it automatically from the components' contracts. Figure 8 gives possible contracts for the two components.…”

Section: Executing Contractsmentioning

confidence: 99%

“…The contributions of this paper are: (i) A structural correspondence between a SystemC/TLM-PV model and a 42 model; (ii) A generalized execution mode for systems of 42 components given by their contracts only (in [1] we had only one level of hierarchy); (iii) A method for executing the 42 model together with the real SystemC code (the SystemC code for threads and functions is unchanged, but it is executed by the 42 controllers instead of the SystemC scheduler).…”

Section: Contributions and Structure Of The Papermentioning

confidence: 99%

“…42 enriched by control contracts, used to simulate a system of components given by their contracts, can be found in [1]. Figure 3 shows a 42 component.…”

Section: The Component Model 42mentioning

confidence: 99%

See 4 more Smart Citations

Formal and executable contracts for transaction-level modeling in SystemC

Bouhadiba

Maraninchi

Funchal

2009

Proceedings of the Seventh ACM International Conference on Embedded Software

Self Cite

View full text Add to dashboard Cite

Transaction-Level Modeling (TLM) for systems-on-a-chip (SoCs) has become a standard in the industry, using SystemC. With SystemC/TLM, it is possible to develop an executable virtual prototype of a hardware platform, so that software developers can start writing code long before the actual chip is available. A hardware model in SystemC/TLM can be very abstract, compared to the detailed RTL model. It is clearly component-based, with guidelines defining how components should be designed for use in any TLM context. However, these guidelines are quite informal for the moment. In this paper, we establish a structural correspondence between functional SystemC/TLM models and a formal component-model for embedded systems called 42, for which we have defined a notion of control contract, and an execution mode for systems made of components' contracts. This is a way of formalizing the principles of functional SystemC/TLM. Moreover, it allows the combined use of SystemC/TLM components with 42 components. Demonstrating that such a combined use is possible is key to the adoption of formal components' definitions in the community of TLM users.

show abstract

Section: Control Contractsmentioning

confidence: 97%

Section: Contributions and Structure Of The Papermentioning

confidence: 99%

Section: Executing Contractsmentioning

confidence: 99%

Section: Contributions and Structure Of The Papermentioning

confidence: 99%

“…42 enriched by control contracts, used to simulate a system of components given by their contracts, can be found in [1]. Figure 3 shows a 42 component.…”

Section: The Component Model 42mentioning

confidence: 99%

See 3 more Smart Citations

Formal and executable contracts for transaction-level modeling in SystemC

Bouhadiba

Maraninchi

Funchal

2009

Proceedings of the Seventh ACM International Conference on Embedded Software

Self Cite

View full text Add to dashboard Cite

show abstract

On the Formal Verification of Systems of Synchronous Software Components

Günther

Milius

Möller³

2012

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Coordination operators and their composition under the actor-role-coordinator (ARC) model

Song

Ren

2011

SIGBED Rev.

View full text Add to dashboard Cite

For large open and distributed real-time applications, coordination constraints among concurrent, spatially distributed and autonomous entities can be complex. The Actor-Role-Coordinator (ARC) model we developed earlier [1] introduced the concept of roles which are abstractions of behaviors that are to be coordinated. Each role's behaviors may be shared by many concurrent entities, or played by many actors. Based on the role concept, coordination activities in large systems are partitioned into inter-role and intra-role coordinations to mitigate the coordination complexity. This paper focuses on coordination primitives and the composition of these primitives in forming more complex intra-role and inter-role coordination constraints. In particular, we define two primitive coordination operators, i.e., precede ( t) and select ( p), and use them to express temporal and spacial (with respect to actor system's behavioral space) coordination constraints among concurrent and autonomous actors. We further provide an operational semantics for these operators under the ARC model and provide case studies to illustrate their expressiveness in specifying complex coordination constraints.

show abstract

Contract-Based Coordination of Hardware Components for the Development of Embedded Software

Cited by 3 publications

References 13 publications

Formal and executable contracts for transaction-level modeling in SystemC

Formal and executable contracts for transaction-level modeling in SystemC

On the Formal Verification of Systems of Synchronous Software Components

Coordination operators and their composition under the actor-role-coordinator (ARC) model

Contact Info

Product

Resources

About