Glitch on the clock pin of a D-Flop

Discussion in 'VHDL' started by arant, Dec 8, 2008.

  1. arant

    arant Guest

    We had a basic doubt about the D-flop functionality it would be great
    if anyone could reply to the query

    In case the clock pin of a clock has a glitch but the D pin of the
    flop remains at a stable logic value either 1/0 will the output Q of
    the flop produce a glitch ?

    * In case a glitch is not produced, is there any possibility of an
    X at Q pin on the next active edge of the clock due the recirculation
    in the slave stage due to clock glitch

    Thanks in advance
    Arant
    arant, Dec 8, 2008
    #1
    1. Advertising

  2. arant

    Guest

    On Dec 8, 6:54 am, arant <> wrote:
    > We had a basic doubt about the D-flop functionality it would be great
    > if anyone could reply to the query
    >
    > In case the clock pin of a clock has a glitch but the D pin of the
    > flop remains at a stable logic value either 1/0 will the output Q of
    > the flop produce a glitch ?
    >
    >     * In case a glitch is not produced, is there any possibility of an
    > X at Q pin on the next active edge of the clock due the recirculation
    > in the slave stage due to clock glitch
    >
    > Thanks in advance
    > Arant


    Arant,

    I can see why you ask: it would seem that there's no setup violation
    in such a case, so one would think all is OK. The actual answer,
    though is "it's entirely technology dependent, and furthermore, is
    dependent on what the manufacturer of your technology says it's safe
    to do".

    It also depends on what you mean by "glitch" : either a well-formed,
    clean, full-amplitude clock pulse which happens to be arrive before
    the manufacturer's tclk_min specification, or some sort of malformed,
    bounce-on-the-rising edge-followed-by-a-60%-amplitude-burp kind of
    thing. Actual behaviours when receiving an out-of-tolerance input can
    be very sensitive to the precise nature of the deviation. And if
    you're asking about transistor-level behaviour you should post a
    transistor-level schematic :)

    *And* it also depends on what you mean by "can it produce an X"? An
    "X" is a specific modelling concept (in this case from VHDL
    modelling). If you're asking about the behaviour of a specific VHDL
    model, post the code and we can walk through the implementaiotn to
    tell you how it ought to simulate. However, keep in mind that a model
    is just a model and doesn't necessarily reflect the real device. Even
    if you figure out what your real device usually does, there's no
    guarantee that your stock VHDL model will do the same thing.

    If you're asking "can my device still produced undesired output",
    well, that depends entirely on the datasheet. But conservatively,
    assume it will do Something Bad. The datasheet should be read as a
    "contract" between the device manufacturer and you. If you violate
    what the manufacturer says you can do (like break a t_clk_cycle_min
    limit), then any circuit behaviour you observe is *not* guaranteed by
    the manufacturer from lot to lot , over voltage & termperature, over
    process spins, etc. Therefore, when your design which relies on these
    behaviuours starts to fail, and the traffic lights in all four
    directions go green simultaneously, the brakes lock up, or the
    aircraft loses communication with the ground, it's *your* fault for
    taking a risk and breaking the contract. Unless you feel comfortable
    doing the equivalent testing and characterization that, say, a
    multimillion dollar test program achieves, you should not be designing
    *anything* for real, in industry, by asking these kinds of questions.

    Of course, if you're only building a toy gizmo to blink your own
    Christmas lights on a $20 eval board, do whatever the heck you
    want :)

    So I won't even speculate on what your device will or won't do; it
    will depends on the specifics of the device and on the exact stimulus
    it's getting. But more importantly, I'm saying this: be *very, very*
    careful when relying on any of these kinds of behaviours when doing a
    real design.

    Just my two cents. I'm prone to foaming at the mouth about this kind
    of design-- though the years I've seen too many bad things happen as a
    result of timing violations and unfounded assumptions.

    - Kenn
    , Dec 8, 2008
    #2
    1. Advertising

  3. arant

    arant Guest

    On Dec 8, 8:05 pm, wrote:
    > On Dec 8, 6:54 am, arant <> wrote:
    >
    > > We had a basic doubt about the D-flop functionality it would be great
    > > if anyone could reply to the query

    >
    > > In case the clock pin of a clock has a glitch but the D pin of the
    > > flop remains at a stable logic value either 1/0 will the output Q of
    > > the flop produce a glitch ?

    >
    > >     * In case a glitch is not produced, is there any possibility of an
    > > X at Q pin on the next active edge of the clock due the recirculation
    > > in the slave stage due to clock glitch

    >
    > > Thanks in advance
    > > Arant

    >
    > Arant,
    >
    > I can see why you ask: it would seem that there's no setup violation
    > in such a case, so one would think all is OK. The actual answer,
    > though is "it's entirely technology dependent, and furthermore, is
    > dependent on what the manufacturer of your technology says it's safe
    > to do".
    >
    > It also depends on what you mean by "glitch" : either a well-formed,
    > clean, full-amplitude clock pulse which happens to be arrive before
    > the manufacturer's tclk_min specification, or some sort of malformed,
    > bounce-on-the-rising edge-followed-by-a-60%-amplitude-burp kind of
    > thing. Actual behaviours when receiving an out-of-tolerance input can
    > be very sensitive to the precise nature of the deviation. And if
    > you're asking about transistor-level behaviour you should post a
    > transistor-level schematic :)
    >
    > *And* it also depends on what you mean by "can it produce an X"?  An
    > "X" is a specific modelling concept (in this case from VHDL
    > modelling). If you're asking about the behaviour of a specific VHDL
    > model, post the code and we can walk through the implementaiotn to
    > tell you how it ought to simulate. However, keep in mind that a model
    > is just a model and doesn't necessarily reflect the real device. Even
    > if you figure out what your real device usually does, there's no
    > guarantee that your stock VHDL model will do the same thing.
    >
    > If you're asking "can my device still produced undesired output",
    > well, that depends entirely on the datasheet. But conservatively,
    > assume it will do Something Bad. The datasheet should be read as a
    > "contract" between the device manufacturer and you. If you violate
    > what the manufacturer says you can do (like break a t_clk_cycle_min
    > limit), then any circuit behaviour you observe is *not* guaranteed by
    > the manufacturer from lot to lot , over voltage & termperature, over
    > process spins, etc.  Therefore, when your design which relies on these
    > behaviuours starts to fail, and the traffic lights in all four
    > directions go green simultaneously, the brakes lock up, or the
    > aircraft loses communication with the ground, it's *your* fault for
    > taking a risk and breaking the contract. Unless you feel comfortable
    > doing the equivalent testing and characterization that, say, a
    > multimillion dollar test program achieves, you should not be designing
    > *anything* for real, in industry, by asking these kinds of questions.
    >
    > Of course, if you're only building a toy gizmo to blink your own
    > Christmas lights on a $20 eval board, do whatever the heck you
    > want :)
    >
    > So I won't even speculate on what your device will or won't do; it
    > will depends on the specifics of the device and on the exact stimulus
    > it's getting. But more importantly, I'm saying this: be *very, very*
    > careful when relying on any of these kinds of behaviours when doing a
    > real design.
    >
    > Just my two cents. I'm prone to foaming at the mouth about this kind
    > of design-- though the years I've seen too many bad things happen as a
    > result of timing violations and unfounded assumptions.
    >
    >  - Kenn


    Kenn,Thanks for the detailed reply it was more than I bargained
    for ...

    My query was basically targeted towards people who are into CMOS level
    design of
    Flops and have better understanding of the library elements in
    existence today (~65nm)

    Looking at the data-sheets of various manufacturers, they seem pretty
    vague on this kind
    of behavior.
    According to my understanding no timing laws are getting violated here
    as there is basically 'NO'
    timing happening here (i.e no data sampling) so there should not be
    any question of a glitch.

    I think someone who works at a CMOS transistor level can better shed
    light on this.

    -- arant
    arant, Dec 9, 2008
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Valentin Tihomirov

    Are clock and divided clock synchronous?

    Valentin Tihomirov, Oct 23, 2003, in forum: VHDL
    Replies:
    11
    Views:
    3,257
    louis lin
    Oct 28, 2003
  2. Replies:
    4
    Views:
    704
    Peter Alfke
    Apr 27, 2006
  3. Replies:
    5
    Views:
    2,138
    Ricardo
    Jun 23, 2006
  4. himassk
    Replies:
    1
    Views:
    1,220
    Paul Uiterlinden
    May 16, 2007
  5. pankaj.goel
    Replies:
    6
    Views:
    923
    pankaj.goel
    Nov 25, 2008
Loading...

Share This Page