Integration of SystemC-AMS and SoCLib components

Get Complete Project Material File(s) Now! »

Thesis organization

In Chapter 1, the context and objective of this thesis is defined. The organization of the rest of the document is presented below.
In Chapter 2, related work to this thesis is presented. The AMS extensions for Sys-temC are described. The SoCLib library is introduced and its main features are pointed out. An approach developed as part of the SystemC-MDVP (Multi-Disciplinary Virtual Prototyping) simulator that deals with the problem of time synchronization between the TDF and DE MoCs is explained. An overview of TTool and the SystemC-AMS graphical interface and platform generation developed in phase 1 is shown.
In Chapter 3, the development of phase 2 of the LIP6 project “SystemC-AMS extensions for TTool” is described, which consists in the integration of SystemC-AMS and SoCLib components without the use of an OS. Two diﬀerent steps are carried out: first by using a pedagogic SoCLib SystemC model of a one memory mono-core SoC in which assembler instructions were inserted; and later using a SoCLib model of a similar one memory mono-core SoC in which C code was programmed. It is explained as well the need of creating a generic adapter module for connecting the analog and digital components of the models.
In Chapter 4, the time synchronization issues between the TDF and DE MoCs interac-tions are described more deeply. A description of the method proposed in [7] is presented. Finally, a solution for these synchronization issues within the context of this thesis is pro-posed.
In Chapter 5, the development of phase 3 is explained, which integrates the work done from phase 1 and 2 by using TTool’s SoCLib and SystemC-AMS modules along with the MutekH OS. The implementation into TTool of the solution for the synchronization issues between the TDF and the DE MoCs presented in Chapter 4 is described.
In Chapter 6, simulation results of diﬀerent test models are presented. A model that initially stems from a purely digital model in TTool, a rover system meant to assist rescuers to find victims in debris, is used as a case study. A vibration sensor model from the H-Inception project [8] has been modeled and simulated in TTool and is used to compare the results obtained by the SystemC-MDVP simulator as part of the work of [7]. Other SystemC-AMS models have been created in TTool, in SystemC-MDVP and in SystemC to show how the synchronization issues between TDF and DE MoCs are handled in each simulator and compare the results.

SystemC and SystemC-AMS

SystemC [9] is a C++ class library which supports the modeling of embedded systems and represents their hardware components as modules; these modules are connected using ports. The scheduling and synchronization of concurrent processes uses events and sensitivity of the ports. SystemC advances simulation time, separates computations (processes) from communication (channels); it supports hardware oriented data types [10, p. 562].
The SystemC simulation kernel is based on the DE MoC, which describes systems based on temporal sequences of a countable number of events [11]. The processes of a DE MoC describe the functional behavior of the system. The execution of these processes is triggered by events (inputs are sensitive to these events) or by the passing of time (after a « wait » of certain time). The processes themselves can generate new events. All events are sorted with respect to time stamps, and inserted into an event queue. A scheduler determines which processes can be executed next, based on the events from the event queue and the passing of time. Since the schedule is computed during run time, it is known as dynamic scheduling.
The SystemC-AMS extensions increase the capabilities of the SystemC library to allow the design and simulation of AMS and signal processing systems along with digital hard-ware systems [12, p. 169]. SystemC-AMS can be used for creating system-level models which can be used for diﬀerent use cases such as executable specification, virtual proto-typing, architectural exploration and validation of the system [13, p. 1 f].
SystemC-AMS extensions are implemented as a C++ class library. As shown in Fig-ure 2.1, they are built on top of the SystemC standard. SystemC-AMS defines diﬀerent modeling formalisms implemented by using diﬀerent MoCs, to support AMS behavioral modeling. The MoCs that are currently in SystemC-AMS are TDF (Timed Data Flow), LSF (Linear Signal Flow) and ELN (Electrical Linear Networks).
The focus of this work is on the SystemC-AMS TDF MoC. It is based on the SDF (Synchronous Data Flow) [14] modeling formalism with the diﬀerence that TDF is a discrete-time model which considers the data as signals sampled in time, while SDF is an untimed MoC. As explained in [13, p. 7], the TDF model consists of nodes (modules) that represent processes; and arcs (signals) that represent data paths. TDF modules use ports as an interface to connect to other modules through signals. To connect to other TDF modules, TDF ports are used. To connect to DE modules, TDF converter ports are used. A set of connected TDF modules form a directed graph called TDF cluster. Figure 2.2 shows a TDF cluster, where the DE modules are represented as white blocks; TDF modules as gray blocks; TDF ports as black squares; TDF converter ports as black and white squares; DE ports as white squares; and TDF signals as arrows. The TDF modules of a cluster have attributes which are described below.
1. Module Timestep (Tm): denotes the period in which the module will be activated. One module will only be activated if there are enough samples available at its input ports.
2. Rate (R): Each module will read or write a fixed number of data samples each time it is activated. This number is annotated to the ports and it is known as the port rate.
3. Port Timestep (Tp): it is the period at which each port of a module will be activated. It also denotes the time interval between two samples that are being read or written.
4. Delay (D): A delay can be assigned to a port. As its name suggests, this attribute will make the port to hold up a number of samples each time it is activated, and read or write them in the following activation of the port.
Compared to DE models, TDF models have the advantage that they can execute without the overhead of dynamic scheduling. Instead, they define a static schedule which is calculated before the simulation starts, accelerating the simulation’s run time. Once the static schedule is computed, the TDF modules are executed according to this schedule.

