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: Tony Viola who wrote (91382)	10/30/1999 9:00:00 PM
From: John F. Dowd	Respond to of 186894

Tony: Now here is something non-mechanical. Very electrically/electronically high tech. Taken from a RMBS post---- > Also, FYI, Intels RAMBUS controller really stinks. The RAMBUS spec allows > for 128 open pages of memory per channel for reduced latency, but I > believe Intel's specs only allow for 32 open pages, like the BX chipset. I doubt their controller stinks and if does it is not for this reason. First of all, the number of simultaneous open pages is a bit like cache associativity where 1 sucks, 4 is a lot better than 1, 32 is somewhat better than 4, and anything bigger has little benefit on PC type applications. Secondly, DRDRAM devices have three main power management states: powerdown, standby, and attention. Pages are essentially only left open in the attention state. Unfortunately DRDRAMs in standby, and especially in attention states, burn a lot of current. Much of the brain power in designing a DRDRAM memory controller is spent deciding how to optimize which devices you keep in a high power state. How many you can keep hot (especially in the same RIMM) is limited by the fact your PC mobo isn't sitting in a wind tunnel and is probably a disappointingly low number given typical PC physical engineering. > This is why the latency information on RAMBUS's homepage is so much better > than what we are seeing in tests done with the 820. I hope the 840 > corrects this! Besides the speed ratings (600, 712, and 800 Mbps/pin), DRDRAMs also have access time ratings (like CAS latency in SDRAMs). For example 800 Mbps parts have row access latency ratings of 40, 45, and 50 ns. In addition, access time can vary depending on how many RIMMs are in your system and how many devices are on them. The way the rambus channel signals serpentines around going on and off each RIMM means the signal time of flight difference between the memory device closest to the controller and the one farthest away could actually be 3, 4, or even 5 ns (which is like 4 bit periods at 800 Mbps; and you wonder why it is so hard to get these systems to work reliably? :) Ooops I almost forgot, the read command itself has to snake all the way down to tail-end-charlie. This doubles the time of flight delta so there could be up to a 10 ns difference in the "round trip read access latency" between a memory system composed of 32 equal speed grade parts. To compensate for this there is a "TPARM" register in each rambus device that can delay column access latency by up to a further 10 ns. During powerup and resets the firmware + memory controller determine how long the access to the farthest device is and then delays closer device using the TPARM CDLY0 field so that all DRDRAMs in the channel are equally slow. For the best benchmark results a system should have a single RIMM with a few high density parts on it. If you have a fully loaded 3 RIMM system, oops 2 RIMM system with many low density parts on them your device level round trip column access latency will increase by up to 40-50% (20 ns plus and extra 8 or 10 ns with dash 40 parts). Just for laughs, try swapping the RIMM in a one RIMM sytem with the continuity module in the last slot and rerun lmbench or whatever. Now do you want see how you lose even more read access latency in your rambus based computer system? :) The DRDRAM access times are specified from the end of the 10ns long row or column address/command packet to the start of the 10 ns long (8 data beats x 16 bits wide) returning data packet. This means the chipset gets this nice parallel address from the CPU and then has to dribble a 10 ns long address packet to the selected memory device which in turn feeds it into shift registers to reparallelize it internally. Since the data packet comes back 16 bits at a time this means that an extra 3.75 or 8.75 ns (depending on how the chipset RAC is implemented) is needed to assemble the first 64 bit parallel data word for transmission back to the CPU. Of course all of this assumes the fastest DRDRAM parts there are (800 Mbps, dash 40) which are probably as rare as hen's teeth and cost big $$$. Only about 30% of current 0.22 um fabbed DRDRAMs yield at 800 Mbps; the rest have to be binned down to 600 or 712 speed grades. If you want to see some of the gory details yourself goto the NEC web site and download the 72 page data sheet (nicely done BTW) for the uPD488448 128/144 Mbit DRDRAM. (this is in no way meant to disparage NEC, they just make the part based on a design from Rambus Inc. They make other types of DRAMs too :) PD