Subject: Re: 1364.1 ballot responses
From: Shalom Bresticker (Shalom.Bresticker@motorola.com)
Date: Thu Aug 29 2002 - 01:12:25 PDT
I hope the following comments are constructive.
SG05-06:
Clarification:
6.1.4(a,h): The author stated that "current synthesis tools apply this to
an entire module."
I believe that statement was incorrect, and the draft is consistent with
current use.
The addition, on the other hand, is a substantive change to the draft,
which requires reballoting.
TDH02:
4.2(a): The statement about asynchronous data is unclear to me.
For the asynchronous case, it says,
"When asynchronous data is assigned, the asynchronous data shall
not change during period the asynchronous control (the condition
under which the data is assigned) is active."
On the other hand, for the synchronous case, it says,
"Immediately after the clock edge,the input values may be changed."
The reason for the difference is not clear to me.
Or does the term "asynchronous data" refer to the FF output??
JL02:
Subissue 1 complains that the draft uses the pragma name "async_set_reset"
in a way
which is different and inconsistent with current tool usage.
According to my check, the author is correct.
Therefore, the resolution should be either to change to the usage to be
consistent with
current tool usage or to change the pragma name.
Thanks,
Shalom
Jayaram Bhasker wrote:
> Shalom:
>
> Let me respond to each of your relevant responses:
>
> SG05-06: The resolution you proposed, that was in response to the issue
> raised, has been
> documented. In addition, I believe you were making a new proposal - this is
> beyond the scope
> of the ballot document. A resolution for JL02 also has been posted which
> indicates that the
> proposal is deferred for future.
>
> TDH02: The author had proposed a recommended change which I feel is
> reasonable to accept. If you have
> a better proposal or a better wording that addresses the ambiguous clause
> that the author
> points out, please post it for review.
>
> TDH03: Author really meant changing "element" to "elements" which has been
> accepted. The "active"
> is really a typo. I will add this latter comment to the resolution document.
>
> JL01, JL02, JL03, JL05: These issues have been discussed in WG meetings in
> the past.
>
> JL06: Agree with your recommendation. Will move note to 5.2.2.
>
> - bhasker
>
> -----Original Message-----
> From: Shalom.Bresticker@motorola.com
> [mailto:Shalom.Bresticker@motorola.com]
> Sent: Monday, August 26, 2002 8:43 AM
> To: vlog-synth@server.eda.org
> Subject: 1364.1 ballot responses
>
> I worked on the ballot responses for the first set of comments (SAB01-JL06).
>
> In some cases, Jayaram changed what I wrote (as is his right).
>
> Since in some of those cases, I disagree with or at least have reservations
> about his changes, I present here my original comments so that the entire WG
> can
> judge.
>
> The relevant responses are:
>
> SG05-06
> TDH02
> TDH03
> JL01
> JL02
> JL03
> JL05
>
> Regarding JL06, the entire note should be in 5.2.2, not 5.2.2.1.
>
> Shalom
>
> ---------- Forwarded message ----------
> Date: Fri, 9 Aug 2002 14:25:56 +0300 (IDT)
> From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
> To: VhdlCohen@aol.com, cliffc@sunburst-design.com, Jbhasker7@aol.com
> Subject: 1364.1 ballot responses
>
> SAB01: Change "disasserted" to "deasserted".
>
> SAB02: Change "variables that are temporarily
> assigned and used in an always statement" to "intermediate variables
> that are
> temporarily assigned and used only in the same always statement".
>
> Regarding checkability, no change.
>
> SAB03: Change to "If any driver of the signal contains an assignment to
> the value z, then all the drivers must contain such an assignment."
>
> KMC01: No change required.
>
> JAE01: No change required. Don't understand "suggested_remedy =".
>
> SG01:
> Check that all Verilog keywords are boldfaced.
>
> Check that examples are not split over page breaks - pass this
> requirement to IEEE editors.
>
> Change "Unitialized" to "Uninitialized".
>
> "synthesis" in red is OK, it prints as bold. However, (* *) in 6.1 Note
> 1 which are also red do not print as bold. Make them bold.
>
> Change "--" to "//".
>
> Change "eg." to "example".
>
> "SYNTHESIS" is red is OK, it prints like bold. No change.
>
> SG02:
> Replace Example 22 with two cases, where the enable is not registered
> and where it is registered:
>
> Example of three-state driver with non-registered enable:
>
> always @(posedge CLOCK)
> Q <= DIN ;
>
> assign OUT = ENB ? Q : 1'bz ;
>
> This generates one FF with a three-state driver on the output.
>
> Example of three-state driver with reigstered enable:
>
> always @(posedge CLOCK)
> if (!ENB)
> OUT <= 1'b1 ;
> else
> OUT <= DIN ;
>
> This generates two FFs, one on DIN, and one on ENB, with a three-state
> driver on the output of the first FF, controlled by the output of the
> second FF.
>
> SG03:
> Change Example 21 to:
> always @(q or enb)
>
> SG04:
> Delete in 6.1.1 (a) and (b) the sentence
> "The optional value shall be ignored by synthesis tools."
>
> In addition to the reason mentioned by the commenter,
> another reason is that "additional semantics of a non-zero value are not
> defined by this standard", but synthesis tools are not PROHIBITED to use
> the value.
>
> SG05, SG06:
> Discuss in DWG. The addition sounds reasonable.
> In my 1997.08 copy of Synopsys HDL Compiler manual, it says that
> // synopsys_async_set_reset "signal_name_list" does what is written in
> this draft.
> There is also:
>
> // synopsys_async_set_reset_all "block_label_list"
> and
> hdlin_ff_always_async_set_reset = true
>
> But note comment JL02, subissue 1, which seems correct.
>
> SG07:
> Change fourth and fifth paragraphs from "signal names are present" to
> "signal names are specified in the attribute instance".
> Same applies to 6.1.4(h).
>
> By the way, the syntax is not clear when not specifying signals.
> Is it
> (* synthesis, async_set_reset="" *)
> or
> (* synthesis, async_set_reset *) ?
>
> JG01:
> I do not understand the proposal.
> What is a PIC?
> I am not sure it is necessary to specify a "practical conformance
> requirement".
> Many standards, such as 1364 itself, do not do so.
> No change for now.
>
> TDH01: Change "functtionality" to "functionality".
>
> TDH02: Actually, the entire paragraph about asynchronous data is not clear
> to
> me. The timing requirements are the same in any case. The FF does not know
> whether the clock and data are synchronous or asynchronous.
>
> What is the "asynchronous data" being referred to ?
> Is it the input or the output? It is not clear.
>
> TDH03: Change "element" to "elements".
>
> In addition, the commenter changed "inactive" to "active".
> I don't know whether this was intended.
> I myself am not sure of the intended meaning of the sentence.
> I also don't know why first it says "(i.e., latch)" and then "(i.e.,
> latched)".
> Was the difference intended?
>
> TDH04: Change to:
> "However, it may be necessary to include in the event list all the variables
> read in the always statement to avoid ..." (without additional commas).
>
> TDH05: Change to:
> "For example, a variable does not have to appear in the event list of an
> always statement if it is assigned a value with a blocking assignment
> before being used in subsequent expressions within the same always
> statement."
>
> TDH06: Change comment to:
> "// OUT models a positive edge-sensitive storage device with synchronous
> set."
>
> (Similar change to Example 9.
> Also, in Examples 7-10, why "edge-triggered edge-sensitive"?
> "edge-sensitive"
> is enough.)
>
> AI01: No change needed.
>
> JL01: I had trouble reading this and JL02. The comments were too long for my
> Excell cells. But I will do the best I can.
>
> Subissue 1: Discuss in DWG.
>
> Subissue 2: Discuss in DWG.
>
> Subissue 3: For future. No change for now. Coordinate with VHDL SIWG?
>
> JL02: Discuss in DWG. I tend to agree with commenter.
>
> JL03: I tend not to agree with the commenter. I have a different problem
> with
> test_port, however. It seems to contradict Section 4, para. 2, which says
> that
> ports can not be added or deleted during synthesis.
>
> JL04: No change. The idea is to get rid of them entirely.
>
> JL05: I don't understand the comment. What does "ignore required ...
> elements"?
> If they are ignored, then they are not required?
>
> JL06: I agree that the comment is a little confusing. Add a comment in the
> spirit of that suggested by the commenter. (Sorry, I'm too tired to suggest
> specific wording.) This note, however, should be in 5.2.2, not 5.2.2.1.
>
> Shalom
-- 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 29 2002 - 01:24:34 PDT