Update documentation

configs/README.md

@@ -19,7 +19,6 @@ The JSON code below shows an example configuration:
             },
             {
                 "clkMhz": 2000,
-                "type": "generator",
                 "name": "gen0",
                 "numRequests": 2000,
                 "rwRatio": 0.85,
@@ -32,7 +31,6 @@ The JSON code below shows an example configuration:
             },
             {
                 "clkMhz": 1000,
-                "type": "hammer",
                 "name": "ham0",
                 "numRequests": 4000,
                 "rowIncrement": 2097152
@@ -49,11 +47,58 @@ Field Descriptions:
 - "mcconfig": memory controller configuration file
 - "tracesetup": The trace setup is only used in standalone mode. In library mode or gem5 mode the trace setup is ignored. Each device should be added as a json object inside the "tracesetup" array.
 
-Each **trace setup** device configuration can be a **trace player** ("type": "player"), a **traffic generator** ("type": "generator") or a **row hammer generator** ("type": "hammer"). By not specifing the **type** parameter, the device will act as a **trace player**.
+Each **trace setup** device configuration can be a **trace player**, a **traffic generator** or a **row hammer generator**. The type will be automatically concluded based on the given parameters.
 All device configurations must define a **clkMhz** (operation frequency of the **traffic initiator**) and a **name** (in case of a trace player this specifies the **trace file** to play; in case of a generator this field is only for identification purposes).
 The **maxPendingReadRequests** and **maxPendingWriteRequests** parameters define the maximum number of outstanding read/write requests. The current implementation delays all memory accesses if one limit is reached. The default value (0) disables the limit.
 
-A **traffic generator** can be configured to generate **numRequests** requests in total, of which the **rwRatio** field defines the probability of one request being a read request. The length of a request (in bytes) can be specified with the **dataLength** parameter. The **seed** parameter can be used to produce identical results for all simulations. **minAddress** and **maxAddress** specify the address range, by default the whole address range is used. The parameter **addressDistribution** can either be set to **random** or **sequential**. In case of **sequential** the additional **addressIncrement** field must be specified, defining the address increment after each request.
+A **traffic generator** can be configured to generate **numRequests** requests in total, of which the **rwRatio** field defines the probability of one request being a read request. The length of a request (in bytes) can be specified with the **dataLength** parameter. The **seed** parameter can be used to produce identical results for all simulations. **minAddress** and **maxAddress** specify the address range, by default the whole address range is used. The parameter **addressDistribution** can either be set to **random** or **sequential**. In case of **sequential** the additional **addressIncrement** field must be specified, defining the address increment after each request. The address alignment of the random generator can be configured using the **dataAlignment** field. By default, the addresses will be naturally aligned at dataLength.
+
+For more advanced use cases, the traffic generator is capable of acting as a state machine with multiple states that can be configured in the same manner as described earlier. Each state is specified as an element in the **states** array. Each state has to include an unique **id**. The **transitions** field describes all possible transitions from one state to another with their associated **probability**.
+In the context of a state machine, there exists another type of generator: the idle generator. In an idle state no requests are issued. The parameter **idleClks** specifies the duration of the idle state.
+
+An example of a state machine configuration with 3 states is shown below.
+
+```json
+{
+    "clkMhz": 100,
+    "maxPendingReadRequests": 8,
+    "name": "StateMachine",
+    "states": [
+        {
+            "addressDistribution": "sequential",
+            "addressIncrement": 256,
+            "id": 0,
+            "maxAddress": 1024,
+            "numRequests": 1000,
+            "rwRatio": 0.5
+        },
+        {
+            "id": 1,
+            "idleClks": 1000
+        },
+        {
+            "addressDistribution": "random",
+            "id": 2,
+            "maxAddress": 2048,
+            "minAddress": 1024,
+            "numRequests": 1000,
+            "rwRatio": 0.75
+        }
+    ],
+    "transitions": [
+        {
+            "from": 0,
+            "probability": 1.0,
+            "to": 1
+        },
+        {
+            "from": 1,
+            "probability": 1.0,
+            "to": 2
+        }
+    ]
+}
+```
 
 The **row hammer generator** is a special traffic generator that mimics a row hammer attack. It generates **numRequests** alternating read requests to two different addresses. The first address is 0x0, the second address is specified by the **rowIncrement** parameter and should decode to a different row in the same bank. Since only one outstanding request is allowed, the controller cannot perform any reordering, forcing a row switch (precharge and activate) for each access. That way the number of activations on the target rows are maximized.
 

src/simulator/README.md

@@ -0,0 +1,19 @@
+# Simulator
+The **standalone** simulator features a set of trace players, traffic generators and miscellaneous components that can be coupled with DRAMSys.
+
+## Concept
+Initiators in the simulator are split up into two disctinct components: **RequestProducers** and **RequestIssuers**.
+
+**RequestProducers** are simple C++ classes that implement the `RequestProducer` interface. Upon calling the `nextRequest()` method of a producer, a new `Request` is either generated on-the-fly or constructed from a trace file.
+
+**RequestIssuers** are the SystemC modules that connect with DRAMSys. Issuers have no knowledge of where the requests are coming from. They simply call their `nextRequest()` callback that it has been passed in the constructor to obtain the next request to be sent to DRAMSys. Using this concept, the generation and the issuing of request is completely decoupled to make very flexible initiator designs possible.
+
+**Initiators** implement the `Initiator` interface, which describes how the initiator is bound to DRAMSys. This abstracts over the actual socket type used by the initiator.
+Complex initiators may implement the interface directly, but for simple cases, there exists the templated `SimpleInitiator<Producer>` class. This specialized initiator consists of only one producer and one issuer that operate together. The `StlPlayer` and `RowHammer` issuers make use of the `SimpleInitiator`.
+The `TrafficGenerator` is one example of a direct implementation of the `Initiator` interface, as it consists of many producers (which represent the states of the state machine) but of only one issuer.
+
+**Requests** are an abstraction over the TLM payloads the issuer generates. A request describes whether it is a read or a write access or an internal `Stop` request that tells the initiator to terminate.
+The **delay** field specifies the time that should pass between the issuance of the previous and the current request.
+
+## Configuration
+A detailed description on how to configure the traffic generators of the simulator can be found [here](../../configs/README.md).