SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : AMD/INTC/RMBS et ALL -- Ignore unavailable to you. Want to Upgrade?


To: Bilow who wrote (156)10/6/1999 9:50:00 AM
From: wily  Read Replies (1) | Respond to of 271
 
Carl,

RE the better processes

I get it now. Thanks.

Re The engineering flaw:

So, what is the fix? Or is the fat lady singing?

w



To: Bilow who wrote (156)10/6/1999 3:08:00 PM
From: Don Lloyd  Read Replies (2) | Respond to of 271
 
Bilow -

Almost the bottom line of the HP .pdf -

"...The Direct Rambus read operation is complex and, therefore, more complicated to interpret using eye
diagrams. In fact, the only meaningful information that can be obtained from this Rambus line is that it is
performing both reads and writes..."

This seems like a somewhat sparse result for spending what must be at least 100's of K$ overall on HP equipment. At least we can see why HP bought in. -g-

Scanning the entire .pdf makes a convincing argument for the intellectual firepower of RMBS engineering, but an even better one for the persuasiveness of its marketing. -g-

Regards, Don



To: Bilow who wrote (156)10/15/1999 6:13:00 PM
From: Bilow  Read Replies (1) | Respond to of 271
 
Early "leak" is that Camino's problem is about what I predicted in the above post. This leak sounds legit to me. Maybe it is speculation, but we should have had some technical information leak by now, and this is the first stuff I've seen that actually sounded like it was relatively close to a technical description of the problem. (As opposed to stuff that has been filtered of all technical content by the Intel PR people.)

Also, this should be breaking news. Intel seems to have figured out WTF is up with the RAMBUS problems on their boards. The ROOT cause is as follows.

Low launch voltage is due to superposition of:

Back-2-Back Reads to Different Devices (device A & device B)

Specific Data Patterns

Position Sensitivity of EACH Device Being Accessed

Low launch voltage exceeds the specification and derates RDRAM drive strength

Launch Voltage is the voltage of a net when the output buffer begins driving

Output buffer derating combined with architectural B-2-B handoff and reflections + crosstalk causes failure.

All elements simultaneously required to cause failure.

hardocp.com

The problem appears to be a failure of output compliance, which is one of the contributing problems that I listed. Essentially what is happening is that the "low launch voltage" prevents the chip from being able to drive a zero onto the bus. That is, the chip is unable to cause the tranmission line to go to a "low" state because it is already too low in voltage. This is also known as an output voltage range compliance issue.

I wrote: There is another effect, one that has to do with output compliance of the memory drive signal. When the memory is being read, it will have to supply data while there are reflections showing up from the previous data that was already read. That data shows up in full strength. The design is just begging to have non-linearity effect show up. They must have arranged to have a relatively wide compliance voltage range of the Rambus outputs in order to get a hope of this working.

A technical note. Transmission line analysis is easier if you assume that the outputs driving the line have wide enough compliance voltage ranges. This is equivalent to making the assumption that you can linearly add up the effect of different drivers onto the line. If you can't make this assumption, you get non-linear effects, which appears to be what is happening with the Camino.

The leak claims that the problem occurs only as an interaction between two different RDRAM outputs. I don't believe that this would be the case. That is, while it is true that the interaction between two different outputs would provide you with a huge number of different possible interactions, it is also the case that eliminating those interactions will be no more easy than eliminating the interactions that a particular RDRAM chip would have with itself, (over worst case). This is why the technology is being held up. There are deeply fundamental problems with the transmission line drivers when used in read mode. That is, the problem is with an interaction between the RDRAM chips and the motherboard.

I can think of two classes of solution. One, they could prevent the interaction by preventing chips from almost simultaneously driving the line. As I mention above, I don't think that this would eliminate the problem, instead it would just eliminate most of the places where it could show up. (As an analogy, this is equivalent trying to eliminate the tigers by reducing the amount of jungle. Until you eliminate all the jungle, there still might be tigers.) Two, they could change the way that the line is driven so that output compliance is no longer an issue. (This would get all the tigers at the same time.)

There are two ways of preventing interactions between the chips that are obvious to me. The first solution is to shorten the bus so much that the drive from one chip dies out before the next chip turns on. This fix would reduce the maximum number of chips or RIMM modules, and this is the one that INTC has been hinting towards. Of course, this will reduce the maximum amount of memory that can be placed on a channel, and will, in addition, place length constraints on the motherboard routing. The second solution is by enforcing (at the Camino controller level) a dead time between accesses of two different chips. This will reduce the vaunted efficiency of the RDRAM channel, possibly adding in a latency delay...

The other way of fixing the design is to reengineer the system so that the tranmission line stays within output voltage compliance range of the RDRAM chips. There are several ways they could do this. This would pretty much inevitably cause the current RDRAM chips to be made obsolete, along with the Camino, and would require new passives (at least) on the motherboard. I really don't believe that they would consider this as an option.

RMBS is in hot water. I've been wrong before, but my guess is no solution in 4Q.

-- Carl