derek/DRAMSys
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
ae6e1e1040f0185a8df770018321b30dc9ea5df1
DRAMSys/README.md

14 KiB
Raw Blame History

de.uni-kl.ems.dram.vp.system

Generic DRAM controller simulator DRAMSys [1] and related tools.

Basic Setup

Open a terminal window, go to your home directory, create a directory for your projects and change to it.

$ cd
$ mkdir projects
$ cd projects

Clone the repository.

$ 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], tinyxml and icewrapper 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.

$ git clone --recursive https://<user>@git.rhrk.uni-kl.de/<user>/dram.vp.system.git

After cloning go to the project directory.

$ cd dram.vp.system

When working with a fork, the official repository must be added as a remote for your fork.

$ git remote add upstream https://<user>@git.rhrk.uni-kl.de/EIT-Wehn/dram.vp.system.git
$ git remote -v

Also, after a pull request being accepted and merged into the official repository you should get your fork updated.

$ git fetch upstream
$ git checkout master
$ git merge upstream/master
$ git push origin HEAD

Buiding with QTCreator

Execute the QTCreator.

$ qtcreator &

Use the menu bar and open the DRAMSys project.

File -> Open Project -> dram.vp.system/DRAMSys/dram.vp.system.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.

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.

$ 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.

Building 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.

$ mkdir build
$ cd build
$ qmake ../DRAMSys/dram.vp.system.pro
$ make

The compilation generates executable binary files dramSys and traceAnalyzer that can be found inside sub-directories.

From the build directory use the commands below to execute DRAMSys.

$ cd simulator
$ ./dramSys

From the build directory use the commands below to execute the traceAnalyzer.

$ cd analyzer
$ ./traceAnalyzer

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:

<simulation>

    <!-- General Simulator Configuration (used for all simulation setups) -->
    <simconfig>
        <Debug value="1"/>
        <DatabaseRecording value="1"/>
        <PowerAnalysis value="1"/>
        <NumberOfTracePlayers value="5"/>
        <NumberOfMemChannels value="1"/>
        <ControllerCoreDisableRefresh value="0"/>
        <DynamicTemperatureSimulation value="0"/>
    </simconfig>

    <!-- Temperature Simulator Configuration (used for all simulation setups) -->
    <temperature_simconfig>
        <StaticTemperatureDefaultValue value="89" />
        <DynTemperatureSimPeriod value="100" />
        <DynTemperatureSimUnit value="ms" />
    </temperature_simconfig>

    <!-- Memory Specifications -->
    <memspecs>
        <memspec src="../../DRAMSys/simulator/resources/configs/memspecs/WideIO.xml"></memspec>
    </memspecs>

    <!-- Address Mappings -->
    <addressmappings>
        <addressmapping src="../../DRAMSys/simulator/resources/configs/amconfigs/am_wideio.xml"></addressmapping>
    </addressmappings>

    <!-- Memory Configurations -->
    <memconfigs>
        <memconfig src="../../DRAMSys/simulator/resources/configs/memconfigs/fifo.xml"/>
    </memconfigs>
    
    <!-- Trace Setups -->
    <tracesetups>
        <!-- Multiple trace setups are allowed for the same simulation setup -->
        <tracesetup id="fifo">
            <!--
            Specify here a trace file for each of the trace players. Trace
            players without a file will not generate transactions.
            It is also possible to choose "cklMhz" and the "bl" for every
            player.
            -->
            <device clkMhz="200">voco2.stl</device>
            <device clkMhz="200">voco2.stl</device>
            <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.

Simulation Setups

Every possible combination of memory specification, address mapping and memory configuration corresponds to a simulation setup.

DRAMSys executes all the trace setups listed in the configuration file for each of the simulation setups.

A single trace setup is composed of an id string and one or more devices.

The device configuration consists of two configuration fields - clkMhz (operation frequency for this device) and bl (burst length) - and a trace file.

A trace file is a pre-recorded file containing memory transactions. Each memory transaction has a timestamp that tells the simulator when it shall happen, a transaction type (e.g. read, write) and a memory address.

A trace player is equivalent to a bus master device (i.e. a device that locks a bus and generates memory transactions). By adding device elements into the trace setup section one can specify the operation frequency, the burst length and the trace file to be used by trace players.

Trace players without a corresponding device configuration do not generate transactions.

DRAMSys executes all the simulation setups within the configuration file providing flexibility for exhaustive explorations.

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
    • NumberOfTracePlayers (unsigned int)
      • Number of trace players
    • NumberOfMemChannels (unsigned int)
      • Number of memory channels
    • ControllerCoreDisableRefresh (boolean)
      • "1": disables refreshes
      • "0": normal operation (refreshes enabled)
    • DynamicTemperatureSimulation (boolean)
      • "1": enables the dynamic temperature simulation feature
      • "0": static temperature during simulation

  • Temperature Simulator Configuration

    • StaticTemperatureDefaultValue (int)
      • Temperature value for simulations with static temperature
    • DynTemperatureSimPeriod (unsigned int)
      • Period of the dynamic temperature simulation
    • DynTemperatureSimUnit (string)
      • "s": seconds
      • "ms": millisecond
      • "us": microseconds
      • "ns": nanoseconds
      • "ps": picoseconds
      • "fs": femtoseconds

  • 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 is a good example.

    <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

    <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

  • Memory Configuration

    The content of fifo.xml is presented below as an example.

    <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 (string)
      • Trace setup id. Two kinds of output files are generated by DRAMSys: SQLite databases containing transactions related to each memory channel (.tdb) and a text file (.txt) with the program output. The base name for these files comes from this field.
    • clkMhz (unsigned int)
      • Speed of the trace player
    • bl (unsigned int)
      • Burst length
    • trace file
      • A pre-recorded file containing memory transactions to be executed by a trace player.

Some attributes are self-explanatory while others require some previous knowhow of memory technologies.

Resources of the simulator are available inside of the resources directory and its sub-directories.

$ cd DRAMSys/simulator/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/

Reference in New Issue View Git Blame Copy Permalink