Allow variable data length in memory manager.

README.md

@@ -123,7 +123,8 @@ The JSON code below shows an example configuration:
         "tracesetup": [
             {
                 "clkMhz": 300,
-                "name": "ddr3_example.stl"
+                "name": "ddr3_example.stl",
+                "addLengthConverter": true
             },
             {
                 "clkMhz": 2000,
@@ -160,6 +161,7 @@ Fields Description:
 
 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**.
 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 optional parameter **addLengthConverter** adds a transaction length converter between initiator and DRAMSys. This unit divides a large transaction up into several smaller transactions with the maximum length of one DRAM burst access.
 The **maxPendingReadRequests** and **maxPendingWriteRequests** parameters define the maximum number of outstanding read/write requests. The current implementation delays all memory accesses when 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 **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.
@@ -171,7 +173,7 @@ Most configuration fields reference other JSON files which contain more speciali
 
 #### Trace Files
 
-A **trace file** is a prerecorded file containing memory transactions. Each memory transaction has a time stamp that tells the simulator when it shall happen, a transaction type (*read* or *write*) and a hexadecimal memory address.
+A **trace file** is a prerecorded file containing memory transactions. Each memory transaction has a time stamp that tells the simulator when it shall happen, a transaction type (*read* or *write*) and a hexadecimal memory address. The optional length parameter (in bytes) allows sending transactions with a custom length that does not match the length of a single DRAM burst access. In this case a length converter has to be added. Write transactions also have to specify a data field when storage is enabled in DRAMSys.
 
 There are two different kinds of trace files. They differ in their timing behavior and are distinguished by their file extension.
 
@@ -183,11 +185,11 @@ Syntax example:
 
 ```
 # Comment lines begin with #
-# [clock-cyle]: [write|read] [hex-address] [hex-data (optional)]
-31:	read	0x400140
-33:	read	0x400160
-56:	write	0x7fff8000 0x123456789abcdef...
-81:	read	0x400180
+# cycle: [(length)] command hex-address [hex-data]
+31: read 0x400140
+33: read 0x400160
+56: write 0x7fff8000 0x123456789abcdef...
+81: (128) read 0x400180
 ```
 
 ##### Relative STL Traces (.rstl)
@@ -198,11 +200,11 @@ Syntax example:
 
 ```
 # Comment lines begin with #
-# [clock-cyle]: [write|read] [hex-address] [hex-data (optional)]
-31:	read	0x400140
-2:	read	0x400160
-23:	write	0x7fff8000 0x123456789abcdef...
-25:	read	0x400180
+# cycle: [(length)] command hex-address [hex-data]
+31: read 0x400140
+2: (512) read 0x400160
+23: write 0x7fff8000 0x123456789abcdef...
+10: read 0x400180
 ```
 
 ##### Elastic Traces