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: Tenchusatsu who wrote (31911)	10/10/1999 3:37:00 AM
From: dumbmoney	Read Replies (1) \| Respond to of 93625

So if you trace traffic from PCI to memory, you'll find data first moving over a 32-bit PCI bus, then squeezed into an 8-bit HubLink port, then expanded out to the 16-bit Rambus interface, and finally expanded to 16 bytes inside the RDRAM device. Sounds insane, doesn't it? I wouldn't say insane, but...is there any end-user benefit provided by the new "hub" system? (aside from shaving a few pennies from the packaging cost)

To: Tenchusatsu who wrote (31911)	10/10/1999 4:31:00 AM
From: Bilow	Read Replies (1) \| Respond to of 93625

Hi Tenchusatsu; I'll take a crack at explaining why Intel is muxing some data but not others... It's all about making trade offs between cost and performance. There is no simple rule that says something like "always use the widest bus possible, to therefore obtain maximum bandwidth," or one that says "always use the fastest bus possible, to therefore obtain the smallest pin count." Instead, these decisions are complex issues that are difficult to reduce to a few simple words. For any given technology, (for instance 0.25 micron CMOS put into BGA packages on PCB in early 1999), there is a natural speed limit. This is like most things in life. For instance, aircraft have a natural speed limit somewhat below the speed of sound. To build an aircraft that flies faster than that speed is possible, but it is relatively expensive. That is why a ticket on the Concorde costs so much (and that ticket is probably subsidized by the governments that paid for the plane). The natural speed limits on a direct connection between two chips on the same PCB is something like 266MHz, that is why the HubLink connection is chosen to be that fast. In addition, latency is not much of an issue there, as data tends to be in long bursts, or I/O limited anyway. So naturally the engineers necked it down to 8 bits. Why does the PCI have 32-bits wide? That bus is an older, somewhat slower, technology, and, in addition, is not a simple connection between chips on the same motherboard. So the PCI bus naturally runs at a lower MHz. It is also the case that the PCI bus has to allow installation of all kinds of junk. It is just that sort of bus, (ones where the users can add all kinds of things to), that engineers have learned to give extra margin to. The PCI bus just isn't at all comparable to a bus between two chips on a motherboard. So the two busses have different natural speeds. So the engineers necked the data. Necking the data down to 8-bits isn't at all insane. It's just a matter of making the natural engineering trade off between costs and performance. Not much of a performance hit, but 24 pins saved on costs - easy decision to make. I really doubt that there was much fear about the design decision. Doing the necking just wasn't that big of a deal. Of course, one wonders why they didn't neck it down to 1-bit wide at 2GHz... Here's a question for you. Why did the Intel engineers stop at 266MHz? Why didn't they go to 800MHz, like Rambus, or even beyond? My answer is that it all boils down to engineering trade offs. 266MHz is a natural, fairly easy, solution, one that is reliable and inexpensive. Direct Rambus is not. DRDRAM pushes the interface between chips to an insanely high speed, and this has caused problems for all the manufacturers involved - the memory makers, the RIMM module makers, the controller chip maker, and the motherboard makers. Before the Camino fiasco, the (tech) question on this board centered on the performance issues of RDRAM designs versus other memory systems. But external events have made it more natural to explore the question of system reliability, and difficulty of design. I've been figuring on posting a long comment on the subject of "time budgets", which is how (good) electronics engineers figure out how fast they can run things. What I'd like to do is to figure out the time budgets for memory data reads on FPM, SDRAM, DDR SDRAM, and RDRAM. What basically happened with RDRAM is that the technology puts extremely difficult requirements on the parts that make it up. Maybe actually seeing the comparative numbers between the various options will make it more obvious what has happened and why. But I'm going to require some goading to make these calculations. They seem just a little too much like work. Basically, I need someone to piss me off. The basic fact is that determining what is an "insane" speed for a given technology is not something that is trivial. It requires some work and a little insight to make the calculations. I doubt that the answers to these questions will be obvious to many of the readers of these posts. This is not to say that they are stupid, just that they do something else for a living, other than design digital electronics. -- Carl

To: Tenchusatsu who wrote (31911)	10/10/1999 11:28:00 AM
From: grok	Read Replies (1) \| Respond to of 93625

RE: <How would you explain HubLink, the interface between the north and south bridges of Intel's 800-series of chipsets? It's only 8 bits wide, but it runs at 266 MHz for a maximum bandwidth of 266 MB/sec. No longer is the PCI bus in between the north and south bridges; it's now hanging off the south bridge. So if you trace traffic from PCI to memory, you'll find data first moving over a 32-bit PCI bus, then squeezed into an 8-bit HubLink port, then expanded out to the 16-bit Rambus interface, and finally expanded to 16 bytes inside the RDRAM device. Sounds insane, doesn't it? Tenchusatsu> Hublink sounds like a good idea to me. They can do everything they need in 8 bits so why not do it? And I'm sure that 266 MHz is a piece of cake with low risk and testable on current testers. (Just like DDR!) It seems to me that Rambus is a significantly different situation where they actually decrease performance in latency-sensitive apps (like maybe all apps?) with the serialization delay, create lots of complexity trying to regain the power increase with NAP/etc modes, and create a nightmare for the infrastructure by requiring all new test equipment (which actually may still not adequately test the chips!), etc. All this to save pins on the controller?