Archives
 
 
 
  Special
 
 
 
  About Us
 
 
 

Newsletter
Free E-mail Newsletter from BYTE.com

 
    
           
Visit the home page Browse the four-year online archive Download platform-neutral CPU/FPU benchmarks Find information for advertisers, authors, vendors, subscribers Request free information on products written about or advertised in BYTE Submit a press release, or scan recent announcements Talk with BYTE's staff and readers about products and technologies

ArticlesOne Machine, Many RAMs


June 1995 / State Of The Art / Fast, Smart RAM / One Machine, Many RAMs
Rick Cook

During the next few years, our desktop computers may well use three or more different kinds of RAM, each chosen for a specific function. For example, a system might use fast, synchronous SRAMs for secondary or tertiary cache, an advanced asynchronous DRAM (e.g., enhanced DRAM, or EDRAM; or extended data out RAM, or EDORAM) for main memory, and RDRAM (Rambus DRAM) or WRAM (Window RAM) on the video card. And yes, you'll be able to plug a PC Card with flash RAM into it, too.

This will be a logical outgrowth of efforts to tune systems for maximum performance. In the old days, if you wanted a faster computer, you used a faster processor running at a higher clock speed. Today, however, designers ne ed to carefully balance every subsystem to prevent bottlenecks. Since different types of RAM have different strengths, it makes engineering sense and, increasingly, economic sense to incorporate several types of memory into a single computer.

As the DRAM market fragments in a shower of new technologies, standards and standards-setting organizations are hardly involved at all. One of the earliest memory standards efforts, IEEE's 1596.4 (called RamLink), is stalled; no products have yet appeared and none are likely to appear for years, says Steven Przybylski, a consultant specializing in DRAM technology. And while synchronous DRAMs are covered by a JEDEC (Joint Electronic Device Engineering Council) standard, says Przybylski, it's incomplete, and synchronous parts from different manufacturers don't always work together. At the same time, however, the proprietary RDRAM technology has become one of the most standardized because its developer, Rambus (Mountain View, CA), has required compatibility from all its licensees.

Therefore, we're not likely to see a single DRAM standard again; instead, we'll have several de facto standards, each optimized for a particular kind of product or application in a classic commodity market. There's still a lot of shaking out going on among these exotic RAM technologies, with competing approaches for nearly every niche.

We can see the effects of competition in the VRAM area. Until recently, dual-ported VRAMs were as much as twice the price of the equivalent DRAM. That led many analysts to predict that VRAM use would drop over the next several years as less expensive fast RAM technologies appeared. Instead, the price of VRAMs has dropped to the point that they're now competitive with the new DRAMs.

Another important factor driving memory in many directions is the considerable pressure to deliver more memory bandwidth. For the workstation market, RAM and computer designers are concerned about how they'll meet the needs of emerging 300-MHz, 300-SPECmark compute r systems. A DRAM technology that's well suited for fast video might not be ideal for main memory. For example, Rambus does well in video applications because it's so good at handling burst data in memories of a few megabytes. Unfortunately, those same characteristics make it a less appropriate choice for the main RAM of a fast, general-purpose computer.

The result is a chicken-and-egg proposition. Everyone agrees we're going to need a lot more bandwidth in main memory quickly. But companies are reluctant to commit to a technology until a clear winner emerges, and that won't happen until one technology starts getting a lot of design wins. So in the end, rather than leaping directly to a new architecture for main memory, systems makers will probably proceed cautiously and incrementally.

In time, the DRAM market will probably come back to standardized, commodity parts available from many sources, and we'll once again buy primarily on price. However, that won't happen overnight. For the next severa l years, we're all going to have to be careful whenever we buy memory for our systems. Different computers may use very different RAM technologies, and it's inevitable that some systems will require specific parts from specific manufacturers. This isn't a pleasant prospect, but it's the price we'll have to pay for increased memory performance and capacity.


Rick Cook is a freelance writer living in Phoenix, Arizona. He can be reached on the Internet or BIX at rcook@bix.com .

Up to the State Of The Art section contentsGo to previous article: Is Cache Losing Its Cachet?Go to next article: Why RAM Prices Stay HighSearchSend a comment on this articleSubscribe to BYTE or BYTE on CD-ROM  
Flexible C++
Matthew Wilson
My approach to software engineering is far more pragmatic than it is theoretical--and no language better exemplifies this than C++.

more...

BYTE Digest

BYTE Digest editors every month analyze and evaluate the best articles from Information Week, EE Times, Dr. Dobb's Journal, Network Computing, Sys Admin, and dozens of other CMP publications—bringing you critical news and information about wireless communication, computer security, software development, embedded systems, and more!

Find out more

BYTE.com Store

BYTE CD-ROM
NOW, on one CD-ROM, you can instantly access more than 8 years of BYTE.
 
The Best of BYTE Volume 1: Programming Languages
The Best of BYTE
Volume 1: Programming Languages
In this issue of Best of BYTE, we bring together some of the leading programming language designers and implementors...

Copyright © 2005 CMP Media LLC, Privacy Policy, Your California Privacy rights, Terms of Service
Site comments: webmaster@byte.com
SDMG Web Sites: BYTE.com, C/C++ Users Journal, Dr. Dobb's Journal, MSDN Magazine, New Architect, SD Expo, SD Magazine, Sys Admin, The Perl Journal, UnixReview.com, Windows Developer Network