Subject: Re: feedback for the ballot response document
From: Shalom Bresticker (Shalom.Bresticker@motorola.com)
Date: Thu Aug 22 2002 - 01:18:49 PDT
Jenjen Tiao wrote:
> JAE01: the author seems to be saying that the translate_off/_on should
> be kept, explain to him the reasoning behind the WG resolution.
If so, then this comment duplicates JL04.
The WG discussed this issue extensively.
The same functionality is provided by `ifdef SYNTHESIS.
> SG02: I would like to suggest that all of the example code (whether in
> part or
> whole) need to be verified by actually generating the synthesizable code
> to ensure
> the correctness of the comments and explanation given in the doc.
> However, since
> there are quite a bit through out the entire doc, at least verify the
> ones now that
> will be given in response to the ballot.
I agree, where possible.
In some case it is not possible because it depends on new features, such as
ROM inference.
In this particular case, I took the examples from the Synopsys Verilog HDL
Compiler Reference Manual
(just changing the blocking assignments to non-blocking assignments),
although not the latest edition.
> JG01: explain to the author by stating to him the scope of the standard.
I agree with the author that clause 4 is problematic.
I suggest that it be reconsidered entirely.
Maybe it is not even needed at all.
The standard need not specify a "practical conformance requirement,"
just as 1364 does not.
> JL05: elaborate a bit more to the author on why the restriction has been
> considered unnecessary.
Actually, my response to this comment was
"JL05: I don't understand the comment. What does "ignore required ...
elements"?
If they are ignored, then they are not required?"
> JL07: may be changing the text to "two-dimensional array of reg data
> type" instead
FYI: 1364-2001 was very careful about removing confusion between "reg" and
"register".
1364-2001 states,
"NOTE In previous versions of the Verilog standard,the term register was
used to encompass both the reg ,integer , time ,real and realtime types;but
that the term is no longer used as a Verilog data type."
Now the term "variable" is used to mean any of these data types,
whereas "reg" is reserved for reg data type specifically.
> JL13: I'm sorry, I don't have a copy of the proposed standard and I am
> just
> assuming the issue has something to do with some code in some current
> synthesis tools that the standard would like to get rid of and provide a
>
> workaround using existing verilog construct. An example would be the
> translate_off/translate_on meta-comments so widely used... If this
> section
> deals with such issues, then I have the following question:
> 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?
> PJM18: same issue as in JL07 - change to "two-dimensional array of reg
> data type"
>
> PJM33: maybe change the word "go" to "become"
The author of PJM33 is correct. The comma he requests is needed, regardless
of the word "thus".
Thanks for your comments, Jenjen.
-- 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"The devil is in the details."
This archive was generated by hypermail 2b28 : Thu Aug 22 2002 - 01:27:16 PDT