Hello everybody! As I could read, clock enables are pretty to avoid glitches on FFs or counters. I hope, so does mine. My problem: A counter, triggered by a master-clock is enabled by a signal which might be "glitchy" on some occasions, because the enable itself is generated by an edge-detector, which gets an asynchrounous signal for detection: Slow-Encoder-Signal -> FF-BASED-EDGE-DETECTOR -> CE of COUNTER. What would be the behavior of the counter, if CE is too short and too near to the clock? It would be o.k., if the counter simply wouldn't count, but is it possible, that the counter sets into metastate? Regards, Thomas.
Clock Enable safe?
Started by ●September 18, 2008
Reply by ●September 18, 20082008-09-18
<t.bartzick@gmx.net> wrote in message news:b21088bb-cb93-4e0a-8789-934157d6aa62@k7g2000hsd.googlegroups.com...> > Slow-Encoder-Signal -> FF-BASED-EDGE-DETECTOR -> CE of COUNTER. >^ ^ ----Is the clock for this ^ FF the same clock as this ^ counter? Cheers, Syms.
Reply by ●September 18, 20082008-09-18
On 18 Sep., 18:45, "Symon" <symon_bre...@hotmail.com> wrote:> <t.bartz...@gmx.net> wrote in message > > news:b21088bb-cb93-4e0a-8789-934157d6aa62@k7g2000hsd.googlegroups.com... > > > Slow-Encoder-Signal -> FF-BASED-EDGE-DETECTOR -> CE of COUNTER. > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^ =A0 =A0 =A0 =A0 =A0==A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^> ----Is the clock for this ^ FF the same clock as this ^ counter? > > Cheers, Syms.Hi! Yes, it is! Thomas.
Reply by ●September 18, 20082008-09-18
<t.bartzick@gmx.net> wrote in message news:9094dad7-fac6-47f8-b672-a12038d33355@59g2000hsb.googlegroups.com... On 18 Sep., 18:45, "Symon" <symon_bre...@hotmail.com> wrote:> <t.bartz...@gmx.net> wrote in message > > news:b21088bb-cb93-4e0a-8789-934157d6aa62@k7g2000hsd.googlegroups.com... > > > Slow-Encoder-Signal -> FF-BASED-EDGE-DETECTOR -> CE of COUNTER. > > ^ ^ > ----Is the clock for this ^ FF the same clock as this ^ counter? > > Cheers, Syms.Hi! Yes, it is! Thomas. Then it won't be glitchy when it matters. Mike
Reply by ●September 18, 20082008-09-18
On Sep 18, 3:15=A0pm, "Mike Lewis" <some...@micrsoft.com> wrote:> <t.bartz...@gmx.net> wrote in message > > news:9094dad7-fac6-47f8-b672-a12038d33355@59g2000hsb.googlegroups.com... > On 18 Sep., 18:45, "Symon" <symon_bre...@hotmail.com> wrote: > > > <t.bartz...@gmx.net> wrote in message > > >news:b21088bb-cb93-4e0a-8789-934157d6aa62@k7g2000hsd.googlegroups.com... > > > > Slow-Encoder-Signal -> FF-BASED-EDGE-DETECTOR -> CE of COUNTER. > > > ^ ^ > > ----Is the clock for this ^ FF the same clock as this ^ counter? > > > Cheers, Syms. > > Hi! > > Yes, it is! > > Thomas. > > Then it won't be glitchy when it matters. > MikeThat would only be true if the output CE of 'FF-BASED-EDGE-DETECTOR' is the output of a flip flop. The OP was wondering what would happen if "if CE is too short and too near to the clock". The only way to get that situation would be if CE is NOT the output of a flip flop (or a metastable event). While he also said that the same clock is used to clock the ''FF-BASED-EDGE-DETECTOR' it doesn't necessarily follow that the final output is a flop. If that output is from logic that depends on an asynchronous input than all bets are off. If the output is a flop, then perhaps the OP needs to explain just what situation he envisions where the output of such a flop could ever be 'too short' or 'too near the clock' since that would make absolutely no sense. KJ
Reply by ●September 18, 20082008-09-18
Hi! First: Thank you all for fast answers! The edge-detection is done via two D-FFs connected serially and by an AND-gate with one negated input, so the output of the first FF goes into the non-negated and the output of the second into the negated. The corresponding VHDL code is as follows: proc_FF1 : process (osc) begin if (rising_edge(osc)) then ff1_out <=3D ENCODER_SIGNAL; end if; end process; proc_FF2 : process (osc) begin if (rising_edge(osc)) then ff2_out <=3D ff1_out; end if; end process; edge_detected_pulse <=3D ff1_out and (not ff2_out); proc_CNTR : process (osc) begin if (rising_edge(osc)) then if (R =3D '1') then cntr <=3D (others =3D> '0'); else if (edge_detected_pulse =3D '1') then cntr <=3D cntr + 1; end if; end if; end process; So as you can see, 'edge_detected_pulse' is my 'CE' for the counter. Please be free to comment! Thanks! Thomas. KJ schrieb:> On Sep 18, 3:15=EF=BF=BDpm, "Mike Lewis" <some...@micrsoft.com> wrote: > > <t.bartz...@gmx.net> wrote in message > > > > news:9094dad7-fac6-47f8-b672-a12038d33355@59g2000hsb.googlegroups.com..=.> > On 18 Sep., 18:45, "Symon" <symon_bre...@hotmail.com> wrote: > > > > > <t.bartz...@gmx.net> wrote in message > > > > >news:b21088bb-cb93-4e0a-8789-934157d6aa62@k7g2000hsd.googlegroups.com.=..> > > > > > Slow-Encoder-Signal -> FF-BASED-EDGE-DETECTOR -> CE of COUNTER. > > > > > ^ ^ > > > ----Is the clock for this ^ FF the same clock as this ^ counter? > > > > > Cheers, Syms. > > > > Hi! > > > > Yes, it is! > > > > Thomas. > > > > Then it won't be glitchy when it matters. > > Mike > > That would only be true if the output CE of 'FF-BASED-EDGE-DETECTOR' > is the output of a flip flop. The OP was wondering what would happen > if "if CE is too short and too near to the clock". The only way to > get that situation would be if CE is NOT the output of a flip flop (or > a metastable event). While he also said that the same clock is used > to clock the ''FF-BASED-EDGE-DETECTOR' it doesn't necessarily follow > that the final output is a flop. If that output is from logic that > depends on an asynchronous input than all bets are off. > > If the output is a flop, then perhaps the OP needs to explain just > what situation he envisions where the output of such a flop could ever > be 'too short' or 'too near the clock' since that would make > absolutely no sense. > > KJ
Reply by ●September 19, 20082008-09-19
Hi, first of all, try to avoid a full quote, as long as not necessary. On 18 Sep., 23:56, "t.bartz...@gmx.net" <t.bartz...@gmx.net> wrote:> So as you can see, 'edge_detected_pulse' is my 'CE' for the counter. > > Please be free to comment!Your enable could be considered glitchfree with respect to the next FF stage iff you use the same clock and handle the clock skew properly. In fact it is no special glitch problem, but you have an enable signal that is valid at the usual timing points (between signal delay on longest path until signal delay on fastest path from all inputs to the end). You should always inspect the timing from primary inputs or FF outputs to the input of the next ff stage with static timing analyses. For an enable with high fan out it is always a good idea to use only one FF as source for this enable. regards Thomas
Reply by ●September 19, 20082008-09-19
t.bartzick@gmx.net wrote:> The edge-detection is done via two D-FFs connected serially and by an > AND-gate with one negated input, > so the output of the first FF goes into the non-negated and the output > of the second into the negated. > The corresponding VHDL code is as follows:If you want to be absolutely sure that this circuit won't go metastable, I'd use three FFs instead of two, and use the last two to generate the enable. The first FF may go metastable, but the other two will be safe. proc_FF1 : process (osc) begin if (rising_edge(osc)) then ff1_out <= ENCODER_SIGNAL; ff2_demet <= ff1_out; ff3_demet <= ff2_demet; end if; end process; edge_detected_pulse <= ff2_demet and (not ff3_demet);> proc_CNTR : process (osc) > begin > if (rising_edge(osc)) then > if (R = '1') then > cntr <= (others => '0'); > else if (edge_detected_pulse = '1') then > cntr <= cntr + 1; > end if; > end if; > end process; > > So as you can see, 'edge_detected_pulse' is my 'CE' for the counter. > > Please be free to comment! > Thanks! > > Thomas. > > > KJ schrieb: >> On Sep 18, 3:15�pm, "Mike Lewis" <some...@micrsoft.com> wrote: >>> <t.bartz...@gmx.net> wrote in message >>> >>> news:9094dad7-fac6-47f8-b672-a12038d33355@59g2000hsb.googlegroups.com... >>> On 18 Sep., 18:45, "Symon" <symon_bre...@hotmail.com> wrote: >>> >>>> <t.bartz...@gmx.net> wrote in message >>>> news:b21088bb-cb93-4e0a-8789-934157d6aa62@k7g2000hsd.googlegroups.com... >>>>> Slow-Encoder-Signal -> FF-BASED-EDGE-DETECTOR -> CE of COUNTER. >>>> ^ ^ >>>> ----Is the clock for this ^ FF the same clock as this ^ counter? >>>> Cheers, Syms. >>> Hi! >>> >>> Yes, it is! >>> >>> Thomas. >>> >>> Then it won't be glitchy when it matters. >>> Mike >> That would only be true if the output CE of 'FF-BASED-EDGE-DETECTOR' >> is the output of a flip flop. The OP was wondering what would happen >> if "if CE is too short and too near to the clock". The only way to >> get that situation would be if CE is NOT the output of a flip flop (or >> a metastable event). While he also said that the same clock is used >> to clock the ''FF-BASED-EDGE-DETECTOR' it doesn't necessarily follow >> that the final output is a flop. If that output is from logic that >> depends on an asynchronous input than all bets are off. >> >> If the output is a flop, then perhaps the OP needs to explain just >> what situation he envisions where the output of such a flop could ever >> be 'too short' or 'too near the clock' since that would make >> absolutely no sense. >> >> KJ
Reply by ●September 19, 20082008-09-19
On Sep 19, 9:22=A0am, PatC <p...@REMOVETHISpatocarr.com> wrote:> t.bartz...@gmx.net wrote: > > The edge-detection is done via two D-FFs connected serially and by an > > AND-gate with one negated input, > > so the output of the first FF goes into the non-negated and the output > > of the second into the negated. > > The corresponding VHDL code is as follows: > > =A0 =A0If you want to be absolutely sure that this circuit won't go > metastable, I'd use three FFs instead of two, and use the last two to > generate the enable. The first FF may go metastable, but the other two > will be safe. > > proc_FF1 : process (osc) > begin > =A0 =A0 if (rising_edge(osc)) then > =A0 =A0 =A0 =A0ff1_out <=3D ENCODER_SIGNAL; > =A0 =A0 =A0 =A0ff2_demet <=3D ff1_out; > =A0 =A0 =A0 =A0ff3_demet <=3D ff2_demet; > =A0 =A0 end if; > end process; > > edge_detected_pulse <=3D ff2_demet and (not ff3_demet); > >Hi! That's what I've feared! Ergo: My actual design in fact contains metastability of a certain probability. I've also thought about the idea of insertion of a further FFs but I've wanted to get shure... Thank you for support! Thomas.
Reply by ●September 19, 20082008-09-19
On Sep 19, 4:10=A0am, "t.bartz...@gmx.net" <t.bartz...@gmx.net> wrote:> On Sep 19, 9:22=A0am, PatC <p...@REMOVETHISpatocarr.com> wrote: > > > > > > > t.bartz...@gmx.net wrote: > > > The edge-detection is done via two D-FFs connected serially and by an > > > AND-gate with one negated input, > > > so the output of the first FF goes into the non-negated and the outpu=t> > > of the second into the negated. > > > The corresponding VHDL code is as follows: > > > =A0 =A0If you want to be absolutely sure that this circuit won't go > > metastable, I'd use three FFs instead of two, and use the last two to > > generate the enable. The first FF may go metastable, but the other two > > will be safe. > > > proc_FF1 : process (osc) > > begin > > =A0 =A0 if (rising_edge(osc)) then > > =A0 =A0 =A0 =A0ff1_out <=3D ENCODER_SIGNAL; > > =A0 =A0 =A0 =A0ff2_demet <=3D ff1_out; > > =A0 =A0 =A0 =A0ff3_demet <=3D ff2_demet; > > =A0 =A0 end if; > > end process; > > > edge_detected_pulse <=3D ff2_demet and (not ff3_demet); > > Hi! > > That's what I've feared! > Ergo: My actual design in fact contains metastability of a certain > probability. I've also thought about the idea of insertion of a > further FFs but I've wanted to get shure... Thank you for support! >You won't rid yourself of metastability by adding another flop, but you will be greatly reducing the probability by adding another flop, at the cost of added latency (maybe that's important, maybe not). You could greatly reduce the probability of metastability even more by adding two, three, four.... Also, the clock rate is important. Metastability takes some amount of time to resolve, it doesn't matter if that time comes from adding flops to a shift chain or simply a slower clock. A single flop that is clocked at 10 MHz will be more immune to having something bad happen due to metastability than a two flop shift chain running at 100 MHz. In the former case one clock cycle is 100 ns, in the second it is only 10 ns. Traditionally, most folks bring in async signals into a 2 flop shift chain and use the output of that as the synchronous version of that async signal so adding the second flop as previously suggested is good enough, but you should take a moment to scan a paper or two about just what causes metastability in the first place to educate yourself so you'll know the tradeoffs. KJ
