recovery/removal timing

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

http://www.sunburst-design.com/papers/CummingsSNUG2003Boston_Resets.pdf

Zak
---------------------------------------
Posted through http://www.FPGARelated.com

On Friday, October 30, 2015 at 4:28:37 PM UTC-4, Mark Curry wrote:
> 
> 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)."
> 

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 device 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 that 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 of 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 clock cycle wide 'reset' clock cycle followed by 'non-reset' and normal operation.  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 end user really has no clue as to whether the proposed async reset of that second flip flop that is used to generate the final chip wide reset is actually working the way you think it does or not.  Try to use an async reset like that where every clock cycle does need to be correct many millions of times every second and run for days/weeks under environmental and voltage stress if you want to demonstrate reliability.  Discussing it within the context 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 context where failure would go undetected does not demonstrate reliability of the circuit in any sort of meaningful way.

> If the D input did NOT match, I think ALL of us would agree that you have a hazard.

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

> But since D==Q, the clock recovery isn't checked/invalid and the reset recovery
> mechanism, (as suggested by both Xilinx and Altera) works.  

Well, Altera as we've seen contradicts themselves.  In another place they do not use the async reset input at all, instead they feed it into the D input [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 different example, it does expose that just because D=Q, doesn't necessarily imply anything special without in-depth knowledge of how the underlying device 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 flip flop but not to the latch.

> Can there be
> any other conclusion?  Do you think that both A's and X's recommended
> methodology has a hazard?  
> 
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 time 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 figure 12-19 on page 31) so it's hard to say they are advocating the asynchronous reset of anything beyond that first flip flop.  The reality is that there is no reason for even that flip flop to be reset asynchronously either as Altera shows in [2].

> Do you follow this recommendation?
I don't use async reset at all unless the device I'm interfacing with requires it for some reason, and typically there is no such requirement.  I'll bring 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 relevant 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 since they aren't the device manufacturer and again, the context of the circuit is the fail-safe power on reset.  Not dissing their expertise, just framing it.  Unfortunately, in section 7.1 which is specifically devoted to explaining why there is no metastability on the second flip flop, all they offer up as an explanation is to say "There is no logic differential between the 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 bolster that claim, they just simply made a claim.  In the next section, they indicate 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 any other.  For a circuit that cannot tolerate failure, the idea that you can ignore a timing requirement because the input and output of a flip flop are 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.  But it was interesting.

Kevin Jennings

[1] http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_7/sim.pdf page 56, section titled 'Set, Resets, and Synthesis Optimization' in chapter 5 'Coding for FPGA Device Flow'.

[2] http://quartushelp.altera.com/14.0/mergedProjects/verify/da/comp_file_rules_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 <= D;
  end if;
end process;

This will fail as well
Q <= (D and C)
  or (Q and not(C));

This form of latch will not fail, but only if implemented exactly like this.  The third term is redundant and will be removed by synthesis tools unless specifically prevented from doing so, but if that term is removed it will make the latch fail

Q <= (D and C)
  or (Q and not(C))
  or (D and Q); <-- Redundant but required

[4] https://www.altera.co.jp/ja_JP/pdfs/literature/hb/qts/qts_qii51006.pdf, page 31, Figure 12-19.