Alan,
I guess I don't see where you would get a 1.5x signal. Lets look at the drivers in the memory chips, not the ones in the RAC which operate differently. The Rambus drivers are current sinks. They have no ability to source current or pull up. All the pullup current is supplied by the terminator resistor which pulls up to 1.8 v, the nominal high value.
Agreed
When a driver wants to assert a high, it doesn't do anything. When it wants to assert a low value, it sinks exactly enough current to pull the characteristic impedance (and terminator value) down 0.4 v to 1.4v which is the reference voltage level.
Agreed
This signal propagates in both directions. In the outer direction, it is absorbed by the terminator. In the inner direction, it bounces off the RAC, thereby doubling the value to 1.0v at the RAC. (Because the RAC is the only device that will examine this value, the 1.4v signal at the other RDRams data pins doesn't matter.)
Agreed
So the Rac will see a solid 1.0v, well below the 1.4v reference level.
Agreed
If two RDrams drive current should overlap slightly, the resultant incoming signal would be 1.8-0.8 until it hits the RAC which would then double it to be 1.8-1.6 or 0.2v. This is above gnd so the signal value is always between 0.2 and 1.8 thereby within the safe operating range of the Ram's and rac's input circuits.
Yes, but you missed the point.
I am suggesting that in a very special situation something different happens. It needs to be a very special situation, otherwise it would have been found and dealt with ages ago.
Consider three successive reads, the first two from a device close to the controller, the third from a different device a long way away from the controller.
The device close to the controller is separated from it by such a distance that the second transmission is exactly superimposed on the reflection of the first. At a propagation velocity of 0.5c this corresponds to a distance of 1.25ns * 30cm * 0.5 * 0.5 = 9.375cm (I made a typing mistake here in my earlier post.)
There is no problem with this. The controller sees both reads in the proper sequence. The memory chip is happily able to drive the bus down to 1V. However, because of the position of the chip and the 1.25 ns time delay between the two transmissions the backwards pulse going towards the terminator is now a 1V pulse (the reflection of the first read plus the backward component of the second, travelling together towards the terminator) rather than the 1.4V pulse that would more often occur.
Now suppose that the other memory chip near the terminator is read - the third read, and that it is such a distance from the first chip that the backwards 1V pulse mentioned above is exactly at its terminals as it is driving a logic 1. This device has to deliver its usual pull-down current, but it needs to pull 1V down to 0.6V rather than the more usual 1.8V down to 1.4V, or 1.4V down to 1.0V.
If that device can happily deliver the required current at 0.6V, then all is well and the system works perfectly. Most of the time this will be the case, even in this very special situation. However, the minimum output drive (sink) current of the drive transistors is only specified down to 0.9V in, for example, the Samsung data sheets, implying that the Rambus designers did not intend this situation to arise. Therefore, under extreme temperature conditions, perhaps, the driver transistor on the second chip might not deliver enough current to provide a clean logic level at the controller. (The required 0.6V is transiently present at the terminals of the second device - what is propagated to the controller is the normal 1.4V pulse, as the two other superimposed pulses are going the other way towards the termination.)
I think Carl agrees with me that this situation could arise unless it is explicitly prohibited. If it does arise, it would only rarely cause errors. The probability of several infrequent events combining together and being detected is extremely low if one is not looking for it. If the 820 has a bug such that it does not prohibit this combination of events, then that bug might not come to light for a long time. Perhaps this is what happened?
May I point you at a somewhat simplistic explanation in the pdf located at -
Unfortunately, simplistic explanations aren't enough because by definition they don't deal with situations like this.
John |
