Each cycle-level module of the repository is described the following way: First a small description to define what the module is. (cache, memory, cpu, bus, ... ). Then the following sections:

This section describes the parameters of the module. A cache module for instance will be parametrized by the cache line size, the associativity and so on...

Those parameters are defined as template parameters of the module c++ class. This allow the c++ compiler to consider all those parameters as static values and therefore to optimize their usage. Module parameters can fall into three different subcategories depending on the parameter usage:

• Core parameters. Those parameters are the most classical parameters of a module. They are very tied to the module itself usually defining the size of the data-structures.
  For instance, a cache module will be parametrized by the number of sets in cache, the number of line per set, the size of each line, and so on. A cpu module could be parametrized by the number of physical registers.
• Connection parameters. Those parameters are tied to the connection of the module and information about the module that are connected to it.
  For instance, a cache module needs to know the width of the connection to another cache lower in the hierarchy to properly split the request and answers into a number of packet small enough to be sent on the wires.
• Behavior parameters. Those parameters have a stronger impact of the module behavior. Changing the size of a cache line in a cache won’t change the way the cache is working very much. But changing its cache replacement policy will.
  For instance, the replacement policy will be a behavior parameter for the cache module. The boolean parameter specifying that the cache could be used with a snooping bus is also a behavior parameter, as the cache will have to deal with memory request coming from the memory side in such a configuration.

The module interface represent the way the module communicates with the external world. This interface is the required information you need to plug the module into your simulator.

Modules communicate through a set of input and output ports falling into the following categories:

* Clock ports. Every sequential module has an input clock port receiving an input clock signal. This clock signal is used to define module processes sensitive to the start of cycle and the end of cycle.
For instance, the bus module as a process sensitive to its input port to send the current value at the beginning of each cycle.

• Data ports. These ports are the way modules communicate following the classical block diagram datapath.
  For instance the cache module has a set of input and output port to receive request from the CPU and to answer this request. This module also has a set of input and output port to send request to the memory hierarchy an to receive answers.
• Optional data ports. A module can also have some ports that are not always available. One of the boolean parameters is most likely used to tell if such a port is available or not.
  For instance the cache module has an optional port for the shared bit is case it is connected to a memory bus supporting bus snooping. This port only exists if the Snooping module parameter is set to true.

The third section provide some hints on the internal module behavior, providing some possible values for a particular field, and how this value is changing.
For instance in the cache module, we’ll define the possible state of a cache line according to the MESI protocol providing cache coherency. And the possible state of a cache request in the cache request queue.