Subject: Re: DASC Scope
From: Alex Zamfirescu (hxml@pacbell.net)
Date: Wed Nov 12 2003 - 20:06:36 PST
Michael:
All you write make good sense under two conditions, and those are
good intention, and technical soundness of the company of coalition-produced-
spec brought to the IEEE attention.
Both conditions are hard to check.
What could go wrong if conditions are not met:
The IEEE group might think it came up with a standard when
in fact it just put a stamp on the name of either an incomplete (no good
intention)
or incorrect (no technical soundness) specification.
In other words an implementation has to be feasible using the
standard alone and that implementation has to be able to handle
code the same way as any other implementation based on the
standard.
If you wait too much to get support from tools and industry,
there is always the problem that some vendors will try to
take advantage by not providing all the needed "tricks" to the
standard group, or that one dominant vendor will hold the golden
implementation that is hardly reproducible directly from
the standard.
Wearing my philosopher hat again, I can even state that it is best
to have a standard that has hidden "holes" because that will
keep a "herd" of experts explaining how to code to major
corporations, and it is probably that group that will be ready
to step up and devise even more new standard "soufflé."
There will also be a holder of the golden implementation
who will be there to promote, support etc.
Talking from the same skeptic perspective, a perfect,
easy to learn, implement and use standard
will apparently never provide for enough maintainers, and will be soon
abandoned for use ("like Latin in some Churches") only when
critical information has to be conveyed.
So the only question is: "How hot is the soufflé?"
Any comments?
Enjoy the day,
Alex Zamfirescu
CTO ASC
----- Original Message -----
From: "Michael McNamara" <mac@verisity.com>
To: "John Michael Williams" <jwill@astragate.net>
Cc: "'DASC Reflector'" <stds-dasc@eda.org>
Sent: Wednesday, November 12, 2003 6:23 PM
Subject: Re: DASC Scope
>
>
> -- On Nov 12 2003 at 13:28, John Michael Williams sent a message:
> > To: stds-dasc@eda.org
> > Subject: "Re: DASC Scope"
> > Hi All.
> >
> > Evan Lavelle wrote:
> > > Just on the issue of taking everything and letting the market decide:
> > >
> > > Brophy, Dennis wrote:
> > >
> > >> The DASC could do the same and allow any and all comers to standardize
> > >> and leave to the market those standards they wish to use.
> > >
> > >
> > > The IEEE does have a history of allowing manufacturers to open
> > > their languages (and bus interfaces, and whatever) by taking them
> > > on as IEEE standards. But what about languages which are already
> > > open? The two obvious cases are SystemVerilog and SystemC. Does
> > > it promote the ends of the IEEE to take on the extra work
> > > required to turn an existing "standard" into an IEEE "standard"?
> >
> > In my opinion, no. If the open standard already works
> > well, then inviting a lot of diverse IEEE opinions to
> > ballot on it probably will just add entropy.
> >
> > Preemptive standardization, with no preexisting dispute,
> > doesn't advance anything.
> >
> > IEEE standardization should be to resolve possible
> > engineering disputes or differences of opinion, not
> > just to consume working or balloting time to author
> > new stuff in the name of IEEE.
> >
> > If several variants of SystemC or SystemVerilog evolved
> > (literally), and differences created incompatibilities, then IEEE
> > should consider resolving such differences by publishing a
> > standard.
> > John
> > jwill@AstraGate.net
> > John Michael Williams
>
> Actually, it has been my experience that IEEE standardization of what
> was up to then a de-facto standard, or a standard supported by a
> consortia, has indeed been very beneficial to the industry and to the
> users.
>
> The Verilog language was a proprietary property of Gateway Design, and
> later Cadence Design, from 1983 until 1990.
>
> Then OVI was established as a consortia to sponsor the language as an
> open standard, and while it met with some success, it wasn't until the
> language was transfered to the IEEE in 1993 that the traction really
> picked up. The IEEE processes required complete disclosure of
> functionality, and mandated a process that was easy for all to
> understand and participate in The IEEE process had been followed by
> many groups previously. The IEEE process made it far easier for we at
> Chronologic to be confident that the tool we were implementing was
> compatible with a standard that had legs.
>
> The new IEEE ALF standard has similar roots; starting as a consortia
> owned standard (Accellera), which then transferred it to the IEEE and
> now IEEE 1603 ALF has been approved (9/11/03) and is gaining more and
> more acceptance.
>
> Based on recent press releases, it is that case that Accellera indeed
> intends to contribute System Verilog to the IEEE 1364 working group,
> enabling resolution of that standard with 1364, as you are
> encouraging.
>
> I feel that our charter as the Design Automation Standardization
> Committee should continue to be to serve as the sponsor of record for
> all the major languages useful for designing electronic systems. We
> indeed should use caution, and consider carefully before pre-emptively
> sponsoring for standardization a language which has not yet developed
> a significant following. Such tasks are better left to individual
> companies, or consortia. However, once some momentum has built up
> around a format, the IEEE standardization path brings transparency of
> process and equality of access to influence direction, which can be
> lacking when a format is company or consortia owned.
>
> "We don't make languages, we make them Standards" (apologies to BASF)
>
> Michael McNamara, Chairman, IEEE 1364 Working Group <mac@verilog.com>
> Sr VP Technology, Verisity Design <mac@verisity.com>
> W 650-934-6888 F 650-934-6893 M 408-930-6875
>
>
>
>
>
>
>
>
>
>
>
>
>
This archive was generated by hypermail 2b28 : Wed Nov 12 2003 - 20:11:23 PST