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 : Intel Corporation (INTC) -- Ignore unavailable to you. Want to Upgrade?

To: Tenchusatsu who wrote (104229)	6/8/2000 2:49:00 PM
From: jim kelley	Read Replies (2) \| Respond to of 186894

Ten, I seem to recall this same issue having come up numerous times with BILOW. He hauls it out from time to time as though it has not been thoroughly discussed. <G> Of course, you are correct!

To: Tenchusatsu who wrote (104229)	6/8/2000 3:17:00 PM
From: pgerassi	Read Replies (1) \| Respond to of 186894

Dear Tench: RDRAM is harder to route. It has a jitter allowance of 20ps to 40ps total between signals (PC800). This means that the traces be no more than +/- 0.6mm different in length and all have the same impedence (50 +/- 1 ohm)(even through the edge connectors). PC133 SDRAM has a jitter allowance of 500ps. This allows its trace length to be no more than +/- 7.5mm different, a much easier requirement. In a RIMM, there is more data traces than on a SDRAM. Remember that to get a 256MB RIMM requires 16 chips which, require 17 sets of channel traces. Where as SDRAM only needs one set. Thus there are far less traces in a SDRAM DIMM. Which all leads to RDRAM being harder to route when used in a PC (or server) environment. Pete

To: Tenchusatsu who wrote (104229)	6/8/2000 5:48:00 PM
From: Bilow	Read Replies (4) \| Respond to of 186894

Hi Tenchusatsu; So we now agree that the pin count for RDRAM (and RIMMs, for that matter) is larger than for SDRAM. Your previous statement was "Yet the pin count is still lower because RDRAM's data path is 1/4 that of SDRAM's, and that more than offsets the additional pins necessary for signal integrity." ,and you now agree that this is not correct. Instead, you now say "That's why the channel is much narrower, and that's what really counts." This is a technical statement, and it is one that we can measure. What you say makes good sense, but without making the calculation there is no way to be sure. I will use Intel documents throughout, the i810 and i820 platform design guides. This is as fair a comparison as I can make. First, the Rambus case. This is the more complicated one, as there are four (and a half) classes of signal trace width requirements, and most of those requirements are complicated by the requirements of having ground traces. I can understand that you never read through the technical documents and made the calculations. I wouldn't have either, but unmasking Rambus falsifications is my hobby, so I know where all the dead bodies lie. Most of the Rambus channel signals are the RSL (Rambus Signal Level) lines that everybody knows about: "To maintain a nominal 28 ohm trace impedance, the RSL signals must be 18 mils wide. To control crosstalk and odd/even mode velocity deltas, there must be a 10 mil ground isolation trace routed between adjacent RSL signals. The 10 mil ground isolation traces must be connected to ground with a via every 1 inch. A 6 mil gap is required between the RSL signals and the ground isolation trace." Page 38 (2-10) developer.intel.com (i820 Chipset Platform Design Guide) This is a total of 18+6+10+6 = 40 mil separation, center to center, between RSL signal traces. The full panoply of Rambus channel signal types is described on page 37 (2-9). Direct Rambus requires 2 high speed CMOS signals. According to page 54 (2-26), they must be 18 mils wide, and presumably have a 6 mil gap for a total of 24 mils. There is also one standard CMOS signal, which would be 5+7mils = 12 mils. The guidelines for the memory clocks are on page 139 (4-9). There are four memory clock lines, a differential pair outgoing, and a differential pair incoming. Each clock line is 14 mils wide, with 6 mil spaces around, and each pair is surrounded by a pair of 22 mil ground traces. The total (center to center) for a pair of clocks is 68 mils, or 34 mils per clock. Now we look for the corresponding figures for the i810 chipset. On page 63 (4-5), the System Memory Layout Guidelines specifications for memory signals are as follows. Fourteen control signals require width of 10 and space of 8 mils, for a total of 18 mils. The remaining 77 signals require width of 5 and space of 7 mils, for a total of 12 mils. So the board width (for traces) for the two technologies are as follows: RDRAM: 2640mils + 224mils + 112mils + 434mils = 1.236 inches SDRAM: 1418mils + 7712mils = 1.176 inches Conclusion: SDRAM DIMM routing is 5% narrower, overall then RDRAM RIMM routing. This is very much a lower bound, as Rambus requires signal length matching, and this adds a lot of effective width to the board area required. In fact, if you would look at the gerbers for a i820 board and compare to an i810 board, you would notice the difference in congestion around the DIMM/RIMM to memory controller. In the RDRAM case, two layers are fully utilized to get the signals over to the memory. You wrote that RDRAM was "much narrower" and you were wrong. Rambus is the worst engineering idea ever to visit memory, don't feel ashamed that you got caught up in their BS. The fact is that every engineer on the planet, who hasn't made the above calculation, believes exactly what you did. What happened with Rambus is that a group of inexperienced hotshot engineers decided to tell an industry how to make a more efficient memory interface. They did an ivory-tower kind of college class analysis of the problem, and they fell into every real world pitfall that older engineers have learned to avoid through the school of hard knocks. Then they convinced Intel management to force it on the industry. It is nearly the ugliest piece of engineering I have ever seen in my life. -- Carl