recovery/removal timing

Thats called a metastable filter. The dice toss determines which cycle produces the reset but the design shouldn't care and work in all cases. If you put an asynchronous signal into two different metastable filters then their outputs may not be identical.

John Eaton

--------------------------------------- Posted through

formatting link

Reply to
jt_eaton
Loading thread data ...

I'm not sure what "correct sampling" means regarding metastability. By definition the sampling is done on a changing signal, so the resulting value is not defined.

I guess I'm not sure what you are saying. Did we lose context of the original issue?

--

Rick
Reply to
rickman

Produce the Altera (since that's what has been discussed) datasheet or appl ication note or some other quality source that supports your statement.

To refute, I'll put up the following from "AN 545: Design Guidelines and Ti ming Closure Techniques for HardCopy ASICs". Admittedly, this is for HardC opy ASICs, not FPGAs but note that there is no mention of the state of the 'D' input. Timing issues are always between two signals, not three. In th is case it is between 'reset' and 'clock'.

Reset recovery time refers to the time between de-asserted reset and when t he clock signal goes high again. Violating recovery time causes metastabili ty on register outputs.

Kevin Jennings [1]

formatting link

Reply to
KJ

Kevin,

I'm lost who's arguing what in this thread. Usenet's a lousy forum for this thing. But, Altera's document directly refutes your last statement.

Page 13 of that Document: "In the event that the ref_clk edge arrives close to the time areset is removed from FF1 and FF2, there is no metastability risk on FF2 because the D-input value is already at a stable value."

The clock recovery check depends on the state of areset, clk, AND the D-input.

Regards,

Mark

Reply to
Mark Curry

no

resolves

signal

for

The input D must be read by flop as '0' or '1' according to predefined levels intrinsic to the flop. If D is changing how do you expect to sample it as '0' or '1'. There should be no transition near the sampling clock edge and D must be defined as either '0' or '1' so that the level is sampled onto Q. This is the whole point in any sampling device. Nothing mysterious here. It is the very basis of tSU and tH

Zak

--------------------------------------- Posted through

formatting link

Reply to
zak

because

nput.

It wasn't my statement it was Altera's statement. Suffice it to say then t hat Altera's own document is self-contradictory. On page 11, in the sectio n 'Metastability safe reset design' they clearly state that violating reset recovery requirements can cause metastability. On page 13, as you found t hey state the exact opposite. Given that Altera is talking out of both sid es, I guess they are not such a good source after all. Good catch!

My statement then is that the page 13 statement must be either wrong or per haps written poorly or the page 11 statement is true only under conditions that are left unstated. If page 13 is correct, then it would be true in ge neral and there would not even be a reset recovery time requirement in the first place. Think about it, if you can violate the reset recovery time re quirement with no penalty as page 13 states, then there effectively is no s uch requirement that needs to be 'met' so there would be no need to synchro nize the trailing edge of reset. What does it even mean to have a requirem ent that does not need to be met? Now granted, they do have the caveat abo ut the input being stable, but that will typically be the case anyway since most upstream flops will be in a stable state due to the reset.

So, if you really believe page 13, you shouldn't feel any need to synchroni ze reset. If you really believe page 11, then you will. If you don't know which way to go, you should take the safe route and synchronize.

Kevin Jennings

Reply to
KJ

Of course. I think we all understand what sampling is.

On the other hand, I have no idea what your point in discussing "correct sampling" is.

--

Rick
Reply to
rickman

I agree, the statement is poorly worded. What I think it meant to say, (and what I've been arguing all along) is that "..there is no metastability risk on FF2 because the D-nput value is already at a stable value (0) matching the output value Q (0)."

If the D input did NOT match, I think ALL of us would agree that you have a hazard. But since D==Q, the clock recovery isn't checked/invalid and the reset recovery mechanism, (as suggested by both Xilinx and Altera) works. Can there be any other conclusion? Do you think that both A's and X's recommended methodology has a hazard? Do you follow this recommendation?

If I had time, I'd quickly simulate this. It'd be easy to setup. I know longer rememeber enough about UDP modeling to just look at the cell models and see what it does. I *DO* recall seeing this in models in the past however - qualifying a recovery check with a comparison D==Q.

Regards,

Mark

Reply to
Mark Curry

be

By

resulting

clock

Nothing

On the point of oscillation that you raised. If technology can dampen oscillations or completely remove them then it is only part of the timing violation problem. It remains that there will be tSU/tH requirement no matter what technology is used. Dampening oscillations will only improve on MTBF.

Zak

--------------------------------------- Posted through

formatting link

Reply to
zak

I didn't say the oscillations were the same thing as metastability. The point is in the case of the reset timing, there is no timing violation on the D input. So unless there was an oscillation from the reset timing violation, why would the output change at all?

--

Rick
Reply to
rickman

This doc (see page 22) answers directly issues raised in this post

formatting link

Zak

--------------------------------------- Posted through

formatting link

Reply to
zak

and what I've

because

ue Q (0)."

Not saying that's not the case, I'm just saying that the part about 'D=Q' in your statement is not supported by any device manufacturer from what I' ve been able to find. Maybe it's an oversight on their part, maybe their d evice happen to work the way you would like, who knows? The point is when you rely on things that are not specifically supported, you're the one out on the limb. The fact that Altera directly contradicted themselves means t hat one of those statements 'as-is', is incorrect. Maybe it's the page 13 statement that should be completely removed?

The problem with discussing the use of the async reset within the context o f a 'power on reset' is that within that context, the circuit usage is fail

-safe. Let's say one or both of those flip flops really does flake out and goes to the wrong state, what happens? Either the reset pulse inside the device is shorter than it "could" have been, or the flops end up seeing the reset followed by a 'non-reset' for one clock cycle followed by a one cloc k cycle wide 'reset' clock cycle followed by 'non-reset' and normal operati on. In either of those scenarios, I would suspect that nearly every single FPGA design in the world will work just fine without any hiccups. So an e nd user really has no clue as to whether the proposed async reset of that s econd flip flop that is used to generate the final chip wide reset is actua lly working the way you think it does or not. Try to use an async reset li ke that where every clock cycle does need to be correct many millions of ti mes every second and run for days/weeks under environmental and voltage str ess if you want to demonstrate reliability. Discussing it within the conte xt of a 'once every now and then' event doesn't show much. By the way, I'm not advocating anyone to do this, just using this example to show that the 'power on reset' application of the async reset of a flip flop in the cont ext where failure would go undetected does not demonstrate reliability of t he circuit in any sort of meaningful way.

a hazard.

I'm not sure why you say that, but OK.

t recovery

Well, Altera as we've seen contradicts themselves. In another place they d o not use the async reset input at all, instead they feed it into the D inp ut [2]. I haven't found anything on Xilinx's website. In fact, what I've found specifically recommends that you never use the asynchronous reset [1] . Can you post the Xilinx recommendation that you are discussing?

As a similar, but related example, [3] is an example of a transparent latch that will fail if D=Q=1, but not if D=Q=0. While this is a differ ent example, it does expose that just because D=Q, doesn't necessarily im ply anything special without in-depth knowledge of how the underlying devic e is implemented in transistor in the silicon. If you want to take a crack at it, explain why the D=Q path that you're proposing applies to the fli p flop but not to the latch.

Can't comment on X's recommendation since I haven't been able to find it. A recommended two different things within the span of two pages of the same document so obviously they don't quite understand it well enough at the ti me to document it either. But in the Quartus 13.1 handbook [4], the async reset is only used to reset the very first flip flop in the chain (See figu re 12-19 on page 31) so it's hard to say they are advocating the asynchrono us reset of anything beyond that first flip flop. The reality is that ther e is no reason for even that flip flop to be reset asynchronously either as Altera shows in [2].

I don't use async reset at all unless the device I'm interfacing with requi res it for some reason, and typically there is no such requirement. I'll b ring the async reset into D and clock it through pretty much as I would any other async input. I've never had the need to reset the device absolutely as fast as possible and never had the need to operate when the clock isn't up and running. Basically reset like shown in [2].

The link that Zak last posted by Cummings et al is actually somewhat releva nt but it comes from secondary sources. The authors all appear to have at least some ASIC design expertise, but they have no real skin in the game si nce they aren't the device manufacturer and again, the context of the circu it is the fail-safe power on reset. Not dissing their expertise, just fram ing it. Unfortunately, in section 7.1 which is specifically devoted to exp laining why there is no metastability on the second flip flop, all they off er up as an explanation is to say "There is no logic differential between t he input and output of the flip-flop so there is no chance that the output would oscillate between two different logic values." They did not indicate that they performed any Spice simulations and actual lab testing to bolste r that claim, they just simply made a claim. In the next section, they ind icate that they suggested to a doubter that they perform a transistor level sim and that person then reported that it agreed with the prediction. So at least someone performed some simulation, but again without lab data, it' s not as strong.

Probably all this means is that for a circuit such as power on reset where failure is tolerated, any synchronizing circuit will work just as well as a ny other. For a circuit that cannot tolerate failure, the idea that you ca n ignore a timing requirement because the input and output of a flip flop a re in the same state is a dicey one to bet anything on.

Anyway, I'm sure the horse is long since dead and the beating can stop. Bu t it was interesting.

Kevin Jennings

[1]
formatting link
df page 56, section titled 'Set, Resets, and Synthesis Optimization' in cha pter 5 'Coding for FPGA Device Flow'. [2]
formatting link
ules_reset_external.htm [3] This form of latch has been directly observed to eventually fail with certain common technologies if D=Q=1. process(D, C) begin if (C=1) then Q
Reply to
KJ

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.