Silicon Investor (SI) -- The First Internet Community

STOCKTALK

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 : Rambus (RMBS) - Eagle or Penguin -- Ignore unavailable to you. Want to Upgrade?

To: Ali Chen who wrote (34394)	11/12/1999 8:36:00 PM
From: Glenn Norman	Respond to of 93625

re: (Glenn Madman) :) Yo_ALI CHIN..................There is nothing wrong with being a MAD MUTHA, as long as you are RIGHT!!!!!! Salude and kiss mine camel breath - you friend GLENN Holding RAMBUS LONG makes your breath smell fresher!!!!

To: Ali Chen who wrote (34394)	11/12/1999 8:39:00 PM
From: Bilow	Read Replies (2) \| Respond to of 93625

Hi Ali Chen; I'm going to have to defend Rambus a little on that relative propagation delay thing... First of all, don't worry about you and John not quite agreeing on the meaning of the term "propagation delay". As engineers, we know that what really matters is whether the thing is going to work or not. So looking at the issue of the RIMM modules (and the motherboard) having mixed internal and external RSL signal lines... What you have to do, as a designer, is make sure that each RSL signal uses internal or external lines equally, and at the same point in the trace. Then all the propagation delay differences due to humidity etc., will cancel. What doesn't cancel is the difference between the arrival time of the close RDRAMs and the far RDRAMs. Sure, this will depend on humidity, and God knows what else, but this is not critical due to the following: (1) For memory reads, the clock that causes the read is passed along with the data. So it suffers the same speed ups or slow downs as the data. Consequently the read back data shows up coincident with the clock. We should note that what appears to be the best leaked information on the Rambus failure suggests that the problem is with the reads, not with the writes. If this information is correct, and I personally believe it is, then humidity isn't likely to be the problem as far as arrival times of (the leading edges of) signals. Of course, the changes in impedance will cause reflections. Interestingly, the reflections that come from the incoming data signal will end up absorbed by the termination resistor. So there are no reflections that show up (to first order) at the controller. Instead, it is the reflections that come from the outgoing data wave that would show up in first order at the controller. Anyway, I don't see this as a big deal, but I have to admit that I haven't done the P-Spice simulation. I only hope that the Rambus people did. In any case, the problem is not one of the arrival time of the primary wave, those waves are synchronized by design. If the RIMM guys did put some data lines inside the PCB more than they put others, or the clock, then you are correct, there will be a timing problem with the data versus the clock. (2) On writes, the clock and data are sent outgoing. Because the write data arrives at the closer RDRAMs before it arrives at the outer ones, it is convenient to delay that write data inside the RDRAM enough to counteract this. This counteraction is controlled by the registers that someone was talking about earlier on this thread. I think that these have to do with writing, rather than reading, but I may have it reversed.... Nah... All those delay registers do is sort of synchronize all the RDRAM together. In this case, synchronize means that all memory chips act as if they are the same distance from the processor, the distance of the farthest memory chip. (Incidentally, this synchronization is the explanation for why when people put more RDRAM into a channel, it causes the channel to provide worse performance. This has been shown in several interesting benchmarks.) Of course the farthest out memory chips don't need any delays, they are farther out. The nearer chips are delayed on reads by the time required for the clock to propagate back from the end of the Rambus channel forwards towards the controller. The writes signals are not delayed on the bus, but are delayed internal to the RDRAM chips. The nearer RDRAM chips delay the write according to the programmed amount. Perhaps an example will help. If the Rambus channel length is 5ns long, then the nearest RDRAM chips will be programmed to delay their writes by 10ns. The reason for the doubling, is because there are two delays, one for reads, and one for writes. These have to be both matched. John, did I get it right? -- Carl

To: Ali Chen who wrote (34394)	11/13/1999 7:44:00 AM
From: John Walliker	Respond to of 93625

Ali, John, a little of nit-picking: No problem. No, you did suggest: "..clearly that Rambus modulate the trace width to achieve a constant impedance and hence propagation velocity". Which is plain incorrect but you have no guts to admit your unfamiliarity with high-speed design basics. Or maybe my English is not serving me right? You must start by considering the beginning of this exchange. I responded to an article that claimed that in addition to the inherent signal delay associated with the transmission lines there was an additional delay caused by capacitive loading from device inputs which was significant in terms of system latency and that reflections would be caused of sufficient magnitude to potentially disrupt system operation. I responded by stating that Rambus had compensated for this capacitive loading by modulating the transmission line characteristics in such a way that the impedance would remain essentially constant and there would not be an extra substantial RC delay. I think that the references I quoted support that assertion. I qualified my statement by saying that this only applied over the frequency range used by RSL signals. Clearly, if a time domain reflectometer is used with a very short risetime test signal it will see reflections from the modulated track width and device inputs. However, Rambus drivers have a controlled slew rate to avoid such fast edges and therefore such reflections are minimised. You now accept that the RSL signals are all embedded in the inner layers of the circuit board, so the effect of humidity on signal skew that you suggest will not occur. The propagation velocity in that situation is equal to the velocity of light in the medium - glass fibre/epoxy resin with a bit of fire retardant. As for the effect on CMOS signals, firstly they are likely to be much less sensitive to timing errors than RSL signals because of the much lower clock frequency. Secondly, I think your calculation of the effect of water vapour in air is flawed because you assume that the dielectric above a stripline over a single ground plane has the same effect as the dielectric below it. There are two factors to consider here. Firstly, even for a stripline entirely in air the electric field is concentrated mostly in the region between the stripline and the ground plane, with less above it. Secondly, this effect is enhanced when the dielectric constant of the medium below the stripline is higher than that above it. This means that small changes in the much lower dielectric constant of the air above the stripline will have a proportionally lower effect than you suggest. Hence I do not accept that your assertion is valid. Data in the design guide supports this. There is a table of propagation velocities for fully embedded and surface striplines which shows only a 15% difference between the two. If what you suggested were true then this difference would be much greater. Furthermore, none of the reports have implied problems with the CMOS signals. In one respect, there is an extra significant delay associated with each device. This comes about because of the minimum electrical spacing between devices that is required for the matching sections of pcb track. If devices are densely packed together then the tracks need to take a meandering path to maintain this minimum electrical separation. This is clearly illustrated in the references I have quoted. There is no need to calculate extra delays, because this is all built into the RIMM timing specifications. In any case, who's design is failing in the field under real workload, your RAMBUS or something else? If there were no such shameful failures, I would never question any of this "design" rules. If, instead of attempt to re-evaluate the whole design and find the cause of manufacturing variability, you prefer to close your eyes and think that the tolerance of 0.3% will go away and will be magically maintained in mass production, it is your problem. Not mine. If you look back over my earlier postings I think you will see that in discussions with bilow I have tried very hard to arrive at an understanding of what might have caused the problems and the extent to which they can be truly avoided. I also think that there is a real possibility that the conclusions from those discussions were correct, but only the insiders know for sure. John