Re: [vhdl-200x] Stephen Bailey's concerns on Group Organization and PAR

I didn't ask for the PAR to be modified. I asked for a clue as to the scope of the revision. All revision PARs have a scope as generic and broad as the original. That does not prevent the SG or expected WG participants from specifying what they plan to do. Until I asked the question, there was virtually no discussion of the scope. After my email, it became clear that scope expectations are extremely diverse.

I repeat that every standards WG I have participated had an understanding of the scope at the time the PAR was submitted. These circumstances are intentionally vague and divorced from the likeliest source of funding (Accellera) by choosing a membership organization which prohibits their participation.

These are not conditions conducive to success.

Why the rush? What is so difficult in spending a few months on the scope?

-----------
Stephen Bailey

On Dec 21, 2010, at 2:14 PM, "Jim Lewis" <Jim@synthworks.com> wrote:

> Hi All,
> I am writing this to address some of Stephen Bailey's
> concerns.
>
> > [Stephen]
> > I find it impossible to believe that there is no
> > clue of what the scope of this effort will actually
> > entail.
> The amount of detail that is in the PAR is exactly the same
> as the PAR for VHDL-2008 (which is based off of one from when
> Stephen was chair). The VHDL-2008 par is here:
> http://www.eda-twiki.org/vasg/p1076_2008_approved_par.pdf
>
> Due to your concern, I checked other PARs and have found
> them to have a similar level of detail. For example the
> latest (2010) SystemVerilog PAR is here:
> http://www.eda-twiki.org/twiki/pub/P1800/P1800Workinggroup/P1800_PAR_2010.pdf
>
> The 2010 P1800 SystemVerilog purpose states:
> This standard develops the 1800 SystemVerilog language
> in order to meet the increasing usage of the language in
> specification, design and verification of
> hardware. This revision corrects errors and clarifies
> aspects of the language definition in the 1800-2009
> standard. This revision also provides enhanced features
> that ease design, improve verification, and enhance cross
> language interactions.
>
> > [Stephen]
> > SG's have 6 months. They should be able to determine the relative scope
> > of the project in that time frame. Asking for PAR approval after 2
> > meetings that focus only on the type of organization of the WG is
> > inappropriate.
>
> The IEEE-SA by-laws actually say under some conditions the PAR can be
> approved in one meeting. Instead we took two.
>
> > [Stephen]
> > Why would anyone want to be
> > involved? Can you think of a better way to ensure maximum
> > dissatisfaction with the result than to leave an understanding of the
> > scope unstated? The email discussion since I distributed my negative
> > vote on PAR approval indicates how wide the expectations are.
> The following is similar to a quote I heard (was it Judy Gorman or
> Mick Jagger?):
> In the standards process you don't necessarily get
> what you want, but if you participate you usually get
> something you can live with.
>
> If we follow the Accellera process, there are lots of checks
> and balances in it. This is how I see the process working
> (note, these are just my thoughts, the WG will have to
> approve any process that we decide to use):
> 1) Requirements team
> Who: All
> Purpose: Develop and prioritize requirements.
> Action:
> High priority requirements get forwarded to the
> proposals team. Low priority requirements don't
> get WG authorization to go forward.
> 2) Proposals team
> Who: People who feel comfortable writing or reviewing
> one or more proposals
> Purpose: Write proposals for implementation of requirements
> Actions:
> Champions volunteer to work on requirement.
> If an enhancement does not get a champion,
> it does not go any further.
> All proposals are reviewed in detail approved by
> the proposals team before they go to the next step.
> 3) Proposal vs Requirements Review
> Who: All (Requirements + Proposals team)
> Purpose: Make sure the proposals implement the requirements
> from the viewpoint of the requirements team.
> Actions:
> Vote on proposals to make sure they address
> the requirements.
> 4) Write LRM changes
> Who: LRM mechanics
> Action:
> Write LRM language change specifications for the proposals.
> 5) LRM change vs. Proposal Review
> Who: All (LRM + Proposals + ?Requirements?)
> Purpose: Identify any differences in the proposal and the
> LRM change (if any).
> Action:
> Vote to approve or disapprove any differences in
> LRM change from proposals.
>
> Peace,
> Jim
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Jim Lewis
> Director of Training mailto:Jim@SynthWorks.com
> SynthWorks Design Inc. http://www.SynthWorks.com
> 1-503-590-4787
>
> Expert VHDL Training for Hardware Design and Verification
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.