Re: 1364 vs. Verilog-XL

From: Shalom Bresticker (Shalom.Bresticker@motorola.com)
Date: Sun Feb 22 2004 - 02:53:06 PST

  • Next message: Shalom.Bresticker@motorola.com: "errata/522: PROPOSAL - A.2.2.3: delay2 and delay3 should be constant expressions"

    Dennis,

    I have attached an IEEE P1364 Position Paper from 12.17.1993.
    It might be useful to review it.

    Like it or not, the Cadence and Synopsys simulators together have the vast
    majority of the market,
    according to the latest sales figures I have seen, and 1364 usually has no
    interest in deliberately contradicting
    their behavior where all of them agree.

    1364 can sometimes be more or less restrictive than them,
    but it needs a very good reason to do the opposite from them.

    There are mistakes in 1364. That is why the ETF exists.
    A classic mistake was in the definition of $readmem, for example.

    Yes, it would be nice if all of us had access to XL. It certainly does help me
    in my work that I have access
    to XL, NCV, and VCS. And if I had access to ModelSim, I would also check its
    behavior as well.
    If you want to donate me a copy, I'll be glad to report on its behavior as well.

    By the way, I don't know of any simulator which is today totally compliant to
    1364-2001.
    And when I find bugs in the simulator behaviors, I report them to the vendors,
    and I request them to change their behavior to be compliant.

    Every time I find a discrepancy, I consciously consider and try to decide
    whether it is more logical for the tool to change or for the standard.

    Shalom

    "Brophy, Dennis" wrote:

    > I guess it is nice that the opportunity exists for one entity to match XL while the rest of the community must rely on the IEEE work as the standard's official record of behavior.
    >
    > I understand that these statements are true and an accurate reflection of many Verilog users, but only serve to weaken and tarnish this group and the profession since it only reads to me that the work of this technical group is to a great degree irrelevant.
    >
    > Maybe all members of the team should be given copies of XL to help in the cause of bringing the LRM into alignment with XL.
    >
    > -Dennis 

    --
Shalom Bresticker                           Shalom.Bresticker@motorola.com
Design & Reuse Methodology                             Tel: +972 9 9522268
Motorola Semiconductor Israel, Ltd.                    Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL                       Cell: +972 50 441478

    [x]Motorola General Business Information
