SDRAM Simulation Module v1.0

The SDRAM module v1.0 is developed to replace the original main memory module pro- vided with SimpleScalar v3.0d. As a timing simulation module, the major functionality of

3.2 SimpleScalar Simulation Environment 43

CPU

Virtual Paging System

Write Buffer SDRAM Address Mapping Logic Memory Access Scheduler Rank0 Rank1 Rank0 Rank1 Ch1 Ch0

SDRAM Controller _{SDRAM Device}

Bank0 DevN Bank0 Dev0 Bank0 DevN Bank0 Dev0

Figure 3.1: SDRAM Module v1.0 for SimpleScalar

the SDRAM module v1.0 is to determine the access latency at the time when a memory access is issued. The access latency is calculated based on the address of the requested memory block, the current state of SDRAM devices and bus availability. These considera- tions are absent from the original main memory module used by SimpleScalar v3.0d. The SDRAM module v1.0 is a purely timing module, which does not provide any of the data storage and retrieval functionalities of main memory. Functional memory continues to be handled by SimpleScalar. The SDRAM module v1.0 is composed of SDRAM device mod- ules, an SDRAM controller module and an optional virtual paging system, as illustrated in Figure 3.1.

3.2.1.1 SDRAM Device Module

The SDRAM device module represents a typical JEDEC SDR/DDR SDRAM device. It is fully parameterized, including many of the parameters present in an SDRAM device, including capacity, clock frequency, data rate, I/O width, row size, column size and timing constraints (tRP, tRCD, tCL, etc). Some of these timing constraints are listed in Table 2.1.

Bank Precharge Row activate Bank precharge Auto Refresh Column access Idle Precharged Active Auto refresh

Figure 3.2: Bank state transition diagram

the bank state transition diagram given in Figure 3.2, all banks are reset to idle state after initialization. Each bank precharge or auto refresh will send the bank to the precharged state. The state is transited to active by a row activate, where one or more column accesses can perform reads or writes.

3.2.1.2 SDRAM Controller Module

The SDRAM controller module provides a main memory interface to the CPU, accepts and schedules main memory requests issued by the CPU in a manner similar to that of a hardware memory controller. As introduced in Section 2.4, multiple SDRAM devices are concatenated to form a rank to fill the data bus of the memory interface. Ranks share address/data buses and are selected by chip select (CS) signals. Composed by one or more ranks, channels have unique address/data buses as well as control signals. As shown in Figure 3.1, the SDRAM controller module further contains three submodules. They are SDRAM address mapping logic, memory access scheduler and write buffer.

• SDRAM address mapping logic translates the physical address of each memory access into the SDRAM address in terms of channel, rank, bank, row, column and byte index using the selected SDRAM address mapping technique, as introduced in Section 2.6.

3.2 SimpleScalar Simulation Environment 45

• Memory access scheduler generates required SDRAM bus transactions for each mem- ory access according to the current state of the target SDRAM device. Transactions are then scheduled and sent to the device. Unlike the naive in order scheduler as shown in Figure 2.15(a) which schedules transactions strictly in order, the scheduler used by the SDRAM module v1.0 attempts to interleave and overlap transactions between adjacent accesses whenever possible, while it maintains the actual data transactions in the same order as accesses arrive. This scheduler is still considered as an in order scheduler, however it is more efficient than a naive in order scheduler and is used in SDRAM address mapping studies.

• A limited-size write buffer replaces the infinite write buffer originally used by Sim- pleScalar v3.0d [63]. The write buffer offers three features. First, it hides the write latency so that writes can complete immediately. Second, the write buffer allows reads to bypass writes to reduce read latency. Third, if a read requests the same memory block as a previous write, the write data can be forwarded from the latest write to the read, therefore reducing the traffic to the main memory. In the presence of a write buffer, reads must search the write buffer for possible read hits before accessing the main memory to avoid data hazard. The write buffer performs writebacks when the write buffer reaches its capacity or when the SDRAM bus has been idle for a certain number of memory cycles.

3.2.1.3 Dynamic Upper Bound Controller Policy

The SDRAM controller makes the decision, logically at the end of each access, whether or not leave the accessed row open. This decision making process is known as applying controller policies. The SDRAM controller module supports two static controller policies, OP and CPA, as introduced in Section 2.3.

policy called Dynamic Upper Bound (DYN-UPB) is added into the SDRAM module v1.0. With DYN-UPB policy, the controller keeps the accessed row open and postpones the decision until the next access to this bank is available. If the subsequent access to the same bank is known to be a row conflict, then the controller goes back in time and precharges the bank by modifying the state of that bank. Obviously DYN-UPB policy requires the knowledge of future access information which is only available in simulations. The purpose of introducing DYN-UPB policy is to predict an upper bound of performance improvement that a dynamic controller policy could achieve under the constraints of the simulation environment, specifically access sequence.

3.2.1.4 Virtual Paging System

Virtual paging system determines the placement of data in the physical address space and allows programs that require a larger amount of memory than the size of physical memory to run by swapping pages [60]. There is no virtual paging system implemented in SimpleScalar v3.0d as it does not simulate the entire operating system. Given single thread benchmarks, enough main memory (no page swapping) and fixed main memory access latency, virtual paging system does not have impacts on the performance. However, with a detailed nonuniform main memory, such as what the SDRAM module v1.0 represents, page placements will result in different access latencies. A preliminary virtual paging system is therefore implemented and added into SimpleScalar v3.0d.

The virtual paging system translates virtual addresses into physical addresses using an inverted page table [60]. As a purely functional module, this simulated virtual paging system does not generate any timing information. It does not have a Translation Look- aside Buffer (TLB) either. In addition, assuming simulated machines have enough physical memory for each benchmark, there will be no page swapping or page faults expect for initial page allocations.

3.2 SimpleScalar Simulation Environment 47

Two paging allocation algorithms are implemented, Sequential Allocation and Random Allocation. With sequential allocation, pages are allocated sequentially from the beginning of the physical address space. Random allocation on the other hand allocates pages com- pletely randomly. While sequential allocation is more like a typical machine shortly after booting up, random allocation models a machine running for a long time with high memory utilization, in which pages are randomized located in the physical address space.