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

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Bilow who wrote (156)10/15/1999 6:13:00 PM
From: Bilow  Read Replies (1) 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
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext