To: Tony Viola who wrote (28733 ) 9/6/1999 3:13:00 AM From: Bilow Read Replies (3) | Respond to of 93625
Hi Tony Viola; Regarding the 800MHz vs. 400MHz on RDRAM. When I compared 800MHz RDRAM to 250MHz DDR, I was comparing apples to apples. The clock rates for RDRAM and DDR are 400MHz and 125MHz, respectively, more or less, while the peak data rates are twice these. I say "more or less", because DDR is actually supposed to be available at much higher frequencies. The fact is that industry rarely uses RAM at its peak theoretical speed. The reason for this is that engineers like to have margin left over. That margin is why you can usually disobey the injunction to not mix memory makers on the same motherboard and live. Motherboard designers are not likely to tune their boards up to the maximum speed that DDR can provide, which is why I am quoting 125MHz. Engineers like to leave themselves some room, especially for an advantage which is marginal at best. The fact of engineering is that a working computer is much more valuable than one that doesn't work, but goes a few % faster. Most of the technical problems with rambus is due to inadequate timing (or possibly voltage) margins. At data rates of 800MHz, there just isn't any room for error. This is what the memory makers are having trouble meeting. Later, when production numbers of parts are available to the board makers, the chip set and board makers will have their own set of problems. Most non-technical people have no idea how fast 800MHz is. I'll try and explain. Each bit is only active for the length of time it takes light to travel about 15 inches. 250MHz is a lot slower. Light can travel something like four feet in that time. That's long enough to smoke a cigarette (common expression among digital engineers to express the concept of plenty of time in the nanosecond domain). I know that these numbers seem pretty magical to people who don't work in these areas, but there is a lot of difference. ICs are made from transistors, and everybody uses pretty much the same transistors. Getting those transistors to run three times faster is very, very hard. Rambus cut a few corners, and made a few optimistic estimates when they selected their target. The problem with these really high speed interfaces is manufacturability. Some time when I feel like it, I may post some notes on worst case timing design. Until then, you are just going to have to take me at my word when I say that designing circuits that can sample data at 800MHz just isn't easy. Actually, it is fairly easy to get prototypes of this sort of thing running. I could do it in 74S TTL, in fact. But it wouldn't be manufacturable, and I would have to have a bunch of adjustments to get it to work. Then, when you blew cold or hot air across it, it would fail. But it would run in a stable enough environment. In fact, prototypes are the easiest thing in the world to get running, but that doesn't mean squat when it comes to putting out a manufacturable product. Real products have to be worst case designed. That means that any pile of parts work when you solder them together the same way, and they work no matter what the temperature is (within limits) and no matter what the power voltages provided to them is (within limits) and no matter what the logic voltages input to them is (within limits), etc. A not uncommon problem with designs is that the prototypes work great, but when put into manufacturing, some percentage of the units fail. Modern electronic manufacturing companies are not capable of surviving a very high failure rate (like 2%). A big, complicated system like a computer has a huge number of things that can go wrong, so each one of those things has to have a very, very, very small likelihood of failing. The basic problem with designing to RDRAM is the extreme tightness of timing and voltage margins, relative to current transistor technology. They are just cutting it very, very close, possibly too close. My guess is that they will eventually get the bugs worked out, but I always thought this, and, in fact, at the beginning of this year I thought they would get the bugs worked out on schedule. They have not done this. This is a failure . There is no other way to describe it. Rambus failed to meet schedule , and it is in trouble, but not as much as INTC is, in my opinion. -- Carl