Cycle-level modules usually correspond to hardware components or hardware blocks composing the cycle-level simulator. A module can correspond to a single stage of an out-of-order pipeline, or to the whole pipeline of an in-order simulator.
Modules are defined as a C++ class, the state of the module being defined by the properties of the class. For a stage register for instance, the state will correspond to the value stored in the register.
Modules can also implements actions that will either access or modify their own state values. Such actions are defined as processes defined as methods of the module. All the processes of a module will implement his overall behavior.
Modules can communicate through a port-based communication scheme: The principle is to use ports and signals to communicate between different modules. Basically, each module can have input and output ports, and an output is linked with an input port through a signal. Passing values between modules consists in writing to/reading from input/output ports.
For each process defined within a module, the user can specify the list of input signals the process is sensitive, definging the sensitivity list of a process. Module communication is implemented through processes accessing input and output ports.
To enhance reusability of cycle-level modules accross simulators, the centralized control was distributed to the different modules composing the simulator. So control is both part of the module behavior implemented through processes, and part of the communication scheme.
A connection between two modules is composed of three different signals, as shown on the figure below.
The figure correspond to a source module A communicating with a target module B. The three signals are the following:
For details on those signals, please refer to this tutorial.
The clock signal is not a simple data signal, but implemented as a specific signal: