LRM Errata to review before April 6

From: Anders Nordstrom (andersn@nortel.ca)
Date: Tue Apr 07 1998 - 17:35:15 PDT

Next message: Anders Nordstrom: "REMINDER: BTF Conference Call April 6"
Previous message: Michael McNamara: "Enhancement to BTF - B3 Writing binary data."
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

BAD MSG:
<HTML>
HEAD>
   <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
   <META NAME="GENERATOR" CONTENT="Mozilla/4.03 [en] (X11; U; SunOS 4.1.4 sun4m) [Netscape]">
   <TITLE> Errata to vote on by BTF </TITLE>
</HEAD>
<BODY BGCOLOR="#FFF0F0">
Content-Length: 90839
X-Lines: 2631
X-Status: $$$$
X-UID: 0000000373
Status: RO

<H1>
New LRM Errata for 1364 WG to vote on</H1>
<BR>
<BR>
<HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE01 - Annex A - simple _identifier error</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>graham@compass-da.com (Paul Graham)</TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal</TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Anders Nordstrom</TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>Annex A. The BNF syntax for simple_identifier, simple_identifier
::= [a-zA-Z][a-zA-Z_$] if taken seriously, means that an identifier must
contain exactly two characters. Furthermore, the second character may not
be numeric. I suppose the intent was simple_identifier ::= [a-zA-Z][a-zA-Z0-9_$]*</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>On page 603 change</FONT>
<BR><FONT SIZE=+1>from:</FONT>
<BR><FONT SIZE=+1>simple_identifier ::= [a-zA-Z][a-zA-Z_$]</FONT>
<BR><FONT SIZE=+1>to:</FONT>
<BR><FONT SIZE=+1>simple_identifier ::= [a-zA-Z_] [ { [a-zA-Z0-9_$] } ]</FONT>
<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE07 - Section 14.5.11 - timing_check problems</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>graham@compass-da.com (Paul Graham) </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal</TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Ted Elkind</TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>Section 14.5.11. The syntax for timing check condition</FONT>
<PRE><FONT SIZE=+1>timing_check_condition ::=
                scalar_expression
                | ~scalar_expression
                | scalar_expression == scalar_constant
                | scalar_expression === scalar_constant
                | scalar_expression != scalar_constant</FONT></PRE>
<FONT SIZE=+1>has many problems.</FONT>
<BR><FONT SIZE=+1>First, the syntax given in the syntax box in section
14.5.11 is different from that given in Annex A.7. The syntax in Annex
A includes an extra choice:</FONT>
<BR><FONT SIZE=+1>| expression !== scalar_constant</FONT>
<BR><FONT SIZE=+1>And why does section 14.5.11 use "scalar_expression"
while Annex A uses "expression"? Which is correct?</FONT>
<BR><FONT SIZE=+1>Second, the syntax is ambiguous. Given the code</FONT>
<BR><FONT SIZE=+1>$setup(a, posedge b &&& ~c, 10);</FONT>
<BR><FONT SIZE=+1>is the expression "~c" to be interpreted as the first
alternative, "scalar_expression", or as the second alternative, "~scalar_expression".
Either interpretation is possible.</FONT>
<BR><FONT SIZE=+1>Similarly, in</FONT>
<BR><FONT SIZE=+1>$setup(a, posedge b &&& c == 1, 10);</FONT>
<BR><FONT SIZE=+1>the expression "c == 1" can be interpreted as either
the first choice or the fifth choice. Note that the examples given in section
14.5.11 avoid this ambiguity:</FONT>
<BR><FONT SIZE=+1>$setup(data, posedge clk &&& (~clr), 10);</FONT>
<BR><FONT SIZE=+1>Here expression "(~clr)" can only be interpreted as "scalar_expression",
not as "~scalar_expression". Why? Because the syntax for "~scalar_expression"
does not allow enclosing parentheses.</FONT>
<BR><FONT SIZE=+1>I think the syntax for timing_check_condition could be
better written:</FONT>
<BR><FONT SIZE=+1>timing_check_condition ::= scalar_expression</FONT>
<BR><FONT SIZE=+1>This supports the apparent intent of the actual syntax,
and it allows all the examples given in section 14.5.11. (Note: Perhaps
the syntax given in 14.5.11 is intended more as a suggested usage pattern
than as a linguistic definition.)</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>Add the following line at the end of the rule for timing_check_condition
in Syntax 14-8 on page 196:</FONT>
<PRE><FONT SIZE=+1>
| scalar_expression !== scalar_constant"</FONT></PRE>
<FONT SIZE=+1>Change the rule for scalar_timing_check_condition in A.7
page 601 to:</FONT>
<PRE><FONT SIZE=+1>timing_check_condition ::=
                scalar_expression
                | ~scalar_expression
                | scalar_expression == scalar_constant
                | scalar_expression === scalar_constant
                | scalar_expression != scalar_constant
                | scalar_expression !== scalar_constant</FONT></PRE>

<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE08 - Annex A.8 - Embedded spaces clarification</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>graham@compass-da.com (Paul Graham)</TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Submitted (priority not yet assigned)</TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Cliff Cummings</TD>
</TR>
</TABLE>

<FONT SIZE=+1>NOTE: I Recommend combining BE08 and BE35 into BE08 because
they both affect a common piece of the BNF. ?. Annex A.8. At the end of
this section is the note</FONT>
<PRE><FONT SIZE=+1>1--Embedded spaces are illegal.</FONT></PRE>
<FONT SIZE=+1>It is not clear what this note applies to. It could apply
to the definitions of unary_operator, binary_operator, unsigned_number,
decimal_base, binary_base, octal_base, and hex_base. Perhaps it also applies
to decimal_number, real_number, and name_of_system_function?</FONT>
<H2>
<FONT SIZE=+1>BE35 - ambiguous grammar for number</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Paul Graham </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Submitted (priority not yet assigned)</TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Cliff Cummings</TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>The grammar for a number is ambiguous. A number, for instance
a real_number, may begin with a sign (+ or -). Yet the syntax for expression
allows + and - to be unary operators. So the expression -3 can be parsed
either as a decimal_number with a sign or as an expression whose operator
is - and whose operand is the (positive) decimal_number 3. If -3 is parsed
as a decimal_number with a sign, then the statement: parameter x = --3;
should be legal, since the first "-" is a unary operator in an expression
and the second is not an operator at all, but part of the decimal_number.</FONT>
<BR><FONT SIZE=+1>I recommend that you follow VHDL's rule which is that
a numeric literal never includes a sign, and any sign (+ or -) preceding
a numeric literal is a unary operator in an expression.</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>I agree that the LRM is not clear and propose the following
changes to the BNF :</FONT>
<BR><FONT SIZE=+1>NOTE: In e-mail text format, base(1) = base followed
by a "1" subscript (subscripts do not show up in pure text files)</FONT>
<BR><FONT SIZE=+1>In section A.8, pg. 602:</FONT>
<PRE><FONT SIZE=+1>1995>real_number ::=
1995> [ sign ] unsigned_number . unsigned_number
1995> | [ sign ] unsigned_number [ . unsigned_number ] e [ sign ]
unsigned_number
1995> | [ sign ] unsigned_number [ . unsigned_number ] e [ sign ]
unsigned_number

1998 BE08>real_number(1) ::=
1998 BE08> unsigned_number . unsigned_number
1998 BE08> | unsigned_number [ . unsigned_number ] e [ sign ] unsigned_number
1998 BE08> | unsigned_number [ . unsigned_number ] E [ sign ] unsigned_number</FONT></PRE>
<FONT SIZE=+1>In section A.8, pp. 603:</FONT>
<PRE><FONT SIZE=+1>1995>decimal_number ::=
1995> [ sign ] unsigned_number
1995> | [ size ] decimal_base unsigned_number
1995>binary_number ::= [ size ] binary_base binary_digit { _ | binary_digit }
1995>octal_number ::= [ size ] octal_base octal_digit { _ | octal_digit }
1995>hex_number ::= [ size ] hex_base hex_digit { _ | hex_digit }

1998 BE08>decimal_number ::=
1998 BE08> unsigned_number
1998 BE08> | [ size ] decimal_base unsigned_number
1998 BE08>binary_number ::= [ size ] binary_base binary_value
1998 BE08>octal_number ::= [ size ] octal_base octal_value
1998 BE08>hex_number ::= [ size ] hex_base hex_value</FONT></PRE>
<FONT SIZE=+1>In section A.8, pp. 603:</FONT>
<PRE><FONT SIZE=+1>1995>unsigned_number ::= decimal_digit { _ | decimal_digit }

1998 BE08>unsigned_number(1) ::= decimal_digit { _ | decimal_digit }
1998 BE08>binary_value(1)::= binary_digit { _ | binary_digit }
1998 BE08>octal_value(1)::= octal_digit { _ | octal_digit }
1998 BE08>hex_value(1)::= hex_digit { _ | hex_digit }</FONT></PRE>
<FONT SIZE=+1>In section A.8, pp. 603:</FONT>
<PRE><FONT SIZE=+1>1995>decimal_base ::= 'd | 'D
1995>binary_base ::= 'b | 'B
1995>octal_base ::= 'o | 'O
1995>hex_base ::= 'h | 'H

1998 BE08>decimal_ base(1)::= 'd | 'D
1998 BE08>binary_ base(1)::= 'b | 'B
1998 BE08>octal_ base(1)::= 'o | 'O
1998 BE08>hex_ base(1)::= 'h | 'H</FONT></PRE>
<FONT SIZE=+1>In section A.8, pp. 603:</FONT>
<PRE><FONT SIZE=+1>1995>name_of_system_function ::= $identifier
1998 BE08>name_of_system_function(2) ::= $identifier</FONT></PRE>
<FONT SIZE=+1>NOTES</FONT>
<BR><FONT SIZE=+1>1- Embedded spaces are illegal</FONT>
<BR><FONT SIZE=+1>2- The $ in name_of_system_function may not be followed
by a space</FONT>
<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE12 - delay_or_event_control omission</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>graham@compass-da.com (Paul Graham) </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Anders Nordstrom </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>Section 9.7. Syntax box 9-8 defines delay_or_event_control:</FONT>
<PRE><FONT SIZE=+1> delay_or_event_control ::=
        delay_control
        | event_control</FONT></PRE>
<FONT SIZE=+1>Annex A.6 page 598 defines it differently:</FONT>
<PRE><FONT SIZE=+1> delay_or_event_control ::=
        delay_control
        | event_control
        | repeat (expression) event_control</FONT></PRE>
<FONT SIZE=+1>Which version of the syntax is correct?</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>Replace the follwing statement in Syntax 9-8:</FONT>
<PRE><FONT SIZE=+1> delay_or_event_control ::=
        delay_control
        | event_control</FONT></PRE>
<FONT SIZE=+1>with:</FONT>
<PRE><FONT SIZE=+1> delay_or_event_control ::=
        delay_control
        | event_control
        | repeat (expression) event_control</FONT></PRE>

<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE14 - Missing tasks in list in section 14</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>chas@cadence.com </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Anders Nordstrom / Mike McNamara </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>The section on PLA modeling tasks lists half of the tasks
twice and doesn't list the other half.</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>Under the heading "PLA modeling tasks", change the last four
task names in column one from $async... to $sync... and change the first
four task names in column two from $sync... to $async...</FONT>
<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE15 - $fopen() on MCD is unclear</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>chas@cadence.com </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Anders Nordstrom </TD>
</TR>
</TABLE>

<H3> Details </H3>
<FONT SIZE=+1>
Section 14.2.2 on page 181 does not explain what would happen if $fclose()
is used on an MCD which is being used by $fmonitor() or $fstrobe.</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>Add the following sentence to section 14.2.1 in the text
for the new file I/O proposal B03: <P>
"Active $fmonitor or $fstrobe operations
on a file descriptor or MCD are implicitly canceled by an $close operation.

<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE17 - Can functions contain immediate non blocking assignments</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Steve Meyer, sjmeyer@crl.com </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Adam Krolnik </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>In IEEE P1634 LRM section 10.3.4 page 130 there is a list
of statement types illegal in function bodies. As I read the 5 rules, non
blocking assignments with delay controls such as "a <= #5 b;" are illegal
because they contain time controls, but immediate non blocking assignments
seem to be allowed (i.e. "a <= b;"). I assume immediate non blocking
assignments are illegal in function bodies because they schedule events
that must be processed after a function returns. Is this true? I guess
fixing section 10.3.4 should be on the behavioral task force errata list.

/Steve</FONT>
<PRE><FONT SIZE=+1>Steve Meyer Phone: (415) 296-7017
Pragmatic C Software Corp. Fax: (415) 296-0946
220 Montgomery St., Suite 925 email: sjmeyer@crl.com
San Francisco, CA 94104</FONT></PRE>

<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>
Change the second sentence in section 10.3.4 on
page 130 to: <P>
"The following six rules govern their usage:"<P>
Add a sixth
rule as: <P>
f) A function shall not have any non-blocking assignments.</FONT>

<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE19 - length of logical not</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Simon Read </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Adam Krolnik </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>There is no definition of whether logical not (!) evaluates
its operand with the length of the expression or with a self-determined
length. I will assume it is self-determined (as for other simple unary
operators).</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>Add to the first box on row 3 on page 44 of Table 4-21 the
operator "!". <P> The content of the box is now: "op i, there op is: &

<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE20 - who cares about inter_assignment_timing_control_statement</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Daniel Barclay </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Anders Nordstrom </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>intra_assignment_timing_control_statement is defined in Syntax
9-12 but not referred to anywhere in the grammar.</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>Replace the content in syntax 9-12 on page 117 with:</FONT>
<PRE><FONT SIZE=+1>blocking_assignment ::= reg_lvalue = [delay_or_event_control] expression
non_blocking_assignment ::= reg_lvalue = [delay_or_event_control] expression
delay_or_event_control ::= delay_control
                         | event_control
                         | repeat (expression) event_control
delay_control ::= # delay_value
                         | # (mintypmax_expression)
event_control ::= @ event_identifier
                         | # ( event_expression )</FONT></PRE>
<FONT SIZE=+1>which matches the BNF from appendix A.6 on page 599</FONT>
<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE22 - defparams versus mipva</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Mitch Perilstein </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Anders Nordstrom / Mike McNamara </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>How are multiple defparams and module instance parameter
value assignments to the same parameter value resolved? [XL:defparam always
wins.]</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>Add the text "If a defparam assignment conflicts with a module
instance parameter, the parameter in the module will take the value specified
by the defparam." before the last sentence in section 12.2 on page 139</FONT>
<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE23 - 12.2 and 12.2.2 conflict</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Mitch Perilstein </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Anders Nordstrom / Mike McNamara </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>The first sentence in 12.2 implies a parent-child relationship
is necessary to override parameter values. 12.2.2 says defparam statements
can change parameter values anywhere in the design. The first sentence
in 12.2 should be dropped.</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>Remove the sentence "When one module instanciates .... ...
instanciated module" in section 12.2 on page 139</FONT>
<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE24 - multiple defparams not mentioned</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Mitch Perilstein </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Anders Nordstrom / Mike McNamara </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>The lrm neither allows nor disallows multiple defparams of
a single parameter value. [XL: last defparam encountered in source text
wins.]</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>Add the following paragraph before the last paragraph on
page 139: <P>
"In the case of multiple defparams for a single parameter, the
parameter takes the value of the last defparam statement encountered in
the source text."</FONT>
<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE25 - Ranges disallowed for integer type</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Mitch Perilstein </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Mike McNamara </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>The declaration of an integer register having a given size,
such as "integer [1:2] x;" are disallowed by 1364 however are accepted
by many tools, (including XL?)</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>Do not change the LRM, declaration of an integer register
having a given size should still be disallowed.</FONT>
<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE26 - mintypmax is not an operator</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Mitch Perilstein </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Adam Krolnik / BTF meeting </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>The mintypmax selector is listed as an expression but not
an operator, so it doesn't have precedence. This means it cannot be safely
used without parentheses inside or outside a ternary operator. <P>
/Mitch Perilstein <P>
The syntax
box correctly doesn't list enclosing parenthesis because other sections
that describe when a mintypmax_expression is allowed either do not require
them (because the value is not part of a general expression where the ternary
operator is allowed), or specify parenthesis to be used when expressing
a mintypmax_expression. I.e. Section 4.3 examples all use mintypmax expressions
enclosed in parenthesis. Section 7.15.1 examples show mintypmax expressions
used as delays in a comma separated list. Section 13.4.1 examples show
specparam delay values as mintypmax expressions, again in a comma separated
list. Recommend no changes due to this errata report. <P>
Adam Krolnik</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>Change the first sentence of section 4.3 on page 42 to: <P>
"Verilog
HDL delay expressions can be specified as three expressions separated by
colons and enclosed by parentheses. <P>
Add the following BNF from section
A.8 first in Syntax 4-2 on page 42:</FONT>
<PRE><FONT SIZE=+1>expression ::=
        primary
        | unary_operator primary
        | expression binary_operator expression
        | expression ? expression : expression
        | string

