Fast Block
Copy in DRAM
Ningning
Hu & Jichuan Chang
Abstract
Although many techniques have been
exploited to improve the DRAM performance, the ratio of processor speed to DRAM
speed continues to grow rapidly, which makes the DRAM a performance bottleneck
in modern computer systems. In this report, we explore the possibility of
implementing fast block copy operation in DRAM. By writing data in another row
during DRAM refreshing period, we can copy a whole row of data in only two
memory cycles. In order to quantify the usefulness of such an operation, we
first studied the memory copy behavior of typical applications. Aligned and
unaligned row copy and subrow copy instructions are then implemented in SimpleScalar
2.0. The performance improvement of our benchmarks and SPECint95 are
measured and analyzed.
1.
Introduction
DRAM has been used as main memory for over 20 years. During
this time, DRAM density has increased from 1kb/chip to 256Mb/chip, a factor of
256,000, while the latency of DRAM access has only been reduced to 1/10. The
ratio of processor speed to DRAM speed in modern computers continues to grow
rapidly. All these make the DRAM a performance bottleneck of modern computer
system.
One possible way of improving DRAM performance is to exploit
the wide bandwidth within DRAM chip (2-3 orders of magnitude larger than
CPU-memory bandwidth), to copy large amount of data quickly in a single DRAM
chip. Such operations can occur in a DRAM read cycle. In a traditional DRAM
chip, a row of bits is read into a latch upon a RAS signal. After reading the
individual bit within this row, the latched row must be written back to the
same row (since reading operation is destructive). If we can write the content
of latch into an arbitrarily specified row in the same DRAM chip when
refreshing, we can actually copy hundreds of bytes of data in just two DRAM
cycles.
Memory copy operations (memcpy(), bcopy(), etc)
are intensively used in text processing application, networking services,
video/image streaming and operating systems, with different block sizes and
alignment property. In our project, we focus on the opportunity and usefulness
of fast block copy operations in DRAM. This report will introduce our
implementation of DRAMs supporting fast block copy and the simulation results
using fast block copy operations.
The rest of this paper is organized as follows. In section 2,
we will discuss related works. In section 3, we describe the methodology used
in our experiments. In section 4, we will briefly introduce traditional DRAM
organization and how to extend the DRAM hardware to support different kinds of
block copies. In section 5, we present the experiment results and our analysis.
In section 6, we suggest future directions and conclude.
2. Related
works
Many techniques have been used by memory manufactures to
improve the performance of DRAM. Extended data out (EDO) DRAM and synchronous
DRAM (SDRAM) have long been popular. Advanced interface technologies, such as
Rambus RAM (RDRAM), RamLink, and SyncLink are quickly emerging.
Application-specific memories, such as cache DRAM (CDRAM), enhanced DRAM
(EDRAM), video DRAM (VRAM) [3, 4], and Synchronous Pipelined DRAM (SPDRAM) [5],
have achieved better performance in their intended area.
The research community also proposed novel methods to
integrate DRAM with computation logics. For example, The Computational RAM
(C-RAM) brings SIMD computation logic into DRAM by implementing the logic-in
memory at sense-amps [10]. The Intelligent RAM (IRAM) architecture merges the
processor and memory into a single chip to reduce memory access latency,
increases memory size while saving power consumption and board area [9].
There are also many conventional methods to improve the
performance of block copy operations. Non-blocking caches allow the processor
to overlap cache miss stall times with the block movement instructions [11].
Data prefetching are also used to improve the performance of block copy.
Usually the data cache can be bypassed when block transfer operations are
performed. [12] studies the operating system behavior of block copy within IRAM
architecture, which provides complementary result with our project (due to the
restriction of SimpleScalar, we can only observe the behaviors of
applications in user level).
3.
Methodology
We use SimpleScalar 2.0 as our simulator, in which we add
an assemble instruction, blkcp. This instruction is based on the
hardware support of block copy operation within DRAM chip. It can copy a whole
row of DRAM to another new row during the refreshing period of DRAM operation
in 2 cycles, or subrow copy in 3 cycles. We run our simulator on the office
PCs: Pentium III processor running at 733MHz, with 256MB main memory.
There are at least two important factors that influent the
relevance and usefulness of blkcp instructions: (1) the frequency of
block copy operations in different kinds of applications, and 2) the block
sizes and alignment property of these block copy operations. These data should
be collected in both kernel and user modes, by observing all kinds of library
functions that use block copy operations (including bcopy() and memcpy()).
But currently SimpleScalar2.0 doesn’t simulate the kernel mode operations,
and provides limited support of library customization on Linux platform. This
has limited our approach to only observe user applications and instrument only
two library functions: bcopy() and memcpy(). One possible future
work should be to collect data in all possible cases, to do comprehensive
simulation and analysis.
We didn’t have the chance to do detailed hardware simulation,
but block diagram and sequence diagram are described in section 4 to show that
the DRAM can be extended to support fast copy operations.
To start from the simplest case, we restrict that both source
and destination addresses have the same offset with respect to the row size of
DRAM, with which we can copy the source to destination row-by-row. But
according to Figure 1, we realize that aligned whole row copy is seldom the
case for real world applications. So it is necessary for us to consider how to
support the unaligned whole row copy, as well as aligned or unaligned subrow copy.
In our simulation experiments, we inspect the performance improvement for all
these kinds of block copy operations.
Figure 1. Block sizes of memory copy operations in GCC
and Perl.
1. Aligned
row copy: In this mode, blkcp
assumes the source and destination addresses are both aligned with row
boundary. This is the simplest case, and it could make full use of existing
DRAM hardware.
2. Unaligned row copy: In this case, we
remove the strict restriction of aligned row copy by allowing source address
not be aligned with the row boundary. Consequently, for general memory copies,
we could first process the beginning part of the destination, and then process
the remaining memory with the aligned destination address. We will show that our
design only needs three cycles to finish work[1].
3. Subrow copy: Commodity DRAM has
very large row size, for example, 1024 bits. Consequently, in the above two
modes, only very few memory copies can use the blkcp instruction. To
alleviate this situation, subrow copy is implemented. By using mask and shift
registers in DRAM, blkcp can copy one subrow into another subrow
quickly. Subrow copy can be implemented in hardware to support only aligned
(with respect to 2n memory address boundary) or unaligned copy, they
both can finish in three cycles. So our hardware diagram only presents the more
general, unaligned case. In our software simulation, we consider both cases,
the difference is that aligned subrow copy is usually used less. This is
especially significant when block size is large (>64). But for our
benchmarks, the difference is little. So in section 4, we present the result
using unaligned copy, except explicitly mentioned (for example, in fileread).
4. DRAMs Supporting Fast
Block Copy Operation
4.1. DRAM Organization and operations
In
the traditional DRAM, any storage location can be randomly accessed for
read/write by inputting the address of the corresponding storage location. A
typical DRAM of bit capacity 2N * 2M consists of an array
of memory cells arranged in 2N rows (word-lines) and 2M
columns (bit-lines). Each memory cell has a unique location represented by the
intersection of word and bit line. Memory cell consists of a transistor and a
capacitor. The charge on the capacitor represents 0 or 1 for the memory cell.
The support circuitry for the DRAM chip is used to read/write to a memory cell.
It includes:
a) Address decoders to select
a row and a column.
b) Sense amps to detect and
amplify the charge in the capacitor of the memory cell.
c) Read/Write logic to
read/store information in the memory cell.
d) Output Enable logic that
controls whether data should appear at the outputs.
e) Refresh counters to keep
track of refresh sequence.
DRAM
Memory is arranged in a XY grid pattern of rows and columns. First, the row
address is sent to the memory chip and latched, then the column address is sent
in a similar fashion. This row and column-addressing scheme (called
multiplexing) allows a large memory address to use fewer pins. The charge
stored in the chosen memory cell is amplified using the sense amplifier and
then routed to the output pin. Read/Write is controlled using the read/write
logic. [1]
Figure
2. Hardware Diagram of Typical DRAM (2 N x 2N x 1)
A
typical DRAM read operation includes the following steps (refer to Figure 2):
1. The row address is
placed on the address pins visa the address bus
2. RAS pin is activated,
which places the row address onto the Row Address Latch.
3. The Row Address Decoder selects
the proper row to be sent to the sense amps.
4. The Write Enable is
deactivated, so the DRAM knows that it’s not being written to.
5. The column address is
placed on the address pins via the address bus
6. The CAS pin is
activated, which places the column address on the Column Address Latch
7. The CAS pin also serves
as the Output Enable, so once the CAS signal has stabilized the sense amps
place the data from the selected row and column on the Data Out pin so that it
can travel the data bus back out into the system.
8. RAS and CAS are both
deactivated so that the cycle can begin again. [2]
4.2 Block Diagrams
Some important assumptions are introduced to simplify the
implementation of blkcp:
·
The source and destination block are in the same DRAM chip.
We currently don’t support block copy across DRAM chips.
·
There is no overlap between the source and destination blocks.
·
Blkcp
operation
does use register file and is not cacheable.
1M
x 1 DRAM is chosen to illustrate our implementation.
Figure 3. DRAM chip supporting aligned row copy (1M x
1)
4.2.1 Aligned DRAM Row Copy
The
block diagram of DRAM is shown in Figure 3. We add two new components in DRAM
chip: a Buffer Register and a MUX (multiplexer). The Buffer Register is used to
temporarily store the source row, and the MUX is used to choose the write back
data used in refresh period: under normal condition, column latch should be
chosen to refresh, but during row copy mode, WS is raised and Buffer Register
is chosen. Steps of copy operation are listed in the table below. It could
finish block copy in 2 cycles:
|
Cycle |
Action |
Result |
|
1 |
Fit
A0-A9 with SRC row address Raise
RAS |
Column
latch and row buffer now contains the source row data |
|
Raise
R/W |
Refresh
the SRC row (column latch write back to SRC) |
|
|
2 |
Fit
A0-A9 with DST row address Raise
RAS |
|
|
Raise
R/W, raise WS |
Data
in SRC is written back to DST when refreshing. |
4.2.2 Unaligned DRAM Row Copy
The DRAM block diagram supporting unaligned row copy is
included in Appendix A (Figure A1). More hardware are added, including one
shift register, two mask register, one buffer register, one OR logic and one
MUX. As the source address is not aligned, we need 2 cycles to read out a row
size buffer before write to the destination row. Steps of copy operation is
show below:
|
Cycle |
Action |
Result |
|
1 |
Fit
A0-A9 with SRC’s row address Raise
RAS |
Column
latch and Shifter Reg. store the SRC row |
|
Raise
R/W Shift
Reg. shifts SRC’s data to the higher half and transfer to Mask Reg1. |
Column
latch is written back to cell array (refresh) |
|
|
2 |
Fit
A0-A9 with the next row address Raise
RAS Mask
Reg.1 make the lower half bits with 0, and write its content to Buffer Reg. |
Column
latch and Shifter Reg. store the SRC row |
|
Raise
R/W, raise L/S Shift
Reg. shift the row content to the lower half and transfer to Mask Reg.2 |
Column
latch is written back to cell array (refresh) |
|
|
3 |
Fit
A0- A9 with DST row address Raise
RAS, raise L/S Mask
Reg.2 clear the higher bits |
Mask
Reg. 2 stores later half or SRC data that will be written back to DST row. |
|
Raise
R/W, raise WS Buffer
Reg. “OR” Mask Reg2 |
Combined
SRC row is written to DST row |
4.2.3 DRAM Subrow Copy
In this mode, part of the source row (eg. 32b of the 1024b
in a row) can be copied into a subrow destination. It assumes that both the
source subrow and the destination subrow stay within a single row, that is,
they don’t cross the row boundary. The DRAM chip diagram is shown in Appendix A
(Figure A2). The design is similar to that of unaligned row copy DRAM. Steps of
copy operation is show below:
|
Cycle |
Action |
Result |
|
1 |
Fit
A0-A9 with row address Raise
RAS |
Mask
Reg is filled with the src row |
|
Fit
A0-A9 with src subrow column address Raise
CAS, and R/W Mask
Reg set the other bits other than the source subrow with 0 Raise
SRC signal for MUX1 |
Column
latch is written back to cell array (refresh) Shift
Reg. is filled with the source subrow |
|
|
2 |
Fit
A0-A9 with DST’s subrow address Raise
RAS |
Mask
Reg is filled with DST’s data |
|
Fit
A0-A9 with the DST column address Raise
CAS Shift
Reg. shift SRC to DST’s column address Mask
Reg fill the DSR with 0 Raise
DST signal for MUX1 |
Shift
Reg. is filled with shifted SRC data; Buffer Reg. is filled with masked DST
data. |
|
|
3 |
Fit
A0- A9 with DST address Raise
RAS, and R/W Combine
Buffer Reg. and Shift Reg. using OR Raise
WS |
Subrow
SRC is written into DST |
5. Simulation Results and
Analysis
5.1 Simulation Method
5.1.1 Extending the Simulator
SimpleScalar2.0 is used to simulate the effect
of our new block copy operations. We add an instruction (blkcp) into
SimpleScalar’s instruction set, so that assembly programmer can use it to do
fast block copy. Two commonly used block copy functions (bcopy() and memcpy())
are re-implemented using blkcp instruction, the SimpleScalar library is
updated so that C program can use blkcp by calling the library
functions. The implementation is described as below:
a. Add blkcp
into SimpleScalar’s instruction set architecture
In SimpleScalar2.0,
assembly instruction is defined as a C procedure [8]. For example, in the
aligned row copy case (block size = 1024 bytes), blkcp can be defined as following:
b. Modify
library functions to utilize the new instruction
In Linux, memory copy operations are achieved by calling
library function memcpy() and bcopy().
We rewrite them using blkcp, and replace the SimpleScalar library using their new implementations. Our
experiences (which are later confirmed by SimpleScalar’s authors) show that it
is hard to rebuild the Glib in SimpleScalar2.0,
so we simply substitute memcpy.o and bcopy.o in the precompiled
library libc.a of SimpleScalar2.0. Our selected benchmarks are
linked with new library to use blkcp.
An effective way to implement block copy is to simply do a
small number of byte copies at the block’s beginning and ends, so that there is
a maximal destination blocks aligned in the middle part. Our memcpy()
and bcopy() function implementation follows this method. It first judges
whether it’s beneficial to use blkcp instruction. For example, in aligned
row copy, it should check that: (a) memory block to be copied includes at least
one physical row (not just larger than the row size); (b) source and
destination addresses have the same row offset. For operation satisfying the
requirements, block copy will use blkcp;
otherwise the data are copied byte-by-byte (or word-by-word).
If (src and dst meet requirements) {
// non-overlap, and buffer long enough
copy beginning (or ending) unaligned bytes;
block copy the aligned chucks using blkcp;
copy remained unaligned bytes;
}
else {
do memory copy byte-by-byte;
}
5.1.2 Relevant Metrics
In
our experiments, we focus on three performance metrics: (1) Total number of
instructions executed (IN); (2) Total number of memory references (MRN); (3)
Total number of blkcp used. IN and
MRN could not reflect the performance changes directly, because blkcp may
need two or three cycles to finish, and this can’t be reflected in
SimpleScalar. Actually, execution time and memory operation time are the best
metrics to evaluate the performance improvement. But both of them could not be used
as performance metrics in SimpleScalar2.0.
Because, in SimpleScalar2.0, each
instruction is implemented in the form of C procedure, and one instruction
assumed to finish in one cycle actually uses a few lines of C code, which uses
several real machine cycles and makes the real execution time meaningless.
Anyway the frequencies of operations still provide much information about the
performance.
5.1.3 Benchmark
A suitable benchmark for our experiments should meet three
requirements:
(1) Use a
lot of block copy operations;
(2) Block
size are large enough to utilize our blkcp instruction;
(3) Can be
built on SimpleScalar 2.0 to use the
special version of bcopy() & memcpy().
So far, we haven’t found such a benchmark that satisfies
these requirements simultaneously. We have tried to use SPECint95 as our
benchmarks. But for the eight of benchmarks that we could get source code, only
four could be rebuilt (the others need libraries which are not supported by SimpleScalar), and only one of them has
enough block copy operations to be used in our experiments. We also tried other
benchmarks (such as SPLASH – water and ocean), but similar problems remain. Due
to above limitations, we have to write our own benchmarks. Although
self-designed benchmarks have many problems in terms of generality and comparability,
they are useful for us to get the idea about how and when the block copy scheme
can improve the performance. Below we will briefly introduce our benchmarks:
Memcopy
This
benchmark will simulate the behavior of execution of memory intensive application.
It mainly uses two classes of instructions: arithmetic/logic and load/store.
The runtime execution times of ALU/MEM instructions are chosen randomly (but
reasonably large). We wan to test the adaptability of blkcp to various block sizes using this benchmark. Below shows its
pseudo-code:
memcopy
{
pick a random number n1 from 100
to 100,000;
do ALU operations by n1 times;
fill source buffer;
pick another random number buf_len from
1 to 2048;
/* des, src aligned with the biggest
possible row size */
memcpy(dst, src, buf_len);
}
Fileread
This benchmark is used to simulate the behavior of a
networking server, for example http or ftp server. It is known that, a genetic
http server (support static content only) could be implemented as following. In step
(b), (c) and (d), there are generally a lot of memory copy operations carried
out by the operating system to move data between buffers.
network_server_simulator
{
(a) listen for request, parse and check
access rights
(b) read static file;
(c) transform the content into desired
format;
(d) send the result back to client;
}
To
our surprise, we also found that when the application’s read buffer is large
enough (20 Bytes in SimpleScalar’s Glib implementation), fread()
also calls memcpy() to transfer data from system buffer to local buffer.
Since all our source data are big files whose length are large enough, a lot of
memcpy() operations occur. To simplify the analysis and isolate the
effect of blkcp on file system, we write the fileread benchmark, which
only reads files. It is more general because file reading is heavily used in
both kernel mode and user mode.
Perl
Perl is the only benchmark
chosen from SPECint95. It is a Perl language interpreter, which reads in a Perl
script and executes it by interpretation.
5.2. Result and Analysis
In out experiments, we combine the
data get from the three block copy modes. The experiment result with block size
of 1024 is collected using whole row block copy; others are using subrow copy.
Whether aligned or unaligned copy is used will be specified explicitly. Below
we will discuss different benchmarks respectively.
5.2.1
Memcopy
As
memcopy only involves aligned block copy, it is used to get the best
performance improvement that can be expected. Experimental data are shown in
Figure 4. We can see that both IN and MRN are greatly reduced, performance is
improved by terms of 2 to 30!
But
the improvement is not monotonic: it is the best when block size is 16 bytes
and 32 bytes. Because when block size is small (eg, 4 bytes or 8 bytes), most
of memory copies could make use of blkcp,
but the total number of blkcp used is
also large (Fig 4c). On the other hand, when the block size is large (eg, 512
bytes or 1024 bytes), blkcp could
copy a lot of memory once, but only can be used less frequently, and a large
portion of block copy is realized byte-by-byte. The bigger the block size, the more
bytes has to be treated in the normal way, that’s why the performance get worse
when block size is too large. The top line shows our implementation of naïve
memcpy algorithm (copy byte-by-byte), which has a large amount of memory
operations.
|
|
|
|
|
Figure 4. Experimental results of memcopy using unaligned blkcp. In (a) and (b) the top line doesn’t use blkcp, the lower curve is the result using blkcp. The x-axe represents the size of block supported by blkcp. |
5.2.2
Fileread
Figure
5 shows the results of fileread, the curves are very similar with the
aligned mode in Figure 4. The results from fileread tell us that, in the
normal programs, unaligned blkcp
could achieve good improvement for those systems having intensive memory
operations (say, by reading large files).
|
|
|
|
|
|
|
|
|
|
Figure 5. Experimental results for fileread, using unaligned blkcp. In (a) and (b) the top line is the data got without using blkcp, the lower curve is the one using blkcp. The x-axe represents the size of block supported by blkcp. |
Figure
6. Experimental results for fileread, using aligned blkcp. In (a)
and (b) the top line is the data got without using blkcp, the lower curve is the one using blkcp. The x-axe represents the size of block supported by blkcp. |
In the aligned case (Figure 6), although for
all different block sizes, there are significant performance improvements,
especially when the block size is 4 bytes and 8 bytes. The reason is that the
system buffer used in fread() can be actually aligned or unaligned to
different block size, and is not controlled by user application. When the I/O
buffer addresses are only aligned with 8, but the block size of blkcp is 16
bytes or larger, memcpy() can seldom use blkcp, as illustrated by Fig 6c[2].
Consequently, both IN and MRN for those large block sizes are much larger than those
of 4 bytes and 8 bytes.
The experiment results for the aligned case actually vary
with different executions (some time block size of 16 bytes or even 32 bytes
also improves performance significantly). And Figure 6 is a typical execution
snapshot selected among them. It strongly suggests that if the operating system
can intentionally allocate buffer aligned with the block size of blkcp,
the kernel mode performance will also be improved.
5.2.3
Perl
Figure
7 shows the result of Perl. For this benchmark, performance improvement
is not obvious, because there is only a small fraction (compared with memcopy
and fileread) of memory copy operations and the block sizes are
usually within 64 (Figure 7d). What makes thing worse is that this benchmark
failed to finish its execution when the block size is 4, 32, and 64 bytes,
which are marked with hollow triangles in Figure 7. We hypothesize that some
execution mechanisms in Perl conflict with the design of SimpleScalar in these three cases.
Omitting
those wrong data, we still could find that, within the range of the buffer
size, blkcp indeed improves the
performance, but rather small compared with memcopy and fileread.
|
|
|
|
|
|
|
Figure 7. Experimental results for perl, using unaligned blkcp.
In (a) and (b) the top line is the data got without using blkcp, the lower curve is the one
using blkcp. The x-axe represents
the block size supported by blkcp. Hollow triangles are incomplete
execution results. |
|
6.
Conclusion
Our
experiments show that for those systems frequently using large block memory
copy operations, blkcp could indeed improve the performance
significantly, just as illustrated by our first two benchmarks. It also
suggests that the performance of block copy in operating system, such as in
file systems, memory management subsystem, networking protocol stacks, can be
also significantly enhanced. But for the applications in which memory copy
operations do not dominate the performance overhead, we could not expect such
optimistic improvement by just using block copy.
There
are also some limitations in our approach. First, we did not consider the
overhead caused by the introduction of new hardware in our design. Currently,
we haven’t test the feasibility of our hardware design, but it’s apparent that
to implement such a DRAM chip is not easy or cheap. Also, as we only consider
one memory bank in our design, interleaved memory organization is ignored in
our study. The restriction of our simulator also limit the scope of our study,
currently only user mode applications are simulated, and little improvement has
been achieved on most conventional benchmarks. Some people might say that the
result is too conservative because we only modified the implementation of bcopy
and memcpy used by user application, while others might say that our
result is too optimistic because our own benchmark stress block copy operations
too much. We should consider combining the user and kernel mode simulation and
much realistic benchmarks in future research.
It’s
still difficult to conclude whether the hardware cost of such a block copy
operation could be justified. But we can say that in some cases, the
performance improvement is really large and can be used in some domain-specific
application (say, NFS). Future work should be done in comparing the result with
approaches using data prefetching and non-blocking cache. Furthermore, some
other logic and arithmetic operations should also be considered to make full
use of the new hardware we added.
Reference
[1]
Tulika Mitra, Dynamic Random Access Memory: A Survey. Research
Proficiency Examination Report, SUNY Stony Brook, March 1999
[2] RAM Guide. http://arstechnica.com/paedia/r/ram_guide/ram_guide.part1-4.html
[3] Yoichi Oshima, Bing Sheu, Teve H. Jen. High-Speed Architectures
for Multimedia Applications. Circuit & Device, pp 8-13, Jan. 1997
[4] Hiroaki Ikeda and Hidemori Inukai. High-Speed DRAM Architecture Development. IEEE Journal of Solid-State
Circuits, pp 685-692, Vol. 34, No. 5, May 1999
[5] Chi-Weon Yoon, Yon-Kyun
Im, Seon-Ho Han, Hoi-Jun Yoo and Tae-Sung Jung. A Fast Synchronous Pipelined
DRAM (SP-DRAM) Architecture With SRAM Buffers. ICVC, pp 285-288, Oct, 1999.
[6] Doug Burger, Todd. M. Austin. The
SimpleScalar Tool Set, Version 2.0. University of Wisconsin-Madison
Computer Sciences Department Technical Report #1342, June, 1997.
[7] Todd M. Austin. Hardware and Software
Mechanisms for Reducing Load Latency. Ph.D. Thesis, April 1996.
[8] Todd M. Austin. A Hacher’s Guide to the
SimpleScalar Architectural Research Tool Set. ftp://ftp.simplescalar.org/pub/doc/hack_guide.pdf.
[9] David Patterson, Thomas
Anderson, Neal Cardwell, Richard Fromm, Kimberly Keeton, Christoforos Kozyrakis,
Randi Thomas, and Katherine Yelick. A
Case for Intelligent RAM: IRAM. IEEE Micro, April 1997.
[10] Duncan G. Elliott, W. Martin Snelgrove, and Michael Stumm. Computational RAM: A Memory-SIMD
Hybrid and its Application to DSP. In Custom Integrated Circuits
Conference, pp 30.6.1-30.6.4, Boston, MA, May 1992.
[11] Rosenblum, M., et
al., The Impact of Architectural Trends on Operating System Performance,
15th ACM SOSP, pp 285-298, Dec. 1995.
[12] Richard Fromm, Utilizing
the on-chip IRAM bandwidth, Course Project Report, UC Berkeley, 1996
Appendix A: DRAMs supporting
unaligned row copy and subrow copy
