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.Received on Tue Dec 21 14:13:08 2010
This archive was generated by hypermail 2.1.8 : Tue Dec 21 2010 - 14:13:59 PST