SoCLib

As specified in [5], SoCLib is an open SystemC library for the creation of virtual pro-totypes of MPSoCs. It consists of simulation DE models for virtual components which can be simulated with the SystemC simulation environment. SoCLib components are implemented in two ways, based on the type of simulation that is required:
1. CABA (cycle-accurate bit-accurate) for very accurate but slower simulations [15]. TTool mainly focuses on the use of these components.
2. TLM (Transaction Level Modeling) [16] for faster simulations with some loss of accuracy.
SoCLib components are interconnected based on the VCI (Virtual Component Inter-face) [17] protocol. This makes the components easily inter-operable and facilitates the integration of new components into the platform. As noted in [17], it is important to mention that the VCI is not a bus but an interface. Hence, it specifies a request-response protocol, a protocol for transfer of requests and responses, and the coding and contents of these requests and responses. This interface can be used to connect two components in a point-to-point connection. One of the components will act as an initiator, issuing requests; while the other will act as a target, responding to these requests. Also, the VCI can be used as an interface to a wrapper, in other words, as a connection to a bus. In this way, the components can be connected to any bus.
SoCLib makes use of this interface to define its own interconnect component models.
These interconnect components can be of two types:
1. Physical interconnects, which implement interconnects for which an equivalent physical hardware exists.
2. Virtual interconnects, which implement the behavior of an interconnect without having an equivalent physical hardware, which makes simulations faster. TTool implements this type of interconnects which can be either a VGMN (virtual generic micro-network) or a VGSB (virtual generic system bus).
Many SoCLib components have a VCI interface. SoCLib implements special signals to use with the VCI protocol. By doing so, the SoCLib hardware components may connect to the interconnect components via their VCI interfaces and using this VCI signals.

SystemC-MDVP and timed-CPNs

