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
