Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Glitch on the clock pin of a D-Flop

Reply
Thread Tools

Glitch on the clock pin of a D-Flop

 
 
arant
Guest
Posts: n/a
 
      12-08-2008
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
 
Reply With Quote
 
 
 
 
kennheinrich@sympatico.ca
Guest
Posts: n/a
 
      12-08-2008
On Dec 8, 6:54*am, arant <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
arant
Guest
Posts: n/a
 
      12-09-2008
On Dec 8, 8:05*pm, (E-Mail Removed) wrote:
> On Dec 8, 6:54*am, arant <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Modify 24 pin PSU connector to 20 pin JM Computer Information 7 11-28-2006 09:55 PM
Arbitrary Clock Frequencies From Base Clock abhisheknag@gmail.com VHDL 5 06-23-2006 12:45 PM
What is the best way to clock data in on one clock edge and out on another? simon.stockton@baesystems.com VHDL 4 04-26-2006 11:36 PM
Sync for PC clock and server clock PS Computer Support 3 05-13-2005 05:27 AM
Are clock and divided clock synchronous? Valentin Tihomirov VHDL 11 10-28-2003 01:18 PM



Advertisments