sanchayanmaity/gem5
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
gem5/src/mem/dram_ctrl.cc

1803 lines
61 KiB
C++
Raw Normal View History

DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
/*
mem: Make DRAM read/write switching less conservative 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-05-10 00:58:48 +02:00
* Copyright (c) 2010-2014 ARM Limited
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
* All rights reserved
*
* The license below extends only to copyright in the software and shall
* not be construed as granting a license to any other intellectual
* property including but not limited to intellectual property relating
* to a hardware implementation of the functionality of the software
* licensed hereunder. You may use the software subject to the license
* terms below provided that you ensure that this notice is replicated
* unmodified and in its entirety in all distributions of the software,
* modified or unmodified, in source code or in binary form.
*
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
* Copyright (c) 2013 Amin Farmahini-Farahani
* All rights reserved.
*
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are
* met: redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer;
* redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution;
* neither the name of the copyright holders nor the names of its
* contributors may be used to endorse or promote products derived from
* this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
* Authors: Andreas Hansson
* Ani Udipi
mem: Pick the next DRAM request based on bank availability This patch changes the FCFS bit of FR-FCFS such that requests that target the earliest available bank are picked first (as suggested in the original work on FR-FCFS by Rixner et al). To accommodate this we add functionality to identify a bank through a one-dimensional identifier (bank id). The member names of the DRAMPacket are also update to match the style guide.
2013-11-01 16:56:20 +01:00
* Neha Agarwal
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
*/
mem: Pick the next DRAM request based on bank availability This patch changes the FCFS bit of FR-FCFS such that requests that target the earliest available bank are picked first (as suggested in the original work on FR-FCFS by Rixner et al). To accommodate this we add functionality to identify a bank through a one-dimensional identifier (bank id). The member names of the DRAMPacket are also update to match the style guide.
2013-11-01 16:56:20 +01:00
#include "base/bitfield.hh"
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
#include "base/trace.hh"
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
#include "debug/DRAM.hh"
mem: Add DRAM power states to the controller This patch adds power states to the controller. These states and the transitions can be used together with the Micron power model. As a more elaborate use-case, the transitions can be used to drive the DRAMPower tool. At the moment, the power-down modes are not used, and this patch simply serves to capture the idle, auto refresh and active modes. The patch adds a third state machine that interacts with the refresh state machine.
2014-05-10 00:58:48 +02:00
#include "debug/DRAMState.hh"
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
#include "debug/Drain.hh"
#include "mem/dram_ctrl.hh"
mem: Set the cache line size on a system level This patch removes the notion of a peer block size and instead sets the cache line size on the system level. Previously the size was set per cache, and communicated through the interconnect. There were plenty checks to ensure that everyone had the same size specified, and these checks are now removed. Another benefit that is not yet harnessed is that the cache line size is now known at construction time, rather than after the port binding. Hence, the block size can be locally stored and does not have to be queried every time it is used. A follow-on patch updates the configuration scripts accordingly.
2013-07-18 14:31:16 +02:00
#include "sim/system.hh"
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
using namespace std;
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
DRAMCtrl::DRAMCtrl(const DRAMCtrlParams* p) :
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
AbstractMemory(p),
port(name() + ".port", *this),
retryRdReq(false), retryWrReq(false),
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
busState(READ),
mem: Add DRAM power states to the controller This patch adds power states to the controller. These states and the transitions can be used together with the Micron power model. As a more elaborate use-case, the transitions can be used to drive the DRAMPower tool. At the moment, the power-down modes are not used, and this patch simply serves to capture the idle, auto refresh and active modes. The patch adds a third state machine that interacts with the refresh state machine.
2014-05-10 00:58:48 +02:00
nextReqEvent(this), respondEvent(this), activateEvent(this),
prechargeEvent(this), refreshEvent(this), powerEvent(this),
drainManager(NULL),
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
deviceBusWidth(p->device_bus_width), burstLength(p->burst_length),
deviceRowBufferSize(p->device_rowbuffer_size),
devicesPerRank(p->devices_per_rank),
burstSize((devicesPerRank * burstLength * deviceBusWidth) / 8),
rowBufferSize(devicesPerRank * deviceRowBufferSize),
mem: Make DRAM write queue draining more aggressive This patch changes the triggering condition for the write draining such that we grab the opportunity to issue writes if there are no reads waiting (as opposed to waiting for the writes to reach the high threshold). As a result, we potentially drain some of the writes in read idle periods (if any). A low threshold is added to be able to control how many write bursts are kept in the memory controller queue (acting as on-chip storage). The high and low thresholds are updated to sensible values for a 32/64 size write buffer. Note that the thresholds should be adjusted along with the queue sizes. This patch also adds some basic initialisation sanity checks and moves part of the initialisation to the constructor.
2014-03-23 16:12:01 +01:00
columnsPerRowBuffer(rowBufferSize / burstSize),
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
ranksPerChannel(p->ranks_per_channel),
mem: Add support for multi-channel DRAM configurations This patch adds support for multi-channel instances of the DRAM controller model by stripping away the channel bits in the address decoding. The patch relies on the availiability of address interleaving and, at this time, it is up to the user to configure the interleaving appropriately. At the moment it is assumed that the channel interleaving bits are immediately following the column bits (smallest sensible interleaving). Convenience methods for building multi-channel configurations will be added later.
2013-03-01 19:20:22 +01:00
banksPerRank(p->banks_per_rank), channels(p->channels), rowsPerBank(0),
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
readBufferSize(p->read_buffer_size),
writeBufferSize(p->write_buffer_size),
mem: Make DRAM write queue draining more aggressive This patch changes the triggering condition for the write draining such that we grab the opportunity to issue writes if there are no reads waiting (as opposed to waiting for the writes to reach the high threshold). As a result, we potentially drain some of the writes in read idle periods (if any). A low threshold is added to be able to control how many write bursts are kept in the memory controller queue (acting as on-chip storage). The high and low thresholds are updated to sensible values for a 32/64 size write buffer. Note that the thresholds should be adjusted along with the queue sizes. This patch also adds some basic initialisation sanity checks and moves part of the initialisation to the constructor.
2014-03-23 16:12:01 +01:00
writeHighThreshold(writeBufferSize * p->write_high_thresh_perc / 100.0),
writeLowThreshold(writeBufferSize * p->write_low_thresh_perc / 100.0),
mem: Track DRAM read/write switching and add hysteresis This patch adds stats for tracking the number of reads/writes per bus turn around, and also adds hysteresis to the write-to-read switching to ensure that the queue does not oscilate around the low threshold.
2014-03-23 16:12:14 +01:00
minWritesPerSwitch(p->min_writes_per_switch),
writesThisTime(0), readsThisTime(0),
mem: Make DRAM read/write switching less conservative 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-05-10 00:58:48 +02:00
tWTR(p->tWTR), tRTW(p->tRTW), tBURST(p->tBURST),
mem: Add tWR to DRAM activate and precharge constraints 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-10 00:58:48 +02:00
tRCD(p->tRCD), tCL(p->tCL), tRP(p->tRP), tRAS(p->tRAS), tWR(p->tWR),
mem: Add tRTP to the DRAM controller 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-10 00:58:48 +02:00
tRTP(p->tRTP), tRFC(p->tRFC), tREFI(p->tREFI), tRRD(p->tRRD),
mem: Add tTAW and tFAW to the SimpleDRAM model This patch adds two additional scheduling constraints to the DRAM controller model, to constrain the activation rate. The two metrics are determine the size of the activation window in terms of the number of activates and the minimum time required for that number of activates. This maps to current DDRx, LPDDRx and WIOx standards that have either tFAW (4 activate window) or tTAW (2 activate window) scheduling constraints.
2013-01-31 13:49:14 +01:00
tXAW(p->tXAW), activationLimit(p->activation_limit),
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
memSchedPolicy(p->mem_sched_policy), addrMapping(p->addr_mapping),
pageMgmt(p->page_policy),
mem: Limit the accesses to a page before forcing a precharge This patch adds a basic starvation-prevention mechanism where a DRAM page is forced to close after a certain number of accesses. The limit is combined with the open and open-adaptive page policy and if reached causes an auto-precharge.
2014-03-23 16:12:03 +01:00
maxAccessesPerRow(p->max_accesses_per_row),
mem: Add static latency to the DRAM controller This patch adds a frontend and backend static latency to the DRAM controller by delaying the responses. Two parameters expressing the frontend and backend contributions in absolute time are added to the controller, and the appropriate latency is added to the responses when adding them to the (infinite) queued port for sending. For writes and reads that hit in the write buffer, only the frontend latency is added. For reads that are serviced by the DRAM, the static latency is the sum of the pipeline latencies of the entire frontend, backend and PHY. The default values are chosen based on having roughly 10 pipeline stages in total at 500 MHz. In the future, it would be sensible to make the controller use its clock and convert these latencies (and a few of the DRAM timings) to cycles.
2013-05-30 18:54:12 +02:00
frontendLatency(p->static_frontend_latency),
backendLatency(p->static_backend_latency),
mem: Add DRAM power states to the controller This patch adds power states to the controller. These states and the transitions can be used together with the Micron power model. As a more elaborate use-case, the transitions can be used to drive the DRAMPower tool. At the moment, the power-down modes are not used, and this patch simply serves to capture the idle, auto refresh and active modes. The patch adds a third state machine that interacts with the refresh state machine.
2014-05-10 00:58:48 +02:00
busBusyUntil(0), refreshDueAt(0), refreshState(REF_IDLE),
pwrStateTrans(PWR_IDLE), pwrState(PWR_IDLE), prevArrival(0),
nextReqTime(0), pwrStateTick(0), numBanksActive(0)
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
{
// create the bank states based on the dimensions of the ranks and
// banks
banks.resize(ranksPerChannel);
mem: Make tXAW enforcement less conservative and per rank This patch changes the tXAW constraint so that it is enforced per rank rather than globally for all ranks in the channel. It also avoids using the bank freeAt to enforce the activation limit, as doing so also precludes performing any column or row command to the DRAM. Instead the patch introduces a new variable actAllowedAt for the banks and use this to track when a potential activation can occur.
2013-11-01 16:56:22 +01:00
actTicks.resize(ranksPerChannel);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
for (size_t c = 0; c < ranksPerChannel; ++c) {
banks[c].resize(banksPerRank);
mem: Make tXAW enforcement less conservative and per rank This patch changes the tXAW constraint so that it is enforced per rank rather than globally for all ranks in the channel. It also avoids using the bank freeAt to enforce the activation limit, as doing so also precludes performing any column or row command to the DRAM. Instead the patch introduces a new variable actAllowedAt for the banks and use this to track when a potential activation can occur.
2013-11-01 16:56:22 +01:00
actTicks[c].resize(activationLimit, 0);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
}
mem: Make DRAM write queue draining more aggressive This patch changes the triggering condition for the write draining such that we grab the opportunity to issue writes if there are no reads waiting (as opposed to waiting for the writes to reach the high threshold). As a result, we potentially drain some of the writes in read idle periods (if any). A low threshold is added to be able to control how many write bursts are kept in the memory controller queue (acting as on-chip storage). The high and low thresholds are updated to sensible values for a 32/64 size write buffer. Note that the thresholds should be adjusted along with the queue sizes. This patch also adds some basic initialisation sanity checks and moves part of the initialisation to the constructor.
2014-03-23 16:12:01 +01:00
// perform a basic check of the write thresholds
if (p->write_low_thresh_perc >= p->write_high_thresh_perc)
fatal("Write buffer low threshold %d must be smaller than the "
"high threshold %d\n", p->write_low_thresh_perc,
p->write_high_thresh_perc);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
// determine the rows per bank by looking at the total capacity
mem: SimpleDRAM variable naming and whitespace fixes This patch fixes a number of small cosmetic issues in the SimpleDRAM module. The most important change is to move the accounting of received packets to after the check is made if the packet should be retried or not. Thus, packets are only counted if they are actually accepted.
2013-03-01 19:20:24 +01:00
uint64_t capacity = ULL(1) << ceilLog2(AbstractMemory::size());
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
DPRINTF(DRAM, "Memory capacity %lld (%lld) bytes\n", capacity,
AbstractMemory::size());
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
DPRINTF(DRAM, "Row buffer size %d bytes with %d columns per row buffer\n",
rowBufferSize, columnsPerRowBuffer);
rowsPerBank = capacity / (rowBufferSize * banksPerRank * ranksPerChannel);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Add support for multi-channel DRAM configurations This patch adds support for multi-channel instances of the DRAM controller model by stripping away the channel bits in the address decoding. The patch relies on the availiability of address interleaving and, at this time, it is up to the user to configure the interleaving appropriately. At the moment it is assumed that the channel interleaving bits are immediately following the column bits (smallest sensible interleaving). Convenience methods for building multi-channel configurations will be added later.
2013-03-01 19:20:22 +01:00
if (range.interleaved()) {
if (channels != range.stripes())
mem: DRAM controller tidying up Minor tidying up and removing of redundant code, including the printing of queue state every million accesses.
2014-03-23 16:12:06 +01:00
fatal("%s has %d interleaved address stripes but %d channel(s)\n",
mem: Add support for multi-channel DRAM configurations This patch adds support for multi-channel instances of the DRAM controller model by stripping away the channel bits in the address decoding. The patch relies on the availiability of address interleaving and, at this time, it is up to the user to configure the interleaving appropriately. At the moment it is assumed that the channel interleaving bits are immediately following the column bits (smallest sensible interleaving). Convenience methods for building multi-channel configurations will be added later.
2013-03-01 19:20:22 +01:00
name(), range.stripes(), channels);
mem: More descriptive address-mapping scheme names This patch adds the row bits to the name of the address mapping schemes to make it more clear that all the current schemes places the row bits as the most significant bits.
2014-03-23 16:11:53 +01:00
if (addrMapping == Enums::RoRaBaChCo) {
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
if (rowBufferSize != range.granularity()) {
mem: DRAM controller tidying up Minor tidying up and removing of redundant code, including the printing of queue state every million accesses.
2014-03-23 16:12:06 +01:00
fatal("Interleaving of %s doesn't match RoRaBaChCo "
mem: More descriptive address-mapping scheme names This patch adds the row bits to the name of the address mapping schemes to make it more clear that all the current schemes places the row bits as the most significant bits.
2014-03-23 16:11:53 +01:00
"address map\n", name());
mem: Add support for multi-channel DRAM configurations This patch adds support for multi-channel instances of the DRAM controller model by stripping away the channel bits in the address decoding. The patch relies on the availiability of address interleaving and, at this time, it is up to the user to configure the interleaving appropriately. At the moment it is assumed that the channel interleaving bits are immediately following the column bits (smallest sensible interleaving). Convenience methods for building multi-channel configurations will be added later.
2013-03-01 19:20:22 +01:00
}
mem: More descriptive address-mapping scheme names This patch adds the row bits to the name of the address mapping schemes to make it more clear that all the current schemes places the row bits as the most significant bits.
2014-03-23 16:11:53 +01:00
} else if (addrMapping == Enums::RoRaBaCoCh) {
if (system()->cacheLineSize() != range.granularity()) {
mem: DRAM controller tidying up Minor tidying up and removing of redundant code, including the printing of queue state every million accesses.
2014-03-23 16:12:06 +01:00
fatal("Interleaving of %s doesn't match RoRaBaCoCh "
mem: More descriptive address-mapping scheme names This patch adds the row bits to the name of the address mapping schemes to make it more clear that all the current schemes places the row bits as the most significant bits.
2014-03-23 16:11:53 +01:00
"address map\n", name());
mem: Address mapping with fine-grained channel interleaving This patch adds an address mapping scheme where the channel interleaving takes place on a cache line granularity. It is similar to the existing RaBaChCo that interleaves on a DRAM page, but should give higher performance when there is less locality in the address stream.
2013-04-22 19:20:34 +02:00
}
mem: More descriptive address-mapping scheme names This patch adds the row bits to the name of the address mapping schemes to make it more clear that all the current schemes places the row bits as the most significant bits.
2014-03-23 16:11:53 +01:00
} else if (addrMapping == Enums::RoCoRaBaCh) {
if (system()->cacheLineSize() != range.granularity())
mem: DRAM controller tidying up Minor tidying up and removing of redundant code, including the printing of queue state every million accesses.
2014-03-23 16:12:06 +01:00
fatal("Interleaving of %s doesn't match RoCoRaBaCh "
mem: More descriptive address-mapping scheme names This patch adds the row bits to the name of the address mapping schemes to make it more clear that all the current schemes places the row bits as the most significant bits.
2014-03-23 16:11:53 +01:00
"address map\n", name());
mem: Add support for multi-channel DRAM configurations This patch adds support for multi-channel instances of the DRAM controller model by stripping away the channel bits in the address decoding. The patch relies on the availiability of address interleaving and, at this time, it is up to the user to configure the interleaving appropriately. At the moment it is assumed that the channel interleaving bits are immediately following the column bits (smallest sensible interleaving). Convenience methods for building multi-channel configurations will be added later.
2013-03-01 19:20:22 +01:00
}
}
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
// some basic sanity checks
if (tREFI <= tRP || tREFI <= tRFC) {
fatal("tREFI (%d) must be larger than tRP (%d) and tRFC (%d)\n",
tREFI, tRP, tRFC);
}
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
}
mem: Make DRAM write queue draining more aggressive This patch changes the triggering condition for the write draining such that we grab the opportunity to issue writes if there are no reads waiting (as opposed to waiting for the writes to reach the high threshold). As a result, we potentially drain some of the writes in read idle periods (if any). A low threshold is added to be able to control how many write bursts are kept in the memory controller queue (acting as on-chip storage). The high and low thresholds are updated to sensible values for a 32/64 size write buffer. Note that the thresholds should be adjusted along with the queue sizes. This patch also adds some basic initialisation sanity checks and moves part of the initialisation to the constructor.
2014-03-23 16:12:01 +01:00
void
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
DRAMCtrl::init()
mem: Make DRAM write queue draining more aggressive This patch changes the triggering condition for the write draining such that we grab the opportunity to issue writes if there are no reads waiting (as opposed to waiting for the writes to reach the high threshold). As a result, we potentially drain some of the writes in read idle periods (if any). A low threshold is added to be able to control how many write bursts are kept in the memory controller queue (acting as on-chip storage). The high and low thresholds are updated to sensible values for a 32/64 size write buffer. Note that the thresholds should be adjusted along with the queue sizes. This patch also adds some basic initialisation sanity checks and moves part of the initialisation to the constructor.
2014-03-23 16:12:01 +01:00
{
if (!port.isConnected()) {
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
fatal("DRAMCtrl %s is unconnected!\n", name());
mem: Make DRAM write queue draining more aggressive This patch changes the triggering condition for the write draining such that we grab the opportunity to issue writes if there are no reads waiting (as opposed to waiting for the writes to reach the high threshold). As a result, we potentially drain some of the writes in read idle periods (if any). A low threshold is added to be able to control how many write bursts are kept in the memory controller queue (acting as on-chip storage). The high and low thresholds are updated to sensible values for a 32/64 size write buffer. Note that the thresholds should be adjusted along with the queue sizes. This patch also adds some basic initialisation sanity checks and moves part of the initialisation to the constructor.
2014-03-23 16:12:01 +01:00
} else {
port.sendRangeChange();
}
}
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
void
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
DRAMCtrl::startup()
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
{
mem: DRAM controller tidying up Minor tidying up and removing of redundant code, including the printing of queue state every million accesses.
2014-03-23 16:12:06 +01:00
// update the start tick for the precharge accounting to the
// current tick
mem: Add DRAM power states to the controller This patch adds power states to the controller. These states and the transitions can be used together with the Micron power model. As a more elaborate use-case, the transitions can be used to drive the DRAMPower tool. At the moment, the power-down modes are not used, and this patch simply serves to capture the idle, auto refresh and active modes. The patch adds a third state machine that interacts with the refresh state machine.
2014-05-10 00:58:48 +02:00
pwrStateTick = curTick();
mem: DRAM controller tidying up Minor tidying up and removing of redundant code, including the printing of queue state every million accesses.
2014-03-23 16:12:06 +01:00
mem: Make DRAM read/write switching less conservative 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-05-10 00:58:48 +02:00
// shift the bus busy time sufficiently far ahead that we never
// have to worry about negative values when computing the time for
// the next request, this will add an insignificant bubble at the
// start of simulation
busBusyUntil = curTick() + tRP + tRCD + tCL;
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
// kick off the refresh, and give ourselves enough time to
// precharge
schedule(refreshEvent, curTick() + tREFI - tRP);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
}
Tick
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
DRAMCtrl::recvAtomic(PacketPtr pkt)
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
{
DPRINTF(DRAM, "recvAtomic: %s 0x%x\n", pkt->cmdString(), pkt->getAddr());
// do the actual memory access and turn the packet into a response
access(pkt);
Tick latency = 0;
if (!pkt->memInhibitAsserted() && pkt->hasData()) {
// this value is not supposed to be accurate, just enough to
// keep things going, mimic a closed page
latency = tRP + tRCD + tCL;
}
return latency;
}
bool
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
DRAMCtrl::readQueueFull(unsigned int neededEntries) const
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
{
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
DPRINTF(DRAM, "Read queue limit %d, current size %d, entries needed %d\n",
readBufferSize, readQueue.size() + respQueue.size(),
neededEntries);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
return
(readQueue.size() + respQueue.size() + neededEntries) > readBufferSize;
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
}
bool
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
DRAMCtrl::writeQueueFull(unsigned int neededEntries) const
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
{
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
DPRINTF(DRAM, "Write queue limit %d, current size %d, entries needed %d\n",
writeBufferSize, writeQueue.size(), neededEntries);
return (writeQueue.size() + neededEntries) > writeBufferSize;
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
}
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
DRAMCtrl::DRAMPacket*
DRAMCtrl::decodeAddr(PacketPtr pkt, Addr dramPktAddr, unsigned size,
mem: DRAM controller tidying up Minor tidying up and removing of redundant code, including the printing of queue state every million accesses.
2014-03-23 16:12:06 +01:00
bool isRead)
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
{
mem: Address mapping with fine-grained channel interleaving This patch adds an address mapping scheme where the channel interleaving takes place on a cache line granularity. It is similar to the existing RaBaChCo that interleaves on a DRAM page, but should give higher performance when there is less locality in the address stream.
2013-04-22 19:20:34 +02:00
// decode the address based on the address mapping scheme, with
mem: More descriptive address-mapping scheme names This patch adds the row bits to the name of the address mapping schemes to make it more clear that all the current schemes places the row bits as the most significant bits.
2014-03-23 16:11:53 +01:00
// Ro, Ra, Co, Ba and Ch denoting row, rank, column, bank and
// channel, respectively
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
uint8_t rank;
mem: Pick the next DRAM request based on bank availability This patch changes the FCFS bit of FR-FCFS such that requests that target the earliest available bank are picked first (as suggested in the original work on FR-FCFS by Rixner et al). To accommodate this we add functionality to identify a bank through a one-dimensional identifier (bank id). The member names of the DRAMPacket are also update to match the style guide.
2013-11-01 16:56:20 +01:00
uint8_t bank;
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
uint16_t row;
// truncate the address to the access granularity
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
Addr addr = dramPktAddr / burstSize;
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Add comments for the DRAM address decoding This patch adds more verbose comments to explain the two different address mapping schemes of the DRAM controller.
2013-01-31 13:49:18 +01:00
// we have removed the lowest order address bits that denote the
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
// position within the column
mem: More descriptive address-mapping scheme names This patch adds the row bits to the name of the address mapping schemes to make it more clear that all the current schemes places the row bits as the most significant bits.
2014-03-23 16:11:53 +01:00
if (addrMapping == Enums::RoRaBaChCo) {
mem: Add comments for the DRAM address decoding This patch adds more verbose comments to explain the two different address mapping schemes of the DRAM controller.
2013-01-31 13:49:18 +01:00
// the lowest order bits denote the column to ensure that
// sequential cache lines occupy the same row
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
addr = addr / columnsPerRowBuffer;
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Address mapping with fine-grained channel interleaving This patch adds an address mapping scheme where the channel interleaving takes place on a cache line granularity. It is similar to the existing RaBaChCo that interleaves on a DRAM page, but should give higher performance when there is less locality in the address stream.
2013-04-22 19:20:34 +02:00
// take out the channel part of the address
addr = addr / channels;
// after the channel bits, get the bank bits to interleave
// over the banks
bank = addr % banksPerRank;
addr = addr / banksPerRank;
// after the bank, we get the rank bits which thus interleaves
// over the ranks
rank = addr % ranksPerChannel;
addr = addr / ranksPerChannel;
// lastly, get the row bits
row = addr % rowsPerBank;
addr = addr / rowsPerBank;
mem: More descriptive address-mapping scheme names This patch adds the row bits to the name of the address mapping schemes to make it more clear that all the current schemes places the row bits as the most significant bits.
2014-03-23 16:11:53 +01:00
} else if (addrMapping == Enums::RoRaBaCoCh) {
mem: Address mapping with fine-grained channel interleaving This patch adds an address mapping scheme where the channel interleaving takes place on a cache line granularity. It is similar to the existing RaBaChCo that interleaves on a DRAM page, but should give higher performance when there is less locality in the address stream.
2013-04-22 19:20:34 +02:00
// take out the channel part of the address
mem: Add support for multi-channel DRAM configurations This patch adds support for multi-channel instances of the DRAM controller model by stripping away the channel bits in the address decoding. The patch relies on the availiability of address interleaving and, at this time, it is up to the user to configure the interleaving appropriately. At the moment it is assumed that the channel interleaving bits are immediately following the column bits (smallest sensible interleaving). Convenience methods for building multi-channel configurations will be added later.
2013-03-01 19:20:22 +01:00
addr = addr / channels;
mem: Address mapping with fine-grained channel interleaving This patch adds an address mapping scheme where the channel interleaving takes place on a cache line granularity. It is similar to the existing RaBaChCo that interleaves on a DRAM page, but should give higher performance when there is less locality in the address stream.
2013-04-22 19:20:34 +02:00
// next, the column
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
addr = addr / columnsPerRowBuffer;
mem: Address mapping with fine-grained channel interleaving This patch adds an address mapping scheme where the channel interleaving takes place on a cache line granularity. It is similar to the existing RaBaChCo that interleaves on a DRAM page, but should give higher performance when there is less locality in the address stream.
2013-04-22 19:20:34 +02:00
// after the column bits, we get the bank bits to interleave
mem: Add comments for the DRAM address decoding This patch adds more verbose comments to explain the two different address mapping schemes of the DRAM controller.
2013-01-31 13:49:18 +01:00
// over the banks
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
bank = addr % banksPerRank;
addr = addr / banksPerRank;
mem: Add comments for the DRAM address decoding This patch adds more verbose comments to explain the two different address mapping schemes of the DRAM controller.
2013-01-31 13:49:18 +01:00
// after the bank, we get the rank bits which thus interleaves
// over the ranks
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
rank = addr % ranksPerChannel;
addr = addr / ranksPerChannel;
mem: Add comments for the DRAM address decoding This patch adds more verbose comments to explain the two different address mapping schemes of the DRAM controller.
2013-01-31 13:49:18 +01:00
// lastly, get the row bits
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
row = addr % rowsPerBank;
addr = addr / rowsPerBank;
mem: More descriptive address-mapping scheme names This patch adds the row bits to the name of the address mapping schemes to make it more clear that all the current schemes places the row bits as the most significant bits.
2014-03-23 16:11:53 +01:00
} else if (addrMapping == Enums::RoCoRaBaCh) {
mem: Add comments for the DRAM address decoding This patch adds more verbose comments to explain the two different address mapping schemes of the DRAM controller.
2013-01-31 13:49:18 +01:00
// optimise for closed page mode and utilise maximum
// parallelism of the DRAM (at the cost of power)
mem: Add support for multi-channel DRAM configurations This patch adds support for multi-channel instances of the DRAM controller model by stripping away the channel bits in the address decoding. The patch relies on the availiability of address interleaving and, at this time, it is up to the user to configure the interleaving appropriately. At the moment it is assumed that the channel interleaving bits are immediately following the column bits (smallest sensible interleaving). Convenience methods for building multi-channel configurations will be added later.
2013-03-01 19:20:22 +01:00
// take out the channel part of the address, not that this has
// to match with how accesses are interleaved between the
// controllers in the address mapping
addr = addr / channels;
mem: Add comments for the DRAM address decoding This patch adds more verbose comments to explain the two different address mapping schemes of the DRAM controller.
2013-01-31 13:49:18 +01:00
// start with the bank bits, as this provides the maximum
// opportunity for parallelism between requests
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
bank = addr % banksPerRank;
addr = addr / banksPerRank;
mem: Add comments for the DRAM address decoding This patch adds more verbose comments to explain the two different address mapping schemes of the DRAM controller.
2013-01-31 13:49:18 +01:00
// next get the rank bits
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
rank = addr % ranksPerChannel;
addr = addr / ranksPerChannel;
mem: Add comments for the DRAM address decoding This patch adds more verbose comments to explain the two different address mapping schemes of the DRAM controller.
2013-01-31 13:49:18 +01:00
// next the column bits which we do not need to keep track of
// and simply skip past
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
addr = addr / columnsPerRowBuffer;
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Add comments for the DRAM address decoding This patch adds more verbose comments to explain the two different address mapping schemes of the DRAM controller.
2013-01-31 13:49:18 +01:00
// lastly, get the row bits
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
row = addr % rowsPerBank;
addr = addr / rowsPerBank;
} else
panic("Unknown address mapping policy chosen!");
assert(rank < ranksPerChannel);
assert(bank < banksPerRank);
assert(row < rowsPerBank);
DPRINTF(DRAM, "Address: %lld Rank %d Bank %d Row %d\n",
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
dramPktAddr, rank, bank, row);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
// create the corresponding DRAM packet with the entry time and
mem: SimpleDRAM variable naming and whitespace fixes This patch fixes a number of small cosmetic issues in the SimpleDRAM module. The most important change is to move the accounting of received packets to after the check is made if the packet should be retried or not. Thus, packets are only counted if they are actually accepted.
2013-03-01 19:20:24 +01:00
// ready time set to the current tick, the latter will be updated
// later
mem: Pick the next DRAM request based on bank availability This patch changes the FCFS bit of FR-FCFS such that requests that target the earliest available bank are picked first (as suggested in the original work on FR-FCFS by Rixner et al). To accommodate this we add functionality to identify a bank through a one-dimensional identifier (bank id). The member names of the DRAMPacket are also update to match the style guide.
2013-11-01 16:56:20 +01:00
uint16_t bank_id = banksPerRank * rank + bank;
return new DRAMPacket(pkt, isRead, rank, bank, row, bank_id, dramPktAddr,
size, banks[rank][bank]);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
}
void
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
DRAMCtrl::addToReadQueue(PacketPtr pkt, unsigned int pktCount)
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
{
// only add to the read queue here. whenever the request is
// eventually done, set the readyTime, and call schedule()
assert(!pkt->isWrite());
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
assert(pktCount != 0);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
// if the request size is larger than burst size, the pkt is split into
// multiple DRAM packets
// Note if the pkt starting address is not aligened to burst size, the
// address of first DRAM packet is kept unaliged. Subsequent DRAM packets
// are aligned to burst size boundaries. This is to ensure we accurately
// check read packets against packets in write queue.
Addr addr = pkt->getAddr();
unsigned pktsServicedByWrQ = 0;
BurstHelper* burst_helper = NULL;
for (int cnt = 0; cnt < pktCount; ++cnt) {
unsigned size = std::min((addr | (burstSize - 1)) + 1,
pkt->getAddr() + pkt->getSize()) - addr;
readPktSize[ceilLog2(size)]++;
readBursts++;
// First check write buffer to see if the data is already at
// the controller
bool foundInWrQ = false;
mem: Use STL deque in favour of list for DRAM queues This patch changes the data structure used for the DRAM read, write and response queues from an STL list to deque. This optimisation is based on the observation that the size is small (and fixed), and that the structures are frequently iterated over in a linear fashion.
2013-08-19 09:52:32 +02:00
for (auto i = writeQueue.begin(); i != writeQueue.end(); ++i) {
mem: Perform write merging in the DRAM write queue This patch implements basic write merging in the DRAM to avoid redundant bursts. When a new access is added to the queue it is compared against the existing entries, and if it is either intersecting or immediately succeeding/preceeding an existing item it is merged. There is currently no attempt made at avoiding iterating over the existing items in determining whether merging is possible or not.
2013-08-19 09:52:31 +02:00
// check if the read is subsumed in the write entry we are
// looking at
if ((*i)->addr <= addr &&
(addr + size) <= ((*i)->addr + (*i)->size)) {
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
foundInWrQ = true;
servicedByWrQ++;
pktsServicedByWrQ++;
DPRINTF(DRAM, "Read to addr %lld with size %d serviced by "
"write queue\n", addr, size);
mem: Adding stats for DRAM power calculation This patch adds stats which are used for offline power calculation from the 'Micron Power Calculator' spreadsheet.
2013-11-01 16:56:28 +01:00
bytesReadWrQ += burstSize;
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
break;
}
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
}
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
// If not found in the write q, make a DRAM packet and
// push it onto the read queue
if (!foundInWrQ) {
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
// Make the burst helper for split packets
if (pktCount > 1 && burst_helper == NULL) {
DPRINTF(DRAM, "Read to addr %lld translates to %d "
"dram requests\n", pkt->getAddr(), pktCount);
burst_helper = new BurstHelper(pktCount);
}
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Use the same timing calculation for DRAM read and write This patch simplifies the DRAM model by re-using the function that computes the busy and access time for both reads and writes.
2013-11-01 16:56:19 +01:00
DRAMPacket* dram_pkt = decodeAddr(pkt, addr, size, true);
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
dram_pkt->burstHelper = burst_helper;
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
assert(!readQueueFull(1));
rdQLenPdf[readQueue.size() + respQueue.size()]++;
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
DPRINTF(DRAM, "Adding to read queue\n");
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
readQueue.push_back(dram_pkt);
// Update stats
avgRdQLen = readQueue.size() + respQueue.size();
}
// Starting address of next dram pkt (aligend to burstSize boundary)
addr = (addr | (burstSize - 1)) + 1;
}
// If all packets are serviced by write queue, we send the repsonse back
if (pktsServicedByWrQ == pktCount) {
accessAndRespond(pkt, frontendLatency);
return;
}
// Update how many split packets are serviced by write queue
if (burst_helper != NULL)
burst_helper->burstsServiced = pktsServicedByWrQ;
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Make DRAM read/write switching less conservative 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-05-10 00:58:48 +02:00
// If we are not already scheduled to get a request out of the
// queue, do so now
if (!nextReqEvent.scheduled()) {
mem: SimpleDRAM variable naming and whitespace fixes This patch fixes a number of small cosmetic issues in the SimpleDRAM module. The most important change is to move the accounting of received packets to after the check is made if the packet should be retried or not. Thus, packets are only counted if they are actually accepted.
2013-03-01 19:20:24 +01:00
DPRINTF(DRAM, "Request scheduled immediately\n");
schedule(nextReqEvent, curTick());
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
}
}
void
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
DRAMCtrl::addToWriteQueue(PacketPtr pkt, unsigned int pktCount)
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
{
// only add to the write queue here. whenever the request is
// eventually done, set the readyTime, and call schedule()
assert(pkt->isWrite());
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
// if the request size is larger than burst size, the pkt is split into
// multiple DRAM packets
Addr addr = pkt->getAddr();
for (int cnt = 0; cnt < pktCount; ++cnt) {
unsigned size = std::min((addr | (burstSize - 1)) + 1,
pkt->getAddr() + pkt->getSize()) - addr;
writePktSize[ceilLog2(size)]++;
writeBursts++;
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Perform write merging in the DRAM write queue This patch implements basic write merging in the DRAM to avoid redundant bursts. When a new access is added to the queue it is compared against the existing entries, and if it is either intersecting or immediately succeeding/preceeding an existing item it is merged. There is currently no attempt made at avoiding iterating over the existing items in determining whether merging is possible or not.
2013-08-19 09:52:31 +02:00
// see if we can merge with an existing item in the write
stats: Cumulative stats update This patch updates the stats to reflect the: 1) addition of the internal queue in SimpleMemory, 2) moving of the memory class outside FSConfig, 3) fixing up of the 2D vector printing format, 4) specifying burst size and interface width for the DRAM instead of relying on cache-line size, 5) performing merging in the DRAM controller write buffer, and 6) fixing how idle cycles are counted in the atomic and timing CPU models. The main reason for bundling them up is to minimise the changeset size.
2013-08-19 09:52:36 +02:00
// queue and keep track of whether we have merged or not so we
// can stop at that point and also avoid enqueueing a new
// request
mem: Perform write merging in the DRAM write queue This patch implements basic write merging in the DRAM to avoid redundant bursts. When a new access is added to the queue it is compared against the existing entries, and if it is either intersecting or immediately succeeding/preceeding an existing item it is merged. There is currently no attempt made at avoiding iterating over the existing items in determining whether merging is possible or not.
2013-08-19 09:52:31 +02:00
bool merged = false;
auto w = writeQueue.begin();
while(!merged && w != writeQueue.end()) {
// either of the two could be first, if they are the same
// it does not matter which way we go
if ((*w)->addr >= addr) {
stats: Cumulative stats update This patch updates the stats to reflect the: 1) addition of the internal queue in SimpleMemory, 2) moving of the memory class outside FSConfig, 3) fixing up of the 2D vector printing format, 4) specifying burst size and interface width for the DRAM instead of relying on cache-line size, 5) performing merging in the DRAM controller write buffer, and 6) fixing how idle cycles are counted in the atomic and timing CPU models. The main reason for bundling them up is to minimise the changeset size.
2013-08-19 09:52:36 +02:00
// the existing one starts after the new one, figure
// out where the new one ends with respect to the
// existing one
mem: Perform write merging in the DRAM write queue This patch implements basic write merging in the DRAM to avoid redundant bursts. When a new access is added to the queue it is compared against the existing entries, and if it is either intersecting or immediately succeeding/preceeding an existing item it is merged. There is currently no attempt made at avoiding iterating over the existing items in determining whether merging is possible or not.
2013-08-19 09:52:31 +02:00
if ((addr + size) >= ((*w)->addr + (*w)->size)) {
// check if the existing one is completely
// subsumed in the new one
DPRINTF(DRAM, "Merging write covering existing burst\n");
merged = true;
// update both the address and the size
(*w)->addr = addr;
(*w)->size = size;
} else if ((addr + size) >= (*w)->addr &&
((*w)->addr + (*w)->size - addr) <= burstSize) {
// the new one is just before or partially
// overlapping with the existing one, and together
// they fit within a burst
DPRINTF(DRAM, "Merging write before existing burst\n");
merged = true;
// the existing queue item needs to be adjusted with
// respect to both address and size
(*w)->size = (*w)->addr + (*w)->size - addr;
mem: Fixes a bug in simple_dram write merging Fixes updating the value of size in the write merge function. Committed by: Nilay Vaish <nilay@cs.wisc.edu>
2014-01-29 01:00:49 +01:00
(*w)->addr = addr;
mem: Perform write merging in the DRAM write queue This patch implements basic write merging in the DRAM to avoid redundant bursts. When a new access is added to the queue it is compared against the existing entries, and if it is either intersecting or immediately succeeding/preceeding an existing item it is merged. There is currently no attempt made at avoiding iterating over the existing items in determining whether merging is possible or not.
2013-08-19 09:52:31 +02:00
}
} else {
stats: Cumulative stats update This patch updates the stats to reflect the: 1) addition of the internal queue in SimpleMemory, 2) moving of the memory class outside FSConfig, 3) fixing up of the 2D vector printing format, 4) specifying burst size and interface width for the DRAM instead of relying on cache-line size, 5) performing merging in the DRAM controller write buffer, and 6) fixing how idle cycles are counted in the atomic and timing CPU models. The main reason for bundling them up is to minimise the changeset size.
2013-08-19 09:52:36 +02:00
// the new one starts after the current one, figure
// out where the existing one ends with respect to the
// new one
mem: Perform write merging in the DRAM write queue This patch implements basic write merging in the DRAM to avoid redundant bursts. When a new access is added to the queue it is compared against the existing entries, and if it is either intersecting or immediately succeeding/preceeding an existing item it is merged. There is currently no attempt made at avoiding iterating over the existing items in determining whether merging is possible or not.
2013-08-19 09:52:31 +02:00
if (((*w)->addr + (*w)->size) >= (addr + size)) {
// check if the new one is completely subsumed in the
// existing one
DPRINTF(DRAM, "Merging write into existing burst\n");
merged = true;
// no adjustments necessary
} else if (((*w)->addr + (*w)->size) >= addr &&
(addr + size - (*w)->addr) <= burstSize) {
// the existing one is just before or partially
// overlapping with the new one, and together
// they fit within a burst
DPRINTF(DRAM, "Merging write after existing burst\n");
merged = true;
// the address is right, and only the size has
// to be adjusted
(*w)->size = addr + size - (*w)->addr;
}
}
++w;
}
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Perform write merging in the DRAM write queue This patch implements basic write merging in the DRAM to avoid redundant bursts. When a new access is added to the queue it is compared against the existing entries, and if it is either intersecting or immediately succeeding/preceeding an existing item it is merged. There is currently no attempt made at avoiding iterating over the existing items in determining whether merging is possible or not.
2013-08-19 09:52:31 +02:00
// if the item was not merged we need to create a new write
// and enqueue it
if (!merged) {
mem: Use the same timing calculation for DRAM read and write This patch simplifies the DRAM model by re-using the function that computes the busy and access time for both reads and writes.
2013-11-01 16:56:19 +01:00
DRAMPacket* dram_pkt = decodeAddr(pkt, addr, size, false);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Perform write merging in the DRAM write queue This patch implements basic write merging in the DRAM to avoid redundant bursts. When a new access is added to the queue it is compared against the existing entries, and if it is either intersecting or immediately succeeding/preceeding an existing item it is merged. There is currently no attempt made at avoiding iterating over the existing items in determining whether merging is possible or not.
2013-08-19 09:52:31 +02:00
assert(writeQueue.size() < writeBufferSize);
wrQLenPdf[writeQueue.size()]++;
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Perform write merging in the DRAM write queue This patch implements basic write merging in the DRAM to avoid redundant bursts. When a new access is added to the queue it is compared against the existing entries, and if it is either intersecting or immediately succeeding/preceeding an existing item it is merged. There is currently no attempt made at avoiding iterating over the existing items in determining whether merging is possible or not.
2013-08-19 09:52:31 +02:00
DPRINTF(DRAM, "Adding to write queue\n");
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Perform write merging in the DRAM write queue This patch implements basic write merging in the DRAM to avoid redundant bursts. When a new access is added to the queue it is compared against the existing entries, and if it is either intersecting or immediately succeeding/preceeding an existing item it is merged. There is currently no attempt made at avoiding iterating over the existing items in determining whether merging is possible or not.
2013-08-19 09:52:31 +02:00
writeQueue.push_back(dram_pkt);
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
mem: Perform write merging in the DRAM write queue This patch implements basic write merging in the DRAM to avoid redundant bursts. When a new access is added to the queue it is compared against the existing entries, and if it is either intersecting or immediately succeeding/preceeding an existing item it is merged. There is currently no attempt made at avoiding iterating over the existing items in determining whether merging is possible or not.
2013-08-19 09:52:31 +02:00
// Update stats
avgWrQLen = writeQueue.size();
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
} else {
// keep track of the fact that this burst effectively
// disappeared as it was merged with an existing one
mergedWrBursts++;
mem: Perform write merging in the DRAM write queue This patch implements basic write merging in the DRAM to avoid redundant bursts. When a new access is added to the queue it is compared against the existing entries, and if it is either intersecting or immediately succeeding/preceeding an existing item it is merged. There is currently no attempt made at avoiding iterating over the existing items in determining whether merging is possible or not.
2013-08-19 09:52:31 +02:00
}
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
// Starting address of next dram pkt (aligend to burstSize boundary)
addr = (addr | (burstSize - 1)) + 1;
}
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
// we do not wait for the writes to be send to the actual memory,
// but instead take responsibility for the consistency here and
// snoop the write queue for any upcoming reads
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
// @todo, if a pkt size is larger than burst size, we might need a
// different front end latency
mem: Add static latency to the DRAM controller This patch adds a frontend and backend static latency to the DRAM controller by delaying the responses. Two parameters expressing the frontend and backend contributions in absolute time are added to the controller, and the appropriate latency is added to the responses when adding them to the (infinite) queued port for sending. For writes and reads that hit in the write buffer, only the frontend latency is added. For reads that are serviced by the DRAM, the static latency is the sum of the pipeline latencies of the entire frontend, backend and PHY. The default values are chosen based on having roughly 10 pipeline stages in total at 500 MHz. In the future, it would be sensible to make the controller use its clock and convert these latencies (and a few of the DRAM timings) to cycles.
2013-05-30 18:54:12 +02:00
accessAndRespond(pkt, frontendLatency);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Make DRAM read/write switching less conservative 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-05-10 00:58:48 +02:00
// If we are not already scheduled to get a request out of the
// queue, do so now
if (!nextReqEvent.scheduled()) {
DPRINTF(DRAM, "Request scheduled immediately\n");
schedule(nextReqEvent, curTick());
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
}
}
void
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
DRAMCtrl::printQs() const {
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
DPRINTF(DRAM, "===READ QUEUE===\n\n");
mem: Use STL deque in favour of list for DRAM queues This patch changes the data structure used for the DRAM read, write and response queues from an STL list to deque. This optimisation is based on the observation that the size is small (and fixed), and that the structures are frequently iterated over in a linear fashion.
2013-08-19 09:52:32 +02:00
for (auto i = readQueue.begin() ; i != readQueue.end() ; ++i) {
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
DPRINTF(DRAM, "Read %lu\n", (*i)->addr);
}
DPRINTF(DRAM, "\n===RESP QUEUE===\n\n");
mem: Use STL deque in favour of list for DRAM queues This patch changes the data structure used for the DRAM read, write and response queues from an STL list to deque. This optimisation is based on the observation that the size is small (and fixed), and that the structures are frequently iterated over in a linear fashion.
2013-08-19 09:52:32 +02:00
for (auto i = respQueue.begin() ; i != respQueue.end() ; ++i) {
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
DPRINTF(DRAM, "Response %lu\n", (*i)->addr);
}
DPRINTF(DRAM, "\n===WRITE QUEUE===\n\n");
mem: Use STL deque in favour of list for DRAM queues This patch changes the data structure used for the DRAM read, write and response queues from an STL list to deque. This optimisation is based on the observation that the size is small (and fixed), and that the structures are frequently iterated over in a linear fashion.
2013-08-19 09:52:32 +02:00
for (auto i = writeQueue.begin() ; i != writeQueue.end() ; ++i) {
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
DPRINTF(DRAM, "Write %lu\n", (*i)->addr);
}
}
bool
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
DRAMCtrl::recvTimingReq(PacketPtr pkt)
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
{
mem: fix use after free issue in memories until 4-phase work complete.
2012-11-02 17:50:16 +01:00
/// @todo temporary hack to deal with memory corruption issues until
/// 4-phase transactions are complete
for (int x = 0; x < pendingDelete.size(); x++)
delete pendingDelete[x];
pendingDelete.clear();
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
// This is where we enter from the outside world
mem: SimpleDRAM variable naming and whitespace fixes This patch fixes a number of small cosmetic issues in the SimpleDRAM module. The most important change is to move the accounting of received packets to after the check is made if the packet should be retried or not. Thus, packets are only counted if they are actually accepted.
2013-03-01 19:20:24 +01:00
DPRINTF(DRAM, "recvTimingReq: request %s addr %lld size %d\n",
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
pkt->cmdString(), pkt->getAddr(), pkt->getSize());
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: SimpleDRAM variable naming and whitespace fixes This patch fixes a number of small cosmetic issues in the SimpleDRAM module. The most important change is to move the accounting of received packets to after the check is made if the packet should be retried or not. Thus, packets are only counted if they are actually accepted.
2013-03-01 19:20:24 +01:00
// simply drop inhibited packets for now
if (pkt->memInhibitAsserted()) {
mem: DRAM controller tidying up Minor tidying up and removing of redundant code, including the printing of queue state every million accesses.
2014-03-23 16:12:06 +01:00
DPRINTF(DRAM, "Inhibited packet -- Dropping it now\n");
mem: SimpleDRAM variable naming and whitespace fixes This patch fixes a number of small cosmetic issues in the SimpleDRAM module. The most important change is to move the accounting of received packets to after the check is made if the packet should be retried or not. Thus, packets are only counted if they are actually accepted.
2013-03-01 19:20:24 +01:00
pendingDelete.push_back(pkt);
return true;
}
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
// Calc avg gap between requests
if (prevArrival != 0) {
totGap += curTick() - prevArrival;
}
prevArrival = curTick();
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
// Find out how many dram packets a pkt translates to
// If the burst size is equal or larger than the pkt size, then a pkt
// translates to only one dram packet. Otherwise, a pkt translates to
// multiple dram packets
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
unsigned size = pkt->getSize();
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
unsigned offset = pkt->getAddr() & (burstSize - 1);
unsigned int dram_pkt_count = divCeil(offset + size, burstSize);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
// check local buffers and do not accept if full
if (pkt->isRead()) {
mem: SimpleDRAM variable naming and whitespace fixes This patch fixes a number of small cosmetic issues in the SimpleDRAM module. The most important change is to move the accounting of received packets to after the check is made if the packet should be retried or not. Thus, packets are only counted if they are actually accepted.
2013-03-01 19:20:24 +01:00
assert(size != 0);
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
if (readQueueFull(dram_pkt_count)) {
mem: SimpleDRAM variable naming and whitespace fixes This patch fixes a number of small cosmetic issues in the SimpleDRAM module. The most important change is to move the accounting of received packets to after the check is made if the packet should be retried or not. Thus, packets are only counted if they are actually accepted.
2013-03-01 19:20:24 +01:00
DPRINTF(DRAM, "Read queue full, not accepting\n");
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
// remember that we have to retry this port
retryRdReq = true;
numRdRetry++;
return false;
} else {
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
addToReadQueue(pkt, dram_pkt_count);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
readReqs++;
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
bytesReadSys += size;
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
}
} else if (pkt->isWrite()) {
mem: SimpleDRAM variable naming and whitespace fixes This patch fixes a number of small cosmetic issues in the SimpleDRAM module. The most important change is to move the accounting of received packets to after the check is made if the packet should be retried or not. Thus, packets are only counted if they are actually accepted.
2013-03-01 19:20:24 +01:00
assert(size != 0);
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
if (writeQueueFull(dram_pkt_count)) {
mem: SimpleDRAM variable naming and whitespace fixes This patch fixes a number of small cosmetic issues in the SimpleDRAM module. The most important change is to move the accounting of received packets to after the check is made if the packet should be retried or not. Thus, packets are only counted if they are actually accepted.
2013-03-01 19:20:24 +01:00
DPRINTF(DRAM, "Write queue full, not accepting\n");
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
// remember that we have to retry this port
retryWrReq = true;
numWrRetry++;
return false;
} else {
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
addToWriteQueue(pkt, dram_pkt_count);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
writeReqs++;
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
bytesWrittenSys += size;
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
}
} else {
DPRINTF(DRAM,"Neither read nor write, ignore timing\n");
neitherReadNorWrite++;
mem: Add static latency to the DRAM controller This patch adds a frontend and backend static latency to the DRAM controller by delaying the responses. Two parameters expressing the frontend and backend contributions in absolute time are added to the controller, and the appropriate latency is added to the responses when adding them to the (infinite) queued port for sending. For writes and reads that hit in the write buffer, only the frontend latency is added. For reads that are serviced by the DRAM, the static latency is the sum of the pipeline latencies of the entire frontend, backend and PHY. The default values are chosen based on having roughly 10 pipeline stages in total at 500 MHz. In the future, it would be sensible to make the controller use its clock and convert these latencies (and a few of the DRAM timings) to cycles.
2013-05-30 18:54:12 +02:00
accessAndRespond(pkt, 1);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
}
return true;
}
void
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
DRAMCtrl::processRespondEvent()
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
{
DPRINTF(DRAM,
"processRespondEvent(): Some req has reached its readyTime\n");
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
DRAMPacket* dram_pkt = respQueue.front();
if (dram_pkt->burstHelper) {
// it is a split packet
dram_pkt->burstHelper->burstsServiced++;
if (dram_pkt->burstHelper->burstsServiced ==
mem: DRAM controller tidying up Minor tidying up and removing of redundant code, including the printing of queue state every million accesses.
2014-03-23 16:12:06 +01:00
dram_pkt->burstHelper->burstCount) {
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
// we have now serviced all children packets of a system packet
// so we can now respond to the requester
// @todo we probably want to have a different front end and back
// end latency for split packets
accessAndRespond(dram_pkt->pkt, frontendLatency + backendLatency);
delete dram_pkt->burstHelper;
dram_pkt->burstHelper = NULL;
}
} else {
// it is not a split packet
accessAndRespond(dram_pkt->pkt, frontendLatency + backendLatency);
}
delete respQueue.front();
respQueue.pop_front();
if (!respQueue.empty()) {
assert(respQueue.front()->readyTime >= curTick());
assert(!respondEvent.scheduled());
schedule(respondEvent, respQueue.front()->readyTime);
} else {
// if there is nothing left in any queue, signal a drain
if (writeQueue.empty() && readQueue.empty() &&
drainManager) {
drainManager->signalDrainDone();
drainManager = NULL;
}
}
// We have made a location in the queue available at this point,
// so if there is a read that was forced to wait, retry now
if (retryRdReq) {
retryRdReq = false;
port.sendRetry();
}
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
}
void
mem: Make DRAM read/write switching less conservative 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-05-10 00:58:48 +02:00
DRAMCtrl::chooseNext(std::deque<DRAMPacket*>& queue)
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
{
mem: Make DRAM read/write switching less conservative 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-05-10 00:58:48 +02:00
// This method does the arbitration between requests. The chosen
// packet is simply moved to the head of the queue. The other
// methods know that this is the place to look. For example, with
// FCFS, this method does nothing
assert(!queue.empty());
if (queue.size() == 1) {
DPRINTF(DRAM, "Single request, nothing to do\n");
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
return;
}
if (memSchedPolicy == Enums::fcfs) {
// Do nothing, since the correct request is already head
} else if (memSchedPolicy == Enums::frfcfs) {
mem: Make DRAM read/write switching less conservative 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-05-10 00:58:48 +02:00
reorderQueue(queue);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
} else
panic("No scheduling policy chosen\n");
}
mem: Unify request selection for read and write queues This patch unifies the request selection across read and write queues for FR-FCFS scheduling policy. It also fixes the request selection code to prioritize the row hits present in the request queues over the selection based on earliest bank availability.
2013-11-01 16:56:27 +01:00
void
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
DRAMCtrl::reorderQueue(std::deque<DRAMPacket*>& queue)
mem: Unify request selection for read and write queues This patch unifies the request selection across read and write queues for FR-FCFS scheduling policy. It also fixes the request selection code to prioritize the row hits present in the request queues over the selection based on earliest bank availability.
2013-11-01 16:56:27 +01:00
{
// Only determine this when needed
uint64_t earliest_banks = 0;
// Search for row hits first, if no row hit is found then schedule the
// packet to one of the earliest banks available
bool found_earliest_pkt = false;
auto selected_pkt_it = queue.begin();
for (auto i = queue.begin(); i != queue.end() ; ++i) {
DRAMPacket* dram_pkt = *i;
const Bank& bank = dram_pkt->bankRef;
// Check if it is a row hit
if (bank.openRow == dram_pkt->row) {
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
// FCFS within the hits
mem: Unify request selection for read and write queues This patch unifies the request selection across read and write queues for FR-FCFS scheduling policy. It also fixes the request selection code to prioritize the row hits present in the request queues over the selection based on earliest bank availability.
2013-11-01 16:56:27 +01:00
DPRINTF(DRAM, "Row buffer hit\n");
selected_pkt_it = i;
break;
} else if (!found_earliest_pkt) {
// No row hit, go for first ready
if (earliest_banks == 0)
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
earliest_banks = minBankActAt(queue);
// simplistic approximation of when the bank can issue an
// activate, this is calculated in minBankActAt and could
// be cached
Tick act_at = bank.openRow == Bank::NO_ROW ?
bank.actAllowedAt :
std::max(bank.preAllowedAt, curTick()) + tRP;
mem: Unify request selection for read and write queues This patch unifies the request selection across read and write queues for FR-FCFS scheduling policy. It also fixes the request selection code to prioritize the row hits present in the request queues over the selection based on earliest bank availability.
2013-11-01 16:56:27 +01:00
// Bank is ready or is the first available bank
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
if (act_at <= curTick() ||
mem: Unify request selection for read and write queues This patch unifies the request selection across read and write queues for FR-FCFS scheduling policy. It also fixes the request selection code to prioritize the row hits present in the request queues over the selection based on earliest bank availability.
2013-11-01 16:56:27 +01:00
bits(earliest_banks, dram_pkt->bankId, dram_pkt->bankId)) {
// Remember the packet to be scheduled to one of the earliest
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
// banks available, FCFS amongst the earliest banks
mem: Unify request selection for read and write queues This patch unifies the request selection across read and write queues for FR-FCFS scheduling policy. It also fixes the request selection code to prioritize the row hits present in the request queues over the selection based on earliest bank availability.
2013-11-01 16:56:27 +01:00
selected_pkt_it = i;
found_earliest_pkt = true;
}
}
}
DRAMPacket* selected_pkt = *selected_pkt_it;
queue.erase(selected_pkt_it);
queue.push_front(selected_pkt);
}
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
void
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
DRAMCtrl::accessAndRespond(PacketPtr pkt, Tick static_latency)
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
{
DPRINTF(DRAM, "Responding to Address %lld.. ",pkt->getAddr());
bool needsResponse = pkt->needsResponse();
// do the actual memory access which also turns the packet into a
// response
access(pkt);
// turn packet around to go back to requester if response expected
if (needsResponse) {
// access already turned the packet into a response
assert(pkt->isResponse());
mem: Enforce strict use of busFirst- and busLastWordTime This patch adds a check to ensure that the delay incurred by the bus is not simply disregarded, but accounted for by someone. At this point, all the modules do is to zero it out, and no additional time is spent. This highlights where the bus timing is simply dropped instead of being paid for. As a follow up, the locations identified in this patch should add this additional time to the packets in one way or another. For now it simply acts as a sanity check and highlights where the delay is simply ignored. Since no time is added, all regressions remain the same.
2013-02-19 11:56:06 +01:00
// @todo someone should pay for this
pkt->busFirstWordDelay = pkt->busLastWordDelay = 0;
mem: Add static latency to the DRAM controller This patch adds a frontend and backend static latency to the DRAM controller by delaying the responses. Two parameters expressing the frontend and backend contributions in absolute time are added to the controller, and the appropriate latency is added to the responses when adding them to the (infinite) queued port for sending. For writes and reads that hit in the write buffer, only the frontend latency is added. For reads that are serviced by the DRAM, the static latency is the sum of the pipeline latencies of the entire frontend, backend and PHY. The default values are chosen based on having roughly 10 pipeline stages in total at 500 MHz. In the future, it would be sensible to make the controller use its clock and convert these latencies (and a few of the DRAM timings) to cycles.
2013-05-30 18:54:12 +02:00
// queue the packet in the response queue to be sent out after
// the static latency has passed
port.schedTimingResp(pkt, curTick() + static_latency);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
} else {
mem: Fix missing delete of packet in DRAM access This patch fixes a memory leak caused by not deleting packets that require no response.
2013-03-18 10:22:45 +01:00
// @todo the packet is going to be deleted, and the DRAMPacket
// is still having a pointer to it
pendingDelete.push_back(pkt);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
}
DPRINTF(DRAM, "Done\n");
return;
}
mem: Add tTAW and tFAW to the SimpleDRAM model This patch adds two additional scheduling constraints to the DRAM controller model, to constrain the activation rate. The two metrics are determine the size of the activation window in terms of the number of activates and the minimum time required for that number of activates. This maps to current DDRx, LPDDRx and WIOx standards that have either tFAW (4 activate window) or tTAW (2 activate window) scheduling constraints.
2013-01-31 13:49:14 +01:00
void
mem: Add tWR to DRAM activate and precharge constraints 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-10 00:58:48 +02:00
DRAMCtrl::activateBank(Tick act_tick, uint8_t rank, uint8_t bank,
uint16_t row, Bank& bank_ref)
mem: Add tTAW and tFAW to the SimpleDRAM model This patch adds two additional scheduling constraints to the DRAM controller model, to constrain the activation rate. The two metrics are determine the size of the activation window in terms of the number of activates and the minimum time required for that number of activates. This maps to current DDRx, LPDDRx and WIOx standards that have either tFAW (4 activate window) or tTAW (2 activate window) scheduling constraints.
2013-01-31 13:49:14 +01:00
{
mem: Make tXAW enforcement less conservative and per rank This patch changes the tXAW constraint so that it is enforced per rank rather than globally for all ranks in the channel. It also avoids using the bank freeAt to enforce the activation limit, as doing so also precludes performing any column or row command to the DRAM. Instead the patch introduces a new variable actAllowedAt for the banks and use this to track when a potential activation can occur.
2013-11-01 16:56:22 +01:00
assert(0 <= rank && rank < ranksPerChannel);
assert(actTicks[rank].size() == activationLimit);
mem: Add tTAW and tFAW to the SimpleDRAM model This patch adds two additional scheduling constraints to the DRAM controller model, to constrain the activation rate. The two metrics are determine the size of the activation window in terms of the number of activates and the minimum time required for that number of activates. This maps to current DDRx, LPDDRx and WIOx standards that have either tFAW (4 activate window) or tTAW (2 activate window) scheduling constraints.
2013-01-31 13:49:14 +01:00
DPRINTF(DRAM, "Activate at tick %d\n", act_tick);
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
// update the open row
mem: Add tWR to DRAM activate and precharge constraints 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-10 00:58:48 +02:00
assert(bank_ref.openRow == Bank::NO_ROW);
bank_ref.openRow = row;
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
// start counting anew, this covers both the case when we
// auto-precharged, and when this access is forced to
// precharge
mem: Add tWR to DRAM activate and precharge constraints 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-10 00:58:48 +02:00
bank_ref.bytesAccessed = 0;
bank_ref.rowAccesses = 0;
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
++numBanksActive;
assert(numBanksActive <= banksPerRank * ranksPerChannel);
DPRINTF(DRAM, "Activate bank at tick %lld, now got %d active\n",
act_tick, numBanksActive);
mem: Adding stats for DRAM power calculation This patch adds stats which are used for offline power calculation from the 'Micron Power Calculator' spreadsheet.
2013-11-01 16:56:28 +01:00
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
// The next access has to respect tRAS for this bank
bank_ref.preAllowedAt = act_tick + tRAS;
// Respect the row-to-column command delay
bank_ref.colAllowedAt = act_tick + tRCD;
mem: Add tRRD as a timing parameter for the DRAM controller This patch adds the tRRD parameter to the DRAM controller. With the recent addition of the actAllowedAt member for each bank, this addition is trivial.
2013-11-01 16:56:24 +01:00
// start by enforcing tRRD
for(int i = 0; i < banksPerRank; i++) {
mem: Add tWR to DRAM activate and precharge constraints 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-10 00:58:48 +02:00
// next activate to any bank in this rank must not happen
// before tRRD
banks[rank][i].actAllowedAt = std::max(act_tick + tRRD,
banks[rank][i].actAllowedAt);
mem: Add tRRD as a timing parameter for the DRAM controller This patch adds the tRRD parameter to the DRAM controller. With the recent addition of the actAllowedAt member for each bank, this addition is trivial.
2013-11-01 16:56:24 +01:00
}
mem: Add DRAM power states to the controller This patch adds power states to the controller. These states and the transitions can be used together with the Micron power model. As a more elaborate use-case, the transitions can be used to drive the DRAMPower tool. At the moment, the power-down modes are not used, and this patch simply serves to capture the idle, auto refresh and active modes. The patch adds a third state machine that interacts with the refresh state machine.
2014-05-10 00:58:48 +02:00
mem: Add tRRD as a timing parameter for the DRAM controller This patch adds the tRRD parameter to the DRAM controller. With the recent addition of the actAllowedAt member for each bank, this addition is trivial.
2013-11-01 16:56:24 +01:00
// next, we deal with tXAW, if the activation limit is disabled
// then we are done
mem: Make tXAW enforcement less conservative and per rank This patch changes the tXAW constraint so that it is enforced per rank rather than globally for all ranks in the channel. It also avoids using the bank freeAt to enforce the activation limit, as doing so also precludes performing any column or row command to the DRAM. Instead the patch introduces a new variable actAllowedAt for the banks and use this to track when a potential activation can occur.
2013-11-01 16:56:22 +01:00
if (actTicks[rank].empty())
mem: Allow disabling of tXAW through a 0 activation limit This patch fixes an issue where an activation limit of 0 was not allowed. With this patch, setting the limit to 0 simply disables the tXAW constraint.
2013-08-19 09:52:26 +02:00
return;
mem: Add tTAW and tFAW to the SimpleDRAM model This patch adds two additional scheduling constraints to the DRAM controller model, to constrain the activation rate. The two metrics are determine the size of the activation window in terms of the number of activates and the minimum time required for that number of activates. This maps to current DDRx, LPDDRx and WIOx standards that have either tFAW (4 activate window) or tTAW (2 activate window) scheduling constraints.
2013-01-31 13:49:14 +01:00
// sanity check
mem: Make tXAW enforcement less conservative and per rank This patch changes the tXAW constraint so that it is enforced per rank rather than globally for all ranks in the channel. It also avoids using the bank freeAt to enforce the activation limit, as doing so also precludes performing any column or row command to the DRAM. Instead the patch introduces a new variable actAllowedAt for the banks and use this to track when a potential activation can occur.
2013-11-01 16:56:22 +01:00
if (actTicks[rank].back() && (act_tick - actTicks[rank].back()) < tXAW) {
mem: Add tWR to DRAM activate and precharge constraints 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-10 00:58:48 +02:00
panic("Got %d activates in window %d (%llu - %llu) which is smaller "
"than %llu\n", activationLimit, act_tick - actTicks[rank].back(),
act_tick, actTicks[rank].back(), tXAW);
mem: Add tTAW and tFAW to the SimpleDRAM model This patch adds two additional scheduling constraints to the DRAM controller model, to constrain the activation rate. The two metrics are determine the size of the activation window in terms of the number of activates and the minimum time required for that number of activates. This maps to current DDRx, LPDDRx and WIOx standards that have either tFAW (4 activate window) or tTAW (2 activate window) scheduling constraints.
2013-01-31 13:49:14 +01:00
}
// shift the times used for the book keeping, the last element
// (highest index) is the oldest one and hence the lowest value
mem: Make tXAW enforcement less conservative and per rank This patch changes the tXAW constraint so that it is enforced per rank rather than globally for all ranks in the channel. It also avoids using the bank freeAt to enforce the activation limit, as doing so also precludes performing any column or row command to the DRAM. Instead the patch introduces a new variable actAllowedAt for the banks and use this to track when a potential activation can occur.
2013-11-01 16:56:22 +01:00
actTicks[rank].pop_back();
mem: Add tTAW and tFAW to the SimpleDRAM model This patch adds two additional scheduling constraints to the DRAM controller model, to constrain the activation rate. The two metrics are determine the size of the activation window in terms of the number of activates and the minimum time required for that number of activates. This maps to current DDRx, LPDDRx and WIOx standards that have either tFAW (4 activate window) or tTAW (2 activate window) scheduling constraints.
2013-01-31 13:49:14 +01:00
// record an new activation (in the future)
mem: Make tXAW enforcement less conservative and per rank This patch changes the tXAW constraint so that it is enforced per rank rather than globally for all ranks in the channel. It also avoids using the bank freeAt to enforce the activation limit, as doing so also precludes performing any column or row command to the DRAM. Instead the patch introduces a new variable actAllowedAt for the banks and use this to track when a potential activation can occur.
2013-11-01 16:56:22 +01:00
actTicks[rank].push_front(act_tick);
mem: Add tTAW and tFAW to the SimpleDRAM model This patch adds two additional scheduling constraints to the DRAM controller model, to constrain the activation rate. The two metrics are determine the size of the activation window in terms of the number of activates and the minimum time required for that number of activates. This maps to current DDRx, LPDDRx and WIOx standards that have either tFAW (4 activate window) or tTAW (2 activate window) scheduling constraints.
2013-01-31 13:49:14 +01:00
// cannot activate more than X times in time window tXAW, push the
// next one (the X + 1'st activate) to be tXAW away from the
// oldest in our window of X
mem: Make tXAW enforcement less conservative and per rank This patch changes the tXAW constraint so that it is enforced per rank rather than globally for all ranks in the channel. It also avoids using the bank freeAt to enforce the activation limit, as doing so also precludes performing any column or row command to the DRAM. Instead the patch introduces a new variable actAllowedAt for the banks and use this to track when a potential activation can occur.
2013-11-01 16:56:22 +01:00
if (actTicks[rank].back() && (act_tick - actTicks[rank].back()) < tXAW) {
mem: Add tTAW and tFAW to the SimpleDRAM model This patch adds two additional scheduling constraints to the DRAM controller model, to constrain the activation rate. The two metrics are determine the size of the activation window in terms of the number of activates and the minimum time required for that number of activates. This maps to current DDRx, LPDDRx and WIOx standards that have either tFAW (4 activate window) or tTAW (2 activate window) scheduling constraints.
2013-01-31 13:49:14 +01:00
DPRINTF(DRAM, "Enforcing tXAW with X = %d, next activate no earlier "
mem: Add tWR to DRAM activate and precharge constraints 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-10 00:58:48 +02:00
"than %llu\n", activationLimit, actTicks[rank].back() + tXAW);
mem: Add tTAW and tFAW to the SimpleDRAM model This patch adds two additional scheduling constraints to the DRAM controller model, to constrain the activation rate. The two metrics are determine the size of the activation window in terms of the number of activates and the minimum time required for that number of activates. This maps to current DDRx, LPDDRx and WIOx standards that have either tFAW (4 activate window) or tTAW (2 activate window) scheduling constraints.
2013-01-31 13:49:14 +01:00
for(int j = 0; j < banksPerRank; j++)
// next activate must not happen before end of window
mem: Add tWR to DRAM activate and precharge constraints 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-10 00:58:48 +02:00
banks[rank][j].actAllowedAt =
std::max(actTicks[rank].back() + tXAW,
banks[rank][j].actAllowedAt);
mem: Add tTAW and tFAW to the SimpleDRAM model This patch adds two additional scheduling constraints to the DRAM controller model, to constrain the activation rate. The two metrics are determine the size of the activation window in terms of the number of activates and the minimum time required for that number of activates. This maps to current DDRx, LPDDRx and WIOx standards that have either tFAW (4 activate window) or tTAW (2 activate window) scheduling constraints.
2013-01-31 13:49:14 +01:00
}
mem: Add DRAM power states to the controller This patch adds power states to the controller. These states and the transitions can be used together with the Micron power model. As a more elaborate use-case, the transitions can be used to drive the DRAMPower tool. At the moment, the power-down modes are not used, and this patch simply serves to capture the idle, auto refresh and active modes. The patch adds a third state machine that interacts with the refresh state machine.
2014-05-10 00:58:48 +02:00
// at the point when this activate takes place, make sure we
// transition to the active power state
if (!activateEvent.scheduled())
schedule(activateEvent, act_tick);
else if (activateEvent.when() > act_tick)
// move it sooner in time
reschedule(activateEvent, act_tick);
}
void
DRAMCtrl::processActivateEvent()
{
// we should transition to the active state as soon as any bank is active
if (pwrState != PWR_ACT)
// note that at this point numBanksActive could be back at
// zero again due to a precharge scheduled in the future
schedulePowerEvent(PWR_ACT, curTick());
mem: Add tTAW and tFAW to the SimpleDRAM model This patch adds two additional scheduling constraints to the DRAM controller model, to constrain the activation rate. The two metrics are determine the size of the activation window in terms of the number of activates and the minimum time required for that number of activates. This maps to current DDRx, LPDDRx and WIOx standards that have either tFAW (4 activate window) or tTAW (2 activate window) scheduling constraints.
2013-01-31 13:49:14 +01:00
}
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
void
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
DRAMCtrl::prechargeBank(Bank& bank, Tick pre_at)
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
{
// make sure the bank has an open row
assert(bank.openRow != Bank::NO_ROW);
// sample the bytes per activate here since we are closing
// the page
bytesPerActivate.sample(bank.bytesAccessed);
bank.openRow = Bank::NO_ROW;
mem: Add precharge all (PREA) to the DRAM controller This patch adds the basic ingredients for a precharge all operation, to be used in conjunction with DRAM power modelling. Currently we do not try and apply any cleverness when precharging all banks, thus even if only a single bank is open we use PREA as opposed to PRE. At the moment we only have a single tRP (tRPpb), and do not model the slightly longer all-bank precharge constraint (tRPab).
2014-05-10 00:58:48 +02:00
// no precharge allowed before this one
bank.preAllowedAt = pre_at;
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
Tick pre_done_at = pre_at + tRP;
bank.actAllowedAt = std::max(bank.actAllowedAt, pre_done_at);
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
assert(numBanksActive != 0);
--numBanksActive;
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
DPRINTF(DRAM, "Precharging bank at tick %lld, now got %d active\n",
pre_at, numBanksActive);
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
mem: Add DRAM power states to the controller This patch adds power states to the controller. These states and the transitions can be used together with the Micron power model. As a more elaborate use-case, the transitions can be used to drive the DRAMPower tool. At the moment, the power-down modes are not used, and this patch simply serves to capture the idle, auto refresh and active modes. The patch adds a third state machine that interacts with the refresh state machine.
2014-05-10 00:58:48 +02:00
// if we look at the current number of active banks we might be
// tempted to think the DRAM is now idle, however this can be
// undone by an activate that is scheduled to happen before we
// would have reached the idle state, so schedule an event and
// rather check once we actually make it to the point in time when
// the (last) precharge takes place
if (!prechargeEvent.scheduled())
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
schedule(prechargeEvent, pre_done_at);
else if (prechargeEvent.when() < pre_done_at)
reschedule(prechargeEvent, pre_done_at);
mem: Add DRAM power states to the controller This patch adds power states to the controller. These states and the transitions can be used together with the Micron power model. As a more elaborate use-case, the transitions can be used to drive the DRAMPower tool. At the moment, the power-down modes are not used, and this patch simply serves to capture the idle, auto refresh and active modes. The patch adds a third state machine that interacts with the refresh state machine.
2014-05-10 00:58:48 +02:00
}
void
DRAMCtrl::processPrechargeEvent()
{
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
// if we reached zero, then special conditions apply as we track
// if all banks are precharged for the power models
if (numBanksActive == 0) {
mem: Add DRAM power states to the controller This patch adds power states to the controller. These states and the transitions can be used together with the Micron power model. As a more elaborate use-case, the transitions can be used to drive the DRAMPower tool. At the moment, the power-down modes are not used, and this patch simply serves to capture the idle, auto refresh and active modes. The patch adds a third state machine that interacts with the refresh state machine.
2014-05-10 00:58:48 +02:00
// we should transition to the idle state when the last bank
// is precharged
schedulePowerEvent(PWR_IDLE, curTick());
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
}
}
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
void
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
DRAMCtrl::doDRAMAccess(DRAMPacket* dram_pkt)
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
{
DPRINTF(DRAM, "Timing access to addr %lld, rank/bank/row %d %d %d\n",
dram_pkt->addr, dram_pkt->rank, dram_pkt->bank, dram_pkt->row);
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
// get the bank
Bank& bank = dram_pkt->bankRef;
mem: Add tWR to DRAM activate and precharge constraints 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-10 00:58:48 +02:00
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
// for the state we need to track if it is a row hit or not
bool row_hit = true;
mem: Add tWR to DRAM activate and precharge constraints 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-10 00:58:48 +02:00
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
// respect any constraints on the command (e.g. tRCD or tCCD)
Tick cmd_at = std::max(bank.colAllowedAt, curTick());
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
// Determine the access latency and update the bank state
if (bank.openRow == dram_pkt->row) {
// nothing to do
mem: Merge DRAM page-management calculations This patch treats the closed page policy as yet another case of auto-precharging, and thus merges the code with that used for the other policies.
2014-05-10 00:58:48 +02:00
} else {
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
row_hit = false;
mem: Merge DRAM page-management calculations This patch treats the closed page policy as yet another case of auto-precharging, and thus merges the code with that used for the other policies.
2014-05-10 00:58:48 +02:00
// If there is a page open, precharge it.
if (bank.openRow != Bank::NO_ROW) {
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
prechargeBank(bank, std::max(bank.preAllowedAt, curTick()));
mem: Add tTAW and tFAW to the SimpleDRAM model This patch adds two additional scheduling constraints to the DRAM controller model, to constrain the activation rate. The two metrics are determine the size of the activation window in terms of the number of activates and the minimum time required for that number of activates. This maps to current DDRx, LPDDRx and WIOx standards that have either tFAW (4 activate window) or tTAW (2 activate window) scheduling constraints.
2013-01-31 13:49:14 +01:00
}
mem: Add a simple adaptive version of the open-page policy This patch adds a basic adaptive version of the open-page policy that guides the decision to keep open or close by looking at the contents of the controller queues. If no row hits are found, and bank conflicts are present, then the row is closed by means of an auto precharge. This is a well-known technique that should improve performance in most use-cases.
2013-11-01 16:56:26 +01:00
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
// next we need to account for the delay in activating the
// page
Tick act_tick = std::max(bank.actAllowedAt, curTick());
mem: Limit the accesses to a page before forcing a precharge This patch adds a basic starvation-prevention mechanism where a DRAM page is forced to close after a certain number of accesses. The limit is combined with the open and open-adaptive page policy and if reached causes an auto-precharge.
2014-03-23 16:12:03 +01:00
mem: Add tWR to DRAM activate and precharge constraints 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-10 00:58:48 +02:00
// Record the activation and deal with all the global timing
// constraints caused be a new activation (tRRD and tXAW)
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
activateBank(act_tick, dram_pkt->rank, dram_pkt->bank,
mem: Add tWR to DRAM activate and precharge constraints 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-10 00:58:48 +02:00
dram_pkt->row, bank);
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
// issue the command as early as possible
cmd_at = bank.colAllowedAt;
mem: Add tWR to DRAM activate and precharge constraints 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-10 00:58:48 +02:00
}
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
// we need to wait until the bus is available before we can issue
// the command
cmd_at = std::max(cmd_at, busBusyUntil - tCL);
// update the packet ready time
dram_pkt->readyTime = cmd_at + tCL + tBURST;
// only one burst can use the bus at any one point in time
assert(dram_pkt->readyTime - busBusyUntil >= tBURST);
// not strictly necessary, but update the time for the next
// read/write (add a max with tCCD here)
bank.colAllowedAt = cmd_at + tBURST;
mem: Add tRTP to the DRAM controller 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-10 00:58:48 +02:00
// If this is a write, we also need to respect the write recovery
// time before a precharge, in the case of a read, respect the
// read to precharge constraint
bank.preAllowedAt = std::max(bank.preAllowedAt,
dram_pkt->isRead ? cmd_at + tRTP :
dram_pkt->readyTime + tWR);
mem: Fix bug in DRAM bytes per activate This patch ensures that we do not sample the bytes per activate when the row has already been closed.
2014-03-23 16:12:05 +01:00
mem: Merge DRAM page-management calculations This patch treats the closed page policy as yet another case of auto-precharging, and thus merges the code with that used for the other policies.
2014-05-10 00:58:48 +02:00
// increment the bytes accessed and the accesses per row
bank.bytesAccessed += burstSize;
++bank.rowAccesses;
// if we reached the max, then issue with an auto-precharge
bool auto_precharge = pageMgmt == Enums::close ||
bank.rowAccesses == maxAccessesPerRow;
// if we did not hit the limit, we might still want to
// auto-precharge
if (!auto_precharge &&
(pageMgmt == Enums::open_adaptive ||
pageMgmt == Enums::close_adaptive)) {
// a twist on the open and close page policies:
// 1) open_adaptive page policy does not blindly keep the
// page open, but close it if there are no row hits, and there
// are bank conflicts in the queue
// 2) close_adaptive page policy does not blindly close the
// page, but closes it only if there are no row hits in the queue.
// In this case, only force an auto precharge when there
// are no same page hits in the queue
bool got_more_hits = false;
bool got_bank_conflict = false;
// either look at the read queue or write queue
const deque<DRAMPacket*>& queue = dram_pkt->isRead ? readQueue :
writeQueue;
auto p = queue.begin();
// make sure we are not considering the packet that we are
// currently dealing with (which is the head of the queue)
++p;
// keep on looking until we have found required condition or
// reached the end
while (!(got_more_hits &&
(got_bank_conflict || pageMgmt == Enums::close_adaptive)) &&
p != queue.end()) {
bool same_rank_bank = (dram_pkt->rank == (*p)->rank) &&
(dram_pkt->bank == (*p)->bank);
bool same_row = dram_pkt->row == (*p)->row;
got_more_hits |= same_rank_bank && same_row;
got_bank_conflict |= same_rank_bank && !same_row;
++p;
mem: Add a simple adaptive version of the open-page policy This patch adds a basic adaptive version of the open-page policy that guides the decision to keep open or close by looking at the contents of the controller queues. If no row hits are found, and bank conflicts are present, then the row is closed by means of an auto precharge. This is a well-known technique that should improve performance in most use-cases.
2013-11-01 16:56:26 +01:00
}
mem: Merge DRAM page-management calculations This patch treats the closed page policy as yet another case of auto-precharging, and thus merges the code with that used for the other policies.
2014-05-10 00:58:48 +02:00
// auto pre-charge when either
// 1) open_adaptive policy, we have not got any more hits, and
// have a bank conflict
// 2) close_adaptive policy and we have not got any more hits
auto_precharge = !got_more_hits &&
(got_bank_conflict || pageMgmt == Enums::close_adaptive);
}
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
mem: Merge DRAM page-management calculations This patch treats the closed page policy as yet another case of auto-precharging, and thus merges the code with that used for the other policies.
2014-05-10 00:58:48 +02:00
// if this access should use auto-precharge, then we are
// closing the row
if (auto_precharge) {
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
prechargeBank(bank, std::max(curTick(), bank.preAllowedAt));
mem: Add tRAS parameter to the DRAM controller model This patch adds an explicit tRAS parameter to the DRAM controller model. Previously tRAS was, rather conservatively, assumed to be tRCD + tCL + tRP. The default values for tRAS are chosen to match the previous behaviour and will be updated later.
2013-11-01 16:56:16 +01:00
mem: Merge DRAM page-management calculations This patch treats the closed page policy as yet another case of auto-precharging, and thus merges the code with that used for the other policies.
2014-05-10 00:58:48 +02:00
DPRINTF(DRAM, "Auto-precharged bank: %d\n", dram_pkt->bankId);
}
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
// Update bus state
busBusyUntil = dram_pkt->readyTime;
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
DPRINTF(DRAM, "Access to %lld, ready at %lld bus busy until %lld.\n",
dram_pkt->addr, dram_pkt->readyTime, busBusyUntil);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Make DRAM read/write switching less conservative 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-05-10 00:58:48 +02:00
// Update the minimum timing between the requests, this is a
// conservative estimate of when we have to schedule the next
// request to not introduce any unecessary bubbles. In most cases
// we will wake up sooner than we have to.
nextReqTime = busBusyUntil - (tRP + tRCD + tCL);
mem: Just-in-time write scheduling in DRAM controller This patch removes the untimed while loop in the write scheduling mechanism and now schedule commands taking into account the minimum timing constraint. It also introduces an optimization to track write queue size and switch from writes to reads if the number of write requests fall below write low threshold.
2013-11-01 16:56:25 +01:00
mem: Make DRAM read/write switching less conservative 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-05-10 00:58:48 +02:00
// Update the stats and schedule the next request
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
if (dram_pkt->isRead) {
mem: Track DRAM read/write switching and add hysteresis This patch adds stats for tracking the number of reads/writes per bus turn around, and also adds hysteresis to the write-to-read switching to ensure that the queue does not oscilate around the low threshold.
2014-03-23 16:12:14 +01:00
++readsThisTime;
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
if (row_hit)
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
readRowHits++;
bytesReadDRAM += burstSize;
perBankRdBursts[dram_pkt->bankId]++;
mem: Make DRAM read/write switching less conservative 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-05-10 00:58:48 +02:00
// Update latency stats
totMemAccLat += dram_pkt->readyTime - dram_pkt->entryTime;
totBusLat += tBURST;
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
totQLat += cmd_at - dram_pkt->entryTime;
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
} else {
mem: Track DRAM read/write switching and add hysteresis This patch adds stats for tracking the number of reads/writes per bus turn around, and also adds hysteresis to the write-to-read switching to ensure that the queue does not oscilate around the low threshold.
2014-03-23 16:12:14 +01:00
++writesThisTime;
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
if (row_hit)
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
writeRowHits++;
bytesWritten += burstSize;
perBankWrBursts[dram_pkt->bankId]++;
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
}
}
void
mem: Make DRAM read/write switching less conservative 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-05-10 00:58:48 +02:00
DRAMCtrl::processNextReqEvent()
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
{
mem: Make DRAM read/write switching less conservative 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-05-10 00:58:48 +02:00
if (busState == READ_TO_WRITE) {
DPRINTF(DRAM, "Switching to writes after %d reads with %d reads "
"waiting\n", readsThisTime, readQueue.size());
// sample and reset the read-related stats as we are now
// transitioning to writes, and all reads are done
rdPerTurnAround.sample(readsThisTime);
readsThisTime = 0;
// now proceed to do the actual writes
busState = WRITE;
} else if (busState == WRITE_TO_READ) {
DPRINTF(DRAM, "Switching to reads after %d writes with %d writes "
"waiting\n", writesThisTime, writeQueue.size());
wrPerTurnAround.sample(writesThisTime);
writesThisTime = 0;
busState = READ;
}
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
if (refreshState != REF_IDLE) {
// if a refresh waiting for this event loop to finish, then hand
// over now, and do not schedule a new nextReqEvent
if (refreshState == REF_DRAIN) {
DPRINTF(DRAM, "Refresh drain done, now precharging\n");
refreshState = REF_PRE;
// hand control back to the refresh event loop
schedule(refreshEvent, curTick());
}
// let the refresh finish before issuing any further requests
return;
}
mem: Make DRAM read/write switching less conservative 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-05-10 00:58:48 +02:00
// when we get here it is either a read or a write
if (busState == READ) {
// track if we should switch or not
bool switch_to_writes = false;
if (readQueue.empty()) {
// In the case there is no read request to go next,
// trigger writes if we have passed the low threshold (or
// if we are draining)
if (!writeQueue.empty() &&
(drainManager || writeQueue.size() > writeLowThreshold)) {
switch_to_writes = true;
} else {
// check if we are drained
if (respQueue.empty () && drainManager) {
drainManager->signalDrainDone();
drainManager = NULL;
}
// nothing to do, not even any point in scheduling an
// event for the next request
return;
}
} else {
// Figure out which read request goes next, and move it to the
// front of the read queue
chooseNext(readQueue);
mem: Simplify DRAM response scheduling This patch simplifies the DRAM response scheduling based on the assumption that they are always returned in order.
2014-05-10 00:58:48 +02:00
DRAMPacket* dram_pkt = readQueue.front();
doDRAMAccess(dram_pkt);
mem: Make DRAM read/write switching less conservative 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-05-10 00:58:48 +02:00
// At this point we're done dealing with the request
mem: Simplify DRAM response scheduling This patch simplifies the DRAM response scheduling based on the assumption that they are always returned in order.
2014-05-10 00:58:48 +02:00
readQueue.pop_front();
// sanity check
assert(dram_pkt->size <= burstSize);
assert(dram_pkt->readyTime >= curTick());
// Insert into response queue. It will be sent back to the
// requestor at its readyTime
if (respQueue.empty()) {
assert(!respondEvent.scheduled());
schedule(respondEvent, dram_pkt->readyTime);
} else {
assert(respQueue.back()->readyTime <= dram_pkt->readyTime);
assert(respondEvent.scheduled());
}
respQueue.push_back(dram_pkt);
mem: Make DRAM read/write switching less conservative 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-05-10 00:58:48 +02:00
// we have so many writes that we have to transition
if (writeQueue.size() > writeHighThreshold) {
switch_to_writes = true;
}
}
// switching to writes, either because the read queue is empty
// and the writes have passed the low threshold (or we are
// draining), or because the writes hit the hight threshold
if (switch_to_writes) {
// transition to writing
busState = READ_TO_WRITE;
// add a bubble to the data bus, as defined by the
// tRTW parameter
busBusyUntil += tRTW;
// update the minimum timing between the requests,
// this shifts us back in time far enough to do any
// bank preparation
nextReqTime = busBusyUntil - (tRP + tRCD + tCL);
}
mem: Fix DRAM draining to ensure write queue is empty This patch fixes the draining of the SimpleDRAM controller model. The controller performs buffering of writes and normally there is no need to ever empty the write buffer (if you have a fast on-chip memory, then use it). The patch adds checks to ensure the write buffer is drained when the controller is asked to do so.
2012-11-08 10:25:06 +01:00
} else {
mem: Make DRAM read/write switching less conservative 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-05-10 00:58:48 +02:00
chooseNext(writeQueue);
DRAMPacket* dram_pkt = writeQueue.front();
// sanity check
assert(dram_pkt->size <= burstSize);
doDRAMAccess(dram_pkt);
writeQueue.pop_front();
delete dram_pkt;
// If we emptied the write queue, or got sufficiently below the
// threshold (using the minWritesPerSwitch as the hysteresis) and
// are not draining, or we have reads waiting and have done enough
// writes, then switch to reads.
if (writeQueue.empty() ||
(writeQueue.size() + minWritesPerSwitch < writeLowThreshold &&
!drainManager) ||
(!readQueue.empty() && writesThisTime >= minWritesPerSwitch)) {
// turn the bus back around for reads again
busState = WRITE_TO_READ;
// note that the we switch back to reads also in the idle
// case, which eventually will check for any draining and
// also pause any further scheduling if there is really
// nothing to do
// here we get a bit creative and shift the bus busy time not
// just the tWTR, but also a CAS latency to capture the fact
// that we are allowed to prepare a new bank, but not issue a
// read command until after tWTR, in essence we capture a
// bubble on the data bus that is tWTR + tCL
busBusyUntil += tWTR + tCL;
// update the minimum timing between the requests, this shifts
// us back in time far enough to do any bank preparation
nextReqTime = busBusyUntil - (tRP + tRCD + tCL);
}
}
schedule(nextReqEvent, std::max(nextReqTime, curTick()));
// If there is space available and we have writes waiting then let
// them retry. This is done here to ensure that the retry does not
// cause a nextReqEvent to be scheduled before we do so as part of
// the next request processing
if (retryWrReq && writeQueue.size() < writeBufferSize) {
retryWrReq = false;
port.sendRetry();
mem: Fix DRAM draining to ensure write queue is empty This patch fixes the draining of the SimpleDRAM controller model. The controller performs buffering of writes and normally there is no need to ever empty the write buffer (if you have a fast on-chip memory, then use it). The patch adds checks to ensure the write buffer is drained when the controller is asked to do so.
2012-11-08 10:25:06 +01:00
}
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
}
mem: Pick the next DRAM request based on bank availability This patch changes the FCFS bit of FR-FCFS such that requests that target the earliest available bank are picked first (as suggested in the original work on FR-FCFS by Rixner et al). To accommodate this we add functionality to identify a bank through a one-dimensional identifier (bank id). The member names of the DRAMPacket are also update to match the style guide.
2013-11-01 16:56:20 +01:00
uint64_t
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
DRAMCtrl::minBankActAt(const deque<DRAMPacket*>& queue) const
mem: Pick the next DRAM request based on bank availability This patch changes the FCFS bit of FR-FCFS such that requests that target the earliest available bank are picked first (as suggested in the original work on FR-FCFS by Rixner et al). To accommodate this we add functionality to identify a bank through a one-dimensional identifier (bank id). The member names of the DRAMPacket are also update to match the style guide.
2013-11-01 16:56:20 +01:00
{
uint64_t bank_mask = 0;
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
Tick min_act_at = MaxTick;
mem: Pick the next DRAM request based on bank availability This patch changes the FCFS bit of FR-FCFS such that requests that target the earliest available bank are picked first (as suggested in the original work on FR-FCFS by Rixner et al). To accommodate this we add functionality to identify a bank through a one-dimensional identifier (bank id). The member names of the DRAMPacket are also update to match the style guide.
2013-11-01 16:56:20 +01:00
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
// deterimne if we have queued transactions targetting a
mem: Pick the next DRAM request based on bank availability This patch changes the FCFS bit of FR-FCFS such that requests that target the earliest available bank are picked first (as suggested in the original work on FR-FCFS by Rixner et al). To accommodate this we add functionality to identify a bank through a one-dimensional identifier (bank id). The member names of the DRAMPacket are also update to match the style guide.
2013-11-01 16:56:20 +01:00
// bank in question
vector<bool> got_waiting(ranksPerChannel * banksPerRank, false);
for (auto p = queue.begin(); p != queue.end(); ++p) {
got_waiting[(*p)->bankId] = true;
}
for (int i = 0; i < ranksPerChannel; i++) {
for (int j = 0; j < banksPerRank; j++) {
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
uint8_t bank_id = i * banksPerRank + j;
mem: Pick the next DRAM request based on bank availability This patch changes the FCFS bit of FR-FCFS such that requests that target the earliest available bank are picked first (as suggested in the original work on FR-FCFS by Rixner et al). To accommodate this we add functionality to identify a bank through a one-dimensional identifier (bank id). The member names of the DRAMPacket are also update to match the style guide.
2013-11-01 16:56:20 +01:00
// if we have waiting requests for the bank, and it is
// amongst the first available, update the mask
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
if (got_waiting[bank_id]) {
// simplistic approximation of when the bank can issue
// an activate, ignoring any rank-to-rank switching
// cost
Tick act_at = banks[i][j].openRow == Bank::NO_ROW ?
banks[i][j].actAllowedAt :
std::max(banks[i][j].preAllowedAt, curTick()) + tRP;
if (act_at <= min_act_at) {
// reset bank mask if new minimum is found
if (act_at < min_act_at)
bank_mask = 0;
// set the bit corresponding to the available bank
replaceBits(bank_mask, bank_id, bank_id, 1);
min_act_at = act_at;
}
mem: Pick the next DRAM request based on bank availability This patch changes the FCFS bit of FR-FCFS such that requests that target the earliest available bank are picked first (as suggested in the original work on FR-FCFS by Rixner et al). To accommodate this we add functionality to identify a bank through a one-dimensional identifier (bank id). The member names of the DRAMPacket are also update to match the style guide.
2013-11-01 16:56:20 +01:00
}
}
}
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
mem: Pick the next DRAM request based on bank availability This patch changes the FCFS bit of FR-FCFS such that requests that target the earliest available bank are picked first (as suggested in the original work on FR-FCFS by Rixner et al). To accommodate this we add functionality to identify a bank through a one-dimensional identifier (bank id). The member names of the DRAMPacket are also update to match the style guide.
2013-11-01 16:56:20 +01:00
return bank_mask;
}
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
void
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
DRAMCtrl::processRefreshEvent()
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
{
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
// when first preparing the refresh, remember when it was due
if (refreshState == REF_IDLE) {
// remember when the refresh is due
refreshDueAt = curTick();
// proceed to drain
refreshState = REF_DRAIN;
DPRINTF(DRAM, "Refresh due\n");
}
// let any scheduled read or write go ahead, after which it will
// hand control back to this event loop
if (refreshState == REF_DRAIN) {
if (nextReqEvent.scheduled()) {
// hand control over to the request loop until it is
// evaluated next
DPRINTF(DRAM, "Refresh awaiting draining\n");
return;
} else {
refreshState = REF_PRE;
}
}
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
// at this point, ensure that all banks are precharged
if (refreshState == REF_PRE) {
mem: Add DRAM power states to the controller This patch adds power states to the controller. These states and the transitions can be used together with the Micron power model. As a more elaborate use-case, the transitions can be used to drive the DRAMPower tool. At the moment, the power-down modes are not used, and this patch simply serves to capture the idle, auto refresh and active modes. The patch adds a third state machine that interacts with the refresh state machine.
2014-05-10 00:58:48 +02:00
// precharge any active bank if we are not already in the idle
// state
if (pwrState != PWR_IDLE) {
mem: Add precharge all (PREA) to the DRAM controller This patch adds the basic ingredients for a precharge all operation, to be used in conjunction with DRAM power modelling. Currently we do not try and apply any cleverness when precharging all banks, thus even if only a single bank is open we use PREA as opposed to PRE. At the moment we only have a single tRP (tRPpb), and do not model the slightly longer all-bank precharge constraint (tRPab).
2014-05-10 00:58:48 +02:00
// at the moment, we use a precharge all even if there is
// only a single bank open
mem: Add DRAM power states to the controller This patch adds power states to the controller. These states and the transitions can be used together with the Micron power model. As a more elaborate use-case, the transitions can be used to drive the DRAMPower tool. At the moment, the power-down modes are not used, and this patch simply serves to capture the idle, auto refresh and active modes. The patch adds a third state machine that interacts with the refresh state machine.
2014-05-10 00:58:48 +02:00
DPRINTF(DRAM, "Precharging all\n");
mem: Add precharge all (PREA) to the DRAM controller This patch adds the basic ingredients for a precharge all operation, to be used in conjunction with DRAM power modelling. Currently we do not try and apply any cleverness when precharging all banks, thus even if only a single bank is open we use PREA as opposed to PRE. At the moment we only have a single tRP (tRPpb), and do not model the slightly longer all-bank precharge constraint (tRPab).
2014-05-10 00:58:48 +02:00
// first determine when we can precharge
Tick pre_at = curTick();
mem: Add DRAM power states to the controller This patch adds power states to the controller. These states and the transitions can be used together with the Micron power model. As a more elaborate use-case, the transitions can be used to drive the DRAMPower tool. At the moment, the power-down modes are not used, and this patch simply serves to capture the idle, auto refresh and active modes. The patch adds a third state machine that interacts with the refresh state machine.
2014-05-10 00:58:48 +02:00
for (int i = 0; i < ranksPerChannel; i++) {
for (int j = 0; j < banksPerRank; j++) {
mem: Add precharge all (PREA) to the DRAM controller This patch adds the basic ingredients for a precharge all operation, to be used in conjunction with DRAM power modelling. Currently we do not try and apply any cleverness when precharging all banks, thus even if only a single bank is open we use PREA as opposed to PRE. At the moment we only have a single tRP (tRPpb), and do not model the slightly longer all-bank precharge constraint (tRPab).
2014-05-10 00:58:48 +02:00
// respect both causality and any existing bank
// constraints, some banks could already have a
// (auto) precharge scheduled
pre_at = std::max(banks[i][j].preAllowedAt, pre_at);
}
}
mem: Add DRAM power states to the controller This patch adds power states to the controller. These states and the transitions can be used together with the Micron power model. As a more elaborate use-case, the transitions can be used to drive the DRAMPower tool. At the moment, the power-down modes are not used, and this patch simply serves to capture the idle, auto refresh and active modes. The patch adds a third state machine that interacts with the refresh state machine.
2014-05-10 00:58:48 +02:00
mem: Add precharge all (PREA) to the DRAM controller This patch adds the basic ingredients for a precharge all operation, to be used in conjunction with DRAM power modelling. Currently we do not try and apply any cleverness when precharging all banks, thus even if only a single bank is open we use PREA as opposed to PRE. At the moment we only have a single tRP (tRPpb), and do not model the slightly longer all-bank precharge constraint (tRPab).
2014-05-10 00:58:48 +02:00
// make sure all banks are precharged, and for those that
// already are, update their availability
Tick act_allowed_at = pre_at + tRP;
for (int i = 0; i < ranksPerChannel; i++) {
for (int j = 0; j < banksPerRank; j++) {
if (banks[i][j].openRow != Bank::NO_ROW) {
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
prechargeBank(banks[i][j], pre_at);
mem: Add precharge all (PREA) to the DRAM controller This patch adds the basic ingredients for a precharge all operation, to be used in conjunction with DRAM power modelling. Currently we do not try and apply any cleverness when precharging all banks, thus even if only a single bank is open we use PREA as opposed to PRE. At the moment we only have a single tRP (tRPpb), and do not model the slightly longer all-bank precharge constraint (tRPab).
2014-05-10 00:58:48 +02:00
} else {
banks[i][j].actAllowedAt =
std::max(banks[i][j].actAllowedAt, act_allowed_at);
banks[i][j].preAllowedAt =
std::max(banks[i][j].preAllowedAt, pre_at);
mem: Add DRAM power states to the controller This patch adds power states to the controller. These states and the transitions can be used together with the Micron power model. As a more elaborate use-case, the transitions can be used to drive the DRAMPower tool. At the moment, the power-down modes are not used, and this patch simply serves to capture the idle, auto refresh and active modes. The patch adds a third state machine that interacts with the refresh state machine.
2014-05-10 00:58:48 +02:00
}
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
}
}
mem: Add DRAM power states to the controller This patch adds power states to the controller. These states and the transitions can be used together with the Micron power model. As a more elaborate use-case, the transitions can be used to drive the DRAMPower tool. At the moment, the power-down modes are not used, and this patch simply serves to capture the idle, auto refresh and active modes. The patch adds a third state machine that interacts with the refresh state machine.
2014-05-10 00:58:48 +02:00
} else {
DPRINTF(DRAM, "All banks already precharged, starting refresh\n");
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
mem: Add DRAM power states to the controller This patch adds power states to the controller. These states and the transitions can be used together with the Micron power model. As a more elaborate use-case, the transitions can be used to drive the DRAMPower tool. At the moment, the power-down modes are not used, and this patch simply serves to capture the idle, auto refresh and active modes. The patch adds a third state machine that interacts with the refresh state machine.
2014-05-10 00:58:48 +02:00
// go ahead and kick the power state machine into gear if
// we are already idle
schedulePowerEvent(PWR_REF, curTick());
}
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
refreshState = REF_RUN;
mem: Add DRAM power states to the controller This patch adds power states to the controller. These states and the transitions can be used together with the Micron power model. As a more elaborate use-case, the transitions can be used to drive the DRAMPower tool. At the moment, the power-down modes are not used, and this patch simply serves to capture the idle, auto refresh and active modes. The patch adds a third state machine that interacts with the refresh state machine.
2014-05-10 00:58:48 +02:00
assert(numBanksActive == 0);
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
mem: Add DRAM power states to the controller This patch adds power states to the controller. These states and the transitions can be used together with the Micron power model. As a more elaborate use-case, the transitions can be used to drive the DRAMPower tool. At the moment, the power-down modes are not used, and this patch simply serves to capture the idle, auto refresh and active modes. The patch adds a third state machine that interacts with the refresh state machine.
2014-05-10 00:58:48 +02:00
// wait for all banks to be precharged, at which point the
// power state machine will transition to the idle state, and
// automatically move to a refresh, at that point it will also
// call this method to get the refresh event loop going again
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
return;
}
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
// last but not least we perform the actual refresh
if (refreshState == REF_RUN) {
// should never get here with any banks active
assert(numBanksActive == 0);
mem: Add DRAM power states to the controller This patch adds power states to the controller. These states and the transitions can be used together with the Micron power model. As a more elaborate use-case, the transitions can be used to drive the DRAMPower tool. At the moment, the power-down modes are not used, and this patch simply serves to capture the idle, auto refresh and active modes. The patch adds a third state machine that interacts with the refresh state machine.
2014-05-10 00:58:48 +02:00
assert(pwrState == PWR_REF);
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
Tick ref_done_at = curTick() + tRFC;
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
for (int i = 0; i < ranksPerChannel; i++) {
for (int j = 0; j < banksPerRank; j++) {
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
banks[i][j].actAllowedAt = ref_done_at;
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
}
}
// make sure we did not wait so long that we cannot make up
// for it
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
if (refreshDueAt + tREFI < ref_done_at) {
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
fatal("Refresh was delayed so long we cannot catch up\n");
mem: Adding stats for DRAM power calculation This patch adds stats which are used for offline power calculation from the 'Micron Power Calculator' spreadsheet.
2013-11-01 16:56:28 +01:00
}
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
// compensate for the delay in actually performing the refresh
// when scheduling the next one
schedule(refreshEvent, refreshDueAt + tREFI - tRP);
mem: Add DRAM power states to the controller This patch adds power states to the controller. These states and the transitions can be used together with the Micron power model. As a more elaborate use-case, the transitions can be used to drive the DRAMPower tool. At the moment, the power-down modes are not used, and this patch simply serves to capture the idle, auto refresh and active modes. The patch adds a third state machine that interacts with the refresh state machine.
2014-05-10 00:58:48 +02:00
assert(!powerEvent.scheduled());
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Add DRAM power states to the controller This patch adds power states to the controller. These states and the transitions can be used together with the Micron power model. As a more elaborate use-case, the transitions can be used to drive the DRAMPower tool. At the moment, the power-down modes are not used, and this patch simply serves to capture the idle, auto refresh and active modes. The patch adds a third state machine that interacts with the refresh state machine.
2014-05-10 00:58:48 +02:00
// move to the idle power state once the refresh is done, this
// will also move the refresh state machine to the refresh
// idle state
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
schedulePowerEvent(PWR_IDLE, ref_done_at);
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
mem: Add DRAM power states to the controller This patch adds power states to the controller. These states and the transitions can be used together with the Micron power model. As a more elaborate use-case, the transitions can be used to drive the DRAMPower tool. At the moment, the power-down modes are not used, and this patch simply serves to capture the idle, auto refresh and active modes. The patch adds a third state machine that interacts with the refresh state machine.
2014-05-10 00:58:48 +02:00
DPRINTF(DRAMState, "Refresh done at %llu and next refresh at %llu\n",
mem: Merge DRAM latency calculation and bank state update This patch merges the two control paths used to estimate the latency and update the bank state. As a result of this merging the computation is now in one place only, and should be easier to follow as it is all done in absolute (rather than relative) time. As part of this change, the scheduling is also refined to ensure that we look at a sensible estimate of the bank ready time in choosing the next request. The bank latency stat is removed as it ends up being misleading when the DRAM access code gets evaluated ahead of time (due to the eagerness of waking the model up for scheduling the next request).
2014-05-10 00:58:48 +02:00
ref_done_at, refreshDueAt + tREFI);
mem: Add DRAM power states to the controller This patch adds power states to the controller. These states and the transitions can be used together with the Micron power model. As a more elaborate use-case, the transitions can be used to drive the DRAMPower tool. At the moment, the power-down modes are not used, and this patch simply serves to capture the idle, auto refresh and active modes. The patch adds a third state machine that interacts with the refresh state machine.
2014-05-10 00:58:48 +02:00
}
}
void
DRAMCtrl::schedulePowerEvent(PowerState pwr_state, Tick tick)
{
// respect causality
assert(tick >= curTick());
if (!powerEvent.scheduled()) {
DPRINTF(DRAMState, "Scheduling power event at %llu to state %d\n",
tick, pwr_state);
// insert the new transition
pwrStateTrans = pwr_state;
schedule(powerEvent, tick);
} else {
panic("Scheduled power event at %llu to state %d, "
"with scheduled event at %llu to %d\n", tick, pwr_state,
powerEvent.when(), pwrStateTrans);
}
}
void
DRAMCtrl::processPowerEvent()
{
// remember where we were, and for how long
Tick duration = curTick() - pwrStateTick;
PowerState prev_state = pwrState;
// update the accounting
pwrStateTime[prev_state] += duration;
pwrState = pwrStateTrans;
pwrStateTick = curTick();
if (pwrState == PWR_IDLE) {
DPRINTF(DRAMState, "All banks precharged\n");
// if we were refreshing, make sure we start scheduling requests again
if (prev_state == PWR_REF) {
DPRINTF(DRAMState, "Was refreshing for %llu ticks\n", duration);
assert(pwrState == PWR_IDLE);
// kick things into action again
refreshState = REF_IDLE;
assert(!nextReqEvent.scheduled());
schedule(nextReqEvent, curTick());
} else {
assert(prev_state == PWR_ACT);
// if we have a pending refresh, and are now moving to
// the idle state, direclty transition to a refresh
if (refreshState == REF_RUN) {
// there should be nothing waiting at this point
assert(!powerEvent.scheduled());
// update the state in zero time and proceed below
pwrState = PWR_REF;
}
}
}
// we transition to the refresh state, let the refresh state
// machine know of this state update and let it deal with the
// scheduling of the next power state transition as well as the
// following refresh
if (pwrState == PWR_REF) {
DPRINTF(DRAMState, "Refreshing\n");
// kick the refresh event loop into action again, and that
// in turn will schedule a transition to the idle power
// state once the refresh is done
assert(refreshState == REF_RUN);
processRefreshEvent();
mem: Ensure DRAM refresh respects timings This patch adds a state machine for the refresh scheduling to ensure that no accesses are allowed while the refresh is in progress, and that all banks are propely precharged. As part of this change, the precharging of banks of broken out into a method of its own, making is similar to how activations are dealt with. The idle accounting is also updated to ensure that the refresh duration is not added to the time that the DRAM is in the idle state with all banks precharged.
2014-05-10 00:58:48 +02:00
}
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
}
void
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
DRAMCtrl::regStats()
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
{
using namespace Stats;
AbstractMemory::regStats();
readReqs
.name(name() + ".readReqs")
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
.desc("Number of read requests accepted");
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
writeReqs
.name(name() + ".writeReqs")
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
.desc("Number of write requests accepted");
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
readBursts
.name(name() + ".readBursts")
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
.desc("Number of DRAM read bursts, "
"including those serviced by the write queue");
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
writeBursts
.name(name() + ".writeBursts")
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
.desc("Number of DRAM write bursts, "
"including those merged in the write queue");
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
servicedByWrQ
.name(name() + ".servicedByWrQ")
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
.desc("Number of DRAM read bursts serviced by the write queue");
mergedWrBursts
.name(name() + ".mergedWrBursts")
.desc("Number of DRAM write bursts merged with an existing one");
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
neitherReadNorWrite
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
.name(name() + ".neitherReadNorWriteReqs")
.desc("Number of requests that are neither read nor write");
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
perBankRdBursts
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
.init(banksPerRank * ranksPerChannel)
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
.name(name() + ".perBankRdBursts")
.desc("Per bank write bursts");
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
perBankWrBursts
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
.init(banksPerRank * ranksPerChannel)
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
.name(name() + ".perBankWrBursts")
.desc("Per bank write bursts");
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
avgRdQLen
.name(name() + ".avgRdQLen")
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
.desc("Average read queue length when enqueuing")
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
.precision(2);
avgWrQLen
.name(name() + ".avgWrQLen")
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
.desc("Average write queue length when enqueuing")
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
.precision(2);
totQLat
.name(name() + ".totQLat")
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
.desc("Total ticks spent queuing");
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
totBusLat
.name(name() + ".totBusLat")
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
.desc("Total ticks spent in databus transfers");
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
totMemAccLat
.name(name() + ".totMemAccLat")
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
.desc("Total ticks spent from burst creation until serviced "
"by the DRAM");
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
avgQLat
.name(name() + ".avgQLat")
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
.desc("Average queueing delay per DRAM burst")
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
.precision(2);
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
avgQLat = totQLat / (readBursts - servicedByWrQ);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
avgBusLat
.name(name() + ".avgBusLat")
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
.desc("Average bus latency per DRAM burst")
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
.precision(2);
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
avgBusLat = totBusLat / (readBursts - servicedByWrQ);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
avgMemAccLat
.name(name() + ".avgMemAccLat")
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
.desc("Average memory access latency per DRAM burst")
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
.precision(2);
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
avgMemAccLat = totMemAccLat / (readBursts - servicedByWrQ);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
numRdRetry
.name(name() + ".numRdRetry")
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
.desc("Number of times read queue was full causing retry");
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
numWrRetry
.name(name() + ".numWrRetry")
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
.desc("Number of times write queue was full causing retry");
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
readRowHits
.name(name() + ".readRowHits")
.desc("Number of row buffer hits during reads");
writeRowHits
.name(name() + ".writeRowHits")
.desc("Number of row buffer hits during writes");
readRowHitRate
.name(name() + ".readRowHitRate")
.desc("Row buffer hit rate for reads")
.precision(2);
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
readRowHitRate = (readRowHits / (readBursts - servicedByWrQ)) * 100;
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
writeRowHitRate
.name(name() + ".writeRowHitRate")
.desc("Row buffer hit rate for writes")
.precision(2);
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
writeRowHitRate = (writeRowHits / (writeBursts - mergedWrBursts)) * 100;
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
readPktSize
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
.init(ceilLog2(burstSize) + 1)
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
.name(name() + ".readPktSize")
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
.desc("Read request sizes (log2)");
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
writePktSize
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
.init(ceilLog2(burstSize) + 1)
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
.name(name() + ".writePktSize")
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
.desc("Write request sizes (log2)");
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
rdQLenPdf
mem: SimpleDRAM variable naming and whitespace fixes This patch fixes a number of small cosmetic issues in the SimpleDRAM module. The most important change is to move the accounting of received packets to after the check is made if the packet should be retried or not. Thus, packets are only counted if they are actually accepted.
2013-03-01 19:20:24 +01:00
.init(readBufferSize)
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
.name(name() + ".rdQLenPdf")
.desc("What read queue length does an incoming req see");
wrQLenPdf
mem: SimpleDRAM variable naming and whitespace fixes This patch fixes a number of small cosmetic issues in the SimpleDRAM module. The most important change is to move the accounting of received packets to after the check is made if the packet should be retried or not. Thus, packets are only counted if they are actually accepted.
2013-03-01 19:20:24 +01:00
.init(writeBufferSize)
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
.name(name() + ".wrQLenPdf")
.desc("What write queue length does an incoming req see");
mem: Add bytes per activate DRAM controller stat This patch adds a histogram to track how many bytes are accessed in an open row before it is closed. This metric is useful in characterising a workload and the efficiency of the DRAM scheduler. For example, a DDR3-1600 device requires 44 cycles (tRC) before it can activate another row in the same bank. For a x32 interface (8 bytes per cycle) that means 8 x 44 = 352 bytes must be transferred to hide the preparation time.
2013-05-30 18:54:13 +02:00
bytesPerActivate
mem: Limit the accesses to a page before forcing a precharge This patch adds a basic starvation-prevention mechanism where a DRAM page is forced to close after a certain number of accesses. The limit is combined with the open and open-adaptive page policy and if reached causes an auto-precharge.
2014-03-23 16:12:03 +01:00
.init(maxAccessesPerRow)
mem: Add bytes per activate DRAM controller stat This patch adds a histogram to track how many bytes are accessed in an open row before it is closed. This metric is useful in characterising a workload and the efficiency of the DRAM scheduler. For example, a DDR3-1600 device requires 44 cycles (tRC) before it can activate another row in the same bank. For a x32 interface (8 bytes per cycle) that means 8 x 44 = 352 bytes must be transferred to hide the preparation time.
2013-05-30 18:54:13 +02:00
.name(name() + ".bytesPerActivate")
.desc("Bytes accessed per row activation")
.flags(nozero);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Track DRAM read/write switching and add hysteresis This patch adds stats for tracking the number of reads/writes per bus turn around, and also adds hysteresis to the write-to-read switching to ensure that the queue does not oscilate around the low threshold.
2014-03-23 16:12:14 +01:00
rdPerTurnAround
.init(readBufferSize)
.name(name() + ".rdPerTurnAround")
.desc("Reads before turning the bus around for writes")
.flags(nozero);
wrPerTurnAround
.init(writeBufferSize)
.name(name() + ".wrPerTurnAround")
.desc("Writes before turning the bus around for reads")
.flags(nozero);
mem: Adding stats for DRAM power calculation This patch adds stats which are used for offline power calculation from the 'Micron Power Calculator' spreadsheet.
2013-11-01 16:56:28 +01:00
bytesReadDRAM
.name(name() + ".bytesReadDRAM")
.desc("Total number of bytes read from DRAM");
bytesReadWrQ
.name(name() + ".bytesReadWrQ")
.desc("Total number of bytes read from write queue");
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
bytesWritten
.name(name() + ".bytesWritten")
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
.desc("Total number of bytes written to DRAM");
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
bytesReadSys
.name(name() + ".bytesReadSys")
.desc("Total read bytes from the system interface side");
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
bytesWrittenSys
.name(name() + ".bytesWrittenSys")
.desc("Total written bytes from the system interface side");
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
avgRdBW
.name(name() + ".avgRdBW")
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
.desc("Average DRAM read bandwidth in MiByte/s")
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
.precision(2);
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
avgRdBW = (bytesReadDRAM / 1000000) / simSeconds;
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
avgWrBW
.name(name() + ".avgWrBW")
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
.desc("Average achieved write bandwidth in MiByte/s")
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
.precision(2);
avgWrBW = (bytesWritten / 1000000) / simSeconds;
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
avgRdBWSys
.name(name() + ".avgRdBWSys")
.desc("Average system read bandwidth in MiByte/s")
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
.precision(2);
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
avgRdBWSys = (bytesReadSys / 1000000) / simSeconds;
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
avgWrBWSys
.name(name() + ".avgWrBWSys")
.desc("Average system write bandwidth in MiByte/s")
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
.precision(2);
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
avgWrBWSys = (bytesWrittenSys / 1000000) / simSeconds;
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
peakBW
.name(name() + ".peakBW")
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
.desc("Theoretical peak bandwidth in MiByte/s")
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
.precision(2);
mem: Replacing bytesPerCacheLine with DRAM burstLength in SimpleDRAM This patch gets rid of bytesPerCacheLine parameter and makes the DRAM configuration separate from cache line size. Instead of bytesPerCacheLine, we define a parameter for the DRAM called burst_length. The burst_length parameter shows the length of a DRAM device burst in bits. Also, lines_per_rowbuffer is replaced with device_rowbuffer_size to improve code portablity. This patch adds a burst length in beats for each memory type, an interface width for each memory type, and the memory controller model is extended to reason about "system" packets vs "dram" packets and assemble the responses properly. It means that system packets larger than a full burst are split into multiple dram packets.
2013-08-19 09:52:30 +02:00
peakBW = (SimClock::Frequency / tBURST) * burstSize / 1000000;
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
busUtil
.name(name() + ".busUtil")
.desc("Data bus utilization in percentage")
.precision(2);
busUtil = (avgRdBW + avgWrBW) / peakBW * 100;
totGap
.name(name() + ".totGap")
.desc("Total gap between requests");
avgGap
.name(name() + ".avgGap")
.desc("Average gap between requests")
.precision(2);
avgGap = totGap / (readReqs + writeReqs);
mem: Adding stats for DRAM power calculation This patch adds stats which are used for offline power calculation from the 'Micron Power Calculator' spreadsheet.
2013-11-01 16:56:28 +01:00
// Stats for DRAM Power calculation based on Micron datasheet
busUtilRead
.name(name() + ".busUtilRead")
.desc("Data bus utilization in percentage for reads")
.precision(2);
busUtilRead = avgRdBW / peakBW * 100;
busUtilWrite
.name(name() + ".busUtilWrite")
.desc("Data bus utilization in percentage for writes")
.precision(2);
busUtilWrite = avgWrBW / peakBW * 100;
pageHitRate
.name(name() + ".pageHitRate")
.desc("Row buffer hit rate, read and write combined")
.precision(2);
mem: Fixes for DRAM stats accounting This patch fixes a number of stats accounting issues in the DRAM controller. Most importantly, it separates the system interface and DRAM interface so that it is clearer what the actual DRAM bandwidth (and consequently utilisation) is.
2013-11-01 16:56:31 +01:00
pageHitRate = (writeRowHits + readRowHits) /
(writeBursts - mergedWrBursts + readBursts - servicedByWrQ) * 100;
mem: Adding stats for DRAM power calculation This patch adds stats which are used for offline power calculation from the 'Micron Power Calculator' spreadsheet.
2013-11-01 16:56:28 +01:00
mem: Add DRAM power states to the controller This patch adds power states to the controller. These states and the transitions can be used together with the Micron power model. As a more elaborate use-case, the transitions can be used to drive the DRAMPower tool. At the moment, the power-down modes are not used, and this patch simply serves to capture the idle, auto refresh and active modes. The patch adds a third state machine that interacts with the refresh state machine.
2014-05-10 00:58:48 +02:00
pwrStateTime
.init(5)
.name(name() + ".memoryStateTime")
.desc("Time in different power states");
pwrStateTime.subname(0, "IDLE");
pwrStateTime.subname(1, "REF");
pwrStateTime.subname(2, "PRE_PDN");
pwrStateTime.subname(3, "ACT");
pwrStateTime.subname(4, "ACT_PDN");
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
}
void
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
DRAMCtrl::recvFunctional(PacketPtr pkt)
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
{
// rely on the abstract memory
functionalAccess(pkt);
}
Port: Add protocol-agnostic ports in the port hierarchy This patch adds an additional level of ports in the inheritance hierarchy, separating out the protocol-specific and protocl-agnostic parts. All the functionality related to the binding of ports is now confined to use BaseMaster/BaseSlavePorts, and all the protocol-specific parts stay in the Master/SlavePort. In the future it will be possible to add other protocol-specific implementations. The functions used in the binding of ports, i.e. getMaster/SlavePort now use the base classes, and the index parameter is updated to use the PortID typedef with the symbolic InvalidPortID as the default.
2012-10-15 14:12:35 +02:00
BaseSlavePort&
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
DRAMCtrl::getSlavePort(const string &if_name, PortID idx)
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
{
if (if_name != "port") {
return MemObject::getSlavePort(if_name, idx);
} else {
return port;
}
}
unsigned int
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
DRAMCtrl::drain(DrainManager *dm)
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
{
sim: Move the draining interface into a separate base class This patch moves the draining interface from SimObject to a separate class that can be used by any object needing draining. However, objects not visible to the Python code (i.e., objects not deriving from SimObject) still depend on their parents informing them when to drain. This patch also gets rid of the CountedDrainEvent (which isn't really an event) and replaces it with a DrainManager.
2012-11-02 17:32:01 +01:00
unsigned int count = port.drain(dm);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
// if there is anything in any of our internal queues, keep track
// of that as well
mem: SimpleDRAM variable naming and whitespace fixes This patch fixes a number of small cosmetic issues in the SimpleDRAM module. The most important change is to move the accounting of received packets to after the check is made if the packet should be retried or not. Thus, packets are only counted if they are actually accepted.
2013-03-01 19:20:24 +01:00
if (!(writeQueue.empty() && readQueue.empty() &&
respQueue.empty())) {
mem: Fix DRAM draining to ensure write queue is empty This patch fixes the draining of the SimpleDRAM controller model. The controller performs buffering of writes and normally there is no need to ever empty the write buffer (if you have a fast on-chip memory, then use it). The patch adds checks to ensure the write buffer is drained when the controller is asked to do so.
2012-11-08 10:25:06 +01:00
DPRINTF(Drain, "DRAM controller not drained, write: %d, read: %d,"
mem: SimpleDRAM variable naming and whitespace fixes This patch fixes a number of small cosmetic issues in the SimpleDRAM module. The most important change is to move the accounting of received packets to after the check is made if the packet should be retried or not. Thus, packets are only counted if they are actually accepted.
2013-03-01 19:20:24 +01:00
" resp: %d\n", writeQueue.size(), readQueue.size(),
respQueue.size());
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
++count;
sim: Move the draining interface into a separate base class This patch moves the draining interface from SimObject to a separate class that can be used by any object needing draining. However, objects not visible to the Python code (i.e., objects not deriving from SimObject) still depend on their parents informing them when to drain. This patch also gets rid of the CountedDrainEvent (which isn't really an event) and replaces it with a DrainManager.
2012-11-02 17:32:01 +01:00
drainManager = dm;
mem: Make DRAM read/write switching less conservative 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-05-10 00:58:48 +02:00
mem: Fix DRAM draining to ensure write queue is empty This patch fixes the draining of the SimpleDRAM controller model. The controller performs buffering of writes and normally there is no need to ever empty the write buffer (if you have a fast on-chip memory, then use it). The patch adds checks to ensure the write buffer is drained when the controller is asked to do so.
2012-11-08 10:25:06 +01:00
// the only part that is not drained automatically over time
mem: Make DRAM read/write switching less conservative 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-05-10 00:58:48 +02:00
// is the write queue, thus kick things into action if needed
if (!writeQueue.empty() && !nextReqEvent.scheduled()) {
schedule(nextReqEvent, curTick());
}
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
}
if (count)
sim: Move the draining interface into a separate base class This patch moves the draining interface from SimObject to a separate class that can be used by any object needing draining. However, objects not visible to the Python code (i.e., objects not deriving from SimObject) still depend on their parents informing them when to drain. This patch also gets rid of the CountedDrainEvent (which isn't really an event) and replaces it with a DrainManager.
2012-11-02 17:32:01 +01:00
setDrainState(Drainable::Draining);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
else
sim: Move the draining interface into a separate base class This patch moves the draining interface from SimObject to a separate class that can be used by any object needing draining. However, objects not visible to the Python code (i.e., objects not deriving from SimObject) still depend on their parents informing them when to drain. This patch also gets rid of the CountedDrainEvent (which isn't really an event) and replaces it with a DrainManager.
2012-11-02 17:32:01 +01:00
setDrainState(Drainable::Drained);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
return count;
}
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
DRAMCtrl::MemoryPort::MemoryPort(const std::string& name, DRAMCtrl& _memory)
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
: QueuedSlavePort(name, &_memory, queue), queue(_memory, *this),
memory(_memory)
{ }
AddrRangeList
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
DRAMCtrl::MemoryPort::getAddrRanges() const
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
{
AddrRangeList ranges;
ranges.push_back(memory.getAddrRange());
return ranges;
}
void
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
DRAMCtrl::MemoryPort::recvFunctional(PacketPtr pkt)
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
{
pkt->pushLabel(memory.name());
if (!queue.checkFunctional(pkt)) {
// Default implementation of SimpleTimingPort::recvFunctional()
// calls recvAtomic() and throws away the latency; we can save a
// little here by just not calculating the latency.
memory.recvFunctional(pkt);
}
pkt->popLabel();
}
Tick
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
DRAMCtrl::MemoryPort::recvAtomic(PacketPtr pkt)
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
{
return memory.recvAtomic(pkt);
}
bool
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
DRAMCtrl::MemoryPort::recvTimingReq(PacketPtr pkt)
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
{
// pass it to the memory controller
return memory.recvTimingReq(pkt);
}
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
DRAMCtrl*
DRAMCtrlParams::create()
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
{
mem: Rename SimpleDRAM to a more suitable DRAMCtrl 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
2014-03-23 16:12:12 +01:00
return new DRAMCtrl(this);
DRAM: Introduce SimpleDRAM to capture a high-level controller This patch introduces a high-level model of a DRAM controller, with a basic read/write buffer structure, a selectable and customisable arbiter, a few address mapping options, and the basic DRAM timing constraints. The parameters make it possible to turn this model into any desired DDRx/LPDDRx/WideIOx memory controller. The intention is not to be cycle accurate or capture every aspect of a DDR DRAM interface, but rather to enable exploring of the high-level knobs with a good simulation speed. Thus, contrary to e.g. DRAMSim this module emphasizes simulation speed with a good-enough accuracy. This module is merely a starting point, and there are plenty additions and improvements to come. A notable addition is the support for address-striping in the bus to enable a multi-channel DRAM controller. Also note that there are still a few "todo's" in the code base that will be addressed as we go along. A follow-up patch will add basic performance regressions that use the traffic generator to exercise a few well-defined corner cases.
2012-09-21 17:48:13 +02:00
}
Reference in a new issue Copy permalink