1364.1 ballot responses


Subject: 1364.1 ballot responses
From: Shalom.Bresticker@motorola.com
Date: Mon Aug 26 2002 - 05:43:27 PDT


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



This archive was generated by hypermail 2b28 : Mon Aug 26 2002 - 05:57:41 PDT