derek/DRAMSys
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update readme.

Browse Source
This commit is contained in:
Lukas Steiner
2022-05-05 11:11:47 +02:00
parent 9aaf095d7c
commit 92d043c29e
1 changed files with 13 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
README.md
View File

@@ -19,11 +19,11 @@ If you decide to use DRAMSys in your research please cite the papers [2] [3]. To
- **standalone** simulator with trace players, **gem5**-coupled simulator and **TLM-AT-compliant library**
- support for **DDR3/4**, **LPDDR4**, **Wide I/O 1/2**, **GDDR5/5X/6** and **HBM1/2**
- support for **DDR5** and **LPDDR5** under development (contact [Matthias Jung](mailto:matthias.jung@iese.fraunhofer.de) for more information)
- support for **DDR5**, **LPDDR5** and **HBM3** under development (contact [Matthias Jung](mailto:matthias.jung@iese.fraunhofer.de) for more information)
- automatic source code generation for new JEDEC standards [3] [9] from the domain-specific language DRAMml
- FIFO, FR-FCFS and FR-FCFS with read/write grouping scheduling policies
- open, closed, open adaptive and closed adaptive page policy [8]
- all-bank refresh and per-bank refresh with pulled-in and postponed refresh commands
- all-bank refresh, same-bank refresh and per-bank refresh with pulled-in and postponed refresh commands
- staggered power down [5]
- coupling to **DRAMPower** [4] and **3D-ICE** [8] for power and thermal simulation
- **Trace Analyzer** for visual and metric-based result analysis
@@ -42,23 +42,22 @@ All requests, responses and DRAM commands can be recorded in an SQLite trace dat
The Trace Analyzer's main window is shown below.
If you are interested in the database recording feature and the Trace Analyzer, if you need support on how to setup DRAMSys in a virtual platform of your company, or if you require custom modifications of the simulator please contact [Matthias Jung](mailto:matthias.jung@iese.fraunhofer.de).
If you are interested in the Trace Analyzer, if you need support with the setup of DRAMSys in a virtual platform of your company, or if you require custom modifications of the simulator please contact [Matthias Jung](mailto:matthias.jung@iese.fraunhofer.de).
![Trace Analyzer Main Window](DRAMSys/docs/images/traceanalyzer.png)
## Basic Setup
Start using DRAMSys by cloning the repository.
Use the `--recursive` flag to initialize all submodules within the repository, namely **DRAMPower**, **SystemC** and **nlohmann json**.
Use the `--recursive` flag to initialize all submodules within the repository, namely **DRAMPower**, **SystemC**, **nlohmann JSON** and **SQLite Amalgamation**.
### Dependencies
DRAMSys is based on the SystemC library. SystemC is included as a submodule and will be build automatically with the DRAMSys project. If you want to use an external SystemC version, export the environment variables `SYSTEMC_HOME` (SystemC root directory) and `SYSTEMC_TARGET_ARCH` (e.g. linux64) and add the path of the library to `LD_LIBRARY_PATH`.
DRAMSys requires a **C++17** compiler. The build process is based on **CMake** (minimum version **3.10**). Furthermore, the simulator is based on **SystemC**. SystemC is included as a submodule and will be build automatically with the project. If you want to use an external SystemC version, export the environment variables `SYSTEMC_HOME` (SystemC root directory) and `SYSTEMC_TARGET_ARCH` (e.g., linux64).
### Building DRAMSys
DRAMSys uses CMake for the build process, the minimum required version is **CMake 3.10**.
To build the standalone simulator for running memory trace files, create a build folder in the project root directory, then run CMake and make:
To build the standalone simulator for running memory trace files or a traffic generator, create a build folder in the project root directory, then run CMake and make:
```bash
$ cd DRAMSys
@@ -91,7 +90,7 @@ $ cd simulator
$ ./DRAMSys
```
The default base config file is *ddr3-example.json* and located in *DRAMSys/library/resources/simulations*, the default resource folder for all nested config files is *DRAMSys/library/resources*.
The default base config file is *ddr3-example.json* located in *DRAMSys/library/resources/simulations*, the default resource folder for all nested config files is *DRAMSys/library/resources*.
To run DRAMSys with a specific base config file:
@@ -107,7 +106,7 @@ $ ./DRAMSys ../../DRAMSys/tests/example_ddr3/simulations/ddr3-example.json ../..
### DRAMSys Configuration
The DRAMSys executable supports one argument which is a JSON file that contains certain arguments and the path of other configuration files for the desired simulation.
The DRAMSys executable supports one argument, which is a JSON file that contains certain arguments and the name of nested configuration files for the desired simulation. Alternatively, the contents of nested configuration files can also be added directly to the top configuration file instead of the file name.
The JSON code below shows an example configuration:
@@ -150,7 +149,7 @@ The JSON code below shows an example configuration:
}
}
```
Fields Description:
Field Descriptions:
- "simulationid": simulation file identifier
- "simconfig": configuration file for the DRAMSys simulator
- "thermalconfig": thermal simulation configuration file
@@ -162,9 +161,9 @@ 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.
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 **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 **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.
@@ -567,6 +566,7 @@ The content of [config.json](DRAMSys/library/resources/configs/thermalsim/config
The development of DRAMSys was supported by the German Research Foundation (DFG) as part of the priority program [Dependable Embedded Systems SPP1500](http://spp1500.itec.kit.edu) and the DFG grant no. [WE2442/10-1](https://www.uni-kl.de/en/3d-dram/). Furthermore, it was supported within the Fraunhofer and DFG cooperation program (grant no. [WE2442/14-1](https://www.iese.fraunhofer.de/en/innovation_trends/autonomous-systems/memtonomy.html)) and by the [Fraunhofer High Performance Center for Simulation- and Software-Based Innovation](https://www.leistungszentrum-simulation-software.de/en.html). Special thanks go to all listed contributors for their work and commitment during seven years of development.
Shama Bhosale
Derek Christ
Luiza Correa
Peter Ehses
Johannes Feldmann
@@ -576,6 +576,7 @@ Matthias Jung
Frederik Lauer
Ana Mativi
Felipe S. Prado
Iron Prando
Tran Anh Quoc
Janik Schlemminger
Lukas Steiner