errata/566: Re: errata/566: Re: errata/566: 9.5: case item expression ambiguity

From: Steven Sharp (sharp@cadence.com)
Date: Wed Mar 24 2004 - 16:40:00 PST

  • Next message: Steven Sharp: "errata/566: Re: errata/566: Re: errata/566: 9.5: case item expression ambiguity"

    The following reply was made to PR errata/566; it has been noted by GNATS.

    From: Steven Sharp <sharp@cadence.com>
    To: etf-bugs@boyd.com, Brad.Pierce@synopsys.com
    Cc:
    Subject: Re: errata/566: Re: errata/566: 9.5: case item expression ambiguity
    Date: Wed, 24 Mar 2004 19:51:18 -0500 (EST)

    > First, if this would effect the simulation efficiency
    > of even those case statements without side-effecting
    > case item expressions, then I wouldn't want it. I
    > assumed that static analysis could determine which
    > case statements are afflicted with this rather rare
    > style, and treat only those case statements in the
    > new way. If not, then never mind.
     
     You are correct. Such an analysis is possible, and not
     particularly difficult. Case item expressions with function
     calls would be very rare, so they would have minimal effect
     on overall performance.
     
     However, that still leaves subtler costs. Having to implement
     and maintain multiple approaches has a cost. There are more
     likely to be bugs in the resulting more complex implementations.
     These costs are harder to measure, but would end up getting
     passed on to the user in one way or another.
     
     I also have a philosophical objection to defining the semantics
     by specifying an inefficient algorithm, and excusing it because
     there is an undocumented optimization that makes it more efficient.
     In this particular situation, the optimization is pretty obvious.
     In others, it might not be obvious. This could result in a language
     that can only be implemented efficiently by the people privy to the
     undocumented information. I don't think we want to start going down
     that path.
     
    > Having said that, the reason I was attracted to your
    > interpretation is that it seemed to fit better with
    > the handling of full_case parallel_case pragmas, which,
    > unlike side-effecting case item expressions, are very
    > common. It seemed natural to pull out all the side-effects,
    > do them in sequence, and only then do the case. (But
    > maybe it's just me, because full_case parallel_case
    > itself seems more natural to me than priority style.)
     
     The reason why full_case parallel_case pragmas exist is that the
     definition of Verilog case is not parallel. It is defined as
     sequential operations, like an if-then-else-if. Even if you
     specified that all of the side effects should be done on each
     execution, they would still be done in a particular sequence,
     so they would still not be parallel. And if there are multiple
     potential matches, only the first will be taken, which is not
     parallel. Since cases are defined sequentially, taking this one
     piece and trying to make it more parallel just makes it inconsistent
     with the rest.
     
     If a case qualifies for full_case parallel_case, then I assume it
     can't have any case item expresion side effects anyway. So in the
     situation where it seems natural to you to evaluate all the case item
     expressions before the compares, it doesn't really matter whether you
     do or not. You are free to regard it that way if you like (in a sort
     of reversal of your argument above about optimizing simulation). And
     in the situations where it would matter, you can't treat it as a
     full_case parallel_case anyway. So where is the advantage?
     
     So even if the cost of this were almost zero, you haven't described
     any clear benefit that would offset it.
     
     More importantly, Verilog cases currently evaluate and then compare
     each case item expression before moving on to evaluate the next. If
     this were changed, it could create backward compatibility issues. Why
     would we want to change it?
     
     Steven Sharp
     sharp@cadence.com
     

    This archive was generated by hypermail 2.1.4 : Wed Mar 24 2004 - 16:40:02 PST and
    sponsored by Boyd Technology, Inc.