RE: 1364 vs. Verilog-XL

From: Brophy, Dennis (dennisb@model.com)
Date: Tue Feb 24 2004 - 18:09:02 PST

  • Next message: Shalom.Bresticker@motorola.com: "RE: 1364 vs. Verilog-XL"

    Mac,

    I have been consistent in the points I raise. At Mentor Graphics we seek an IEEE Std. 1364-2001 LRM that represents the consensus of the ballot constituency and is the definitive reference for the language.

    To that end, we are pleased that 1364-2001c version of the LRM is available from the IEEE to serve as the definitive Verilog reference. We know and recognize that this was a large task that took many hours of time from the working group and the IEEE to accomplish. We are extremely pleased that this has happened.

    But, in terms of the LRM being a definitive reference, I don't think you see this as we do. There is no reference simulator. OVISim is dead. Cadence Design Systems informed OVI many years ago they were no longer going to license it. Even in 1995 you agreed that OVISim was old in the tooth. (See: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&th=7abbef0c318e28b4&seekm=MAC.95Mar13195232%40it.chronologic.com&frame=off)

    This past year I had seen positions within the 1364 working group that are counter to the claim that the LRM is the reference and I have consistently challenged them. Is there anything other than this group - and the balloted LRMs it produces - that are the IEEE's version of Verilog?

    This past year we have been told that to decode and understand the LRM, we need to participate in the 1364 working group, that we should be better mind readers because the balloted LRM is not what one meant to write, and more recently, Verilog-XL, or other named pre-2001 versions of Verilog simulators define Verilog.

    Mac, I think it is time for you to be clear.

    There is no reference simulator. There is only a language reference manual.

    From the OVI side, I think it needs to be clear as well.

    OVI never donated OVISim to the IEEE. This is no "donated executable" as you reference in your email to justify many of the points you make. It just does not exist.

    OVI only assigned copyright of the documentation. OVI used to sell OVISim and it represented a large portion of its operating budget. And it bears to be repeated: Cadence Design Systems terminated the OVISim license program with OVI many years ago and indicated they had no future plans to do this again. Upon the approval of 1364-1995, Cadence Design Systems expected the industry to use this specification as the basis of Verilog support and even used this reason to support the termination.

    I understand that the industry was able to grow from a reference simulator in the OVI setting and there continues to be many that want to cling to this past. It certainly has its benefits. I agree. But is has no place in the IEEE.

    In the years since OVISim rights were terminated by Cadence, many have come to accept Verilog-XL as the next version of that reference simulator. And, in the most recent email that I took exception to, Verilog-XL was joined by NCSim and VCS. It is interesting to note that none of these tools, to my knowledge, offer full support the current 1364-2001 standard. (See: http://www.sunburst-design.com/papers/CummingsDVCON2003_V2K1_SimScore_rev1_2.pdf) As someone who fields a Verilog 1364-2001 complaint simulator, who has sought to have a clean LRM available from the IEEE to authenticate its implementation and validate a claim of compliance with the language, I find the actions of this group to be anti-competitive and stall the adoption of tools built on that version of the standard as they cling to pre-2001 implementations.

    In regards to other points made in your email, I will comment since you seem to be searching for justification to maintain close commercial interactions with simulator implementations to drive the standard within this group.

    Your point on "IEEE standards should be relevant and respond to . market needs. They should not distort . the market" need to be balanced with protection of IEEE's 501 (c)(3) tax-exempt status. The IEEE says: "Commercial considerations are not proper factors for consideration or discussion." In fact, the IEEE says: ". discussions should be confined to technical, engineering, and safety considerations." The market wants a standard Verilog, I think that is what this means. So 1364 and its work is relevant.

    Your point on "IEEE standards represent a consensus on the subject manner [sic] of the standard at the time the standard is promulgated" means the IEEE Std. 1364-2001c, the approved version of the standard, represents the consensus on the subject matter. Consensus is not something in someone's head, it is not in an implementation, it is not the deliberation of the working group or discovered while participating in a working group. It is arrived at and established upon approval of a specification via a formal ballot. IEEE Std. 1364-2001c is the consensus opinion.

    Your point that the OVISim reference simulator was "incorrectly referred to by some on this list as 'Verilog-XL'; when as pointed out in truth it should have been referred to as OVIsim." I think everyone speaks for himself or herself. Unfortunately, there is no OVISim any more. And, Verilog-XL was listed along with NCSim and VCS. Were they mistakenly referred to as well? You are really stretching it with that argument. You may wish to re-read the email since there was an offer to include ModelSim in this list if given for free. (Have you ever looked-up the definition of 'extortion?' You might want to.)

    In regards to:

    >So I expect that there is no controversy on the desirability and the
    >legality of adapting the standard to respond to the clear market need
    >to accurately document the required semantics of simulators wishing to
    >match the donation as reflected by the OVI LRM and OVIsim, which we
    >have reason to believe is also the consensus of the industry which has
    >reportedly driven all implementations to mimic this behavior, rather
    >than the behavior describe in the standard, in order to achieve sign
    >off status.

    Sorry Mac, OVI's job was to use the reference simulator to stimulate product development and the completion of the original LRM. The OVI LRM was superceded by IEEE 1364-1995 and IEEE 1364-1995 LRM was superceded by IEEE 1364-2001. And, again, there never was an OVISim in the IEEE setting. You are confusing OVI with the IEEE. You are also are confusing what consensus is in the IEEE. You attempt to equate consensus of the industry as being consensus in the IEEE setting to allow the working group to promote changes to the IEEE specification to match pet-commercial product implementations. This is just wrong and tarnishes the IEEE and the profession.

    If the industry wants all Verilog simulators to act the same, they can tell them to conform to IEEE Std. 1364-2001.

    Since you were not active in OVI at the management level, I would like to share with you some actions OVI took after Cadence Design Systems cancelled the OVISim licenses rights. Attached you will see an email from Vassilios Gerousis, the OVI Technical Committee Chair to the OVI Board requesting support to form a technical subcommittee to build Verilog models that could be used for compliance testing.

    Vassilios noted that he saw 5 versions of Verilog floating out there and that no work was being done in the IEEE group to foster compliance testing. His plan was to focus on Verilog-99 (known as 2001).

    He asked the chair, the other Maq, for a list of names to help form this group. None were ever given and it was never done. Instead, Si2 stepped into the breach and they offered a program by which they would qualify ASIC member company libraries against a set of simulators to ensure compatibility. This successful program has ended and their serves are no longer offered. (See: http://www.eetimes.com/news/98/1026news/si2.html)

    As pointed out above, there are independent consultants that are testing implementations against their Verilog models to see if they all conform to the specification. In the case of the DVCon reference above, it was a conformance test to certain aspects of 1364-2001. I see from the DVCon program, this information is being updated this year with newer data and maybe more tools.

    I applaud and support the independent activities to qualify tools against the LRM. It is a shame that the offer from Vassilios was ignored. The industry and the IEEE 1364-2001 standard would have benefited from it.

    -Dennis

    -----Original Message-----
    From: owner-1364@accellera.org [mailto:owner-1364@accellera.org]On
    Behalf Of Michael McNamara
    Sent: Monday, February 23, 2004 8:17 AM
    To: Vassilios.Gerousis@infineon.com
    Cc: mac@verisity.com; Brophy, Dennis; Shalom.Bresticker@motorola.com;
    1364@accellera.org; etf@boyd.com
    Subject: RE: 1364 vs. Verilog-XL

    Vasslious: Thank you for your well thought out reply.

    At issue here is not behavior of new features of 1364 which I can
    assure you have been and continue to be each based wholly on the prose
    approved by the committee, and ratified by the balloting group.

    Instead at issue here is the semantics of a element of the standard
    that is based on the material of the original donation, which was as
    you describe, and as I recall, a less than perfect document set, as
    well as a reference implementation, which was provided to elucidate
    the behavior of the reference simulator, should the working group
    determine this was necessary or even advisable.

    In all cases the working group reserved the right to itself, as it is
    required to do by the IEEE, to standardize on syntax and semantics
    which are different than those of any donation.

    To make it clear, there is no intention or requirement (or even
    ability) to extend this donated executable to reflect the activities
    of the 1364-1995 working group or any subsequent working group.

    The question that was here raised on the issue under discussion was
    the validity of correcting the LRM in its description of the behavior
    of certain timing check system calls to reflect the actual behavior
    of the reference simulator.

    This reference simulator was incorrectly referred to by some on this
    list as 'Verilog-XL'; when as pointed out in truth it should have been
    referred to as 'OVIsim'.

    The task the working group has before it is to follow the IEEE
    requirements which I excerpt:

    "IEEE standards represent a consensus on the subject manner of the
    standard at the time the standard is promulgated".

    "IEEE standards should be relevant and respond to ... market needs.
    They should not distort the ... market."

    So I expect that there is no controversy on the desirability and the
    legality of adapting the standard to respond to the clear market need
    to accurately document the required semantics of simulators wishing to
    match the donation as reflected by the OVI LRM and OVIsim, which we
    have reason to believe is also the consensus of the industry which has
    reportedly driven all implementations to mimic this behavior, rather
    than the behavior describe in the standard, in order to achieve sign
    off status.

    If there is indeed controversy on any aspect of this plan, especially
    should the concerns be based on the requirements of the Patent policy
    that exhort each of us to bring such matters before the Working Group
    by such parties at the time for such proposals; and that a vote be
    held; and should disagreement continue, the usual IEEE methods for
    appeal would be available to those choosing to pursue this.

    -mac

    -- On Feb 23 2004 at 15:30, Vassilios.Gerousis@infineon.com sent a message:
    > To: mac@verisity.com, dennisb@model.com, Shalom.Bresticker@motorola.com, 1364@accellera.org, etf@boyd.com
    > Subject: "RE: 1364 vs. Verilog-XL"
    > Hi Shalom, Dennis and Mac,
    > As far as I know, I am the only who "lived the history" of OVI prior
    > to Dennis and many people after him. OVISIM (or Verilog-XL) was put together
    > by Cadence generosity to help jumpstart the industry at that time. The
    > reason for that, the LRM did not exist, and we had, at that time, is
    > Verilog Modeling Guidelines. No one can really build a tool based on this
    > documentation. Although an OVI LRM was designed afterwards, it really did
    > not reflect properly simulation semantics (since synthesis semantics was not
    > an issue at that time). So the simulator was done for only one reason, lack
    > of good documentation (LRM).
    > To continue this model within IEEE, continues the impression that the LRM is
    > not a good reference.
    >
    > IEEE is supposed to build an independent LRM representing what a
    > simulator should do and it is not be designed to reflect a single product in
    > the market place. Verilog 1995 provided additional functionality that even
    > Verilog-XL at that time or other products did not support. Verilog 2001,
    > went even further beyond the scope of all simulators (or actual products)
    > that existed at that time, and no one product implemented the complete set
    > (one vendor claims to do so) of 2001. Should we ask this vendor to provide
    > their simulator as THE reference instead of the IEEE 2001? One also should
    > ask why VHDL LRM is better in this respect than IEEE Verilog 2001?
    >
    > Do you plan to add things into 2005, only if they are implemented in
    > Verilog-XL? How this team is going to integrate Accellera Work when it is
    > done? What reference simulator is planned for this topic for IEEE 2005?
    >
    >
    > Best Regards
    >
    > Vassilios
    >
    > -----Original Message-----
    > From: owner-1364@accellera.org [mailto:owner-1364@accellera.org] On Behalf
    > Of Michael McNamara
    > Sent: Monday, February 23, 2004 10:33 AM
    > To: Brophy, Dennis
    > Cc: Shalom.Bresticker@motorola.com; 1364@accellera.org; etf@boyd.com
    > Subject: RE: 1364 vs. Verilog-XL
    >
    >
    >
    > So, Dennis, what do you suggest?
    >
    > As you happen to be the chair of the entity whose predecessor donated this
    > technology to the IEEE, an entity which I believe retains title to the
    > reference implementation (which is OVIsim, not Verilog-XL, by the way), it
    > seems that the right thing, and as you point out, likely the now REQUIRED
    > thing is that Accellera makes OVIsim available to all on a free, non
    > discriminatory basis.
    >
    > I also thank you for following the steps of immediately pointing out
    > statements made by members of the committee that might be viewed as
    > discriminatory, or anti trust and the like.
    >
    > -mac
    >
    >
    > -- On Feb 23 2004 at 00:37, Brophy, Dennis sent a message:
    > > To: Shalom.Bresticker@motorola.com, 1364@accellera.org, etf@boyd.com >
    > Subject: "RE: 1364 vs. Verilog-XL" > Shalom, >
    > > I commend you for all the work you have put into the IEEE groups
    > > to improve the quality of the Verilog specification. I certainly > want
    > to see this continue. >
    > > At the same time, all of us may wish to re-acquaint ourselves
    > > with anti-competitive issues which you outlined in your email and >
    > promote as being legitimate. You may wish to read "What You Need > to Know
    > About IEEE Standards and the Law" at the IEEE website: >
    > http://standards.ieee.org/resources/index.html#guides.
    > >
    > > In regards to the position paper, I have read it before. But it
    > > is no longer operative. In addition to the IEEE CS DASC approving > its
    > new rules last week in Paris, all groups operating under the > DASC must
    > now do the same. Since the DASC was instructed to start > immediate
    > operation under DASC rules according to the CS SAB relay > information, new
    > rules for all groups need to be formed. Since > this document is
    > anti-competitive, I see little chance of it > surviving as this happens. >
    >
    > > The position paper is anti-competitive, serves to restrain trade
    > > and confers on market leaders a permanent market position. Since > IEEE
    > standards-developing groups should assure that there are no > agreements or
    > understandings - express or implied, formal or > informal - that restrict a
    > participant's freedom to make > independent decisions in those matters that
    > may affect competition, > a dependence on an implementation that is private
    > is not allowed. > (In fact, dependence on "trade secrets," as this is, is
    > one of the > tell-tale sign of anit-competitive agreements.) >
    > > Since this group is littered with references to XL and I have no
    > > freedom to make independent decisions on any matters which relate > to
    > it, it affects my ability to compete. You have state so > much. In the
    > United States, this is call unfair restraint of trade. > It is illegal and
    > remedy can include recovery of lost trade. The > greater problem is the
    > Antitrust Division of the U.S. Department of > Justice generally enforces
    > for the federal government, but private > lawsuits to halt antitrust
    > activities have become increasingly > popular, particularly since
    > attorney's fees are awarded to the > winning party. This is a legal
    > specialty which has kept some > industries relatively honest and made some
    > lawyers wealthy. >
    > > Your message suggests that this group is used to support an
    > > under-defined standard for the benefit of the two players. This is >
    > evidence of systemic and longstanding collusions to manipulate the > market
    > which attorneys love to see. >
    > > Also, discussions of market sizes, product offerings and details
    > > of products is out bounds for discussion within an IEEE standards >
    > group. Just because you know of no company that offers full > Verilog-2001
    > support does not mean this is so. >
    > > Again, my suggestion is to review the IEEE website since there
    > > are issues here which not only affect this group, but can call into >
    > question the IEEE's non-profit tax status. >
    > > Regards,
    > >
    > > Dennis
    > >
    > > -----Original Message-----
    > > From: owner-etf@boyd.com [mailto:owner-etf@boyd.com]On Behalf Of Shalom
    > > Bresticker > Sent: Sunday, February 22, 2004 2:52 AM > To: Brophy,
    > Dennis > Cc: etf@boyd.com > Subject: Re: 1364 vs. Verilog-XL >
    > >
    > > 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
    > >


    attached mail follows:

    Dear OVI Board,
            It has to my attention the proliferation of many versions of Verilog and
    the creation of multiple Verilog standards :
            
    1- OVISIM is still Verilog-XL 1.6. It has not kept uptodate.
    2- OVI Verilog 1.0 (equivelent to OVISIM)
    3- OVI Verilog 2.0.
    4- IEEE 1364.
    5- the New IEEE 1364-99

            There is no compliance models for people to test each version. We have
    started the effort at Verilog-AMS, to collect models for Verilog-A/MS and post
    those on the EDA.ORG web site. We hope that over time these will become
    compliant.
            We need to do a similar thing for Verilog. I would like to start to form
    a committee to start collecting these models and post them over the web.
    Hopefully the EDA vendors can help us to collect such models, especially the
    ones used for regression testing. This is an important topic, and will help
    speed up the adoption of the standard.
            Maq, you can help by asking people who volunteered to enhance the
    language by providing exmaple models that we can put as the IEEE-99 standard for
    Verilog.
            I would like to get names of people who can head that activity. It
    should come from an EDA vendor and possibly a user.
            
    Best Regards

    Vassilios Gerousis

    This archive was generated by hypermail 2.1.4 : Tue Feb 24 2004 - 17:54:16 PST and
    sponsored by Boyd Technology, Inc.