The SystemC-MDVP simulator was developed at LIP6 as part of two previous works [7, 18]. This simulator targets the simulation of heterogeneous systems which can be modeled using diﬀerent MoCs. Within the context of SystemC-MDVP a solution for the detection of the time synchronization issues between the DE and TDF MoCs during the elaboration phase of the SystemC model is proposed. The approach is based on an equivalent representation of the TDF clusters and the interactions with the DE domain using timed-CPN (timed-Coloured Petri Nets).
CPN (Coloured Petri Nets) is a graphical discrete-event modelling language that can be used to create models and analyze the properties of concurrent systems. It combines the capabilities of Petri Nets and those of a high level programming language. Finally, it provides the primitives for the definition of data types, for describing the manipulation of the data, and for creating compact models that can be parameterisable.[19, p. 3] As it is described below, CPN can be used to represent TDF modules and their connections. Finally, if timing information is required, it can be added to the CPN models. In this case they are known as timed-CPNs.[19, p. 231]
As mentioned before, the TDF MoC is based on the SDF modeling formalism. It is possi-ble to transform SDF models into Petri Nets by means of a set of translating mechanisms [20]. Since an SDF model may be represented by using Petri Nets, a TDF model can make use of Petri Nets as well in order to perform pre-simulation analyses of the model that do not include interactions between the TDF and DE time domains. These pre-simulation analyses do not take into account the time notion handled by the TDF ports and modules of a TDF cluster, but they can be useful in order to obtain a static schedule of the model. To be able to represent the timing information handled by the TDF con-verter ports and their interactions with the DE domain, timed-CPNs have showed to be a good choice for this purpose since they facilitate the detection of time synchronization problems and the proposition of a possible solution to these issues.[7, p. 56 ﬀ] As it is described in detail in [21] and [7, p. 60 ﬀ], the construction of an equivalent representa-tion of the TDF clusters and their interactions with the DE domain using timed-CPN requires a three steps process, which is summarized below.
1. The first step is to represent a TDF module as an equivalent CPN. Figure 2.3 shows this equivalent CPN representation where a transition (square) represents the execution action of the TDF module. This transition has a name M:qM; a guard [jM <> qM] that evaluates if the transition is enabled or not, where jM is the current execution number of the module and qM is the maximum execution number of the module; and a priority LOW. The current execution number jM is stored in a place (ellipse) which has a name Counter M; a color set INT that defines the data type; and the initial tokens of the place InitCountM.
Figure 2.3: Equivalent CPN of a TDF module. (Reprinted from [7, p. 60] with permission.)
2. The second step consists on representing the TDF connections or signals as an equivalent CPN. Figure 2.4 shows the equivalent CPN representation of a TDF signal where the modules that are being connected are represented in a simple way by squares, and the signal is represented using a place (ellipse). The place has a name SN; a color set INT that defines the data type; and a multiset of delay tokens DelaySN which are the addition of the delay attributes of the interconnected ports. The producer and transition modules are linked via directed arcs with functions that calculate the token identifiers produced or consumed when a module is fired.
3. The third step is to represent the TDF input and output converter ports as equiv-alent timed-CPNs. Each port is transformed into a series of transitions and places which control the read and write synchronization events between the TDF and DE MoC. This representation is explained in detail in [7].
Finally, it is shown in [21, 7] that by using an equivalent timed-CPN model for the DE-TDF model, pre-simulation analysis can be performed in order to detect any causality errors and if necessary, provide suggestions on the needed delay modifications that will avoid these time synchronization issues. Using this representation, the SystemC-MDVP simulator can can detect time synchronization issues between the TDF and the DE MoCs before the simulation phase starts, providing as an output to the user a list of Delay parameters that need to be added to the TDF converter ports in order to avoid causality problems.

READ Gadolinium and gadolinium-cerium oxysulfide nanoparticles: synthesis and characterization

TTool

TTool, developed mainly at Télécom ParisTech with LIP6 contribution on code gener-ation and OS for MPSoC, is a UML and SysML based free and open-source software for model-based design and development of embedded systems at two diﬀerent levels: partitioning (blue upper section of Figure 2.5) and embedded software design (blue lower section of Figure 2.5). According to TTool’s philosophy, models are validated before any code is generated and the generated code is correct-by-construction.[2]
Figure 2.5: TTool’s diﬀerent levels for model-based design and development of embedded sys-tems. (Adapted from [22]).
At the partitioning level, Functional and HW/SW Partitioning diagrams can be created in order to find the best software and hardware candidates that can execute the required functions of the system.
1. In the Functional Diagram, the functions of the system, which later will be assigned and implemented in software or hardware, can be modeled.
2. In the HW/SW Partitioning Diagram, the possible hardware architectures for the system can be modeled either as execution nodes (CPUs and HW Accelerators), communication nodes (buses) and storage nodes (memories) [2]. Finally in the HW/SW Partitioning Diagram, the functions defined in the Functional Diagram are mapped to the hardware architecture and they can be allocated either to CPUs or HW Accelerators, while the communication between the functions can be assigned to specific communication and storage nodes.
At the embedded software design level, Software Design and Deployment diagrams can be created. They target the design of software as well as modeling and formal verification of embedded systems.
1. In the Software Design Diagrams, two types of diagrams can be created: Block Diagrams and State Machine Diagrams. With these two diagrams, the system software can be designed as communicating block diagrams and the behavior of each block can be implemented as state machines.
2. With the Deployment Diagrams (DD), each block representing the system software can be mapped to the chosen hardware architecture (CPUs or HW Accelerators) and their internal variables can be mapped to memories.
The Functional, HW/SW Partitioning and Software Design Diagrams are subject to formal verification and validation before the embedded software code can be generated.
that Block can be created, which allows to design the software of the specific task. When the software design is complete, the SyntaxChecker will verify the correctness of the diagrams and will generate a Specification for the software. This Specification along with the DDSpecification is used by the CodeGenerator to generate one source code file per block and a main.c file. Using the libavatar libraries and the MutekH OS (a free portable OS for embedded systems with which several CPU architectures can be targeted [6]), the source code will be cross-compiled to the selected CPU architecture in order to generate an application binary.
In the Deployment Diagrams hardware abstractions are used as shown in Figure 2.5. In the work of [3], the abstraction of digital hardware components into the Deployment Diagram has been addressed and model transformations given, where hardware compo-nents can be transformed into SoCLib modules to generate a SystemC virtual prototype of the model and simulate it with a CABA (cycle-accurate bit-accurate) approach. Once the Deployment Diagram is complete, the DDSyntaxChecker shown in Figure 2.6, will verify that the Deployment Diagram is syntactically correct and generate a DDSpec-ification, used by the CodeGenerator and the deployinfo.h file. The deployinfo.h file contains information used by the LdscriptGenerator to generate the linker script (ldscript) which will be used by Loader utility of SoCLib later. The DDSpecification is also used by the TopcellGenerator to generate a SystemC topcell (top.cc) file, which includes all the required SoCLib modules for the model. This topcell can be compiled using the soclib-cc command to build a platform of the model or SoCLib Executable as it is shown in Figure 2.6. The topcell generates the mapping table for the diﬀerent components of the model. It instantiates all the components from the model and creates the required signals to interconnect them. It creates the Net-List where all the inter-connections of the components are defined. It also calls the Loader utility from SoCLib, which uses the ldscript to load the application binary into the RAM memory compo-nent of the model. Finally the SoCLib executable can be run to start the simulation of the virtual prototype.