<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE27 - transition_pair</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Paul Graham </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Anders Nordstrom </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>The BNF for transition pair is:</FONT>
<PRE><FONT SIZE=+1> transition_pair ::= 01 | 0x | 10 | 1x | x0 | x1</FONT></PRE>
<FONT SIZE=+1>The BNF allows only lowercase x, which is odd, considering
that both x and X are allowed in output_symbol, level_symbol, and binary_digit.
There is also a sentence in the section:</FONT>
<PRE><FONT SIZE=+1> Edge transitions involving z are treated the same way as edge
transitions involving x.
</FONT></PRE>

<PRE><FONT SIZE=+1>If the BNF is taken seriously, it is syntactically impossible to have an
edge transition involving z. Is the BNF incorrect, or does the quoted
sentence have no referent? I suspect that the BNF is incorrect. The
following syntax will work:</FONT></PRE>

<PRE><FONT SIZE=+1> transition_pair ::=
        01
        | 10
        | z_or_x zero_or_one
        | zero_or_one z_or_x

zero_or_one ::= 0 | 1

    z_or_x ::= x | X | z | Z</FONT></PRE>
<FONT SIZE=+1>This allows both x and z, in lowercase and uppercase verions.
This new syntax may require a note saying that no whitespace is allowed
between the z_or_x and zero_or_one non-terminals.</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>Replace the syntax for edge_descriptor on page 601 and in
Syntax 14-7 on page 193 with:</FONT>
<PRE><FONT SIZE=+1> edge_descriptor ::=
        01
        | 10
        | z_or_x zero_or_one
        | zero_or_one z_or_x

zero_or_one ::= 0 | 1

z_or_x ::= x | X | z | Z</FONT></PRE>
<FONT SIZE=+1>Add a note saying that no whitespace is allowed between the
z_or_x and zero_or_one non-terminals.</FONT>
<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE28 - transition_pair vs. edge_descriptor</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Paul Graham </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Anders Nordstrom </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>The syntax box says</FONT>
<PRE><FONT SIZE=+1> edge_control_specifier ::= edge [ transition_pair { , transition_pair } ]

transition_pair ::= 01 | 0x | 10 | 1x | x0 | x1</FONT></PRE>
<FONT SIZE=+1>Yet Annex A.7 p 601 says</FONT>
<PRE><FONT SIZE=+1> edge_control_specifier ::= edge [ edge_descriptor { , edge_descriptor } ]

edge_descriptor ::= 01 | 0x | 10 | 1x | x0 | x1</FONT></PRE>
<FONT SIZE=+1>While the two syntaxes are equivalent, what is the point
of changing the non-terminal name from "transition_pair" to "edge_descriptor"?</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>Change "transition_pair" to "edge_descriptor" in Syntax 14-7
on page 193.</FONT>
<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE29 - illegal example of specparam_assignment</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Paul Graham </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Anders Nordstrom / Mike McNamara </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>A code example given in this section on page 195 includes
the following:</FONT>
<PRE><FONT SIZE=+1> specparam tPLHc = 4:6:9, ...</FONT></PRE>
<FONT SIZE=+1>Annex A.7 on page 599 includes the following syntax:</FONT>
<PRE><FONT SIZE=+1> specparam_declaration ::=
specparam list_of_specparam_assignments ;

list_of_specparam_assignments ::=
specparam_assignment { , specparam_assignment }

    specparam_assignment ::=
        specparam_identifier = constant_expression
        | pulse_control_specparam

    constant_expression ::=
        constant_primary
        | unary_operator constant_primary
        | constant_expression binary_operator constant_expression
        | constant_expression ? constant_expression : constant_expression
        | string

    constant_primary ::=
        number
        | parameter_identifer
        | constant_concatenation
        | constant_multiple_concatenation</FONT></PRE>
<FONT SIZE=+1>According to the BNF, the expression on the RHS of a specparam_assignment
must be a constant_expression. A constant_expression is either a constant_primary,
a unary, binary, or ternary operation, or a string. Clearly 4:6:9 is not
a unary, binary, or ternary operation, or a string, so it must be a constant_primary.
Yet it cannot be a constant_primary, for it is not a number, a paramater_identifier,
or a concatenation. It seems that to accomodate the example, the syntax
must be changed to</FONT>
<PRE><FONT SIZE=+1> specparam_assignment ::=
        specparam_identifier = constant_mintypmax_expression
        | pulse_control_specparam</FONT></PRE>
<FONT SIZE=+1>By the way, I could not find a syntax rule for constant_expression
within the body of the LRM, but only in Annex A.</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>Change the syntax for specparam_assignment on page 599 from:</FONT>
<PRE><FONT SIZE=+1> specparam_assignment ::=
        specparam_identifier = constant_expression
        | pulse_control_specparam</FONT></PRE>
<FONT SIZE=+1>to:</FONT>
<PRE><FONT SIZE=+1> specparam_assignment ::=
        specparam_identifier = constant_mintypmax_expression
        | pulse_control_specparam</FONT></PRE>

<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE30 - Misuse of "shall" with trireg_declaration</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Paul Graham </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Anders Nordstrom / Mike McNamara </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>The syntax for a trireg declaration is
<PRE>
net_declaration ::=
... | trireg [vectored|scalared] [charge_strengh] [range] [delay3] list_of_net_identifiers
;
</PRE>
So the syntax states that charge strength is optional in a trireg declaration.
But in section 3.4 there appears the rule charge strength Shall be used
when declaring a net of type trireg Since the verb "shall" denotes a mandatory
requirement, this means that charge strength is *not* optional in a trireg
declaration. Which is it, optional or not optional? Perhaps you should
say: charge strength May be used only when declaring a net of type trireg</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>In section 3.4 on page 16 change: <P>
from:
charge strength Shall
be used ... <P>to: charge strength Can be used ... <P> from:drive strength Shall
be used ... <P>to: drive strength Can be used...

<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE31 - net_decl_assignment is missing</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Paul Graham </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Anders Nordstrom / Mike McNamara </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>The syntax for net_declaration is</FONT>
<PRE><FONT SIZE=+1> net_declaration ::= ...
        | net_type [vectored|scalared] [drive_strengh] [range] [delay3]
                list_of_net_decl_assignments ;</FONT></PRE>
<FONT SIZE=+1>In section 6.1 the syntax for net_declaration is duplicated,
except that the last line reads:</FONT>
<PRE><FONT SIZE=+1> | net_type [vectored|scalared] [drive_strengh] [range] [delay3]
                list_of_net_assignments ;</FONT></PRE>
<FONT SIZE=+1>That is, list_of_net_decl_assignments became list_of_net_assignments.
Using Annex A as the referee, I conclude that the definition in 3.2.1 is
correct and that in 6.1 is incorrect. There also is no definition of net_decl_assignment
in the text, only in Annex A. I suspect that the definition of net_decl_assignment
was truncated from the syntax box in 3.2.1.</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>In Syntax 6-1 on page 51 under the net_declaration change
"list_of_net_assignments" to "list_of_net_decl_assignments". <P>Change the
last line in the box to "list_of_net_decl_assignments ::= net_decl_assignment
{ ,net_decl_assignment} <P>Add the line "net_decl_assignment ::= net_identifier=expression

In Syntax 3-1 on page 14, add the line: Add the line "net_decl_assignment
::= net_identifier=expression</FONT>
<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE37 - Section 2.7 Title</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Anders Nordstrom </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Adam Krolnik </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>page 10: The title of section 2.7 is Identifiers, Keywords
and system names but the text in the section do not mention system names.</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>Change the name of section 2.7 on page 10 to <P> "Identifier
Classes"

