Obviously you have an enormous amount of confidence in your opinion; thank you for sharing it. As I can, I will attempt to post several responses concerning points you raise in your note. The first...
>>In contrast with the competence of MOSAID, after meeting all the main players in RAMBUS, I was astounded that not one seemed to know anything whatsoever about a DRAM. I was asked to explain how a DRAM worked, and had to show them how each of the current DRAMs operate. This was astounding: after all, this is public information that every engineer should be able to recite in his sleep. If RAMBUS could not design even the simplest circuit using a standard DRAM, how could they develop the next generation?<<
Fascinating. I know several of the players in Rambus -- I've worked with them over the last 15 years or so in the computer industry. The folks I know have designed large microprocessor-based servers from the processor/memory bus up -- designing their own ASIC's to implement very high multiprocessor processor/memory interfaces.
You might want to consider, if the folks at Rambus seemed so ignorant to you, that one common technique used in the technical community when you run across someone you feel is arrogant without the corresponding technical depth to back it up is to "sit back, ask basic questions, and let him make a fool of himself".
A more benign explanation may be that the folks you were talking to are primarily analog engineers. When you start talking about very high speed digital devices, you need to run increasingly into analog problems (as a memory expert, I'm sure you realize this). Much of the intellectual property of the company is focused upon solutions to digital/analog crossover (no pun intended -- techie joke) issues.
>>Also the real speeds in a PC environment are much lower than the headline speeds RAMBUS report due to the large overhead RDRAM carry - there is lots of control for graphics applications, but PCs just want to dump cache data as separate 8 byte blocks, so do not need any of the bit manipulation and masking overhead in RDRAM.<<
I'm translating this statement to read "microprocessor primary caches are currently designed to do smaller data transfers -- RDRAM is optimized for larger data transfers". Of course, you might ask yourself just why microprocessor caches are designed this way. The answer, of course, lies in matching the microprocessor bandwidth with the memory bandwidth. In either tenured or non-tenured bus systems, you have to make sure that you don't introduce so much latency between the primary cache and the memory that a cache miss on an instruction execution causes too much of a stall.
To put this another way, at Intel they have these great software simulators that they run software through. They can change parameters on these software simulators such that they can increase or decrease processor speed, memory speed, cache line size, and an enormous number of variables. A large part of the architects job is selecting the best possible combination of these given various workloads.
What you're seeing from Intel is frustration that they're increasing microprocessor performance every 18 months, but that DRAM performance is increasing on a much, much slower scale. This is one of the factors limiting Intel's ability to maintain very high gross margins by selling very highly priced upper end high-frequency microprocessors.
Anyway, thanks for posting. I'm long on Rambus (I'm a long-term investor) and am positive on all of the things you mention as you are negative. My longer term concern with the company lies beyond the PC and the DRAM market, e.g., just what is Matsushita planning to do in the consumer arena with Rambus technology? |
