Articles: Memory

Table of Contents

Pages: [ 1 | 2 | 3 ]

As soon as we start talking about computer memory, two key performance-related problems arise: bandwidth and latencies. It's just like a racing car: we want it to speed up fast and also have high full speed. Ideally, the two parameters must match each other or you will lose either at turns or at straight parts of the track. As we are so unlucky to live in a non-ideal world, we often have to compromise and choose one of the two parameters to improve first.

There is a kind of division of labor in the industry depending on what company engineers consider the most horrible DRAM vulnerability. For example, Ramtron blames latencies and promotes ESDRAM through its affiliate company Enhanced Memory Systems. Kentron stands for the opposite side and its approach we are going to discuss today.

They start out from the obvious premise: modern CPUs put much higher demands onto the memory subsystem than it can meet. Today's 533MHz FSB of Pentium 4 CPUs delivers 4.3GB/s bandwidth. The upcoming 800MHz FSB will notch 6.4GB/s. At the same time, the maximum bandwidth of a standard DDR module is 3.2GB/s. This is not enough even for the current system bus and we can't hope for any significant advances in the near future.

Now, let's turn to the basics and recall what this memory bandwidth actually is. Luckily, you don't have to take a course in math1s to calculate the thing:

Bandwidth = Bus width x Bus frequency x Number of packs transferred per clock cycle.

For example, in case of PC2700 DDR, the DRAM chip core frequency is 166MHz, the memory bus width is 64bit (or 8Bytes, if you like) and two data packs are transferred per clock. In total it makes 166x8x2 = 2700MB/s.

So, there are three ways to increase memory bandwidth that occur to us on the spot. They correspond to the three parameters of the above-described formula.

The most straightforward way is to increase memory chip frequency. Well, it's quite achievable in a certain way. Manufacturers have already overclocked DDR SDRAM to 4GB/s or 250MHz (compared with the standard 166MHz). But practice shows that the end-performance of these solutions is at most no better than that of standard-frequency modules. It comes as developers have to increase latencies along with the working frequency in order to provide acceptable operation stability. So, these modules can't boast high performance while they do "boast" notably higher price.

By the way, the problem with this approach is also valid for DDR-II. That's why DDR-II bandwidth and frequency won't be too much higher than those of DDR, although it's a long time yet for such chips to come into mass production.

The second, more refined way: to broaden the bus so that it would be possible to transfer more data per clock. Let's make it 128bit wide, instead of the today's 64bit. It's quite reasonable, too. Moreover, as the broader bus means using several parallel 64-bit channels, there would be no problems with latencies here. Every channel would work in its nominal mode. But…

The price of such a solution becomes the negative factor. Of course, we need at least two DIMM modules for the two channels to work effectively (which already means higher cost of the solution). We also need 128 signal lines instead of 64 and a memory controller with more pins (i.e. more contacts by the chipset North Bridge). On the whole, the layout and components mounting grow much more complex, so we need expensive 6-layer PCB instead of a cheaper 4-layer one to ensure proper signal stability. It's all right with servers and workstations, but not in case of mainstream PCs where the price is very important.

And the third possibility left is to increase the multiplier, which builds one 64-bit data pack per clock in case of SDRAM and two in case of DDR SDRAM. Overall, we only need to make some changes to the controller chip and memory chips. That is the solution promoted by Kentron. The company claims it to be both: simple and low-cost. Let's check it out.

Pages: [ 1 | 2 | 3 ]

Discussion

Comments currently: 3
Discussion started: 03/19/03 08:16:01 AM
Latest comment: 03/23/03 01:31:58 PM

View comments

You must log in to add comments.

Forgot password? Registration

remember me