negative hold time

Hold is, as you might know, how long data needs to be stable after the edge of the clock. There is nothing tricky about a negative hold value which suggests electrons going back in time. It just means that internally to the flop, the data has much more delay to the sampler than the clock. If you think about how you fix a hold violation, it becomes clearer: you add a delay to the data input of the flop. A flop with negative hold requirement has some delay added to the data path already.

In case it's not obvious, the implication of this is that the input signal can change _before_ the flip-flop is clocked. The difference in time between doing this and receiving the clock is the same as the magnitude of the negative hold time.

Charles B. Cameron

Let me blame T.I. for inventing (in the late 'sixties) the stupid name "Hold Time", when we are really talking about the latest possible instant of Set-Up Time.

Any D-flip-flop has an extremely tiny timing window (femtoseconds wide), where it takes a snapshot of the D-input and generates either Q or Qbar. The exact position (in time) of this tiny window with respect to the clock edge is a function of processing, temperature and Vcc.

The earliest possible position is specified as Set-up-time. The latest possible position is (unfortunarely) specified as Positive Hold Time if it is later than the clock edge, and as Negative Hold Time if it is before the clock edge.

It would be so much nicer if we used >

change _before_ the flip-flop is clocked. The difference in time between doing this and receiving the clock is the same as the magnitude of the negative hold time.

Really ?!

And I thought the Window between Setup and Hold is where the input signal is NOT supposed to change (e.g. remain stable) !

Depending on the clock transition time the window can be larger or smaller (and is also of course process dependent).

Hmm, all flops I have seen generate both Q and Qbar.

Actually the latest possible change of the data is Setup time, and the earlist possible change is Hold Time.

rudi ======================================================== ASICS.ws ::: Solutions for your ASIC/FPGA needs ::: ..............::: FPGAs * Full Custom ICs * IP Cores ::: FREE IP Cores ->

Rudi,

Yawn.......

Bob

Besides some meaningless semantic quibbling, Rudi's answer indicated basic conceptual differences. A component data sheet should have a component-centric view: The flip-flop has a window in time during which the D-input must be stable, to guarantee predictable operation. This window has an early edge (commonly called set-up time, often specified as a min, but I would call it a max), and it has a late edge (commonly called positive hold time when it is later than the clock edge, negative hold time when it is before the clock edge. I would like to call it the min set-up time, but it's too late to bring sanity to this issue).

Whether something is a min or a max depends on your perspective. With a bridge over a highway, the "14 feet" specification is a min for the bridge builder, but a max for the truck driver...

Much of this is semantics, but semantics can interfere with understanding, sometimes. Peter Alfke

Rudolf Usselmann wrote:

I don't know if any further comment is warrented or valuable, but I am waiting for a download and thought I would post my 2 cents worth.

I agree that the data sheet should be "component" centric. But this is normally done in terms of the interface. The internal sampling of the data input is what is going on, but that is not relevant given occam's razor. All the user needs to know is to maintain the data input stable during a timing window. Using one set of terms vs. the other does not make the mechanics more clear in my point of view.

I agree that the basis of this timing window is not clearly understood by many engineers. The way to improve the understanding is to have the data sheets (or app notes) clearly explain the basis for the window (and how it is measured) rather than just leaving it up to the engineer to try to figure out what the data sheet writer is trying to spec. I often have trouble figuring out just what a spec is trying to say. Perhaps a JEDEC, EIA or other standards body could help by defining measurement terms, what they are measuring and how they are measured?

I especially find it interesting (not in a good way) when the spec I am looking for is not in a data sheet, but instead a similar one is given in its place. For example, when I am looking for max static current draw over temperature and I am given a typical current at 25C. What is the designer trying to tell me?

Here is an explanation for that typical number: In the olden days, static current was extremely low, microamps or a few milliamps, and was usually swamped out by the dynamic power consumption.

So the argument went this way: If the part is hot because it is working hard, running with a fast clock, nobody really cares about the leakage current. Even if it's higher than the room temp spec, it is still an insignificant part of the total current that made the chip get so hot.

When the part is not working hard, it will be near room temperature, and because of the lack of dynamic power, the static current is a standby value, and may be important. And everybody knows that leakage current doubles for every 10 degree C increase in temperature. (The newly increased leakage current is actually rising less dramatically).

With the recent dramatic increase in leakage current (by orders of magnitude), that old reasoning may have to be revised...

Peter Alfke

... and designs need to consider complete power removal of those hungry devices during sleep times, which moves away from a single chip solution..

I think rickman was asking about TYP vs MAX ? Typical appears on a data sheet for many reasons :

