Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
In article <u5SdnYBUwKE4xK_LnZ2dnUU7-U2dnZ2d@giganews.com>,
zak <93737@FPGARelated> wrote:
>>On Thursday, October 29, 2015 at 11:04:19 AM UTC-4, jt_eaton wrote:
>>>
>>>
>>> If your D input is 1 then the timing between reset deassert and clock
>>will
>>> determine whether the flop stays 0 or flips to 1.
>>>
>>> If your D input is 0 then it shouldn't matter because you are choosing
>>> between staying at 0 or loading a 0. Its the same result either way.
>>>
>>
>>If you violate timing you should not necessarily expect things to work
>>properly so saying "...choosing between staying at 0 or loading a 0. Its
>the
>>same result either way" on your second example is rolling the dice and
>>hoping you won't get unlucky.
>>
>>Kevin Jennings
>
>Well in that case how do we explain that the well documented reset sync
>design works.
>I mean that design that connects reset to async port of two stages
>synchroniser but connects D input of first register to '1'. If it is
>matter of dice that design would not be reliable as claimed. (also known
>as filtered reset design)
>
>Zak
Zak - very good point - you're analysis is spot on. Looking back at my
designs, I see I am now using the Xilinx recomended reset synchronizer, same
as discussed here. You're right however, in that using that methodology
depends on the assertion "If D is same as Q" on the FF, the clock recovery
check isn't neccesary. Which I advocated against depending on
in my initial response. Looks like I'm not following my own advice.
But I think it's safe for the reasons I stated - Xilinx recommends it, they
know the Flop internals, therefore, they understand the internal behaviors of
the design.
Looking back, however, I noticed I PREVIOUSLY used a different reset
synchronizer:
reg [ STAGES - 1 : 0 ] reset_in_D;
always @( posedge clk )
if( clk_en )
reset_in_D <= { reset_in_D, reset_in };
assign reset_out = reset_in_D[ STAGES - 1 ] | reset_in;
That version probably is a less optimal use of resources, however, I think
it's safer in the general case - since it doesn't depend on any
specific clock recovery behaviour. Same behaviour - async active edge of
reset is passed through asynchronously. Inactive edge is synchronized. No
clock recovery check to worry about, as the async reset on the flop isn't used.
I may reconsider using this other reset synchronizer again....
Regards,
Mark
Article: 158401On Thursday, October 29, 2015 at 3:04:05 PM UTC-4, Mark Curry wrote: >=20 > Zak - very good point - you're analysis is spot on. Looking back at my > designs, I see I am now using the Xilinx recomended reset synchronizer, s= ame > as discussed here. You're right however, in that using that methodology > depends on the assertion "If D is same as Q" on the FF, the clock recover= y > check isn't neccesary. =20 Except that the device responds to changes on the inputs, not from the stat= e of their outputs. In other words, meeting (or not meeting) a timing requ= irement does not depend on the current state of the output, it only depends= on the inputs and their timing relationship. If you want to believe that = "If D is same as Q" on the FF, the clock recovery check isn't necessary." t= hat's up to you, but it's a belief that is not grounded in any sort of real= ity. Belief that if something happens to be in the correct state already so that= means that you can violate timing and not change that state is a false hop= e. It is not what will be guaranteed to happen, it's just something that y= ou hope will happen. Find a datasheet that actually states what you believ= e. Kevin JenningsArticle: 158402
>Except that the device responds to changes on the inputs, not from the >state of their outputs. In other words, meeting (or not meeting) a timing >requirement does not depend on the current state of the output, it only >depends on the inputs and their timing relationship. If you want to believe that >"If D is same as Q" on the FF, the clock recovery check isn't necessary." >that's up to you, but it's a belief that is not grounded in any sort of >reality. > >Belief that if something happens to be in the correct state already so >that means that you can violate timing and not change that state is a false >hope. It is not what will be guaranteed to happen, it's just something that >you hope will happen. Find a datasheet that actually states what you >believe. > >Kevin Jennings It is not a case of output but that this output flags the inner state of the flop as it a case of latching. Anyway, one thing sure the design that is proven to work (what I stated above) connects reset to async port of BOTH flips so surely the second flop is not protected and that means to me no problem is expected there. I Should say metastablity safe rather than proof. Sorry. The question that arises why need connect reset to second flop at all. It serves a different purpose in that if clock stops and you want to reapply reset... Zak --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158403
On 10/29/2015 3:32 PM, KJ wrote: > On Thursday, October 29, 2015 at 3:04:05 PM UTC-4, Mark Curry wrote: >> >> Zak - very good point - you're analysis is spot on. Looking back at my >> designs, I see I am now using the Xilinx recomended reset synchronizer, same >> as discussed here. You're right however, in that using that methodology >> depends on the assertion "If D is same as Q" on the FF, the clock recovery >> check isn't neccesary. > > Except that the device responds to changes on the inputs, not from the state of their outputs. In other words, meeting (or not meeting) a timing requirement does not depend on the current state of the output, it only depends on the inputs and their timing relationship. If you want to believe that "If D is same as Q" on the FF, the clock recovery check isn't necessary." that's up to you, but it's a belief that is not grounded in any sort of reality. > > Belief that if something happens to be in the correct state already so that means that you can violate timing and not change that state is a false hope. It is not what will be guaranteed to happen, it's just something that you hope will happen. Find a datasheet that actually states what you believe. I don't personally know that much about the current state of FPGA internals, but in a related conversation in one of these groups I was told today's technology will not produce an oscillation on the output with a D input timing violation. I would think this is the same thing as the reset not meeting setup/hold timing. Any ideas? -- RickArticle: 158404
On Thursday, October 29, 2015 at 3:55:46 PM UTC-4, zak wrote: >=20 > It is not a case of output but that this output flags the inner state of > the flop as it a case of latching.=20 >=20 This makes no sense, but I won't belabor it > Anyway, one thing sure the design that is proven to work (what I stated > above) connects reset to async port of BOTH flips so surely the second > flop is not protected and that means to me no problem is expected there. >=20 Again, this is your belief that "no problem is expected there" as well as "= proven to work" for that matter. In the 'Synchronized Asynchronous Reset' = circuit, Altera states the benefit as being that reset "takes effect almost= instantaneously, and ensures that no data path for speed is involved, and = that the circuit is synchronous for timing analysis and is resistant to noi= se". Now take a look at the 'Asynchronous Reset with Follower Registers' s= ection which is similar except that the async reset is not connected to any= thing but the first flip flop. In that section, they explain the reasoning= with metastability and MTBF. You would have to suspend your belief to exp= lain why that circuit is "proven to work". =20 In any case, we're way off the beaten path. My only point in this thread w= as what I put in the first post which is "If you violate timing you should = not necessarily expect things to work properly". You have an unfounded bel= ief that "If your D input is 0 then it shouldn't matter because you are cho= osing between staying at 0 or loading a 0. Its the same result either way."= You have provided no datasheet that backs your claim of correct behavior = in spite of a timing violation so I'll leave it at that and move on. If you're lucky, you'll go through your career and never have this bite you= in the rear. If you're not so lucky, well, hopefully the bite is not too = painful and you learn the lesson at that time since you're unwilling to lea= rn it at this time. Kevin JenningsArticle: 158405
>My only point in this thread >was what I put in the first post which is "If you violate timing you should >not necessarily expect things to work properly". You have an unfounded >belief that "If your D input is 0 then it shouldn't matter because you are >choosing between staying at 0 or loading a 0. Its the same result either >way." You have provided no datasheet that backs your claim of correct behavior >Kevin Jennings In that case the same concept should hold true for setup/hold as well. If so timing violation will occur even though D input has no transition. What would setup or hold mean then? Zak --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158406
In article <9c5808ac-160c-49b1-a141-b311b69a75ba@googlegroups.com>, KJ <kkjennings@sbcglobal.net> wrote: >On Thursday, October 29, 2015 at 3:04:05 PM UTC-4, Mark Curry wrote: >> >> Zak - very good point - you're analysis is spot on. Looking back at my >> designs, I see I am now using the Xilinx recomended reset synchronizer, same >> as discussed here. You're right however, in that using that methodology >> depends on the assertion "If D is same as Q" on the FF, the clock recovery >> check isn't neccesary. > >Except that the device responds to changes on the inputs, not from the state >of their outputs. In other words, meeting (or not meeting) a timing requirement >does not depend on the current state of the output, it only depends on the inputs >and their timing relationship. If you want to believe that "If D is same as Q" >on the FF, the clock recovery check isn't necessary." that's >up to you, but it's a belief that is not grounded in any sort of reality. This isn't true in general at all - it all depends on the underlying design of the cell. The SDF format was specifically modified to allow this feature - to do a timing check depending on some other state (i.e. internal state of the cell). >Belief that if something happens to be in the correct state already so that >means that you can violate timing and not change that state is a false hope. >It is not what will be guaranteed to happen, it's just something that you >hope will happen. Find a datasheet that actually states what you believe. I think you're missing my point - we're agreeing more than disagreeing. I don't advocate depending on that hand wavy, but not documented requirement that no clock recovery check is neccesary when D==Q. However, as Zak points out, the Xilinx recommended reset resynchronization implies that this is true. If it isn't then the recommended reset synchronization has a timing hazard. It may be similar to another "heard, but not documented" feature of Xilinx technology - that a LUT output will NOT glitch if you only change one input. Another feature that I wouldn't recommended depending on, but is asked from time to time in these and similar forums, and I beleive Xilinx has stated a "hand wavy" ok. Regards, MarkArticle: 158407
> >I don't personally know that much about the current state of FPGA >internals, but in a related conversation in one of these groups I was >told today's technology will not produce an oscillation on the output >with a D input timing violation. I would think this is the same thing >as the reset not meeting setup/hold timing. > >Any ideas? > >-- > >Rick Can't be possible. It is not matter of technology since you need a known state at sampling window rather than changing state. Technology can improve on timing window but this can't be zero time. Asynchronous based design doesn't care about timing of flops but logic decisions go through varying delay paths... I heard years ago Achronix trying some ultra high speed fpga based on async design but never heard any update. Zak --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158408
On 10/29/2015 5:40 PM, zak wrote: >> >> I don't personally know that much about the current state of FPGA >> internals, but in a related conversation in one of these groups I was >> told today's technology will not produce an oscillation on the output >> with a D input timing violation. I would think this is the same thing >> as the reset not meeting setup/hold timing. >> >> Any ideas? >> >> -- >> >> Rick > > Can't be possible. It is not matter of technology since you need a known > state at sampling window rather than changing state. Technology can > improve on timing window but this can't be zero time. I didn't say there couldn't be metastability. I said there would be no oscillation. Similar to balancing a pencil on end, the state resolves monotonically with an arbitrary delay. > Asynchronous based design doesn't care about timing of flops but logic > decisions go through varying delay paths... I heard years ago Achronix > trying some ultra high speed fpga based on async design but never heard > any update. I believe they are targeting only very large customers and have been shipping product for some time now, but I don't recall for sure. It should be easy to check out. -- RickArticle: 158409
> >I didn't say there couldn't be metastability. I said there would be no >oscillation. Similar to balancing a pencil on end, the state resolves >monotonically with an arbitrary delay. > > >Rick No oscillation still doesn't mean correct sampling but will help signal settle for next flop. It remains that input must be in a known state for some finite time to be sampled correctly. Zak --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158410
On Thursday, October 29, 2015 at 8:34:48 AM UTC-4, zak wrote: > >One of fundamental aspects of implementing an asynchronous reset, which > is > >often overlooked, is that the reset must be DEASSERTED with proper > timing > >margin with respect to the clock. This is why Altera, and many other > >vendors recommend synching the reset to the relevant clock domain.=20 > Recovery is > >defined as the setup time of the deassertion of the reset with respect > to > >the clock. Removal is defined as the hold time of the deassertion of > the > >reset with respect to the clock. This is defined in the Altera > documenation > >-- I think it's in the Quartus handbook. Timequest does an excellent > job > >analyzing these paths if proper timing constraints are defined. > > > >Robert - lead VHDL/Verilog trainer > >www.digitaldesignconcepts.org >=20 > Thanks Robert, >=20 > My original question was not about "standard" definitions of > recovery/removal but rather the relation of reset deassertion to D input. >=20 >=20 > Normally with setup/hold if D is not changing then timing violation does > not apply.=20 > Does this apply to recovery/removal as well with respect to D input? >=20 > I think Mark Curry answered my question. I will be grateful if you can > share your views with this regard. >=20 > Zak > --------------------------------------- > Posted through http://www.FPGARelated.com Recovery and Removal does NOT apply to the D input. It only applies to the= application of asynchronous signals (preset or set) and the clock. The D= input is a don't care for this timing check. Simply put, if your flip/flo= p's asynchronous inputs and clocks change at the same time, or without enou= gh timing margin, the flop's output will be indeterminate or unstable. As I= said, this is a timing check that is often overlooked by designers.Article: 158411
> >Recovery and Removal does NOT apply to the D input. It only applies to >the application of asynchronous signals (preset or set) and the clock. The >D input is a don't care for this timing check. Simply put, if your >flip/flop's asynchronous inputs and clocks change at the same time, or without >enough timing margin, the flop's output will be indeterminate or unstable. As >I said, this is a timing check that is often overlooked by designers. Any proof? If you look at the well tried circuit of reset synchronisation, according to your view it should not work. So somebody should be wrong. The circuit is this: '1' connects to D1(input of flop1) , Q1 output wired to D2(flop2). Q2 is now the synchronised reset(if deassrted). Both flops clocked by same system clock and their asyc port wired to reset(arrives ant time). This design cannot be explained to work unless D1 & D2 inputs are relevant to definition of recovery/removal as the design must ignore the situation when clock edge of second flop is too close to reset deassertion. It will then fail 50/50 Zak --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158412
> >If you violate timing you should not necessarily expect things to work >properly so saying "...choosing between staying at 0 or loading a 0. Its the >same result either way" on your second example is rolling the dice and >hoping you won't get unlucky. > >Kevin Jennings There is no timing to violate. The vendors data sheet will specify a reset_deassert to clock rise setup time that is only valid if the D input has a 1 that has met the D input setup time.If D is a 0 then there is no timing requirement. John Eaton --------------------------------------- Posted through http://www.FPGARelated.comArticle: 158413
> >Well in that case how do we explain that the well documented reset sync >design works. >I mean that design that connects reset to async port of two stages >synchroniser but connects D input of first register to '1'. If it is >matter of dice that design would not be reliable as claimed. (also known >as filtered reset design) > >Zak 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 http://www.FPGARelated.comArticle: 158414
On 10/30/2015 4:42 AM, zak wrote: >> >> I didn't say there couldn't be metastability. I said there would be no > >> oscillation. Similar to balancing a pencil on end, the state resolves >> monotonically with an arbitrary delay. >> >> >> Rick > > No oscillation still doesn't mean correct sampling but will help signal > settle for next flop. It remains that input must be in a known state for > some finite time to be sampled correctly. 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? -- RickArticle: 158415
On Friday, October 30, 2015 at 12:16:19 PM UTC-4, jt_eaton wrote: >=20 > There is no timing to violate. The vendors data sheet will specify a > reset_deassert to clock rise setup time that is only valid if the D input > has a 1 that has met the D input setup time.If D is a 0 then there is no > timing requirement. >=20 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]https://www.altera.com/en_US/pdfs/literature/an/an545.pdfArticle: 158416
In article <8a16f740-4fdc-45b2-a502-c612072a531e@googlegroups.com>, KJ <kkjennings@sbcglobal.net> wrote: >On Friday, October 30, 2015 at 12:16:19 PM UTC-4, jt_eaton wrote: >> >> There is no timing to violate. The vendors data sheet will specify a >> reset_deassert to clock rise setup time that is only valid if the D input >> has a 1 that has met the D input setup time.If D is a 0 then there is no >> timing requirement. >> > >Produce the Altera (since that's what has been discussed) datasheet or application note or some other quality source that supports your statement. > >To refute, I'll put up the following from "AN 545: Design Guidelines and Timing Closure Techniques for HardCopy ASICs". Admittedly, this is for HardCopy 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 this case it is between 'reset' and 'clock'. > >Reset recovery time refers to the time between de-asserted reset and when the clock signal goes high again. Violating recovery time causes metastability on register outputs. > >Kevin Jennings >[1]https://www.altera.com/en_US/pdfs/literature/an/an545.pdf 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, MarkArticle: 158417
>On 10/30/2015 4:42 AM, zak wrote: >>> >>> I didn't say there couldn't be metastability. I said there would be no >> >>> oscillation. Similar to balancing a pencil on end, the state resolves >>> monotonically with an arbitrary delay. >>> >>> >>> Rick >> >> No oscillation still doesn't mean correct sampling but will help signal >> settle for next flop. It remains that input must be in a known state for >> some finite time to be sampled correctly. > >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 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 http://www.FPGARelated.comArticle: 158418
On Friday, October 30, 2015 at 2:49:26 PM UTC-4, Mark Curry wrote: > But, Altera's document directly refutes your last statement. >=20 > 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." >=20 > The clock recovery check depends on the state of areset, clk, AND the D-i= nput. >=20 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 JenningsArticle: 158419
On 10/30/2015 3:58 PM, zak wrote: >> On 10/30/2015 4:42 AM, zak wrote: >>>> >>>> I didn't say there couldn't be metastability. I said there would be > no >>> >>>> oscillation. Similar to balancing a pencil on end, the state > resolves >>>> monotonically with an arbitrary delay. >>>> >>>> >>>> Rick >>> >>> No oscillation still doesn't mean correct sampling but will help > signal >>> settle for next flop. It remains that input must be in a known state > for >>> some finite time to be sampled correctly. >> >> 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 > > 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 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. -- RickArticle: 158420
In article <0e1bc68e-73c4-409d-8886-62e886915507@googlegroups.com>, KJ <kkjennings@sbcglobal.net> wrote: >On Friday, October 30, 2015 at 2:49:26 PM UTC-4, Mark Curry wrote: >> 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. >> > >It wasn't my statement it was Altera's statement. Suffice it to say then that Altera's own document is self-contradictory. On page 11, in the section 'Metastability safe reset design' they >clearly state that violating reset recovery requirements can cause metastability. On page 13, as you found they state the exact opposite. Given that Altera is talking out of both sides, 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 perhaps 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 general 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 >requirement with no penalty as page 13 states, then there effectively is no such requirement that needs to be 'met' so there would be no need to synchronize the trailing edge of reset. What >does it even mean to have a requirement that does not need to be met? Now granted, they do have the caveat about 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 synchronize 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. 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, MarkArticle: 158421
>On 10/30/2015 3:58 PM, zak wrote: >>> On 10/30/2015 4:42 AM, zak wrote: >>>>> >>>>> I didn't say there couldn't be metastability. I said there would be >> no >>>> >>>>> oscillation. Similar to balancing a pencil on end, the state >> resolves >>>>> monotonically with an arbitrary delay. >>>>> >>>>> >>>>> Rick >>>> >>>> No oscillation still doesn't mean correct sampling but will help >> signal >>>> settle for next flop. It remains that input must be in a known state >> for >>>> some finite time to be sampled correctly. >>> >>> 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 >> >> 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 > >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 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 http://www.FPGARelated.comArticle: 158422
On 10/30/2015 4:45 PM, zak wrote: >> On 10/30/2015 3:58 PM, zak wrote: >>>> On 10/30/2015 4:42 AM, zak wrote: >>>>>> >>>>>> I didn't say there couldn't be metastability. I said there would > be >>> no >>>>> >>>>>> oscillation. Similar to balancing a pencil on end, the state >>> resolves >>>>>> monotonically with an arbitrary delay. >>>>>> >>>>>> >>>>>> Rick >>>>> >>>>> No oscillation still doesn't mean correct sampling but will help >>> signal >>>>> settle for next flop. It remains that input must be in a known state >>> for >>>>> some finite time to be sampled correctly. >>>> >>>> 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 >>> >>> 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 >> >> 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 > > 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. 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? -- RickArticle: 158423
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.comArticle: 158424
On Friday, October 30, 2015 at 4:28:37 PM UTC-4, Mark Curry wrote:
>=20
> 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=20
> the D-nput value is already at a stable value (0) matching the output val=
ue Q (0)."
>=20
Not saying that's not the case, I'm just saying that the part about 'D=3DQ'=
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.
> 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=3D=3DQ, the clock recovery isn't checked/invalid and the rese=
t recovery
> mechanism, (as suggested by both Xilinx and Altera) works. =20
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=3DQ=3D1, but not if D=3DQ=3D0. While this is a differ=
ent example, it does expose that just because D=3DQ, 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=3DQ path that you're proposing applies to the fli=
p 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? =20
>=20
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].
> Do you follow this recommendation?
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] http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_7/sim.p=
df page 56, section titled 'Set, Resets, and Synthesis Optimization' in cha=
pter 5 'Coding for FPGA Device Flow'.
[2] http://quartushelp.altera.com/14.0/mergedProjects/verify/da/comp_file_r=
ules_reset_external.htm
[3] This form of latch has been directly observed to eventually fail with =
certain common technologies if D=3DQ=3D1.
process(D, C)
begin
if (C=3D1) then
Q <=3D D;
end if;
end process;
This will fail as well
Q <=3D (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 unles=
s specifically prevented from doing so, but if that term is removed it will=
make the latch fail
Q <=3D (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.
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z