SystemC-AMS graphical interface and platform generation in TTool

During the first phase of the project “SystemC-AMS extensions for TTool” developed as part of [4], the graphical interface of TTool was augmented, oﬀering the possibility to create SystemC-AMS TDF models which consist of TDF clusters including TDF and DE blocks. As it shown in Figure 2.7, a new SystemC-AMS panel was added. In this panel, a new SystemC-AMS Component Diagram can be created where TDF models can be designed.
A model consists of a TDF cluster which can contain TDF modules (gray blocks) and DE modules (white blocks) that can be interconnected with each other through their respective ports and signals. Several TDF clusters can be designed each in its own panel, in such way that they will be seen by the SoCLib initiator components (CPUs) as individual target components, when the integration of SystemC-AMS with SoCLib components is implemented.
To connect TDF modules, TDF ports (black ports) are used. To connect DE modules, DE ports (white ports) are used. In order to connect a TDF module with a DE module, converter ports (black and white ports) are used. The graphical interface oﬀers a toolbar which allows to select the diﬀerent components to build the model. The code for the TDF and DE modules functions should be provided directly as SystemC-AMS code through the graphical interface of TTool, as Figure 2.8b shows.
When a TDF module is created, it is possible to modify its attributes, parameters and provide manually the code that will define its behavior. The name and Timestep or Period (Tm) of a module can be defined. The period units can be selected as well between seconds, milliseconds, microseconds or nanoseconds. The parameters of a TDF module such as its internal variables or template parameters can be also set up, as it is shown in Figure 2.8a. Finally the code of the TDF module can be given manually. This code will define the SystemC-AMS processing() function, as it is depicted in Figure 2.8b.
Then, a source (.cpp) file is generated as a test-bench. It implements the sc_main function. This function defines the signals that connect the diﬀerent blocks of the cluster. It instantiates all the TDF and DE modules from the TDF cluster. It also creates the interconnection Net-List of the modules by binding the module’s ports to the signals. Finally, it starts the simulation for a default time of 100 milliseconds.
At last, a Makefile is generated. This Makefile can be used to compile the generated SystemC-AMS code and execute the simulation of the TDF model, without including any SoCLib component or embedded software.

INTEGRATION OF SYSTEMC-AMS AND SOCLIB COMPONENTS

Integration of SystemC-AMS and SoCLib components

Development of the GPIO2VCI SoCLib component

