summaryrefslogtreecommitdiff
path: root/src/mem/DRAMCtrl.py
AgeCommit message (Collapse)Author
2015-09-22mem: Add initial HBM configurationsWendy Elsasser
Created the following HBM configurations: 1) HBM gen1 (x128/CH), 2Gb die, 4H stack, 1Gbps, 8 channels 2) HBM gen2 (x64/PC), 8Gb die, 4H stack, 1Gbps, 16 pseudo-channels The configuration values are based on: - The HBM gen1 public JEDEC spec - Publically released data from MemCon presentations - Timing extrapolated from existing LPDDR configurations Will adjust once specs become available.
2015-07-03mem: Increase the default buffer sizes for the DDR4 controllerAndreas Hansson
This patch increases the default read/write buffer sizes for the DDR4 controller config to values that are more suitable for the high bandwidth and high bank count.
2015-06-07mem: Add HMC Timing ParametersMatthias Jung
A single HMC-2500 x32 model based on: [1] DRAMSpec: a high-level DRAM bank modelling tool developed at the University of Kaiserslautern. This high level tool uses RC (resistance-capacitance) and CV (capacitance-voltage) models to estimate the DRAM bank latency and power numbers. [2] A Logic-base Interconnect for Supporting Near Memory Computation in the Hybrid Memory Cube (E. Azarkhish et. al) Assumed for the HMC model is a 30 nm technology node. The modelled HMC consists of a 4 Gbit part with 4 layers connected with TSVs. Each layer has 16 vaults and each vault consists of 2 banks per layer. In order to be able to use the same controller used for 2D DRAM generations for HMC, the following analogy is done: Channel (DDR) => Vault (HMC) device_size (DDR) => size of a single layer in a vault ranks per channel (DDR) => number of layers banks per rank (DDR) => banks per layer devices per rank (DDR) => devices per layer ( 1 for HMC). The parameters for which no input is available are inherited from the DDR3 configuration.
2015-02-03config: Adjust DRAM channel interleaving defaultsAndreas Hansson
This patch changes the DRAM channel interleaving default behaviour to be more representative. The default address mapping (RoRaBaCoCh) moves the channel bits towards the least significant bits, and uses 128 byte as the default channel interleaving granularity. These defaults can be overridden if desired, but should serve as a sensible starting point for most use-cases.
2014-12-02mem: Add a GDDR5 DRAM configOmar Naji
This patch adds a first cut GDDR5 config to accommodate the users combining gem5 and GPUSim. The config is based on a SK Hynix datasheet, and the Nvidia GTX580 specification. Someone from the GPUSim user-camp should tweak the default page-policy and static frontend and backend latencies.
2014-11-14mem: Clarify unit of DRAM controller buffer sizeAndreas Hansson
2014-10-20mem: Add DRAM device size and check against configOmar Naji
This patch adds the size of the DRAM device to the DRAM config. It also compares the actual DRAM size (calculated using information from the config) to the size defined in the system. If these two values do not match gem5 will print a warning. In order to do correct DRAM research the size of the memory defined in the system should match the size of the DRAM in the config. The timing and current parameters found in the DRAM configs are defined for a DRAM device with a specific size and would differ for another device with a different size.
2014-07-25mem: Add missig timing and current parameters to DRAM configsOmar Naji
This patch adds missing timing and current parameters to the existing DRAM configs. These missing timing and current parameters are required by DRAMPower for the DRAM power calculations. The missing values are datasheet values of the specified DRAMs, and the appropriate references are added for the variuos configs.
2014-10-09mem: Remove DRAMSim2 DDR3 configurationOmar Naji
This patch prunes the DDR3 config that was initially created to match the default config of DRAMSim2. The config is not complete as it is, and to avoid having to maintain it, the easiest way forward is to simply prune it. Going forward we are adding power number etc to the other configurations.
2014-09-20mem: Add DDR4 bank group timingWendy Elsasser
Added the following parameter to the DRAMCtrl class: - bank_groups_per_rank This defaults to 1. For the DDR4 case, the default is overridden to indicate bank group architecture, with multiple bank groups per rank. Added the following delays to the DRAMCtrl class: - tCCD_L : CAS-to-CAS, same bank group delay - tRRD_L : RAS-to-RAS, same bank group delay These parameters are only applied when bank group timing is enabled. Bank group timing is currently enabled only for DDR4 memories. For all other memories, these delays will default to '0 ns' In the DRAM controller model, applied the bank group timing to the per bank parameters actAllowedAt and colAllowedAt. The actAllowedAt will be updated based on bank group when an ACT is issued. The colAllowedAt will be updated based on bank group when a RD/WR burst is issued. At the moment no modifications are made to the scheduling.
2014-09-20mem: Add memory rank-to-rank delayWendy Elsasser
Add the following delay to the DRAM controller: - tCS : Different rank bus turnaround delay This will be applied for 1) read-to-read, 2) write-to-write, 3) write-to-read, and 4) read-to-write command sequences, where the new command accesses a different rank than the previous burst. The delay defaults to 2*tCK for each defined memory class. Note that this does not correspond to one particular timing constraint, but is a way of modelling all the associated constraints. The DRAM controller has some minor changes to prioritize commands to the same rank. This prioritization will only occur when the command stream is not switching from a read to write or vice versa (in the case of switching we have a gap in any case). To prioritize commands to the same rank, the model will determine if there are any commands queued (same type) to the same rank as the previous command. This check will ensure that the 'same rank' command will be able to execute without adding bubbles to the command flow, e.g. any ACT delay requirements can be done under the hoods, allowing the burst to issue seamlessly.
2014-05-09mem: Update DDR3 and DDR4 based on datasheetsAndreas Hansson
This patch makes a more firm connection between the DDR3-1600 configuration and the corresponding datasheet, and also adds a DDR3-2133 and a DDR4-2400 configuration. At the moment there is also an ongoing effort to align the choice of datasheets to what is available in DRAMPower.
2014-05-09mem: Add DRAM cycle timeAndreas Hansson
This patch extends the current timing parameters with the DRAM cycle time. This is needed as the DRAMPower tool expects timestamps in DRAM cycles. At the moment we could get away with doing this in a post-processing step as the DRAMPower execution is separate from the simulation run. However, in the long run we want the tool to be called during the simulation, and then the cycle time is needed.
2014-05-09mem: Add tRTP to the DRAM controllerAndreas Hansson
This patch adds the tRTP timing constraint, governing the minimum time between a read command and a precharge. Default values are provided for the existing DRAM types.
2014-05-09mem: Add tWR to DRAM activate and precharge constraintsAndreas Hansson
This patch adds the write recovery time to the DRAM timing constraints, and changes the current tRASDoneAt to a more generic preAllowedAt, capturing when a precharge is allowed to take place. The part of the DRAM access code that accounts for the precharge and activate constraints is updated accordingly.
2014-05-09mem: Make DRAM read/write switching less conservativeAndreas Hansson
This patch changes the read/write event loop to use a single event (nextReqEvent), along with a state variable, thus joining the two control flows. This change makes it easier to follow the state transitions, and control what happens when. With the new loop we modify the overly conservative switching times such that the write-to-read switch allows bank preparation to happen in parallel with the bus turn around. Similarly, the read-to-write switch uses the introduced tRTW constraint.
2014-03-23mem: Rename SimpleDRAM to a more suitable DRAMCtrlAndreas Hansson
This patch renames the not-so-simple SimpleDRAM to a more suitable DRAMCtrl. The name change is intended to ensure that we do not send the wrong message (although the "simple" in SimpleDRAM was originally intended as in cleverly simple, or elegant). As the DRAM controller modelling work is being presented at ISPASS'14 our hope is that a broader audience will use the model in the future. --HG-- rename : src/mem/SimpleDRAM.py => src/mem/DRAMCtrl.py rename : src/mem/simple_dram.cc => src/mem/dram_ctrl.cc rename : src/mem/simple_dram.hh => src/mem/dram_ctrl.hh