Subject: RE: feedback for the ballot response document
From: Shalom.Bresticker@motorola.com
Date: Wed Aug 28 2002 - 11:58:57 PDT
In my opinion, you are still contradicting yourself.
First, you say a tool is FORBIDDEN to support it.
Then you say it is not.
Furthermore, I remind you that the IEEE Style Guide uses "deprecated"
as a recommendation.
Shalom
On Wed, 28 Aug 2002, Jayaram Bhasker wrote:
> Date: Wed, 28 Aug 2002 09:02:08 -0700
> From: Jayaram Bhasker <JBhasker@eSilicon.com>
> To: 'Shalom Bresticker' <Shalom.Bresticker@motorola.com>
> Cc: Jenjen Tiao <tiao@agere.com>, vlog-synth@eda.org
> Subject: RE: feedback for the ballot response document
>
> Shalom:
>
> The terminology is clear to me. The statement:
>
> That means that it is FORBIDDEN for a synthesis tool to support the
> deprecated features.
>
> seems to imply that maybe you are mixing up tool support vs model
> portability. A synthesis tool
> is NOT prohibited from supporting more than the standard. However a
> model written using the standard
> should synthesize to identical behavior on 1364.1-compliant synthesis
> tools.
>
> - bhasker
>
>
> -----Original Message-----
> From: Shalom Bresticker [mailto:Shalom.Bresticker@motorola.com]
> Sent: Tuesday, August 27, 2002 1:16 AM
> To: Jayaram Bhasker
> Cc: Jenjen Tiao; vlog-synth@eda.org
> Subject: Re: feedback for the ballot response document
>
>
> Jayaram,
>
> Your answer does not resolve the inconsistency in the terminology.
>
>
> Shalom
>
>
>
> Jayaram Bhasker wrote:
>
>
> I suppose the issue here is if a synthesis tool continues to support the
>
> translate_off/translate_on meta-comments, can the synthesis tool still
> claim
> IEEE standard compatibility? (Assuming it also supports the IEEE
> standard suggested way.)
> If the answer to the question is yes, then the standard probably wants
> to use
> "Unsupported features used among some current synthesis tools" instead.
>
> The answer, I think, is yes, and the intention is to signal to users
> that the practice
> is highly discouraged even if the supported by the tool.
> "Unsupported" does not convey that.
>
> I have an issue, though, with the wording of 6.3.
> It says, "Current common practices of .... shall not be supported by
> this standard."
>
>
> The wording "shall not" is not appropriate here, as it refers to a
> requirement on
> a user or implementer of this standard. It is not a requirement on the
> standard itself.
>
>
> But let us assume that the meaning is simply "is not supported".
>
>
> Let's look at 1.3 Terminology.
>
>
> It says, "Not supported" means "RTL sythesis shall not support the
> construct.
> RTL synthesis does not expect to encounter the construct and the failure
> shall be undefined."
>
>
> That means that it is FORBIDDEN for a synthesis tool to support the
> deprecated features.
> Was that really the intention?
>
>
> Further, in the first paragraph of 1.3, it also says, "The word should
> is used to indicate that ...
> (in the negative form) a certain course of action is deprecated but not
> prohibited ("should"
> equals "is recommended that")."
>
>
> So now I am really confused.
>
>
> Does "deprecated" mean "shall not", i.e., prohibited, or "should not",
> i.e., not prohibited?
>
>
> [J Bhasker] 6.3 first para clearly states that these features are not
> supported by the standard.
>
>
This archive was generated by hypermail 2b28 : Wed Aug 28 2002 - 12:07:21 PDT