Cordob! Help me! I'm Bilow's coworker who is trying to convince the company to use RDRAM!
His arguments that the technology is dead has been making me look useless at this company, and I could really use some help outlining some arguments I can use against him - and his friends.
We're going to be using DDR for a point 2 point memory system later this year unless you can give me some help right away. We need 64MBytes of memory, with 6.4GBytes/sec peak bandwidth, average bandwidth of 5Gbytes/sec, with burst lengths of 256 bytes, and a 4 to 1 mix of reads to writes. Accesses are expected to be almost totally random, so banks will be closed after each 256 bytes. They want to use the new x32 parts from Infineon, they only need 4 of them to get the above (with a x128 data width), and the parts are supposed to go up to 50% higher frequencies than the 6.4GB/sec I just mentioned. The parts are available as second sources (JEDEC standard pinout) from a couple other memory makers, but here's the Infineon press release:
infineon.com
We're also going to need space for up to 4GB memory with a slow bandwidth requirement and will use either SDRAM DIMMs or RDRAM RIMMs. Since RDRAM RIMMs can only have 2 per channel, that means we need 2 Rambus channels where only one SDRAM channel could provide the same number of slots. But it gets worse. SDRAM DIMMs are available (even from Samsung) in much higher densities with SDRAM than RDRAM, so we really would need twice as many RIMMs than DIMMs. The upshot is that we can put four times as much memory in an SDRAM slot as we can in an RDRAM slot. But I'm still arguing for Rambus, so help me out here!
Instead of this old fashioned memory design, I want to use a multichannel RDRAM interface for the 6.4GBytes/sec port, and RDRAM RIMMs for the bulk memory storage. I'd use a new version of RDRAM, but the Infineon parts are already sampling, while QRSL is unavailable. So to get 6.4GBytes/sec, I will need 4 Rambus PC800 channels of 1.6GBytes/sec each. Here's where I run into problems:
(1) Management wants to have the design tested in FPGAs before we go into production. Since no FPGA maker has an RDRAM interface, but both the leaders (Altera and Xilinx) are DDR compatible, that indicates that we have to at least prototype with DDR. [See #reply-15193347 ]
(2) The Procurement lady says that Micron is offering her contract DDR chips at the same price as PC133, while none of the RDRAM makers are making any of that sort of guarantee. She says that DDR is already in such volume production, and is so standard, that it is sold on the spot market, while RDRAM is not. Even Rambus' big supporter, Samsung, is fully supporting DDR: #reply-14133222
She's voting for DDR. She also says she sees so many different incompatible RDRAM pinouts that she's not sure we can easily choose what will be the cheapest one 2 years from now.
dramexchange.com
(3) The board layout guy says that RDRAM channels take up more board space than DDR channels. He says that even though RDRAM has fewer signals, it requires that each two signals have a continuous ground trace (with lots of vias) routed between them. In addition, he says that RDRAM requires wider traces, and the spaces between traces are wider as well. I'm not too good with numbers, and I can't refute his word. As a starter for the calculation, he gives Bilow's post on SI on the subject, where Bilow computed the total channel widths for PC133 and RDRAM from the Intel motherboard specifications for i820 and i815 chipsets: #reply-13853059
(4) The board layout guy also is complaining about the complicated rules that RDRAM interfaces require. He says that in addition to the ground lines, RDRAM wastes uses space by requiring extra vias to match impedances, and also very careful trace length matching. [See: #reply-14287984 ]
He says that PCB stack up is kind of odd, and that increases the board cost, and reduces our opportunities to obtain alternative suppliers. He also says that he can't figure out what the next pinout for direct RDRAM is going to be. He says that the direct RDRAM is now produced in 5 different pinouts, and that whenever anyone starts up RDRAM production it seems like they define a unique new package to put it in. He thinks that's crazy because SDRAM has had the same JEDEC standard pinout for parts. I think he's just complaining because he doesn't want to produce 5 different board layouts. If I could figure out which pinout the new, 4i versions are going to have I'd tell him to assume that package, but with the proliferation of RDRAM packaging, I really don't know what to say to him.
4 Different DRDRAM packages. Which will be the cheapest next year???
54uBGA: samsungelectronics.com
62uBGA: samsungelectronics.com
92uBGA: samsungelectronics.com
84FGBA: micron.com
Also see #reply-14516140 , #reply-14445998
(5) The guy who's in charge of packaging says that the cost of pins has been dropping so drastically the last few years that it makes less sense to save pins now than it did back when RDRAM was designed. After the interface engineers counted up the number of pins required for an RDRAM channel (there's a lot of ground pins), and compared it to the pincount for a DDR channel, the packaging guy came down hard for DDR as a solution. Bilow wrote extensively on the subject, you can start here to correct his fallacious arguments ( #reply-13483793 ) and then look backwards through the links included there. Be sure and come up with real numbers! I look like a fool every time I stand up in front of this crowd and say something like "Rambus saves pins" without being able to tell them at least approximately how many pins it saves, and what those pins cost. Frankly, the packaging guy is just too modern for me. Back when I started, engineers cared about pins, the guy is way too nonchalant for me. But it sure looks like the numbers are on his side.
(6) The ASIC guy says that if we go with RDRAM, it will reduce the number of suppliers we can choose for the chip. In addition to not being able to prototype the part with FPGAs, we end up with higher NREs, and we will also have to pay royalties. He says that having the RDRAM interface will reduce our opportunity to get the design bid on by as many ASIC houses as possible, and that that will raise costs. He's voting for DDR. He wants to put up a prototype in 2 million gate FPGAs from Xilinx, and then convert the design into an ASIC at one of the half dozen or so companies that do that for Xilinx FPGAs. This is a tough one to answer since we can't even prototype an RDRAM design, what do I say to him?
(7) The VHDL designers say that DDR is a lot simpler to design with than RDRAM. They say that RDRAM has an extraordinarily complicated power up initialization sequence, and in addition, that it requires constant adjustment during regular use. They already don't like having to put refresh cycles into memory, and they say that the extra stuff that RDRAM requires would just be almost too much to bear. They've been using DRAM for years and are used to it the old way, I think they're just a little bit of a stick in the mud. It would be better if Rambus provided a complete IP solution for controlling RDRAM, but instead all they give you is the interfaces that translate from the 16-bit wide RSL channel to a 64-bit wide ASIC internal CMOS channel. Most of the design effort still lies with the designers, and in addition to understanding the Rambus data book for RDRAM, you also have to churn through their data books on the RSL ASIC. The VHDL guys say that adding in someone else's IP, like with the RSL interface macro, you always end up with more work than you bargained for. They also say that they would prefer to make an interface that is dedicated to what we need to do rather than buy one from Rambus that is basically one size fits all.
(8) The Software guys aren't really thrilled about having to write the extra code to control RDRAM. It turns out that RDRAM are initialized and controlled through a serial bus, and since the control is kind of complicated, the VHDL guys are going to make a simple interface and let the software guys take care of it.
Thanks for the assistance, I know you'll be glad to help.
-- Carl's coworker. |
