Guidelines

The objective of these guidelines is:

• to allow the exchange of simulators or simulator components between researchers or with industrials by standardizing the writing rules,
• to make easier the simulator development with the help of few simple principles of conception,
• to build reasonably fast simulators,
• to define a clear interface between simulators in order to build a complex system simulator by simply grouping simulators of these components, independently of the authors of these components.

• We want to simulate processors and complete SOCs (multiple IP blocks, interconnection network…),
• We want to be able to change some simulator components of different granularity levels (complete IP blocks, e.g., processor, or parts of IP blocks, e.g., cache),
• We want to realize simulators precise at the bit and cycle level.

• A partitioning problem: we needs a method to partition the module as in hardware,

especially the control circuitry which may be either local to a hardware component (it does not depends on data produces by another modules inside the clock cycle) or distributed across several modules (the computing of these signals is asynchronous and may depends on control data computed by another modules in the same clock cycle) for a restricted set of control signals.

• A performance problem: the performance of a simulator written in SystemC is strongly correlated to the number of processe wake-ups.

To maximize the opportunity to reuse and to describe an IP block, it is necessary to split it into a large number of modules, that degrades the simulator performance. Thus, it is convenient to mimize the performance loss induced by the increased modularity.

These writing rules will serve:

• To make modules structure as seamless as possible,
• To propose some solutions to the above partitionning and performance problem.

The simulator is made of SystemC modules, each modules modelizing a hardware component of the system. These SystemC modules own some input/output ports which are bind to SystemC signals connecting the modules each other, see figures 1 and 2. In SystemC environment, each modules may contains several processes (called methods). The SystemC scheduler will call the process whenever the signal connected to its input ports changes.

The objective of these rules is to define the way modules communicate each other.

Modules use “Data” and “Valid” signals to communicate each other. “Data” signals represent the processor data path. It refers to any set of user signals,whereas “Valid” signals are the control signal indicating to other modules that new data are availables. We illustrate this with a simple pipeline, see figure 1.

Figure 1 - Modelizing the pipeline data path Each module is connected with “Data” and “Valid” signals to build a pipeline.

Modules use “Accept” signals to control the data flow between the modules. If signal “Valid” is asserted, “Accept” indicates that a module can accept the data in the next clock cycle, see Figure 2

Figure 2 - Controling the data flow into a pipeline using “Accept” signals We added “Accept” signals in the backward direction of “Data” and “Valid” signals. A modules may deassert “Accept” if it cannot take the data on the next clock cycle. Each module computes its output “Accept” from its input “Accept”, “Valid”, and its state.

Module use “Enable” signals to make target module catch the data on “Data” signals. A source module asserts “Enable” when “Accept” is asserted by a target module. Assertion of “Enable” could be conditionned by the assertion of several “Accept” signals, see figure 3.

Figure 3 - Controling the data flow into a pipeline using both “Accept” and “Enable” signals We added “Enable” signals in the forward direction as “Data” and “Valid” signals. The “Enable” output signal of module 2 is asserted only if both output “Accept” signals of module 3 and 4 are asserted.

A process implements the behavior of modules. It communicates with another process through signals, see figure 4 and 5. The objective of these rules is to define the way modules behavior is splitted into processes.

Figure 4 - A SystemC process writing on a signal The process writes on its output port to communicate throught a signal. On figure 4, the module contain a processe and an output port. module is represented as a box, the output port as small a square on the box border, and the signal as arrows.

A processes have a sensitive list defining the signal waking up this process. On figure 5, there are two types of inbound arrows on processes:

 straight arrow: the process is sensitive to the signal.
 dotted arrow: the process is not sensitive to the signal.

Figure 5 - SystemC process sensitivity

Modules may have an “Sequential Process” only sensitive to the clock front edge, see figure 6. The “Sequential Process” is intended to modelize the modules behavior on a cycle base. It may modify the state of the module.

Modules may have an “Combinational Process” sensitive to input “Valid” and “Accept” signals, see figure 6. It is designed to modelize the distribution of the control circuitry among several modules. It may not modifify the state of the module because it is only a function of the input signals and the state of the module.

Figure 6 - SystemC modules designed with Sequential Combinational Processes Figure 6 illustrates how a source module communicates a data to a target module: the “Sequential Process” of the source module process its data, output it on the “Data” signal and assert the output signal “Valid”. The “Combinational Process” of target module asserts the “Accept” output signal. As the target module allow the data transfer, the “Combinational Process” of the source module asserts the “Enable” output signals. On the next clock cycle, the “Sequential Process” of the target consumes the data on its input “Data” signal as the “Enable” is asserted, and so on.

Avoid using module with only “Combinational Process” if possible. Combinational processes can dramatically decrease the simulator performance as they may wake up several times per clock cycle.