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 : Advanced Micro Devices - Moderated (AMD) -- Ignore unavailable to you. Want to Upgrade?

To: Joe NYC who wrote (11964)	10/7/2000 5:09:14 PM
From: combjelly	Read Replies (1) \| Respond to of 275872

Joe, RE:Rambus IP. It is very possible to avoid Rambus' IP in the future. One that should work fine, assuming that you still want to solve the pin problem that Rambus solves, is to us LDT. Now I don't know what the circuitry overhead of LDT is, but if it is sufficiently small then this would be one solution. If it is too high, them an appropriately smaller circuit could be designed. And it would look something like this. Now the people who should be doing this would be Scumbria or Hans or any number of people who know more about this stuff than I do, but... The memory array should be self-refreshing, with a small amount of static or some other fast access memory so you can burst data with a single column access. If you have to move the data quickly, as opposed to accessing it quickly, then you need a low-voltage differential signalling arrangement, this is what Rambus, LDT, that digital protocol for display panels and everything else where you want to move data faster than a couple of 100 MHz per pin. For noise and general control of signal integrity reasons, you probably should stick with point to point so it would be more like LDT than Rambus. I would like to see some type of self-clocked, multiple channel arrangement, but a 4 or 8 bit interface with a clock per channel should work ok. Now the downside to what I have here is that chipset will be more complicated, it will have to adapt to a variable number of memory ports, but with the number of transistors increasing the way it is, that shouldn't be a problem. It would have the salient quality of, as you add chips or modules, you bandwidth goes up. Since there is often, if not usually, a 1 to 1 correspondence between amount of memory and bandwidth requirements, this is a good match. Now you might want to specifiy two populations of memory chips, one which is designed to go on a wide multichip module, and one designed for a narrow module. A wide module would just be separate chips that exist a separate entities, i.e. 4 chips would give you 4 different channels. A narrow module would have the chips designed to work together as a unit and share a single memory channel. This would be needed if you just wanted a lot of memory for the cheapest price and memory bandwidth isn't important, but the cost of multiple channels is. Not sure if this actually describes anything, but there it is. Some type of a packetized protocol would be needed to wrap around all of this, you send a starting address, whether it is a read or write, length of burst and the data, some specifications for critical word first, and voila! We have an IP company...