<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE39 - Task I/O Syntax</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD> Section: </TD><TD> 10.2.1 </TD>
</TR> <TR>
<TD>Date Submitted: </TD><TD> 970103</TD>
</TR> <TR>
<TD>Requestor: </TD><TD> Mitchell Perilstein</TD>
</TR> <TR>

<TD>Status: </TD><TD>Proposal</TD>
</TR> <TR>
<TD>Analyzed by: </TD><TD>Adam Krolnik</TD>
</TR>
</TABLE>
<H3>
Details </H3>

Hi all,<BR>

LRM Sec 10.2.1 needs a little more detail regarding how a task
declaration's input/output declarations interact with its
block_item_declarations in the task scope.

In particular, Sec 10.2.1 says the i/o decls have the same syntax
as module decls in Sec 12; however, Sec 12 also specifies that if
there is an explict declaration of a port, it must match the i/o
decl. This would not appear to be so with tasks both in the LRM
and in the state of the art. (Maybe function declarations need
looking at, also?)
<PRE>
  task Foo;
   output [64:0] x;
   reg [31:0] x;
    //
    // what is x?
    //
  endtask
</PRE>
XL accepts this sort of thing and I believe the model ends up
behaving as if it had a 32-bit output in this example.

<H3> Proposal </H3>

In the last paragraph in section 10.2.1 "Defining a task", the first sentence
reads: <P>

"These [task] declarations have the same syntax as the corresponding declarations in
in a module definition (see Section 12)."
<BR>
Rather than refer to Section 12, I recommend:<BR>

'(see section 12.3.2 "Port Declarations" and section 3.2.2 "Registers")'<BR>

In section 12.3.2 is the sentence describing the behavior that Mitchell pointed
out.<BR>

