SI
SI
discoversearch

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
RMBS 94.82+2.7%Nov 26 3:59 PM EST

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: John Walliker who wrote (30818)9/27/1999 1:44:00 PM
From: Bilow  Read Replies (2) of 93625
 
Hi John Walliker; Re: Explain why the specified setup and hold time window is longer for the IBM 256Mbit DDR process than the older and slower Samsung 128Mbit DRDRAM process. Could it be due to design differences in the data latches that form part of the Rambus interface? This is a great request, I'd be happy to.

Your hypothesis is reasonable to those not familiar with the guts of chips. In fact, if there were design differences in the data latches that form part of the Rambus interface, that could explain the difference in setup and hold times. But that is not what causes these differences. In fact, any modern flip-flop will have setup and hold requirements far tighter than the Rambus spec, or the DDR spec.

First of all, let me note that the very tight setup and hold times on RDRAM were a major pain for the memory makers. It is tight specifications like these that contributed to the memory chips having low yield and late delivery &c. If engineers wanted to build DDR or SDR chips to that sort of setup and hold time requirements, they could, but they don't because it isn't necessary - the frequencies are a lot lower.

But how is it that two parts that use the same flip-flop can end up with different setup and hold requirements? The difference lies in differences in the propagation delay paths to the clock and data, and differences in how these delays scale with temperature, voltage, and process (TVP).

The important thing to note is that setup and hold times are guaranteed over the TVP range. At any particular TVP combination, the actual setup and hold are going to be much tighter than the guaranteed numbers. This is because the setup and hold times depend on TVP. As such, they wander around, as, for instance, the temperature changes, and this is what widens them out. That is, most of the widening occurs in the paths from the pins of the chip to the data and clock inputs of the flip-flop. The propagation delays down these paths depend on TVP.

For the purposes of metastability collapse calculation, one must recognize that the system is at a particular TVP, and, therefore, the setup and hold are a lot tighter than the guaranteed numbers. This is why two systems (almost inevitably) end up with different setup and hold times even though they use the same flip-flop design. These facts are evident to anyone who has designed a chip, at any sort of performance level, I believe.

As to the possible existence of a different flip-flop in the Rambus I/O, I seriously doubt this. The chip engineers generally provide several different flip-flops for designers to choose from, these will have a range of setup and hold times, and different metastability characteristics as well. And what are those setup and hold times? I can look up the data for you, if you are interested, and, in fact may edit it into this post, but typical numbers for modern (i.e. .25u CMOS) processes would be setup and hold times on the order of 50 ps, and that figure is over TVP. At any particular TVP, the setup and hold times are minuscule, though they are not usually guaranteed by the vendor.

This is a great opportunity to further my cause of extending the understanding of digital logic. I have more admiration for you than you think, in that you are willing to discuss these things with me.

-- Carl
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext