Subject: RE: feedback for the ballot response document
From: Jayaram Bhasker (JBhasker@esilicon.com)
Date: Mon Aug 26 2002 - 13:13:29 PDT
See embedded comments below.
- bhasker
-----Original Message-----
From: Shalom Bresticker [mailto:Shalom.Bresticker@motorola.com]
Sent: Thursday, August 22, 2002 4:19 AM
To: Jenjen Tiao
Cc: vlog-synth@server.eda.org
Subject: Re: feedback for the ballot response document
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.
[J Bhasker] Agreed. Will ad comment to WG resolution that WG discussed this
issue extensively.
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.
[J Bhasker] This is a good idea but maybe not practical. If someone has
access to a synthesis tool that supports
these features, you are welcome to test out the listed examples and post
results back to the reflector.
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.
[J Bhasker] I think the WG resolution marked in the ballot document is
sufficient.
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?"
[J Bhasker] I believe the author did not intend to write "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.
[J Bhasker] Good point, Shalom. I will add your note to the ballot response.
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?
[J Bhasker] 6.3 first para clearly states that these features are not
supported by the standard.
PJM18: same issue as in JL07 - change to "two-dimensional array of reg
data type"
[J Bhasker] See Shalom's previous response.
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".
[J Bhasker] Good points. Will make both changes.
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 : Mon Aug 26 2002 - 13:22:24 PDT