[ ]Motorola Internal Use Only
[ ]Motorola Confidential Proprietary

    Principles

    We believe that the activities of the IEEE Working Group on Verilog
    Standardization should be governed by the following principles:

    1. Standardization must happen ASAP to be of maximum benefit.

    Verilog is already a de facto standard. The goal of this working
    group is essentially to codify the existing standard. Future
    development should proceed from a firm base. The existing standard
    is the base.
            
    2. The Specification must be clear, unambiguous, implementable,
            and not over-constraining.
            
    Because Verilog is a de facto standard, there is a tendency to
    believe that the Verilog-XL implementation is the standard. The
    main work of this effort is to separate the essential semantics
    of the Verilog language from the implementation-dependent quirks
    of the Verilog-XL implementation. Furthermore, it is imperative
    for this effort that the result not constrain future implementations
    unduly. This would render the standard effectively obsolete.

    Implications

    1. Nothing should be in the spec which has not been implemented by
            someone.

    There have been many proposals for enhancements to Verilog, many of them
    quite worthwhile. Several have been incorporated into the LRM 2.0 which
    we are using as a base for the spec. However, none of the enhancements
    which have not been implemented are known to be unambiguous, implementable,
    and useful to the general user community. Thus, for our base, everything in
    the spec should be demonstrable.

    2. Nothing should be in the spec which is implementation-dependent.

    There are many implementation-dependent features which should not be in
    the spec. The obvious ones are things like vector length limits. In general,
    most implementation-dependencies should be defined as such, e.g. the vector
    length limit is implementation dependent.

    3. The spec should not codify Verilog-XL bugs.

    There are many Verilog-XL bugs and quirks. This is not to denigrate Verilog-XL.
    Any program as large as Verilog-XL has bugs which have become features. We must
    separate these from desired functionality.

    4. As little as possible in the spec which will prevent future novel
            or advantageous implementations (e.g. parallel).

    There are Verilog-XL semantics which are there simply because that's the way
    it was implemented. If some of these are codified in the spec, it will unduly
    limit future implementations. We already see this with Verilog-XL/Turbo, where
    event ordering is different from Verilog-XL (and from Verilog-non-XL).

    Examples of the above issues

    1. port collapsing

    Port collapsing is described in the LRM 2.0. This is not part of the essential
    semantics of Verilog. Verilog can be, and has been, implemented without using
    port collapsing.

    2. event ordering

    In general, event ordering is not described in the LRM. By and large, this
    should remain the case. The scheduler semantics probably should be described
    (the "XL" scheduling semantics), while other event ordering (e.g. assign
    statement vs. wire assignment) should not.

    3. attributes

    Attributes have not been implemented by anyone, and as such the specification
    is suspect. It is unknown if it is consistent and sufficient for
    implementation.

    4. memory propagation

    Verilog-XL propagates any memory element change to all expressions sensitive
    to any element in the memory. This is simply a quirk of the Verilog-XL
    implementation, and should not be codefied.

    5. evaluation ordering (lhs expressions vs rhs expressions)

    Verilog-XL evaluates a lhs expression before evaluating a rhs expression,
    reulting in a deterministic ordering of side-effects. This should be
    defined as undefined, as it is in C.

    What should be added - detail

    There is a great deal of detail which should be added to the LRM to make it
    an adequate spec. Some examples are:

    parameter value resolution

            It is not specified what the precedence of multiple defparam
            assignments is.

    macro evaluation details

            The spec does not say if, after expansion, the result is
            re-evaluated for further macro expansion or not.
            
    out-of-range bit&part selects

            The result of accessing out-of-range bit and part selects should be
            defined. Verilog-XL does funny things here.
            
    system task definitions

            Many system tasks are effectively part of the language. As of this
            writing, they are still not documented in the LRM.

    Proposal for producing a Verilog-HDL Specification

    Our proposal is the following:

       I. Begin with LRM 2.0.
       II. Seriously consider removing those parts which have not been implemented
           by any simulator.
       III.Remove all Verilog-XL implementation-specific description (or define
           as such).
       IV. Add clarification for behavior which is either known to be wrong or
           ommitted.

    Specifics:
    ---------
     1. take out all references to collapsed ports
     2. take out all references to "vectored" and "scalared"
     3. remove attributes
     4. remove signed and unsigned operator attributes
     5. define unspecified event ordering as undefined
     6. define parameter assignment ordering
     7. macro expansion clarification
     8. port direction inference - define as implementation dependent
     9. signed operation and sized operation clarification
    10. widths on parameters
    11. use of x bits in integers (repeat counts, etc.) undefined
    12. side-effects in rhs of continuous assignment evaluation should be defined
            as implementation-dependent (this one may be controversial)
    13. propagation of memorys should be implementation-dependant
    14. consistency of port declaration sizes
    15. out-of-range bit & part selects (undefined)
    16. rhs & lhs expression ordering should be defined as undefined
            (affects side-effects)
    17. initial value propagation of x's
    18. unknown bits in memory index should be documented
    19. clarification of recursive functions -- should be implementation-dependent
    20. $save/$restart/$incsave should be removed
    21. $protect/$endprotect/$protected/$endprotected should be removed from the
            OVI spec unless Cadence releases the protection algorithm
    22. $dumpchange should be added to page B-42
    23. define the order between initial and always, or define it to be undefined
    24. value-change-dump format should be documented
    25. define semantics of mixed real and non real variables in expressions.
            I.E., does reg [31:0] a; real x; ... a = x;
                    act like a = $realtobits(x); or like a = $rtoi(x) ?
            Does a = x + 0.5; convert arguments to fixed before the
                    addition operation, or after?
    26. When defining $display(), allow %v to accept any variable type.

    This archive was generated by hypermail 2.1.4 : Sun Feb 22 2004 - 02:41:38 PST and
    sponsored by Boyd Technology, Inc.