SoCLib is based on the shared memory paradigm, whose components are interconnected based on the VCI protocol. These components can be initiators which issue requests (e.g. CPUs) and targets that respond to these requests (e.g. RAM memory). The main idea for the integration of SystemC-AMS and SoCLib components in TTool is that the analog components will act as targets for the SoCLib initiator digital components (CPUs). In this sense, the generated topcell will be composed of SoCLib modules and the SystemC-AMS modules (TDF clusters). It is also important to mention that a TDF cluster may have DE modules within it, which are not part of the SoCLib library. This interaction is shown in Figure 3.1, where only the hierarchical composition of the modules is shown.
Due to the fact that SoCLib components are interconnected using the VCI protocol, the need of creating a generic adaptor module which can work as an interface between the SystemC-AMS modules and the the SoCLib interconnect components arose. This new component, which was modelled as a GPIO (general-purpose input/output) adap-tor to VCI and called GPIO2VCI, was developed as a VCI target component following the modeling rules for writing CABA SystemC simulation models for SoCLib [15]. Fig-ure 3.2 shows the model of this component and how it works as an interface between the SystemC-AMS modules (TDF_Module belonging to a TDF Cluster) and the SoCLib VCI interconnect component (VCI_Bus).
The previously mentioned modeling rules specify that the CABA components are built by one or several synchronous FSM (Finite State Machines) and have clearly identified in-ternal registers. The FSM can be described by three types of functions. The transition function, which is triggered once per cycle on the rising edge of the clock, will compute the next values of the registers, depending on their current values and the values of the input signals. The genMoore function, which is triggered once per cycle on the falling edge of the clock, computes the values of output signals that depend on the internal registers. The genMealy function, which is triggered once per cycle on the falling edge of the clock, computes the values of output signals that depend on the internal registers and the values of the input signals.
The GPIO2VCI component’s interface definition shown in Listing 3.1, contains the ports that a typical VCI target component has. These ports are an input clock port p_clk, a negative-edge reset port p_resetn and a VCI target port p_vci. It also has two ports used for communication with the SystemC-AMS modules. These ports are an input port p_rdata_ams, which is used to read data coming from the SystemC-AMS modules; and an output port p_wdata_ams, which is used to write data to the SystemC-AMS modules. It is important to mention that the data type vci_param::data_t of these two ports is internally defined as sc_uint<32>, so any SystemC-AMS module that is connected to the GPIO2VCI component through converter ports, should define this data type in these ports.
The internal registers definition shown in Listing 3.2, has two standard VCI target regis-ters. These registers are the r_fsm_state register, that stores the next state of the FSM of the component; and the r_buf_eop register, which is used to mark an end of packet— i.e. end of a VCI transfer. It also has two new defined registers. The r_rdata_ams register is used to store the data that was read from the SystemC-AMS components. The r_wdata_ams register is used to store the data that needs to be written to the SystemC-AMS components.
As defined in the modeling rules, the component implements two member functions transition() and genMoore(). The transition() function shown in Listing 3.3, will store into the internal registers of the component r_rdata_ams and r_wdata_ams, the values that need to be read from or written to the SystemC-AMS modules, depending on the VCI command p_vci.cmdval that is received. These values are read from the input ports of the component p_rdata_ams and p_vci.wdata.

Table of contents :

1 Introduction
1.1 Context
1.2 Objective
1.3 Thesis organization
2 Related work
2.1 SystemC and SystemC-AMS
2.2 SoCLib
2.3 SystemC-MDVP and timed-CPNs
2.4 TTool
2.5 SystemC-AMS graphical interface and platform generation in TTool
3 Integration of SystemC-AMS and SoCLib components
3.1 Development of the GPIO2VCI SoCLib component
3.2 Integration of SystemC-AMS modules with a pedagogic SoCLib model
3.3 Integration of SystemC-AMS modules with a full SoCLib model
4 Time synchronization between TDF and DE MoCs
4.1 Detection of time synchronization issues
4.1.1 Access to input converter port before an access to output converter port
4.1.2 Access to output converter port before an access to input converter port
4.1.3 Access to output converter port before an access to another output converter port
4.1.4 Access to input converter port before an access to another input converter port
4.1.5 Preliminary conclusions
4.2 Avoidance of time synchronization issues
4.3 Proposal for detection and avoidance of time synchronization issues
5 Integration of SystemC-AMS and SoCLib modules into TTool
5.1 Integration decisions to augment the graphical interface of TTool
5.2 Integration of SystemC-AMS and the SoCLib modules in TTool
5.3 Synchronization of SystemC-AMS and SoCLib modules in TTool
6 Case studies and comparison between TTool, SystemC-AMS and SystemC-MDVP 64
6.1 Case studies
6.1.1 Introduction
6.1.2 Case study 1: Rover
6.1.3 Case study 2: Vibration sensor
6.2 Comparison between TTool, SystemC-AMS and SystemC-MDVP simulators
6.2.1 Model 1
6.2.2 Model 2
6.2.3 Model 3
7 Conclusion and perspectives
7.1 Conclusion
7.2 Perspectives