>1. Which tools are being referred to
In the Verilog standard, the term "implementation" is used, for a tool
that implements the defined semantics of the language. That would be
a simulator, since that is the tool that implements the semantics of
the language. A synthesis tool attempts to implement them in hardware,
but can really only approximate the precise language semantics. Other
tools may manipulate Verilog designs based on those semantics, but they
don't "implement" the semantics.
>2. How often are the checks performed
I think it is pretty clear that the checks are performed when the
case statement is executed. This is not a separate stand-alone
assertion, it is a special case-statement that does extra checking
as part of its evaluation. All this talk about performing the
checks at different times seems to have gone far astray.
If you want it to be checked only on the clock edges, then you need
to put it in the clocked block. If you want it checked whenever the
inputs change, put it in a separate combinational block. This will
result in it being evaluated (and checked) at those times. I believe
that there are different modeling styles that promote putting the
combinational logic in the sequential blocks versus putting them in
separate combinational processes. How you want this checking done
would be one reason for choosing one over the other.
It wouldn't even be legal to do the checks at some other point, since
it would require evaluating the expressions again, which might have side
effects. The proposal Brad put together for issue 218 allows for
flexibility in order and short-circuiting of evaluation of the
expressions when the case is executed, but it doesn't allow them to
be evaluated at any old time. This isn't a problem in realistic
situations, since there won't be side effects, but the language still
has to define the behavior.
>3. During which event region should the check take place
Again, the check is performed when the statement is executed. Though
there are some similarities, this is not a separate assertion. It is a
case statement that does extra checks when it is executed.
>4. Severity of the check
>
> A simulation should not terminate based on these checks. The simulation
> log would be post-processed to determine the correct course of action.
> A warning is appropriate.
Agreed. This is supposed to help the user, not impede them.
>The benefits of this construct could end up getting outweighed by the
>drawback of slower simulations.
Which is another good reason not to have the check done as a separate
process. It would be inefficient to simulate. If you want it done that
way for some reason, you can write an assertion.
Steven Sharp
sharp@cadence.com
Received on Wed Nov 10 15:26:08 2004
This archive was generated by hypermail 2.1.8 : Wed Nov 10 2004 - 15:26:19 PST