[ I would also recommend this change to provide more consistency in the titles of
headings.

Propose an alternate title for sections 3.2.1 "Nets", 3.2.2 "Registers",
10.2.1 "Defining a task" and 10.3.1 "Defining a function". <BR>
New titles are:<BR>

"3.2.1 Net Declarations"<BR>
"3.2.2 Register Declarations"<BR>
"10.2.1 Task Declarations"<BR>
"10.3.1 Function Declarations"<BR>

These match section 12.3.2 "Port Declarations".<BR>
<BR>
     Adam Krolnik<BR>
     Verification Engineer<BR>
     Cyrix - NSM.<BR>
     Richardson TX. 75085<BR>

<p><BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE41 - Section A.6 & A.7 Errata</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>J. Bhasker </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Cliff Cummings </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>Hi, <BR>On going through the Verilog Syntax in 1364 draft LRM,
I noticed the following typos. Not sure if they have been corrected. If
not, I think somebody should make a note of it (Is there a language/issue
analysis committee?). <BR>Section A.7: In rule for "path_declaration", it should
read "state_dependent... ^^^ <BR>Section A.6: In "conditional_statement", "case_statement",
"loop_statement", "wait_statement", "event_trigger" and "disable_statement",
<BR>the first "|" should be deleted. <BR>Section A.6: Should read "blocking_assignment",
"non_blocking_assignment"; <BR>Also delete the first "|" in rule for procedural_continuous_assigment. <P>
- J. Bhasker, Lucent Technologies, jb7@mhcnet.att.com</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>The above entries (and more) in the LRM are typos and I propose
the following changes to the BNF: In section A.6, pg. 598:</FONT>
<PRE><FONT SIZE=+1>statement ::=
                  blocking_assignment ;
1995> | non_blocking assignment ;
1998 BE41> | non_blocking_assignment ;
                | procedural_continuous_assignments ;
                | procedural_timing_control_statement
                | conditional_statement
                | case_statement
                | loop_statement
                | wait_statement
                | disable_statement
                | event_trigger
                | seq_block
                | par_block
                | task_enable
                | system_task_enable</FONT></PRE>
<FONT SIZE=+1>*** NOTE: (Syntax 9-1 on page 100 should also be corrected)
In section A.6, pg. 598:</FONT>
<PRE><FONT SIZE=+1>1995>blocking assignment ::= reg_lvalue = [ delay_or_event_control ]
expression
1998 BE41>blocking_assignment ::= reg_lvalue = [ delay_or_event_control ]
expression</FONT></PRE>
<FONT SIZE=+1>*** NOTE: (Syntax 9-2 on page 101 should also be corrected)
In section A.6, pg. 598:</FONT>
<PRE><FONT SIZE=+1>1995>non-blocking assignment ::= reg_lvalue <= [ delay_or_event_control ]
expression
1998 BE41>non_blocking_assignment ::= reg_lvalue <= [
delay_or_event_control ] expression</FONT></PRE>
<FONT SIZE=+1>(Syntax 9-3 on page 104 is correct) In section A.6, pg. 598:</FONT>
<PRE><FONT SIZE=+1>procedural_continuous_assignments ::=
1995> | assign reg_assignment ;
1998 BE41> assign reg_assignment ;
                | deassign reg_assignment ;
                | force reg_assignment ;
                | force net_assignment ;
                | release reg_lvalue ;
                | release net_lvalue ;</FONT></PRE>
<FONT SIZE=+1>(Syntax 9-4 on page 106 is correct) In section A.6, pg. 599:</FONT>
<PRE><FONT SIZE=+1>conditional_statement ::=
1995> | if ( expression ) statement_or_null [ else statement_or_null ]
1998 BE41> if ( expression ) statement_or_null [ else statement_or_null ]</FONT></PRE>
<FONT SIZE=+1>*** NOTE: This was partially corrected by BE10 *** *** NOTE:
(Syntax 9-7 on page 112 should also be corrected (should be loop_statement
(singular) NOT looping_statements) ^^^ ^ In section A.6, pg. 599:</FONT>
<PRE><FONT SIZE=+1>loop_statement ::=
1995> | forever statement
1998 BE10> forever statement
                | repeat ( expression ) statement
                | while ( expression ) statement
                | for ( reg_assignment ; expression ; reg_assignment ) statement</FONT></PRE>
<FONT SIZE=+1>*** NOTE: (Syntax 9-6 on page 108 should also be corrected)
In section A.6, pg. 599:</FONT>
<PRE><FONT SIZE=+1>case_statement ::=
1995> | case ( expression ) case_item [ case_item ] endcase
1998 BE41> case ( expression ) case_item [ case_item ] endcase
                | casez ( expression ) case_item [ case_item ] endcase
                | casex ( expression ) case_item [ case_item ] endcase</FONT></PRE>
<FONT SIZE=+1>(Syntax 9-11 on page 117 is correct) In section A.6, pg.
599:</FONT>
<PRE><FONT SIZE=+1>wait_statement ::=
1995> | wait ( expression ) statement_or_null
1998 BE41> wait ( expression ) statement_or_null</FONT></PRE>
<FONT SIZE=+1>(Syntax 9-10 on page 116 is correct) In section A.6, pg.
599:</FONT>
<PRE><FONT SIZE=+1>event_trigger ::=
1995> | -> event_identifier ;
1998 BE41> -> event_identifier ;</FONT></PRE>
<FONT SIZE=+1>(Syntax 11-1 on page 132 is correct) In section A.6, pg.
599:</FONT>
<PRE><FONT SIZE=+1>disable_statement ::=
1995> | disable task_identifier ;
1998 BE41> disable task_identifier ;
                | disable block_identifier ;</FONT></PRE>
<FONT SIZE=+1>*** NOTE: (Syntax 13-3 on page 154 should also be corrected)
In section A.7, pg. 600:</FONT>
<PRE><FONT SIZE=+1>path_declaration ::=
                  simple_path_declaration ;
                | edge_sensitive_path_declaration ;
1995> | state-dependent_path_declaration ;
1998 BE41> | state_dependent_path_declaration ;</FONT></PRE>

<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE42 - Signed & Unsigned Keywords</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TD>Annex B </TD>
</TR>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Jayaram Bhasker </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>Hi, <BR>Here are some more errors I found in P1364 draft spec:
<BR>1. In Annex B, pg B-1, the keywords "signed" and "unsigned" are present.
But these keywords are NOT part of the grammar and therefore must be deleted.
<BR>- J. Bhasker, Lucent Technologies, jb7@mhcnet.att.com <P>
>>| >>|> 1. In Annex
B, pg B-1, the keywords "signed" and "unsigned" are present. But <BR> >>|> these
keywords are NOT part of the grammar and therefore must be deleted. <BR> >>|
>>| ... >>|time the definition of the behaviour. It was recognized that
at some <BR>>>|later date this behaviour may be included, and it was also recognized
<BR>>>|that not reserving these words at this time would allow more models
<BR>>>|and libraries to be written that used these names as symbols, which
<BR>>>| ... <BR>What would be the value of affixing these words to the language
itself, rather than providing, in the standard, for means to extend the
language to include or exclude them, at the user's choice? I am thinking
of the somewhat object-oriented approach of PACKAGE-ing, as is used in
VHDL and other languages. Without getting too RISCy, out on a limb, I'd
like to see the language burden on the designer minimized, with the potential
of the language, as a design tool, maximized. <P>John (jwill@neosho) <P>
In article
<4q3un7$iiq@nntpa.cb.att.com> Jayaram_Bhasker <jb7@mhcnet.att.com>writes: <BR>
> Hi, <BR>> Here are some more errors I found in P1364 draft spec: <BR>> 1. In
Annex B, pg B-1, the keywords "signed" and "unsigned" are present. But
<BR>> these keywords are NOT part of the grammar and therefore must be deleted.
<BR>My recollection is that we kept these as reserved words, but did not define
their place in the grammar; certain implementations (Cadence-XL) do define
a meaning to for these keywords, however their sponser did not elect to
press for inclusion in the Standard at this time the definition of the
behaviour. It was recognized that at some later date this behaviour may
be included, and it was also recognized that not reserving these words
at this time would allow more models and libraries to be written that used
these names as symbols, which would aggravate later definition of these
symbols as keywords. <BR>-mac</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>Reject the proposal.</FONT>
<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE43 - Annex A.2 Errata</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TD>Annex A </TD>
</TR>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Jayaram Bhasker </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Anders Nordstrom / Mike McNamara </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>Hi, Here are some more errors I found in P1364 draft spec:
2. In Annex A, pg A-3:</FONT>
<PRE><FONT SIZE=+1> A. "task_argument_declaration" must be "task_item_declaration".
B. "input_declaration" is missing in "task_argument(item)_declaration".</FONT></PRE>
<FONT SIZE=+1>Maybe these errors have already been discovered ....? <P> - J.
Bhasker, Lucent Technologies, jb7@mhcnet.att.com <P>
2. In Annex A, pg A-3: <BR>
A. "task_argument_declaration" must be "task_item_declaration". <BR>
B.
"input_declaration" is missing in "task_argument(item)_declaration". <BR> Without
examining the specifics of your report, I will note that the BNF needs
extensive rework; thanks for more effort in this area.</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>In Annex A page 596 <BR>change "task_argument_declaration" to
"task_item_declaration". <BR>On page 595 add "input_declaration" under "task_item_declaration".</FONT>

<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE45 - Behavioral function definition</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD><TD> 11</TD>
<TR></TR>
<TD>Date Submitted: </TD><TD> 961217</TD>
<TR></TR>
<TD>Requestor: </TD><TD> Steve Meyer</TD>
<TR></TR>
<TD>Status:</TD><TD> Proposal</TD>
<TR></TR>
<TD>Analyzed by: </TD><TD>Adam Krolnik</TD>
</TR>
</TABLE>

<H2> Details </H2>

I just ran into the following function that I think may be illegal
according to the IEEE P1364 standard but probably needs to be explicitly
allowed because break and continue require named blocks. The function below
does not work in Cver because it treats named blocks as task enables
since they can be disabled, and for nested named blocks the downward
chain disabling rule (section 11-1 Oct. 1995 draft) must be applied.

The problem is probably one of documentation clarity. I read section
11 page 1 (but not the remaining examples) as allowing disable of any
named block, therefore named blocks are illegal inside function definitions,
but my interpretation must be wrong since the function is part of the DA
solutions benchmarks and works on other simulators.

Also, I am not sure what the meaning of parallel blocks (fork-join)
is inside functions.

The LRM grammar, in my view correctly, does not define timing behavior
semantics inside functions (see A.2 and A.6). It allows any statement.

I assume it is illegal from outside a function to disable a named block
inside a function because that implies timing control that is explicitly
dis-allowed inside functions. Such disable is, I think, unlikely except for
debuggers that allow statement by statement tracing inside functions.
However, I read section 5.4.2 sentence 2 as allowing functions to be
interrupted in the middle (say) to execute other events because there is
no non timing control statement group atomicity condition.

I hope behavior within functions and for named blocks will be defined more
exactly in the new version of the LRM.

/Steve
<BR>
<PRE>
// function from DA Solutions public domain bench marks das_cpu example
function [0:31] sign_extend;

input [0:15] D2;
reg [0:31] result;

begin
   begin
        begin : sextend
        integer i;
        begin
        for (i = 0; i < 16; i = i+1)
        begin
        result[i] = D2[0];
        result[i+16] = D2[i];
        end
        end
   end
   sign_extend = result;
end
endfunction
endmodule

// here is a test top level module
module top;
reg [0:15] D, X;

initial
begin
  D = 6;
  X = sign_extend(D);
  $display("sign extend of %b is %b", D, X);
end

Steve Meyer Phone: (415) 296-7017
Pragmatic C Software Corp. Fax: (415) 781-1116
220 Montgomery St., Suite 925 email: sjmeyer@crl.com
San Francisco, CA 94104
</PRE>

Hi, Steve.
<BR>
I'll add my two cents worth.
<BR>
Let me preface my remarks by saying that I have only the April 1995 draft
since I apparently have not been judged eligible to get 1364 mailings on a
regular basis.

I don't agree with your interpretations.

I don't think that named blocks should be considered task enables.
My P1364 draft seems to distinguish between named blocks and tasks.
1364 does not imply, in my opinion, that because named blocks can be disabled,
then they are like task enables. You don't explain why you think that
one necessarily follows from the other.

In certain respects, they are similar, but different in others.

I don't see a reason that named blocks should be illegal in functions.

I have in the past argued that functions MUST be executed atomically
in order to guarantee coherent execution.

Regards, <BR>
<PRE>
******************************************************************************
Shalom Bresticker email: shalom@msil.sps.mot.com
Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268
P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522444
******************************************************************************
</PRE>

The following code is acceptable by both XL and VCS; the disable statement
terminates execution of the block and the function returns the current value
assigned to it.
<PRE>
module test;

function f;
  input a,b,c;
  begin :block
  f = a|b & c;
  disable block;
  f = 'b0;
  end
endfunction

initial begin
$display("Result is %0b.", f('b1, 'b0, 'b1));
end
endmodule
</PRE>

<H3> Proposal </H3>

Change the last paragraph of section 11 "Disabling of named blocks and tasks"

from: <BR>

"The disable statement can be used within blocks and tasks to disable the particluar
block or task containing the disable statement. The disable statement cannot be used
to disable functions."

to:
<BR>
"The disable statement can be used within blocks and tasks to disable the particluar
block or task containing the disable statement. The disable statement can be used to
disable named blocks within function, but cannot be used to disable functions."

Adam Krolnik

<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE46 - Continuos assignment evaluation</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Thomas Fitzpatrick </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Anders Nordstrom / Mike McNamara </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>Section 6.1 states that a continuous assignment shall occur
whenever the value of the right-hand side changes. <BR>Section 6.1.2 second
paragraph states that the assignment occurs whenever an operand on the
right- hand side changes. <BR>Suggest the second sentance of the second paragraph
be changed to: <P>"This means that whenever an operand in the right-hand side
expression changes value, the whole right-hand side shall be evaluated
and if the new value is different from the previous value then the new
value shall be assigned to the left-hand side."</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>Change the second sentence of the second paragraph in section
6.1.2 on page 51 to: <P>"This means that whenever an operand in the right-hand
side expression changes value, the whole right-hand side shall be evaluated
and if the new value is different from the previous value then the new
value shall be assigned to the left-hand side."</FONT>
<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE49 - Missing system_task_or_function BNF</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TD>2.7.3, Syntax 2-2 box, page 11 </TD>
</TR>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Stu Sutherland </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Mike McNamara / Anders Nordstrom </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>The "system_task_or_function" BNF listed in this box does
not appear in Annex A. <P>From mac@appr.silicon-sorcery.com Wed Feb 25 19:15:49
1998 <BR>In annex B, BNF for system functions calls appear with the other function
calls, and BNF for system tasks appear with the other task enables. And
in truth, from a BNF perspective, system tasks and system functions are
very different. (A function can appear as part of any expression, while
a task enable is it self a complete statement). <BR>system_task_enable ::=
is part of A.6, behavioral statements. <BR>system_function is part of function
call, in A.8. So, that being said, there is no use for the BNF given in
Syntax 2-2 in the real grammar, as there is no place where it would makes
sense to recognize the top level item od Syntax 2.2, "system_task_or_function"

It had been a non requirement that the BNF's given in the text match exactly
with BNF's in the annex B when we did 1364-1995. It was the case that they
should certainly describe the same language; and it was ok to group together
in the sections BNF's that helped explain the concept being discussed in
that section. <BR>With that basis, I recommened rejecting the proposal. However,
it seems that iteratively we are "fixing" each Syntax BNF to match the
appropriate sections from the Annex B BNF, and since they are close, we
might as well finish the job. <BR>In order to do this we'd need to break Syntax
2-2 so it has two top level targets. In order to make this work, and slavishly
match the BNF in A.6 and A.8, we'd really have to change A.8, as there
isn't a target that matches a system fucntion; rather there is:</FONT>
<PRE><FONT SIZE=+1>expression ::=
                  primary
                | ...
primary ::=
                  number
                | ...
                | function_call
                | ...

function_call ::=
function_identifier ( expression {, expression } )
| name_of_system_function ( expression {, expression } )

name_of_system_function ::=
                $identifier</FONT></PRE>
<FONT SIZE=+1>We'd need to change A.8 to have:</FONT>
<PRE><FONT SIZE=+1>expression ::=
                  primary
                | ...

primary ::=
                  number
                | ...
                | function_call
                | system_function_call
                | ...

function_call ::=
function_identifier ( expression {, expression } )

ystem_function_call ::=
name_of_system_function ( expression {, expression } )

name_of_system_function ::=
$identifier</FONT></PRE>
<FONT SIZE=+1>And then we could make 2-2 say:</FONT>
<PRE><FONT SIZE=+1>system_function_call ::=
name_of_system_function ( expression {, expression } )

name_of_system_function ::=
$identifier

ystem_task_enable ::=
system_task_name [ ( expression {,expression} )]

ystem_task_name ::=
                $identifier</FONT></PRE>
<FONT SIZE=+1>So, as my objection was to doing the work, and you've conjolled
me into doing the work, now I don't much care which way we go, and lean
towards accepting the errata, making the change. So moved!</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>Change A.8 on page 602 and 603 to:</FONT>
<PRE><FONT SIZE=+1>expression ::=
          primary
        | unary_operator primary
        | expression binary_operator expression
        | expression ? expression : expression
        | string

primary ::=
          number
        | identifier
        | identifier [ expression ] { [ expression ] }
        | identifier [ msb_constant_expression : lsb_constant_expression ]
        | concatenation
        | multiple_concatenation
        | function_call
        | system_function_call
        | ( mintypmax_expression )

function_call ::=
function_identifier ( expression { , expression } )

name_of_system_function ::= $identifier</FONT></PRE>
<FONT SIZE=+1>Change Syntax 2-2 on page 11 to:</FONT>
<PRE><FONT SIZE=+1>system_function_call ::=
name_of_system_function ( expression {, expression } )

name_of_system_function ::=
$identifier

ystem_task_enable ::=
system_task_name [ ( expression {,expression} )]

ystem_task_name ::=
$identifier</FONT></PRE>

<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE50 - Incorrect references</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Stu Sutherland </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Anders Nordstrom </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>Note at top of page references sections 17, 23 and 25. There
is no section 25. Section 23 does not reference $identifiers (though perhaps
it should).</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>Change the first sentence on page 12 to: <P>"Additional $identifier
system tasks and functions defined using the PLI, as described in section
17.</FONT>
<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE53 - Unsigned caution error</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TD>3.2.2, Caution box, page 15 </TD>
</TR>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Stu Sutherland </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>The caution states that a register operand shall be treated
as unsigned. This contradicts section 4.1.6 which states that the integer
data type uses signed arithmetic. Also, the caution box references section
4.1.3, which appears to have nothing to do with the topic. Suggest the
following wording for the caution box: "Registers can be assigned negative
values, but only integer, real and realtime shall retain the significance
of the sign. The reg and time registers shall treat the value assigned
to them as an unsigned value. Refer to section 4.1.6 for a description
of how signed and unsigned registers are treated by certain Verilog operators.</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>Change the text in the Caution box on page 15 to: <P>"Registers
can be assigned negative values, but only integer, real and realtime shall
retain the significance of the sign. The reg and time registers shall treat
the value assigned to them as an unsigned value. Refer to section 4.1.6
for a description of how signed and unsigned registers are treated by certain
Verilog operators."</FONT>
<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE54 - Unsigned registers</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Stu Sutherland </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Anders Nordstrom </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>Third paragraph, last sentance states that registers shall
be treated as unsigned. This contradicts section 4.1.6. Suggest the sentance
be struck.</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>This paragraph is re-written to address this issue in the
already passed Signed Arithmetic Proposal (B19). No further LRM changes
proposed.</FONT>

<p><BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE55 - Implicit net type definition </FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD><TD> 3.5, page 16 </TD>
</TR><TR>
<TD>Date Submitted: </TD><TD> 12/8/96 </TD>
</TR><TR>
<TD>Requestor: </TD><TD> Stu Sutherland</TD>
</TR><TR>
<TD>Status: </TD><TD> Proposal</TD>
</TR><TR>
<TD>Analyzed by: </TD><TD> Adam Krolnik</TD>
</TR>
</TABLE>

<H3>
Details </H3>
The first paragraph states that only signals connected to a
primitive, UDP or module instance assume an implicit net declaration. The
third paragraph says the assumed data type is scalar. Verilog-XL and other
simulators also assume an implicit net data type for the left-hand side of
continuous assignments, and will assume a vector size if the net is connected
to a vectored port. The submitter believes there may be other circumstances
where an implicit vector net is assumed. The exact rules for assuming
implicit net types needs to be defined.
<BR>
-----------------------------------------------------------------------------
<BR>

Here is an example that neither XL or VCS will compile because continuous
assignments do not implicitly declare a net. If lines 3 and 10 below (the references
to 'b') are removed, then both simulators will report a width mismatch on
the connection of 'c' to port 'C' - indicating that implicit declaration
of nets results in a scalar net.
<PRE>
module test;

assign b = 4'hf;

ins in (.a(1'b1), .b(1'b0), .C(c));

reg a;
initial begin
$display("Result is %0b.", b);
end
endmodule

module ins(a,b,C);
  input a,b;
  output [1:0] C;
  wire [1:0] C = {a,b};
endmodule
</PRE>
<H3> Recommendation </H3>

Current text correctly defines when implicit net declaration occurrs and
the default definition of a net.

<p><p><p><BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE61 - Assignment to implicit/explicit nets</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Stu Sutherland </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Adam Krolnik </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>The first paragraph does not correctly define how existing
Verilog products handle implicit net declarations. Suggest the sentance
be modified to read: "The continuous assignment statement shall place a
continuous assignment on a net data type. The net may be explicitly declared,
or may inherit an implicit declaration in accordance with the implicit
declarations rules defined in section 3.5."</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>Change the first paragraph in section 6.1.2 on page 51 to:

"The continuous assignment statement shall place a continuous assignment
on a net data type. The net may be explicitly declared, or may inherit
an implicit declaration in accordance with the implicit declarations rules
defined in section 3.5."</FONT>

<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE63 - Repeat count zero</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Tom Fitzpatrick </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Anders Nordstrom </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>Section 9.7.6, page 118, addition to first paragraph. I would
like to say "If the repeat count is <= 0 at the time of evaluation,
the assignment occurs immediately."</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>Add the sentence below to the first paragraph in section
9.7.6, page 118 just before the sentence "This construct is convinient
when events have to be synchronizeed with counts of clock signals": <P>"If
the repeat count is less than or equal to 0 at the time of evaluation,
the assignment occurs as if there is no repeat construct."</FONT>
<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE64 - Realtional ops</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>J. Bhasker </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Mike McNamara / Anders Nordstrom </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>The Verilog LRM does not explain how relational ops are to
be handled: are they numeric comparisons or bit-by-bit comparisons? Here
is an example:</FONT>

<FONT SIZE=+1>LHS is -1 which is 32 bits ("11111...11")</FONT>

<FONT SIZE=+1>RHS is then zero-filled to 32 bits (P1364, pg33, 2nd line
from top).</FONT>

<FONT SIZE=+1>Now if I do a numeric comparison, the answer is 1 (true;
-1 is less than 6)</FONT>

<FONT SIZE=+1>If I do a bit-by-bit comparison (treat as unsigned values,
left to right), the answer is 0 (false: 2**32-1 is greater than 6).</FONT>

<FONT SIZE=+1>My interpretation of P1364 was that for relational operators,
we have to do numeric comparison. (But apparently a major simulation vendor
does not agree).</FONT>

<FONT SIZE=+1>Could anyone please comment on which one is correct?</FONT>

<FONT SIZE=+1>Thanks,</FONT>

<FONT SIZE=+1>- J. Bhasker, Lucent Technologies, jbhasker@lucent.com</FONT>

<FONT SIZE=+1>jbhasker@bell-labs.com writes: <BR>> Hi, <BR>> > The Verilog LRM
does not explain how relational ops are to be handled: <BR>> are they numeric
comparisons or bit-by-bit comparisons? <BR>> > Here is an example: <BR>> > What
is : -1 < -3'd2 <BR>> > LHS is -1 which is 32 bits ("11111...11") > RHS
is "110" not correct. <BR>> > RHS is then zero-filled to 32 bits (P1364, pg33,
2nd line from top).<BR> -1 < -3'd2 is treated as: (LT (UMINUS (1)) (UMINUS
(EXP32 2))) where EXP32 expands it's argument to 32 bits, zero filling.
<BR>The key bit here is that the second UMINUS is an operator, not part of
a token, and that the sizing is done before any operators are applied.
(ref 4.1.3 and 4.4.1) [I now note that the second table entry on page 44
is wrong, and directly contradicts the correct rule you cite from 4.1.7,
and another correct rule in 4.1.8 *sigh*] Hence the final comparison is
done between the bit patterns, 0xffffffff and 0xfffffffe Now here is a
bit that isn't called out very clearly in the specification. 4.1.6 almost
lays it out, but is missing a final clarification. Since there is no rhs
destination for the calculation of (-1 < -3'd2), we can't use the rules
in 4.1.6. <BR>However, it is the case that given any signed operand (which
-1 is) the relational operators treat all their arguments as signed. These
patterns are therefor interpreted as signed numbers, and hence since -1
is not less than -2, the answer is false. <BR>> Now if I do a numeric comparison,
the answer is 1 (true; -1 is less > than 6) <BR>> > If I do a bit-by-bit comparison
(treat as unsigned values, left to <BR>> right), the answer is 0 (false: 2**32-1
is greater than 6). <BR>> > My interpretation of P1364 was that for relational
operators, we have to <BR>> do numeric comparison. (But apparently a major
simulation vendor does <BR>> not agree). <BR>> > Could anyone please comment on
which one is correct? <BR>> > Thanks, <BR>> > > - J. Bhasker, Lucent Technologies,
<BR>jbhasker@lucent.com <P>So, two problems: 1) the second table entry on page
44 should read:</FONT>
<PRE><FONT SIZE=+1>+-------------------------------+-------+------------------------------+
| i op j where op is | | operands are sized to |
| === !== == != && || > >= < <= | 1 bit | max(L(i),L(j)) |
+-------------------------------+-------+------------------------------+</FONT></PRE>
<FONT SIZE=+1>2) section 4.1.7 needs the following sentences added: When
either operand of a relational expression is a signed intergral operand
(an integer, or a unsized, unbased integer) then the expression shall interpreted
as a comparison between signed values. When either operand of a relational
expression is a real operand then the other operand shall be converted
to an equivalent real value, and the expression shall interpreted as a
comparison between two real values. <P>
- mac <P>
> 2) section 4.1.7 needs the
following sentences added: <BR>> >When either operand of a relational expression
is a signed intergral <BR>>operand (an integer, or a unsized, unbased integer)
then the <BR>>expression shall interpreted as a comparison between signed values.
<BR>> This hypothesis does not seem to support the following result from vcs:
(-1 < 1) returns 1 (-1 < 1'b1) returns 0 In fact, it seems a signed
comparison is performed iff BOTH operands are signed integral objects.
<BR>Regards, -Ambar -- <BR>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ambar Sarkar <BR>Email: ambar@viewlogic.com <BR>Viewlogic Systems Inc.,Marlboro
<BR>Phone: (508)879-2150 (H) 293, <BR>Boston Post Rd West, MA 01752 <BR>(800)456-VIEWx5493

Ambar Sarkar writes: <BR>> > 2) section 4.1.7 needs the following sentences
added: <BR>> > > >When either operand of a relational expression is a signed
intergral <BR>> >operand (an integer, or a unsized, unbased integer) then the
<BR>> >expression shall interpreted as a comparison between signed values.
<BR>> > > This hypothesis does not seem to support the following result from
<BR>> vcs: <BR>> > (-1 < 1) returns 1 <BR>> (-1 < 1'b1) returns 0 <BR>> > In fact,
it seems a signed comparison is performed iff BOTH operands <BR>> are signed
integral objects. <BR>> > Regards, <BR>> -Ambar > -- > <BR>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<BR>> Ambar Sarkar Email: ambar@viewlogic.com <BR>> Viewlogic Systems Inc., Marlboro
Phone: (508)879-2150 (H) <BR>> 293, Boston Post Rd West, MA 01752 (800)456-VIEWx5493

I agree, and accept your admendment to my proposal. <BR>Please have the
proposal read: <P>
2) section 4.1.7 needs the following sentences added: <BR>When
both operands of a relational expression are signed intergral operands
(an integer, or a unsized, unbased integer) then the expression shall interpreted
as a comparison between signed values. When either operand of a relational
expression is a real operand then the other operand shall be converted
to an equivalent real value, and the expression shall interpreted as a
comparison between two real values. Otherwise the expression shall interpreted
as a comparison between unsigned values. <P>-mac <P>
Mac wrote: <BR>> > The key bit
here is that the second UMINUS is an operator, not part of <BR>> a token, and
that the sizing is done before any operators are <BR>> applied. <BR>Mac, Thanks
very much for your clarification with further clarification by Ambar (thanks
to Amabar too). The confusion was caused by the - (minus) sign in front
of a sized number. The syntax on pgs 602-603 clearly says that the - in
front of a sized number is a unary minus operator, but the 8th para on
page 7 of LRM says that the - is a sign for the constant number, WHICH
IS INCORRECT. ("A plus or a minus operator preceding the size constant
is a sign for the constant number"). The LRM should be corrected. <BR>- J.
Bhasker, jbhasker@lucent.com</FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>Change the second table entry in Table 4-21 on page 22 to:</FONT>
<PRE><FONT SIZE=+1>+-------------------------------+-------+------------------------------+
| i op j where op is | | operands are sized to |
| === !== == != && || > >= < <= | 1 bit | max(L(i),L(j)) |
+-------------------------------+-------+------------------------------+</FONT></PRE>
<FONT SIZE=+1>Add the following paragraphs at the end of section 4.1.7
on page 33: <P>
When both operands of a relational expression are signed intergral
operands (an integer, or a unsized, unbased integer) then the expression
shall interpreted as a comparison between signed values. When either operand
of a relational expression is a real operand then the other operand shall
be converted to an equivalent real value, and the expression shall interpreted
as a comparison between two real values. Otherwise the expression shall
interpreted as a comparison between unsigned values. <P>
Change the first sentence
in paragraph 8 on page 7 to: <BR> A plus or minus operator preceding the size
constant is a unary plus or minus operator.</FONT>

<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE65 - Real conversion in expressions</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Steve Meyer </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Mike McNamara / Anders Nordstrom </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>I do not think the LRM's explanation of conversion of reals
in expressions is right. <BR>Section 3.9.2, paragraph 2 explicitly states conversion
to real takes place on assignment implying that non reals in expressions
(where operator is defined for real operands) are not converted to real
but rather a syntax error has occurred, but then one of the examples at
bottom of section 3.10 shows a parameter expression with a real and non
real constant. I assume section 3.9.2 should say that implicit conversion
to real occurs for mixed type expressions. Or is the text correct and the
example wrong? <BR>Also I think the LRM should document if there is a difference
between constant expressions and variable expressions i.e. if "3.0 + 4"
is legal but "r + i" where r is declared real and i declared integer is
not legal syntax following text in section 3.9.2. <BR>/Steve</FONT>

<FONT SIZE=+1>Steve Meyer Phone: (415) 296-7017</FONT>

<BR><FONT SIZE=+1> Pragmatic C Software Corp. Fax: (415) 296-0946</FONT>

<BR><FONT SIZE=+1> 220 Montgomery St., Suite 925 email: sjmeyer@crl.com</FONT>

<BR><FONT SIZE=+1> San Francisco, CA 94104</FONT>

<BR><FONT SIZE=+1> </FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>Change the sentence: "Implicit conversions shall take place
when a net or register is assigned to a real." <BR>to: "Implicit conversions
shall take place when an expression is assigned to a real." <BR>
in section
3.9.2 on page 25.</FONT>
<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE66 - Signed and unsigned</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>J. Bhasker </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Tom Fitzpatrick </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>Hi, <BR>The Verilog LRM does not specify how the signedness of
intermediate results of expressions are to be handled. What is "signed
arith_op signed"?, "signed arith_op unsigned"? Jim Vellenga and Ambar Sarkar
from ViewLogic had posted the following comment (when discussing signedness
of relational ops): <BR>++++++++++++++ <BR>>What appears to happen is that if the
expression contains <BR>>a vector value ("reg", "wire", or based integer),
then the <BR>>integers suddenly get treated as 32-bit vectors, and a <BR>>"negation"
of the integer value is treated as the unsigned <BR>>32-bit value with the
equivalent binary reputation. (Negation <BR>>is done via two's-complement arithmetic).
<BR>++++++++++++++ <BR>Here is an example:</FONT>
<PRE><FONT SIZE=+1>integer INTA, INTB, INTC;
reg [66:0] REGA, REGB, REGC;

initial begin
  INTA = (2*32'h40000000)/2; // Stmt A
  REGA = (2*32'h40000000)/2; //Stmt B
  INTB = (4 - 6 ) * 3'd2; // Stmt C
  REGB = (4 - 6 ) * 3'd2; // Stmt D
  INTC = (4 - 6 ) * 3'd2 / 2; // Stmt E
  REGC = (4 - 6 ) * 3'd2 / 2; // Stmt F
  #10;
end</FONT></PRE>
<FONT SIZE=+1>Consider Stmt A. Is the result of 2*32'h40000000 signed or
unsigned? Depending on which one, the final answer is different. Is the
result of (4-6) in Stmt C/D signed or sunsigned? What about (4 - 6 ) *
3'd2 in Stmt E/F? Here is what my simulator produces:</FONT>
<PRE><FONT SIZE=+1>INTA=1073741824
INTB=-4
INTC=2147483646
REGA=(35 zeros)1(30zeros)
REGB=(64 ones)00
REGC=0(64 ones)0</FONT></PRE>
<FONT SIZE=+1>Based on the results and Jim/Ambar's findings and the recent
resolution on relational operators, I conclude the following: <BR>"signed arith_op
signed" produces a signed number "signed arith_op unsigned" causes the
"signed" number to be interpreted as a unsigned number and the result is
unsigned. In the above example, 2*32'h40000000 in Stmt A/B results in an
unsigned value (2 is first converted to a 32-bit unsigned quantity before
mult). 4 - 6 in Stmt C/D results in a signed value. (4 - 6 ) * 3'd2 in
Stmt E/F is an unsigned quantity (the -2 result of (4-6) is converted to
a large positive unsigned number before multiplication). Is this conclusion
reasonable or I am missing something? <BR>- J. Bhasker, Lucent TEchnologies,
jbhasker@lucent.com <P>
My proposal clearly lists the rules for determining
the signedness of an operation. Jim and Ambar reach the correct conclusions
from their experiments and, in fact, this is why we declared the rules
as we did - to be consistent with Verilog-XL. These rules are spelled out
in sections 4.5.1 and 4.5.2 of the proposal. If you have any more questions,
please let me know. <BR> Thanks, -t <BR>-- --------------- <BR>Tom Fitzpatrick</FONT>

<BR><FONT SIZE=+1>Cadence Design Systems Cobra Technical Marketing Manager</FONT>

<BR><FONT SIZE=+1> Product Engineering Logic Design & Verification
Business Unit</FONT>

<BR><FONT SIZE=+1> </FONT>
<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>This issue is resolved by adopting the B19 "Signed Arithmetic
Proposal". No further LRM changes.</FONT>
<BR> <HR SIZE=5 NOSHADE> <H2>
<FONT SIZE=+1>BE67 - The non-blocking assignment</FONT></H2>

<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Section: </TD>

<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Daryl Stewat </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Anders Nordstrom </TD>
</TR>
</TABLE>

<H3>
<FONT SIZE=+1>Details</FONT></H3>
<FONT SIZE=+1>I can't find a report of this on the Errata list, but I'm
not sure if it's already been noted!<BR> cheers Daryl
<BR>Section 9.2.2 "The non-blocking
assignment" describes the behaviour of the non-blocking assignments in
"module evaluates2" in two steps, incorrectly:</FONT>
<PRE><FONT SIZE=+1>+-----
| Step 1: The simulator evaluates the right hand sides of the non-blocking
| assignments and schedules the assignments of the new values at posedge c.
|
| Step 2: At posedge c, the simulator updates the left hand side of each
| non-blocking assignment statement.
+-----
| always @(posedge c) begin
| a <= b;
| b <= a;
| end
+-----</FONT></PRE>
<FONT SIZE=+1>should read:</FONT>
<PRE><FONT SIZE=+1>+-----
| Step 1: at posedge c, the simulator evaluates the right hand sides of
| the non-blocking assignments and schedules the assignments of the new
| values at the end of the present simulation cycle.
|
| Step 2: At the end of the present simulation cycle, the simulator
| updates the left hand side of each non-blocking assignment statement.
+-----</FONT></PRE>

<H3>
<FONT SIZE=+1>Proposal</FONT></H3>
<FONT SIZE=+1>Change the text describing "Step 1" and "Step 2" in Example
1 on page 101 to:</FONT>

<FONT SIZE=+1>Step 1: at posedge c, the simulator evaluates the right
hand sides of the non-blocking assignments and schedules the assignments
of the new values at the end of the present simulation cycle.</FONT>

<FONT SIZE=+1>Step 2: At the end of the present simulation cycle, the
simulator updates the left hand side of each non-blocking assignment statement.</FONT>

<p><BR> <HR SIZE=5 NOSHADE>
<H2> BE70 - Expanded Contents Listing </H2>
<TABLE BORDER COLS=2 WIDTH="50%" >
<TR>
<TD>Date Submitted: </TD>

<TR>
<TD>Requestor: </TD>

<TD>Adam Krolnik </TD>
</TR>

<TR>
<TD>Status: </TD>

<TD>Proposal </TD>
</TR>

<TR>
<TD>Analyzed by: </TD>

<TD>Anders Nordstrom </TD>
</TR>
</TABLE>

<H3> Details </H3>

How would everyone feel if I asked for a larger "Contents" listing? <BR>
One that included all
header sections?]
<BR> <BR>

     Adam Krolnik<BR>
     Verification Engineer<BR>
     Cyrix - NSM.<BR>
     Richardson TX. 75085
<BR>

<H3> Proposal </H3>

Include all header sections in the table of contents on page ix

Next message: Anders Nordstrom: "REMINDER: BTF Conference Call April 6"
Previous message: Michael McNamara: "Enhancement to BTF - B3 Writing binary data."
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

This archive was generated by hypermail 2.1.4 : Mon Jul 08 2002 - 12:52:47 PDT and
sponsored by Boyd Technology, Inc.