From: Michael McNamara (mac@verisity.com)
Date: Mon Feb 23 2004 - 08:16:32 PST
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
> >
This archive was generated by hypermail 2.1.4
: Mon Feb 23 2004 - 08:08:09 PST
and
sponsored by Boyd Technology, Inc.