- Previous message: Shalom Bresticker: "errata/113: errata/113: generate"
- Next in thread: Brophy, Dennis: "RE: Interpretations"
- Maybe reply: Brophy, Dennis: "RE: Interpretations"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
This is somewhat long.
Let's see what IEEE actually says on the subject.
1) IEEE Standards Companion (2003)
(http://standards.ieee.org/guides/companion/part2.html#interpret):
Interpretations
Once a standard is approved, its major technical
development is complete. However, questions may arise
concerning the language used in the standard, the intention
or result meant by a particular action, etc. When a question of
meaning like this arises, an individual can write to the
Secretary of the IEEE-SA Standards Board asking for
interpretation of the passage in question. This request is then
forwarded to the sponsor for action. It is expected that a
group will develop a response to the interpretation request
and send it to the requestor (with a copy sent to the IEEE).
Often, however, someone may just be seeking an explanation
of the reasons behind what the standard said, rather than an
interpretation of the language itself. The Sponsor has the
right to label an interpretation request as an explanation if it
feels this is correct. The Sponsor can use whatever method it
wants to issue an explanation and return that response to the
requestor. The explanation should also be considered if the
standard is revised or amended, as this may be an area of the
standard that requires further clarification.
Completed interpretations are first made available at the IEEE
Standards website. Interpretations must be completed nine
months after any request was classified as an interpretation.
They may be published with the standard they interpret,
either bound in on the next printing or rolled into a collection
of standards. In some cases, the volume of interpretations
being generated by a committee may be great enough to
merit publication of a separate interpretations volume.
Interpretations are a unique form of commentary on the
standard. They are not statements of what the standard
should have done or meant to say. Interpretations cannot
change the meaning of a standard as it currently stands. Even
if the request points out an error in the standard, the
interpretation cannot fix that error. The interpretation can
suggest that this will be brought up for consideration in a
revision or amendment (or, depending on the nature of the
error, an errata sheet might be issued).
However, an interpretation has no authority to do any of this.
It can only discuss, address, and clarify what the standard
currently says. The challenge for the interpreters is to
distinguish between their expertise on what ?should be,?
their interests in what they ?would like the standard to be,?
and what the standard says. Interpretations are often
valuable, though, because the request will point out problems
that might otherwise have gone unaddressed.
One of the reasons interpretations cannot change the
standard is that they are not developed through an officially
balanced consensus process, that is, a ballot. The
interpretation request is handled by the sponsor through an
interpretations group. This group can be the standing
working group that developed the standard or it can be any
of the members of the working group or balloting group who
have expressed an interest in participating in the
interpretations process, depending on the rules of the
sponsor.
There is a requirement for balance in membership; it's
probably best to follow the principles of balance that were
used in balloting to establish balance in interpretations
groups. Interpretations also have to be balloted in the
Sponsor. But because this process doesn?t meet the rules
for approval of changes that are applied to an IEEE ballot, an
interpretation cannot change the meaning of a document.
All working groups should be aware that they may be called
upon to handle interpretations and come up with a process
for doing so while they are still developing their standard.
Level of participation in a working group is usually highest at
this point, and it is important for working group members to
be aware of this responsibility and prepare for their potential
involvement. Remember, some groups receive no
interpretations requests at all, while others receive many, so
the group may have nothing to do or a great deal to do. The
interpretations process you develop should be well known
within your technical community so that anyone who wants to
can participate. The procedure for submitting interpretations
requests is published in the front of every IEEE standard.
Some possible answers to requests are shown in Annex C to
give guidance on how to handle requests without altering the
meaning of the standard. Interpretations are useful in
indicating when a revision or an errata sheet might be
necessary as well. And if the Sponsor feels it cannot issue an
interpretation for a request, this is an area that clearly should
be reconsidered when the standard is revised.
Some Guidelines for Interpretations
1) The standard is what it says. If the
words are substantively wrong, then a
corrective corrigenda via the balloting
process is the correct response.
2) If the standard is ambiguous, then
the interpretation must favor a looser
requirement rather than a more
restrictive one. Again, a corrective
corrigenda can be initiated if needed.
3) If two parts of the standard
contradict one another, then a
rationale should be created and the
IEEE errata process should be applied
to correct the contradiction.
More information on interpretations
can be found here. (This points to
"IEEE Standards Interpretations", below)
Many interpretations groups meet via
phone or electronic mail, which avoids
any travel requirements or significant
time away from work.
2) IEEE Standards Companion, Annex C
(http://standards.ieee.org/guides/companion/annexb-c.html#partc)
Interpretation Responses
Some proforma examples of responses for
interpretation requests follow.
1.The unambiguous situation
"The standard clearly states . . . , and users
have to conform to this."
2.The "defect" situation (that is, if the standard
appears to be wrong)
"The standard states . . . , and users have to
conform to this. However, concerns have
been raised about this that are being referred
to the sponsor for possible action at the next
revision."
3.The ambiguous situation
"The standard is unclear on this issue, and no
distinction can be made between alternative
implementations based on this. This is being
referred to the sponsor for possible action at
the next revision."
4.The unaddressed issue
"The standard does not speak to this issue,
and as such no distinction can be made
between alternative implementations based on
this. This is being referred to the sponsor for
possible action at the next revision."
5.Conditional interpretation based on other
standard(s)
"The required behavior of this standard is
dependent on the requirements of another
standard. If the other standard requires aaa,
then this standard requires bbb. But if the
other standard requires ccc, then this standard
requires ddd. A request for interpretation of
the other standard is being forwarded to its
developing committee."
6.Substantially identical to a previous
interpretation
"This request is substantially identical to
interpretation #nnn, and the resolution of that
interpretation applies in this case."
7.Substantially identical to prior request, but with
critical new perspective
"This request is substantially identical to
interpretation #nnn; however, in considering
<rationale> it appears that the previous
interpretation should be superseded. The
current interpretation for this situation (which
does affect the previous conclusion) is . . . "
In this case, an attempt should be made to
notify the previous requestor with the
updated information.
8.Request for interpretation of a different
document or of a draft
"This request is for interpretation of nnn; the
approved standard is IEEE Std nnn. The
requestor is asked to resubmit this request if
the question(s) are still pertinent to the
approved IEEE standard."
9.Request is unclear (after attempt to contact
requester for clarification)
"This request is not sufficiently clear to permit
an appropriate interpretation. The requestor is
asked to submit a rephrased or more specific
request."
Some rationale, specific issue, or point of
ambiguity should be addressed in the
feedback to the requestor.
10.Request is inappropriate
"This request is being returned to you
because the questions asked do not
constitute a request for interpretation but
rather a request for consulting advice.
Generally, an interpretation request is
submitted when the wording of a specific
clause or portion of a standard is ambiguous
or incomplete. The request should state the
two or more possible interpretations or the
lack of completeness of the text. While you
referred to clause nnn, you have not indicated
any problem with the text. Please understand
that it is beyond the scope of this
committee/working group to provide
consulting advice."
3) IEEE Standards
Interpretations (http://standards.ieee.org/reading/ieee/interp/index.html)
Occasionally, questions may arise regarding the meaning of
portions of standards as they relate to specific applications.
Such requests for interpretations should ask for
clarifications of the exact nature of the contents of the
standard.
Questions relating to such interpretations are reviewed and
evaluated by a balance of members representing the
specific committee interests. This officially formed
interpretations subgroup creates and circulates a draft
interpretation among its members. It transmits a final
interpretation to the party initiating the request only after
consensus has been achieved. The interpretation is also
given to the standards-developing committee to consider
addressing it in a supplement or the next revision to the
standard.
Interpretations are issued to explain and clarify the intent of
the standard and are not intended to constitute an alteration
to the original standard or to supply consulting information.
The interpretations subgroup cannot make new rules to fit
situations not yet covered in the standard, even if the
investigations of the subgroup lead it to conclude that the
requirement is incomplete or in error. Changes to the
standard are made only through revisions or supplements to
the standard.
It is recognized that requests are frequently received that
are partially or totally requests for information rather than
requests for an interpretation. It is inappropriate to issue an
official interpretation to answer such requests. The
interpretations subgroup may, however, find from its
research that the literal printing of the standards text is not
identical to that approved by the standards developers and
may issue an editorial correction as a part of its
interpretation.
The original interpretations requests in this document have
been lightly edited to remove extraneous matter and to
focus on the problem presented. Some illustrations have
been redrawn for publication. With these exceptions,
requests are in the form received.
Procedure for Requesting an
Interpretation
Requests for interpretations should be addressed to
Secretary, IEEE Standards Board
IEEE Standards Department
445 Hoes Lane
P.O. Box 1331
Piscataway, NJ 08855-1331
Requests for interpretations may be sent via email to Linda
Gargiulo.
Requests for interpretations should include
1.The specific designation of the standard, including the
year of publication.
2.The specific subsection being questioned.
3.The applicable conditions for the case in question.
Line drawings should be black ink originals. Whenever
possible, an electronic file of graphics should be submitted
on disk in PICT, EPS, or TIFF format. Photos should be
black-and-white glossy prints. These illustrations must be
reproduced for committee circulation and eventually will be
used to supplement the text of the next edition. Clear
diagrams and pictures will make the work of interpretation
easier and more valuable to users.
Requests, including all supplementary material, must be in a
form that is easily reproducible. If suitable for consideration,
requests will be sent to the interpretations subgroup. After
consideration by the subcommittee, which may involve
many exchanges of correspondence, the inquirer will be
notified of the decision of the subgroup. Decisions will be
published from time to time in cumulative form and may be
ordered from the IEEE.
4) IEEE-SA Standards Board Bylaws (JAN 2004)
(http://standards.ieee.org/guides/bylaws/sect5.html#5.5)
5.5 Interpretations
While it is always the intent of standards-developing committees to use language
that is so clear that it is unnecessary to explain or amplify the original
intent of the committee, occasionally questions arise regarding the meaning of
portions of standards as they relate to specific applications.
Questions relating to such interpretations require review and evaluation by a
balance of committee interests. No single officer or member of an IEEE
Sponsor or subgroup thereof shall provide a written or verbal opinion concerning
any portion of the text of an IEEE standards document or an American National
Standard developed under IEEE secretariat, unless that opinion has first been
subjected to consideration by an interpretations subgroup that represents all
interested parties on the committee. The actions to be taken shall be as
specified in subclause 5.9 of the IEEE-SA Standards Board Operations Manual.
5) IEEE-SA Standards Board Operations Manual (2004)
(http://standards.ieee.org/guides/opman/sect5.html#5.9)
Some of this was changed recently, the following is the new wording:
5.9 Interpretations and explanations
Requests for interpretations shall be submitted or confirmed in writing to the
Secretary of the IEEE-SA Standards Board, who shall forward the request
to the appropriate Sponsor.
Upon receipt, the Sponsor shall screen all such requests to separate those that
require formal interpretation from those requesting an explanation. An
interpretation provides meaning to a clause, phrase, or sentence when it is open
to more than one reading or is ambiguous. An explanation does not
attempt to resolve ambiguities, but tries to elucidate the reasons for a
particular concept or approach. The Sponsor shall notify the Secretary of the
IEEE-SA Standards Board in writing, including electronic mail, preferably within
10 working days but no more than 30 days from the date of receipt of
the request, of which classification has been assigned to the request.
The Secretary of the IEEE-SA Standards Board shall notify the requestor within
10 working days of the Sponsor's written notification of the
classification of the request and the anticipated response date.
5.9.1 Explanations process
The Sponsor shall prepare explanations in the manner it deems practical and send
them to the party initiating the request and to the Secretary of the
IEEE-SA Standards Board. The correspondence shall clearly note that the request
was considered to be an explanation only. The explanation shall be
developed in a timely manner. A copy of the explanation shall be kept in the
Sponsor's records for consideration in developing any revisions or
amendments to the standard.
The Sponsor shall not be required to develop a response that in its estimation
constitutes engineering application information that would normally be
within the area of consultant services. The explanation will be made available
to any other party who makes a request to review the explanation. A charge
may be incurred for providing such a copy and is the responsibility of the
review requestor.
5.9.2 Interpretations process
The Sponsor may forward requests for interpretation to a designated
interpretations group.
The proposed response prepared by the designated interpretations group shall be
approved by a majority of that group prior to submittal to the
Sponsor.
Once accepted by the interpretations group, a vote on the proposed response
shall be taken in accordance with Sponsor rules. As a courtesy, the
preliminary response may be sent to the requestor. If the requestor submits
comments on the preliminary response within 15 days of the date that the
proposed interpretation is sent to the requestor, the Sponsor shall consider the
comments and respond to the requestor. The proposed interpretation
response shall be concluded within nine months of notification of classification
of the interpretations request as an interpretation by the Sponsor.
The final interpretation shall be transmitted to the party initiating the
request. A copy shall be forwarded to the Secretary of the IEEE-SA Standards
Board, together with a list of the members of the designated interpretations
group for IEEE records. IEEE Standards interpretations shall be posted at
the IEEE Standards website until the next amendment or revision of the standard.
If the Sponsor is unable to reach consensus on an interpretation, the Sponsor
can respond to the requestor that an interpretation will not be
forthcoming on this matter. It should be noted that, if the Sponsor cannot issue
an interpretation for a request, this area of the standard should be
considered for revision.
Interpretations shall be developed in a timely fashion. If the Sponsor
classifies the request as an interpretation, the Secretary of the IEEE-SA
Standards
Board shall provide a status report to the requestor no more than 90 days from
the Sponsor's classification of the interpretation request as an
interpretation. The Sponsor shall keep a log of all interpretations requested
and completed. The Sponsor shall consider interpretations either as
corrigenda, when developing an amendment to the standard, or for inclusion in
the next revision of the standard.
5.9.3 Disclaimer
Wording to this effect is included in each IEEE standard published:
"At lectures, symposia, seminars, or educational courses, an individual
presenting information on IEEE standards shall make it clear that his or her
views
should be considered the personal views of that individual rather than the
formal position, explanation, or interpretation of the IEEE."
When a proposed interpretation is sent to a requestor and a Sponsor, the
following wording shall be attached:
"WARNING: This proposed interpretation is not an official IEEE Sponsor
interpretation, as it has not yet been balloted and, as such, is subject to
change.
This proposed interpretation is for informative purposes only. USE AT YOUR OWN
RISK."
Now, having seen all that, if you are still reading this, let's see what Steven
wrote.
Steven Sharp wrote:
> >That makes sense. On the last paragraph though, I'm not sure
> >that *Verilog* cases currently do evaluate in that way, even if
> >existing Verilog simulation *tools* evaluate them in that way.
> >Is there really anything in the LRM itself that would make
> >my hypothetical new tool wrong if it followed Shalom's "dachuk"
> >interpretation?
>
> There are several questions here.
>
> 1. Can you apply your own "dachuk" interpretation to the standard
> and legitimately claim that you are following the standard? I think
> that the answer is no. There was an intended interpretation, which
> was actually pretty clear here. Even if it weren't clear and could
> reasonably be considered ambiguous, that still doesn't mean that any
> interpretation you choose is valid. There was still an intended
> interpretation, and that is the only valid one.
According to the IEEE Standards Companion,
"If the standard is ambiguous, then the interpretation must favor a looser
requirement rather than a more restrictive one."
That is for the case "if it weren't clear and could reasonably be considered
ambiguous".
> Presumably there is a procedure for requesting clarification from the
> standards body, so you can get the official interpretation. If you
> apply your own interpretation instead of the official interpretation,
> it is your mistake, just as if you misread the LRM. I assume that
> there is some official IEEE policy to this effect, because it seems
> like the only reasonable way to handle it.
>
> 2. What if the LRM says nothing about a subject? Is this the same as
> saying something ambiguous (i.e. you should ask for an interpretation)?
> Or is it reasonable to assume that an implementation is not constrained
> in that area? I think that this would still be subject to official
> interpretation, but hopefully most readers have good enough judgement to
> avoid the need to ask in most cases. One problem here is that if there
> is no text in the LRM, there may not be any historical knowledge of the
> intent. That brings us to the next question.
From the Standards Companion, example response 4:
4.The unaddressed issue
"The standard does not speak to this issue,
and as such no distinction can be made
between alternative implementations based on
this. This is being referred to the sponsor for
possible action at the next revision."
From the IEEE Standards Intrepreations page,
"The interpretations subgroup cannot make new rules to fit
situations not yet covered in the standard, even if the
investigations of the subgroup lead it to conclude that the
requirement is incomplete or in error."
> 3. Is the LRM the sole source of the definition of the language? In an
> ideal world, it would be. However, I don't think that this is practical
> with the current Verilog LRM. It started out as the Verilog-XL Reference
> Manual, which was not a complete or rigorous specification of the language.
> It was only adequate because there was a reference implementation. Some
> improvements have been made since, but it is still not complete. And in
> the meantime, we have officially lost the reference implementation. That
> creates a problem. I think that practicality requires us to recognize
> that we have to get historical knowledge of the "intent" in a variety of
> ways, including the memories of those who were involved, and the known
> behavior of the former reference implementation.
I think the IEEE rules are pretty clear that the standard IS
"the sole source of the definition of the language"
(including official interpretations of what is already written there).
> Not everyone has direct access to those memories or that reference
> implementation, but I don't think that matters. Those are not directly
> the standard anyway. Everyone has equal access to the actual standard,
> including asking for official interpretations of it. Such interpretations
> are always going to be based on knowledge that was not universal (since
> otherwise the asker would have known the answer already).
>
> So existing Verilog tools may not define the language, but the behavior of
> some of them may indicate the historical intent of something that is not
> explicit enough in the LRM. In that sense, they assist in defining the
> language.
>
> 4. If we accept the behavior of some implementation as "correct", would
> that be sufficient to define the standard? The answer here is clearly
> no. The standard may allow a variety of behaviors in some situation,
> while a tool can only practically implement one. The tool can indicate
> a behavior that is allowed, but not whether any alternatives are allowed.
> That requires reference to the LRM, and judgement.
>
> This is also something that can change. There are things that were
> originally specified to be nondeterministic, but were later required to
> be deterministic and match the reference implementation (e.g. order of
> nonblocking assignments completing). Others were originally intended to
> work a specific way, but were later relaxed to allow a noncompliant
> implementation to be considered compliant (e.g. whether all subprocesses
> have to be disabled by a disable statement).
And of course an implementation's behavior is not automatically correct.
The fact that some implementation works some way, even if it is the original
implementation upon which the original standard was based, does not
automatically mean that is what the standard should be. In fact, during the
development of 1364-1995, there were some deliberate changes, and that
original implementation is not and never has been 100% compliant to 1364-1995
(which is not meant to imply that any other implementation is in a better or
worse state).
> 5. How does all of this apply to the specific question of case item
> expression evaluation? Here is my opinion, which may or may not be
> backed up by official IEEE policy.
>
> The text in question is reasonably clear, and I think everyone agrees on
> the intent of it. So that provides an official interpretation of the
> text. A hypothetical tool that did not follow that interpretation would
> be wrong.
Even if everyone agrees on the intent, that still does not make it an
official interpretation. There is a process for that. Fortunately for us
(or unfortunately, depending on how you look at it), IEEE does not
deal with compliance certification.
> However, Shalom says that text is not in the published standard, but is
> something that we approved for a later draft. I am not sure what the
> resulting effect is. I think it would be considered an interpretation of
> the standard, which is being inserted into the text for the next revision
> (subject to balloting at that time).
Again, we have not issued it as an official interpretation.
We could think about issuing an interpretation document.
> The behavior that we approved happens to match certain existing tools,
> and that is presumably part of why we approved it. If we were discussing
> the approval of that text, we could debate whether the standard should
> require that exact behavior, or allow some variation. If a proposal is
> made to change that text, then we can discuss it again. But at present
> I think that the text has been approved as an interpretation, and that
> the intent of it is known, so that is the standard. The text itself seems
> to me to describe that intent adequately, so I am not convinced that there
> is a problem here.
>
> >Consider the semantics of fork. I think it's probably the case that
> >existing tools do not interleave threads. But if I wanted to execute
> >each thread truly in parallel on separate processors, wouldn't that
> >be within the letter of the LRM law? There are likely some existing
> >Verilog programs that rely on the threads of a fork happening one after
> >the other, in some nondeterministic order, but not interleaved.
> >My hypothetical new tool would break them, but still be legal Verilog.
>
> The LRM explicitly allows interleaving of process execution in section 5.
> However, if you took the interleaving to an extreme (as would happen with
> separate processors if you didn't do some basic synchronization around
> critical regions), I think it would fall outside the intent of this section.
> While the intent was apparently partly to allow for parallel simulation,
> an extreme interpretation of the allowed interleaving could create serious
> language problems that the original authors probably didn't intend.
Which is related to my favorite issue, #57.
-- 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
- Next message: Shalom Bresticker: "errata/569: 17.2.3: $swrite is not a file-based i/o task"
- Previous message: Shalom Bresticker: "errata/113: errata/113: generate"
- Next in thread: Brophy, Dennis: "RE: Interpretations"
- Maybe reply: Brophy, Dennis: "RE: Interpretations"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
This archive was generated by hypermail 2.1.4
: Tue Mar 30 2004 - 00:27:04 PST
and
sponsored by Boyd Technology, Inc.