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: John Walliker who wrote (30850)	9/27/1999 2:25:00 PM
From: Bilow	Read Replies (1) \| Respond to of 93625

Hi John Walliker; The chip scale packaging used by Rambus certainly doesn't hurt, in that it reduces prop delays (and tightens the pin to pin differences), but the vast majority of Rambus's tight setup and hold specs come from enforcing very careful design onto the designers of both the controller and the memory. Another chunk probably comes from the DLL stuff, though my gut instinct tells me that you could design a system with extremely tight setup and hold times without using a DLL. What you have to do is match the prop delays down the two paths, the path from the clock pin to the flip-flop, and the path from the data pin to the flip-flop. The only reason this is not completely trivial is that Rambus is 16 or 18 bits wide. Plus there may be differences between the input times of I/O cells versus the input times of Input only cells, or whatever. This means that one clock input has to connect to 18 flip-flops, while one data input only has to connect to a single flip-flop. (Actually, in most implementations that I can imagine, you would put in two flip-flops, one for each edge of the clock, but the ratios work out the same either way.) So the designers either have to match the long delay clock tree by using slower buffers in the data paths, or, more likely, they arrange to use the same gates with the same output loads in both paths. You can do this by just adding in dummy loads. The interesting part, as a designer, is preventing your dummy loads from being optimized away by the silicon compiler, by the way. And after that, you have to figure out a way to "test" them, if you want to get good fault coverage. I would think that having Rambus design latches and flip-flops for every memory makers memory process would be somewhat excessive. I would think that the standard flip-flops would have specs that would be more than good enough. -- Carl Enjoy, time for me to go to work. Ouch! RMBS is hitting 60 on ISLD again...