- It's a better sounding number (don't laugh..)

- It's easier/quicker to derive than a MAX corner value.

- It's also usefull for average battery life calculations.

but sometimes, customers want to know worst case battery life, and they may even be using batteries good enough to spec that over temperature. So they need a corresponding chip value.

If the spec omits MAX, the designer could be trying to say any or all of :

- The silicon is so new, we don't know this number yet

- Our test coverage could not guarantee this on all devices

- We do not bother to test it

- A few devices have this very high, and we are unsure why

- Why does that number matter again ?

The new Lattice 4000 family, and Xilinx Coolrunner II do seem to have good Typ, and Max static Icc specs, so perhaps those customers are more demanding ?

Personally, I prefer to see Icc vs Temp plots, and in the old days of data sheets, they would plot Typ and Max on the same graph!

-jg

Uh, what if "room temp" is 85C? That is a valid operating spec for many chips, right?

That was just one example I could think of off the top of my head. There are lots of timing related specs or even functional specs that are just not clear in many data sheets. I think that often these specs reflect how the parts are tested, without thorough consideration of how they are used.

No, I was not asking about just the difference between TYP and MAX, my issue is TYP at 25C vs. anything at full temp range. Static current normally goes *way* up as you approach 85C and gets serious as you get near 125C on automotive temp parts. Try specing the max life of a battery powered RTC over a temp range of -40C to 125C.

Normally they give a footnote about this saying this is "preliminary" and will be filled out later.

This is also normally stated when true.

Same as above.

Now we are getting to my concern.

If they are saying that, then I need a new supplier. :)

This was just one example of poorly spec'd data. I have also seen poor specs in timing and functionality.

There is another aspect: When we spec the max value, we have to guarantee it. That can hurt when one of a thousand pins has a leakage current of 11 uA. It feels bad to throw away a multi-$100 part for that reason especially when it is in short supply. On the other hand, a 10 uA per pin spec looked silly on the XC3000L, where the max Icc was spec'ed as 50 uA. We solved this by connecting all pins together in the tester, and still guaranteeing 10 uA total for all of them together. Some specifications have a very wide margin, but it is expensive to measure extremely low currents. That's where "typical" helps...

I was po>

Sounds a good solution..

It depends on the process, and device. Here are some real numbers, as an example (appologies for the brand)

ispMACH 4032Z ICC Standby Power Supply Current TYP MAX Vcc = 1.8V, TA = 25°C 10 - µA Vcc = 1.9V, TA = 70°C 13 20 µA Vcc = 1.9V, TA = 85°C 15 25 µA Vcc = 1.9V, TA = 125°C 22 - µA

My Comments : These are micro-amp figures, so are in the region of what was considered classic leakage, but they are a little better behaved - not log related.

Here, Iq only climbs slowly with temp, and the ratio or margin of MAX:TYP is relatively low. ( under 2:1 )

That means either the process control is very good, or that there is a yield hit in meeting the MAX corner.

To me this is (unusually) well spec'd. One can see a room temp/average Vcc value, for nominal calculations, and one can also see a choice of upper corner values, that show both the temp/Vcc effect alone, and also the process corner effect.

-jg

(snip)

By having two parameters you can have a typical for both, and also a max/min (whichever is applicable).

Now, I suppose the names could be more symmetric. What is the opposite of setup? Maybe takedown, or something like that? Maybe release is the opposite of hold. I don't think setup/takedown or release/hold make very good pairs. It might be that I am too used to setup/hold by now.

-- glen

My preference is for the term Time Aperture. That makes it clear it is narrow, and requires either leading and trailing numbers, or a centre point, and a width would also be valid. The concept of Aperture then also naturally leads onto adding Jitter on the clock, or data to any design margins. A centre point and width spec would more naturally align with Jitter values.

It also leads to Aperture skew, which is the miss-match in these windows across multiple flip flops in a device. Not good if you are crossing clock domains. These can be much wider than the metastable aperture.

Then there is the metastable aperture (modeled) you mention above.

I'm not sure I'd agree that the 0.03fs is the actual width of the aperture. The 0.03 is derived by extrapolate from a log eqn fit, and has units of fs.

Any attempt to measure the aperture would be swamped in jitter, as best in class jitter is 'some picoseconds', rather than 'sub-picoseconds'. A one volt signal with 1ns risetime, has 1mv/ps, so system noise (gnd/vcc/crosstalk) in the order of 1mv will create in the region of 1ps of jitter. 100ps rise, with 1% system noise also gives 1ps jitter.

I can think of a method where you might get close to getting a physical aperture width value, but it would need a test chip, rather than std devices.

-jg