Files
DRAMSys/README.md
Éder Ferreira Zulian 34cae6d675 Readme file updated.
When working in a fork one must add the official repository as a remote
upstream in order to be able to sync with it.
2015-06-12 13:03:12 +02:00

318 lines
9.8 KiB
Markdown

de.uni-kl.ems.dram.vp.system
============================
Generic DRAM controller simulator **DRAMSys** [1] and related tools.
## Basic Setup
In a terminal window execute the commands that follow.
Go to your home directory.
``` bash
$ cd
```
Create a directory for your projects.
``` bash
$ mkdir projects
```
Clone the repository.
``` bash
$ git clone --recursive https://<user>@git.rhrk.uni-kl.de/EIT-Wehn/dram.vp.system.git
```
The *--recursive* flag tells git to initialize all submodules within the
repository. **DRAMPower** [2] and **tinyxml** are examples third party
repositories that were embedded within the source tree as submodules.
It is possible to work with a **fork** of the official codebase. In that case,
after pushing changes into your fork you should create a **pull request** in
order to get your changes merged into to the official codebase.
``` bash
$ git clone --recursive https://<user>@git.rhrk.uni-kl.de/<user>/dram.vp.system.git
```
Also, the official repository must be added as a remote for your fork.
``` bash
$ git remote add upstream https://<user>@git.rhrk.uni-kl.de/EIT-Wehn/dram.vp.system.git
$ git remote -v
```
After a pull request being accepted and merged into the official repository
you should get your fork updated.
``` bash
$ git fetch upstream
$ git checkout master
$ git merge upstream/master
$ git push origin HEAD
```
After cloning go to the project directory.
``` bash
$ cd dram.vp.system
```
### With QTCreator
Execute the *QTCreator*.
``` bash
$ qtcreator &
```
Use the menu bar and open the DRAMSys project.
**File -> Open Project -> dram.vp.sys/dram/dramSys/dramSys.pro**
When you open the project for the first time a configuration window pops-up.
Then click in **Configure Project** and after that **Build** the project.
Repeat the procedure above and build the trace analyser project.
**File -> Open Project -> dram.vp.sys/analyser/analyser/traceAnalizer.pro**
To speedup the building process one can use the additional **make** option
**-j[jobs]**. The command line below returns a good number to be passed to
make as the number of jobs that can run simultaneously to improve the building
time.
``` bash
$ cat /proc/cpuinfo | grep processor | wc -l
```
In the left bar go to **Projects -> Build & Run -> Build Steps -> Make**.
Click in **Details** then **Make arguments** and add **-j** followed by the
number you got.
### Without QTCreator
In case you prefer a command line interface to the QTCreator GUI you can also
use **qmake** to generate a Makefile and then compile the project.
``` bash
$ cd dram
$ mkdir build
$ cd build
$ qmake ../dramSys/dramSys.pro
$ make
```
### DRAMSys Configuration
The **dramSys** executable supports one argument which is a XML file that
contains configurable aspects of the desired simulation. If no argument is
passed through the command line a default configuration file will be loaded.
The XML code below shows a typic configuration:
``` xml
<simulation>
<simconfig>
<Debug value="1" />
<DatabaseRecording value="1" />
<PowerAnalysis value="1" />
</simconfig>
<memspecs>
<memspec src="../resources/configs/memspecs/WideIO.xml"></memspec>
</memspecs>
<addressmappings>
<addressmapping src="../resources/configs/amconfigs/am_wideio.xml"></addressmapping>
</addressmappings>
<memconfigs>
<memconfig src="../resources/configs/memconfigs/fifo.xml"/>
</memconfigs>
<tracesetups>
<tracesetup id="fifo">
<device clkMhz="200">voco2.stl</device>
</tracesetup>
</tracesetups>
</simulation>
```
Some configuration fields reference other XML files which contain more
specialized chunks of the configuration like memory specification, address
mapping and memory configurations.
The XML configuration files are parsed by the program and the configuration
details extracted are assigned to the correspondent attributes of the internal
configuration structure.
#### Configuration File Sections
The main configuration file is divided into self-contained sections, each of
these sections is a set of logically related configuration aspects for the
simulation.
Below are listed the configuration sections and configuration fields.
- **Simulator configuration**
- *Debug* (boolean)
- "1": enables debug output on console
- "0": disables debug output
- *DatabaseRecording* (boolean)
- "1": enables trace file recording for the trace analyser tool
- "0": disables trace file recording
- *PowerAnalysis* (boolean)
- "1": enables live power analysis with the DRAMPower tool
- "0": disables power analysis
- **Memory specification**
A file with memory specifications. This information comes from datasheet and
usually does not change.
- **Address Mapping**
XML files describe the address mapping to be used in the simulation.
The file [am_wideio.xml](dram/resources/configs/amconfigs/am_wideio.xml) is
a good example.
``` xml
<addressmapping>
<channel from="27" to="28"/>
<row from="14" to="26"/>
<column from="7" to="13"/>
<bank from="4" to="6" />
<bytes from="0" to="3" />
</addressmapping>
```
![Address Mapping Sample 1](docs/images/am_sample1.png)
``` xml
<addressmapping>
<channel from="27" to="28"/>
<column from="20" to="26"/>
<row from="7" to="19"/>
<bank from="4" to="6" />
<bytes from="0" to="3" />
</addressmapping>
```
![Address Mapping Sample 2](docs/images/am_sample2.png)
- **Memory Configuration**
The content of [fifo.xml](dram/resources/configs/memconfigs/fifo.xml) is
presented below as an example.
``` xml
<memconfig>
<BankwiseLogic value="0"/>
<OpenPagePolicy value="1"/>
<MaxNrOfTransactions value="8"/>
<Scheduler value="FIFO_STRICT"/>
<Capsize value="5"/>
<PowerDownMode value="TimeoutSREF"/>
<PowerDownTimeout value="100"/>
<!-- Error Modelling -->
<ErrorChipSeed value="42"/>
<ErrorCSVFile value="../src/error/error_new.csv"/>
<ErrorStoreMode value="NoStorage"/>
</memconfig>
```
- *BankwiseLogic* (boolean)
- "1": perform bankwise-refresh [3] and bankwise-powerdown [4]
- "0": do not perform bankwise operations
- *OpenPagePolicy* (boolean)
- "1": use open page precharge policy
- "0": do not use open page precharge policy
- *MaxNrOfTransactions* (unsigned int)
- Maximum number of transactions.
- *Scheduler* (string)
- "FIFO": first in, first out
- "FIFO_STRICT": out-of-order treatment of queue elements not allowed
- "FR_FCFS": first-come, first-served
- *Capsize* (unsigned int)
- Capacitor cell size.
- *PowerDownMode* (enum EPowerDownMode)
- "NoPowerDown": no power down mode (active idle)
- "Staggered": staggered power down policy [5]
- "TimeoutPDN": precharge idle
- "TimeoutSREF": self refresh
- *Buswidth* (unsigned int)
- Bus width in bits.
- *ReadWriteGrouping* (boolean)
- "1": enable read writing grouping
- "0": disable read writing grouping
- *ReorderBuffer* (boolean)
- "1": use reordering buffer
- "0": do not use reordering buffer
- *ErrorChipSeed* (unsigned int)
- Seed to initialize the random error generator.
- *ErrorCSVFile* (string)
- CSV file with error injection information.
- *ErrorStoreMode* (enum ErrorStorageMode)
- "NoStorage": no storage
- "Store": store data without error model
- "ErrorModel": store data with error model [6]
- **Trace setups**
- *id*
- trace setup id
- *clkMhz*
- speed of the trace player
Some attributes are self-explanatory while others require some previous
knowhow of memory technologies or some knowledge of the simulator source code.
Resources of the simulator are available in the **resources** directory its
sub-directories.
``` bash
$ cd /projects/dram.vp.system/dram/resources
```
A description of the content each directory follows.
- **resources**
- **configs**: XML files used for configure specific details of the simulation.
- am_configs: address mapping configuration
- memconfigs: memory configuration
- memspecs: configuration related to the memory technology
- **scripts**: useful tools like address scrambler, trace analyser, database
creator, etc.
- **simulations**: global configuration
- **traces**: trace files for simulations. They contain accesses to memory
in certain known scenarios.
#### References
[1] TLM Modelling of 3D Stacked Wide I/O DRAM Subsystems, A Virtual Platform for Memory Controller Design Space Exploration
M. Jung, C. Weis, N. Wehn, K. Chandrasekar. International Conference on High-Performance and Embedded Architectures and Compilers 2013 (HiPEAC), Workshop on: Rapid Simulation and Performance Evaluation: Methods and Tools (RAPIDO), January, 2013, Berlin.
[2] DRAMPower: Open-source DRAM Power & Energy Estimation Tool
Karthik Chandrasekar, Christian Weis, Yonghui Li, Sven Goossens, Matthias Jung, Omar Naji, Benny Akesson, Norbert Wehn, and Kees Goossens
URL: http://www.drampower.info
[3] Energy Optimization in 3D MPSoCs with Wide-I/O DRAM
M. Sadri, M. Jung, C. Weis, N. Wehn, L. Benini. Conference Design, Automation and Test in Europe (DATE), March, 2014, Dresden, Germany.
[4] DRAMSys: A flexible DRAM Subsystem Design Space Exploration Framework
M. Jung, C. Weis, N. Wehn. Accepted for publication, IPSJ Transactions on System LSI Design Methodology (T-SLDM), October, 2015.
[5] Optimized Active and Power-Down Mode Refresh Control in 3D-DRAMs
M. Jung, M. Sadri, C. Weis, N. Wehn, L. Benini., VLSI-SoC, October, 2014, Playa del Carmen, Mexico.
[6] Retention Time Measurements and Modelling of Bit Error Rates of WIDE-I/O DRAM in MPSoCs
C. Weis, M. Jung, P. Ehses, C. Santos, P. Vivet, S. Goossens, M. Koedam, N. Wehn. Accepted for publication, IEEE Conference Design, Automation and Test in Europe (DATE), March, 2015, Grenoble, France
[7] http://www.uni-kl.de/3d-dram/publications/