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.