Project topics and materials
Get Complete Project Material File(s) Now! »
Traditional vs New SoC Design Flow
In this section, we study the evolution of the methodologies used in the conceptual design of complex systems : the traditional design process and the new design process [ed05b]. In a traditional design process, the system specication is directly followed by hardware and software development. This is why, it is not easy to reach an implementation that is functionally correct and that respects the initial specications. We may need to follow several steps and iterations to produce a nal SoC that is conform to the specications. As a result, the traditional design ow is a time consuming and an inecient process since it is not usually easy to add any transformations to the design after prototype. The traditional design ow is illustrated in Figure 2.3. As shown in this gure, the system specication is split into two distinct parts : (1) system hardware development and (2) system software development. Note that there is no communication between these two parts. Each part is developed independently until we generate a prototype of the system under design. Thus, no transformations can be added once the hardware and the software are designed. The traditional hardware design process relies classically on three dierent levels of abstraction. A general classication of the design process is available through the Y-Chart [GK83, AG02](Figure 2.4). It denes system level, register-transfer (RT) level, gate level, and transistor level. Each level represents a specic model. We distinguish between the behavioral and the structural model : a behavioral model describes the functionality of the component with dierent scenarios ; i.e. a graph with dierent states and the transitions between them. The structural model describes dierent components of the system and the connections between them.
Attempts at Raising Abstraction Level
Many attempts were made to raise the abstraction level in order to gain in speed during simulation without loss of accuracy [ed05b]. Thus, the high level model must rst simulate the application during a millions of cycles within a reasonable duration of time. Second, the model must be as accurate as possible to give reliable simulation results ; i.e, it must contains enough details about the hardware in order to run the embedded software. Besides, in order to optimize the SOC project cost, the high level model should be developed in a considerable low eort.
First, designers resort to hardware/software co-verication [ed05b]. In SW/HW coveri cation, they simulate the software on an RTL model of the hardware and they use a faster processor model that is called Instruction Set Simulator (ISS). It is an instructionaccurate model developed in C language at a higher level of abstraction. The main advantage of that technique is that we can integrate, verify and debug the SOC in an early phase of the design cycle before the implementation of the hardware. The simulation speed of the application is considerably higher in the co-verication of hardware/software. Moreover, any modication on the hardware or the software will be both time and cost ecient since the chip is not manufactured yet. Despite the eciency of the co-verication in term of time and cost compared to logic simulation, it still lack performance. Thus, it takes a long time to develop the RTL hardware model that is used to simulate the software.
The Modeling Approach with TLM
As discussed earlier, a SoC component is modeled as a module in TLM. A TLM module is a set of hardware blocks or IPs. Each block is represented through its internal functionality, its inputs/outputs and how it is synchronized with other blocks. No details about the architecture or internal pipelines are implemented. A complete SoC TLM platform is constructed by instantiating and binding dierent modules and channels together. Once the platform is integrated, SoC simulation is performed by executing the related embedded software. The system synchronization could be modeled by specic means such as events, signals, and interrupts or by data-exchanges. If any of these potential system synchronizations cause a call to the simulation kernel, it enables the scheduler to activate other modules. We may consider two fundamental classes of TLM[ed05b]
Untimed TLM.
Timed TLM.
On one hand, the untimed TLM is an architectural model targeted specically at early functional software development and functional verication where timing annotations are not considered or are abstracted from the system description. This model is used to perform simulation speed. It is also called programmer’s view (PV). On the other hand, the timed TLM is a micro-architectural model that is annotated with time about the behavioral and communication specications. The main purpose of timed TLM is to ensure the simulation accuracy that must be respected in real-time embedded software development and architecture analysis. It is also called programmer’s view plus timing (PVT).
Table of contents :
1 Introduction
1.1 Context
1.2 Summary of Contributions
1.2.1 Research Questions
1.2.2 Contributions
1.3 Outline
2 The System-on-Chip Design Flow
2.1 Introduction
2.2 SoC Bottlenecks
2.2.1 Explosive Complexity
2.2.2 Time-to-Market Pressure
2.2.3 Cost
2.3 Traditional vs New SoC Design Flow
3 Top-Down and Bottom-Up Approaches in the Conceptual Design
3.1 The Top-Down Approach
3.2 The Bottom-Up Approach
3.3 Conclusion
I System Level Modeling with SystemC
4 Transaction-Level Modeling (TLM)
4.1 Introduction
4.2 Attempts at Raising Abstraction Level
4.3 The Transaction Level Modeling
4.3.1 Description of TLM
4.3.2 The Modeling Approach with TLM
4.3.3 The Novel Design Flow with TLM
4.4 Conclusion
5 SystemC Language
5.1 Introduction
5.2 Structure of a SystemC Model
5.2.1 Syntax
5.2.2 Processes
5.2.3 Channels
5.2.4 Events
5.2.5 Time in SystemC
5.3 SystemC Scheduler
5.4 The TLM Library
II Modeling with SystemC Waiting State Automata (WSA)
6 Introduction and Related Works
6.1 Introduction
6.2 Existing Static Approaches in SystemC Modeling and Verication
6.3 Summary
7 SystemC Waiting State Automata
7.1 Motivations and General Approach
7.2 Example
7.3 Syntax
7.4 Model Properties
7.5 Conclusion
8 Symbolic Composition and Reduction of SystemC WSA
8.1 The Symbolic Composition of the SystemC WSA
8.2 The Symbolic Reduction of the SystemC WSA
8.3 Conclusion
9 Extending the SystemC Waiting State Automata with Counters and with Time
9.1 Extending the SystemC WSA with Counters
9.1.1 Syntax
9.1.2 The Symbolic Composition
9.1.3 The Symbolic Reduction
9.2 Extending the SystemC WSA with Time
9.2.1 Syntax
9.2.2 Symbolic Composition
9.2.3 Symbolic Reduction
9.3 Extending the SystemC WSA with Counters and Time
9.3.1 Syntax
9.3.2 Symbolic Composition
9.3.3 Symbolic Reduction
9.4 Conclusion
10 Summary
11 Mapping SystemC Designs to SystemC WSA
11.1 Determining Constituent Components
11.2 SystemC WSA of the Components
11.2.1 SystemC WSA of SC METHOD Processes
11.2.2 SystemC WSA of SC THREAD Processes
III Automatic Generation of SystemC Waiting State Automata from SystemC Codes
12 Introduction (Global Approach)
12.1 Formal Semantics of the Programming Language
12.1.1 Subset of SystemC
12.1.2 SystemC Operational Semantics
12.2 Symbolic Execution
12.3 Abstract Analysis and Traces Merging
12.3.1 Galois Connection
12.3.2 Fixed points Computation
12.3.3 Widening Operators
12.3.4 Traces merging
13 Formal Semantics of SystemC
13.1 Motivations and Related Works
13.2 Formal Semantics of SystemC
13.2.1 Basic Statements
13.2.2 Channel Statements
13.2.3 Event Statements
13.2.4 Wait Statements
13.2.5 Function Calls
13.2.6 Sequential Composition
13.2.7 Parallel Composition
13.3 Conclusion
14 Applying Static Analysis to Automatically Generate the SystemC Waiting State Automata
14.1 Abstracting Low Level Semantics of SystemC to High Level Semantics
14.1.1 Introduction
14.1.2 Example
14.1.3 Extended Symbolic Execution
14.1.4 Abstracting Operational Semantics of a Subset of SystemC
14.1.5 The Abstracted Operational Semantics vs the SystemC Waiting State Automata Semantics
14.2 Predicate Abstraction
14.2.1 Background
14.2.2 Handling Execution Traces Without Loops
14.2.3 Handling Loops
14.2.4 Conclusion
14.3 The Simple Bus Case Study
15 Conclusion
IV Applications of the SystemC WSA Model
16 Introduction
17 Modeling and Simulation of SystemC Programs using the SystemC WSA
17.1 Introduction
17.2 Modeling and Simulation with the SystemC WSA
17.3 Summary
18 Hardware/Software Co-verication (Worst Case Execution Time Estima- tion Work ow Based on the Timed WSA Model of SystemC Designs)
18.1 Introduction
18.2 Related Works
18.3 Modeling the Processor
18.4 WCET Estimation
18.4.1 Value Analysis
18.4.2 Conjoint Symbolic Execution
18.4.3 Intelligent States Fusion
18.5 Conclusion
19 Applying Verication Techniques to SystemC WSA
19.1 Anomalous Behaviors
19.1.1 Introduction
19.1.2 Liveness and Determinism
19.2 Applying Model Checking Techniques to SystemC WSA
19.2.1 Introduction
19.2.2 Checked properties
V Conclusion and Prospects
20 Conclusion and Prospects
20.1 Results and Discussion
20.2 Prospects
List of Figures
List of Acronyms
Bibliography
