Subject: Re: DASC Scope
From: Gabe Moretti (gmoretti@comcast.net)
Date: Thu Nov 13 2003 - 05:27:35 PST
I would like to address two points, one from Evan Lavelle and the other from
Dennis Brophy. Both have made insightful comments regarding the
standardization process, but I would like to clarify and suggest a different
direction.
There is, I fear, some amount of misunderstanding regarding NesCom rules and
help available from NesCom. The requirement to coordinate standards was
removed because the procedure did not fit the needs of all of the sponsoring
societies, so the rule was arbitrary in some cases and lead to unnecessary
work. This does not mean that IEEE-SA sees coordination as not important.
With respect to WG chairs having to be creative with respect to the process,
or the DASC needing an advisory group, I would like to point out that in
many cases this is already available. NesCom, for example, has appointed
mentors to help WG Chairs with the process of submitting a PAR that meets
the NesCom requirements. I have served that function once in the last two
years and in all cases both mentors and chairs have been satisfied with the
process.
The field of EDA is one that requires more coordination than most. This is
especially true in the area of languages and data formats and protocols. I
believe that the Computer Society must become aware that EDA plays an
important role in electronics and finally give the DASC the attention it
deserves. If our parent society is not capable of this, than the DASC
itself should work on developing operating rules for its WGs that include
the requirement of coordination with existing and developing standards.
The problem with asking IEEE-SA to make rules to help us is that we are
asking for generic rules that must apply to all Sponsoring Societies. We
have a specific problem: let's not pass the buck. I personally think that
we have been suffering from benign neglect by the Computer Society, because
the DASC has been, in IEEE terms, extremely successful in developing
standards that have been and continue to be both technically and financially
rewarding to IEEE-SA. What the DASC needs to do is to determine whether or
not we want to make the effort to develop what we need ourselves, at times
in spite of our parent organization, or sound a waking call to our sponsor.
In this case, going all the way to IEEE-SA is not the best, or more
efficient, course of action.
Gabe
----- Original Message -----
From: "Evan Lavelle" <eml@riverside-machines.com>
To: "'DASC Reflector'" <stds-dasc@eda.org>
Cc: "Ron Waxman" <r.waxman@computer.org>; "John Michael Williams"
<jwill@astragate.net>
Sent: Thursday, November 13, 2003 5:11 AM
Subject: Re: DASC Scope
> Ron Waxman wrote:
> > At 04:28 PM 11/12/03, John Michael Williams wrote:
> >> If several variants of SystemC or SystemVerilog
> >> evolved (literally)
>
> > They will.
>
> >> , and differences created
> >> incompatibilities,
>
> > They will.
> >
> >> then IEEE should consider resolving
> >> such differences by publishing a standard.
> >
> > Which is why an IEEE standard for a widely used "industrial strength" de
> > facto standard is needed before the problem exists.
>
> I don't think this will fix the problem, because we don't appear to have
> the procedures in place to handle this. Your point is basically that an
> IEEE standard is in some way independent and fixed, and is impermeable
> to vendor pressure, while a vendor or industry group standard is none of
> these things, and is subject to drift (correct me if I'm wrong).
>
> However, consider that one year from now DASC will very likely contain
> several hundred members, primarily composed of representatives of the
> major EDA vendors. If a group within DASC wants to push through a change
> which is beneficial to a particular vendor or group of vendors, then
> there is a very real possibility that this will happen. We will simply
> have become exactly what we are trying to avoid.
>
> How do we protect against this possibility? I can see 3 possible routes:
>
> 1 Strengthen the procedures to reduce vendor influence. This is already
> possible to some extent, but the WG chair has to apply this rule
> arbitrarily, in a way which is not defined. And what if the WG chair is
> an employee of the vendor who wishes to push through a change? I don't
> see that this is a viable route.
>
> 2 Is this what the Steering committee and NesCom are already attempting
> to do, in a rather ill-defined way? If so, this needs fixing. Their
> procedures need to be transparent, we need to know who's on these groups
> without resorting to Google, we need to know what their affiliations
> are, and we need to be convinced that they represent a cross-section of
> *users*, and that they represent the interests of *IEEE members*, not
> EDA vendors. The DASC does not exist to advance the interests of EDA
> vendors.
>
> 3 This is my personal favourite. The DASC needs a new advisory group.
> This should be composed of about 50 - 100 members, whose purpose will be
> to advise on the future direction of EDA, to arbitrate on issues such as
> whether a language is suitable for IEEE standardisation, to advise on
> whether an existing standard needs modification, and to ensure
> transparency and impartiality. The current DASC and the SC will remain
> unchanged, and the DASC will contain the hundreds of paying and voting
> members required for actually creating the standards. The advisory group
> should be composed of EDA experts, with demonstrable impartiality, and
> experience of a range of languages. The group should be composed of
> academics, and experts from within the industry. Voting needs to be
> secret to ensure that industry members are not unduly influenced by
> their employers.
>
> Evan Lavelle
>
This archive was generated by hypermail 2b28 : Thu Nov 13 2003 - 05:31:29 PST