summaryrefslogtreecommitdiff
path: root/src/mem/SimpleDRAM.py
AgeCommit message (Collapse)Author
2013-07-18mem: Set the cache line size on a system levelAndreas Hansson
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-05-30mem: More descriptive DRAM config namesAndreas Hansson
This patch changes the class names of the variuos DRAM configurations to better reflect what memory they are based on. The speed and interface width is now part of the name, and also the alias that is used to select them on the command line. Some minor changes are done to the actual parameters, to better reflect the named configurations. As a result of these changes the regressions change slightly and the stats will be bumped in a separate patch.
2013-05-30mem: Add static latency to the DRAM controllerAndreas Hansson
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-30mem: Add a LPDDR3-1600 configurationAndreas Hansson
This patch adds a typical (leaning towards fast) LPDDR3 configuration based on publically available data. As expected, it looks very similar to the LPDDR2-S4 configuration, only with a slightly lower burst time.
2013-05-30mem: Adapt the LPDDR2 to match a single x32 channelAndreas Hansson
This patch adapts the existing LPDDR2 configuration to make use of the multi-channel functionality. Thus, to get a x64 interface two controllers should be instantiated using the makeMultiChannel method. The page size and ranks are also adapted to better suit with a typical LPDDR2 part.
2013-04-22mem: Address mapping with fine-grained channel interleavingAndreas Hansson
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-22mem: More descriptive enum names for address mappingAndreas Hansson
This patch changes the slightly ambigious names used for the address mapping scheme to be more descriptive, and actually spell out what they do. With this patch we also open up for adding more flavours of open- and close-type mappings, i.e. interleaving across channels with the open map.
2013-04-22mem: Add a WideIO DRAM configurationAndreas Hansson
This patch adds a WideIO 200 MHz configuration that can be used as a baseline to compare with DDRx and LPDDRx. Note that it is a single channel and that it should be replicated 4 times. It is based on publically available information and attempts to capture an envisioned 8 Gbit single-die part (i.e. without TSVs).
2013-03-01mem: Add a method to build multi-channel DRAM configurationsAndreas Hansson
This patch adds a class method that allows easy creation of channel-interleaved multi-channel DRAM configurations. It is enabled by a class method to allow customisation of the class independent of the channel configuration. For example, the user can create a MyDDR subclass of e.g. SimpleDDR3, and then create a four-channel configuration of the subclass by calling MyDDR.makeMultiChannel(4, mem_start, mem_size).
2013-03-01mem: Add support for multi-channel DRAM configurationsAndreas Hansson
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-01-31mem: Add DDR3 and LPDDR2 DRAM controller configurationsAndreas Hansson
This patch moves the default DRAM parameters from the SimpleDRAM class to two different subclasses, one for DDR3 and one for LPDDR2. More can be added as we go forward. The regressions that previously used the SimpleDRAM are now using SimpleDDR3 as this is the most similar configuration.
2013-01-31mem: Add tTAW and tFAW to the SimpleDRAM modelAni Udipi
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.
2012-11-02sim: Include object header files in SWIG interfacesAndreas Sandberg
When casting objects in the generated SWIG interfaces, SWIG uses classical C-style casts ( (Foo *)bar; ). In some cases, this can degenerate into the equivalent of a reinterpret_cast (mainly if only a forward declaration of the type is available). This usually works for most compilers, but it is known to break if multiple inheritance is used anywhere in the object hierarchy. This patch introduces the cxx_header attribute to Python SimObject definitions, which should be used to specify a header to include in the SWIG interface. The header should include the declaration of the wrapped object. We currently don't enforce header the use of the header attribute, but a warning will be generated for objects that do not use it.
2012-09-21DRAM: Introduce SimpleDRAM to capture a high-level controllerAndreas Hansson
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.