ISSUE 192

Number 192
Category errata
Synopsis 3.3.1: are real values for ranges allowed?
State lrmdraft
Class errata-discuss
Arrival-DateNov 17 2002
Originator Shalom Bresticker
Release 2001b: 3.3.1, 3.10, 4.2.1, 4.2.2
Environment
Description

3.3.1 says that range msb and lsb's must be constant
expressions. This implies that real values are allowed.

Same for BNF. There is no definition of an
"integer expression".

However, both Verilog-XL and MTI simulators reject a
statement like
reg [31.0 : 0] qq ;

This problem probably occurs in other contexts as well.
Fix
Slight modifications:

1. In 3.3.1:

REPLACE the 2nd paragraph:

"Both msb constant expression and lsb constant expression shall be
constant expressions. The msb and lsb constant expressions can be
any value -- positive, negative or zero. The lsb constant expresson
can be a greater, equal, or lesser value than the msb constant
expression."

WITH:

"Both the msb constant expression and the lsb constant expression
shall be constant integer expressions. The msb and lsb constant
expressions can be any integer value -- positive, negative or
zero. The lsb value may be greater than, equal to, or
less than the msb value."


2. In 3.10, para. 2, change sentence 5 FROM:

"The expression(s) that specify the indices of the array shall be constant
expressions."

TO:

"The expressions that specify the indices of the array shall
be constant integer expressions."


3. In 4.2.1, in para. 3, CHANGE

"Both expressions shall be constant expressions."

TO

"Both the msb_expr and lsb_expr shall be constant integer
expressions."


In para. 5, CHANGE:

"The width_expr shall be a constant expression. It also
shall not be affected by run-time parameter assignments."

TO:

"The msb_base_expr and lsb_base_expr shall be integer
expressions, and the width_expr shall be a positive constant
integer expression."
(Note: This supercedes the fix of issue #228, part 1).


4. In 4.2.2:

In para. 5, CHANGE

"The addr_expr can be any expression;"

TO:

"The addr_expr can be any integer expression".


In para. 9, CHANGE:

"The syntax for access to the array ... an expression for each addressed
dimension:"

TO:

"The syntax for access to the array ... an integer expression for each addressed
dimension:"


In para. 10, CHANGE:

"As before, the addr_expr can be any expression."

TO:

"As before, the addr_expr can be any integer expression."


5. New issue (#395) filed with problems found in 3.9.1.
Audit-Trail

From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, Shalom.Bresticker@motorola.com
Cc:
Subject: Re: errata/192: 3.3.1: are real values for ranges allowed?
Date: Mon, 18 Nov 2002 20:02:55 -0500 (EST)

>Category: errata
>Confidential: no
>Originator: Steven Sharp <sharp@cadence.com>
>Release: 2001b
>Class: TBD
>Description:
NC-Verilog also does not allow real values in ranges in declarations.

Note that the standard does prohibit them in indices of bit and part-selects
in section 3.9.1. They are prohibited in array declarations in section 3.10,
where it says that "The value of the constant expression can be a positive
integer, a negative integer, or zero." Note that it is not clear that only
a zero integer is allowed :-).

It is clear that reals should be prohibited in ranges in declarations of
vectors also. Section 3.3.1 has a similar statement to arrays, which
should be modified to require integers.

Steven Sharp
sharp@cadence.com


From: "Brad Pierce" <Brad.Pierce@synopsys.com>
To: <etf-bugs@boyd.com>
Cc:
Subject: Re: errata/192: 3.3.1: are real values for ranges allowed?
Date: Mon, 18 Nov 2002 18:04:58 -0800

>Category: errata
>Confidential: no
>Originator: "Brad Pierce" <Brad.Pierce@synopsys.com>
>Release: 2001b
>Class: TBD
>Description:
Yet there is no syntax category integer_number that includes
all numbers except real_numbers.

How about --

number ::= integer_number
| real_number

integer_number ::= decimal_number
| octal_number
| binary_number
| hex_number

msb_constant_expression = integer_number

lsb_constant_expression = integer_number

?

-- Brad



From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, Brad.Pierce@synopsys.com
Cc:
Subject: Re: errata/192: 3.3.1: are real values for ranges allowed?
Date: Mon, 18 Nov 2002 21:31:37 -0500 (EST)

>Category: errata
>Confidential: no
>Originator: Steven Sharp <sharp@cadence.com>
>Release: 2001b
>Class: TBD
>Description:

> msb_constant_expression = integer_number
>
> lsb_constant_expression = integer_number

These are not restricted to being simple numbers. They can be arbitrary
expressions involving parameters and numbers. And as soon as your grammar
allows parameters, then it allows real-valued parameters. There isn't even
a theoretical way to prevent getting a real value with just the grammar.
This requires a semantic check.

Also note that the main reason this comes up is that the power operator is
specified as producing a real result from integer operands, if either is
signed. So even somehow restricting to integer operands wouldn't work unless
power operators were disallowed in constant expressions.

But we should fix the power operator so that it doesn't have this property
anyway.

Steven Sharp
sharp@cadence.com


From: "Brad Pierce" <Brad.Pierce@synopsys.com>
To: <etf-bugs@boyd.com>
Cc:
Subject: Re: errata/192: 3.3.1: are real values for ranges allowed?
Date: Mon, 18 Nov 2002 19:20:38 -0800

>Category: errata
>Confidential: no
>Originator: "Brad Pierce" <Brad.Pierce@synopsys.com>
>Release: 2001b
>Class: TBD
>Description:
Yes, you're completely right about that.

Regarding syntactic vs. semantic checks, although
I see some places where the syntactic approach
still seems more natural, such as --

module_item vs. non_port_module_item
function_item_declaration vs. task_item_declaration

it does seem there ought to be a better way
to define what a constant expression is.

-- Brad


From: Michael McNamara <mac@verisity.com>
To: Steven Sharp <sharp@cadence.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/192: 3.3.1: are real values for ranges allowed?
Date: Tue, 19 Nov 2002 08:57:21 -0800

>Category: errata
>Confidential: no
>Originator: Michael McNamara <mac@verisity.com>
>Release: 2001b
>Class: TBD
>Description:


Steven Sharp writes:
> Precedence: bulk
>
> The following reply was made to PR errata/192; it has been noted by GNATS.
>
> From: Steven Sharp <sharp@cadence.com>
> To: etf-bugs@boyd.com, Shalom.Bresticker@motorola.com
> Cc:
> Subject: Re: errata/192: 3.3.1: are real values for ranges allowed?
> Date: Mon, 18 Nov 2002 20:02:55 -0500 (EST)
>
> >Category: errata
> >Confidential: no
> >Originator: Steven Sharp <sharp@cadence.com>
> >Release: 2001b
> >Class: TBD
> >Description:
> NC-Verilog also does not allow real values in ranges in declarations.
>
> Note that the standard does prohibit them in indices of bit and part-selects
> in section 3.9.1. They are prohibited in array declarations in section 3.10,
> where it says that "The value of the constant expression can be a positive
> integer, a negative integer, or zero." Note that it is not clear that only
> a zero integer is allowed :-).
>
> It is clear that reals should be prohibited in ranges in declarations of
> vectors also. Section 3.3.1 has a similar statement to arrays, which
> should be modified to require integers.
>
> Steven Sharp
> sharp@cadence.com

Is there strong objection to removing these prohibitions? How are
they helping us?

Is anyone in favor of removing these restrictions, and have the tool
_allow_ the use of reals in bit, part and array declaration, where we
would require the tool to do automatic type conversion to the
appropriate integer value?

Automatic conversion from real to int happens in many other places in
Verilog.

When coding VCS we took the position of performing the obvious
conversion, so for example passing a real to a %d or an integer to a
%g 'works' as one would hope. Testing with VCS reveals that this is
still the case:

In VCS one can indeed use reals in range specifications; however it
seems that if there is a non zero decimal, vcs (version 5.2) will
complain that the vector is too large. :-/

Given:

% cat f.v
module f();
initial $display("hello world");
reg [30:3] a;
reg [30.0:2.0] b;
initial begin
a = 12345678;
b = 87654321;
#10;
$display("%d %g %f %x %b %o",3.1415926, 3.1415926, 3.1415926, 3.1415926, 3.1415926, 3.1415926);
$display("%d %g %f %x %b %o",a,a,a,a,a,a);
$display("%d %g %f %x %b %o",b,b,b,b,b,b);
end
endmodule

VCS says:
Chronologic VCS simulator copyright 1991-2000
Contains Synopsys proprietary information.
Compiler version 5.2; Runtime version 5.2; Nov 19 18:36 2002

hello world
3 3.14159 3.141593 3 0000000000000000000000000000000000000000000000000000000000000011 000000000000000000003
12345678 1.23457e+07 12345678.000000 0bc614e 0000101111000110000101001110 0057060516
87654321 8.76543e+07 87654321.000000 05397fb1 00101001110010111111110110001 0516277661
V C S S i m u l a t i o n R e p o r t
Time: 10
CPU Time: 0.070 seconds; Data structure size: 0.0Mb
Tue Nov 19 18:36:05 2002

whereas Cadence Verilog-XL says:
Compiling source file "f.v"

Error! Expression uses reals in an illegal context [Verilog-EURIC]
"f.v", 4: [30:2]
1 error
End of VERILOG-XL 3.10.s001 Nov 19, 2002 18:38:57

and MTI vlog says:
Model Technology ModelSim EE vlog 5.3d Compiler 2000.02 Feb 4 2000
-- Compiling module f
ERROR: f.v(4): Illegal context for real expression
ERROR: f.v(4): Illegal context for real expression

So, it looks like where we are is choosing between three possibilities:

1) wordcraft the power function definition so that the expression 2**5
yields 'd30, but 2.1**5 yields 'sd40.5 so that a natural use of
this operator behaves as expected.

2) make range, bit and partselects accept reals, automatically
converting them to the nearest interger.

3) invent an int() conversion operator, so that folks can type:
reg [int(A**B)-1:0] vec;
and essentially get #2 by adding four key strokes.

(Note that given that we have already added constant functions, we
could just push the burden on the user, making them declare in their
top module:

module top (...);

function [31:0] int(real r);
begin
int = r;
end
endfunction

endmodule

and then later in any module that wants to use power:

reg [top.int(a**b)-1:0] vec;

this adds nine keystrokes to get what, in my opinion, is would be what
the writer would expect.)

I realize that making range, bit and partselect accept reals is not an
errata, and hence would have to wait for the next cycle; but I am just
wondering what the sense is of the group.

-mac






From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: drm@xilinx.com
Cc: etf-bugs@boyd.com
Subject: Re: errata/192: PROPOSAL - 3.3.1: are real values for ranges allowed?
Date: Thu, 08 May 2003 10:25:57 +0300

I propose the following modification. If it seems reasonable, you can put it in
the FIX field.


1. In 3.3.1:

REPLACE the 2nd paragraph:

"Both msb constant expression and lsb constant expression shall be
constant expressions. The msb and lsb constant expressions can be
any value -- positive, negative or zero. The lsb constant expresson
can be a greater, equal, or lesser value than the msb constant
expression."

WITH:

"Both the msb constant expression and the lsb constant expression
shall be constant integer expressions. The msb and lsb constant
expressions can be any integer value -- positive, negative or
zero. The lsb value can be greater than, equal to, or
less than the msb value."


2. In 3.9.1, add items to the dashed list:

"-- Real number bit range specifications of vectors (see 3.3.1)
-- Real number address range specifications of array dimensions (see 3.10)"


3. In 3.10, para. 2, change sentence 2 FROM:

"The expression(s) that specify the indices of the array shall be constant
expressions."

TO:

"The expressions that specify the indices of the array shall be constant integer
expressions."


4. In 4.2.1, in para. 3, CHANGE

"Both expressions shall be constant expressions."

TO

"Both expressions shall be constant integer expressions."


In para. 5, CHANGE:

"The width_expr shall be a constant expression."

TO:

"The width_expr shall be a constant integer expression". (Note: see errata/228.)



5. In 4.2.2:

In para. 5, CHANGE

"The addr_expr can be any expression;"

TO:

"The addr_expr can be any integer expression".


In para. 9, CHANGE:

"The syntax for access to the array ... an expression for each addressed
dimension:"

TO:

"The syntax for access to the array ... an integer expression for each addressed
dimension:"


In para. 10, CHANGE:

"As before, the addr_expr can be any expression."

TO:

"As before, the addr_expr can be any integer expression."




--
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




From: Dennis Marsa <drm@xilinx.com>
To: Shalom Bresticker <Shalom.Bresticker@motorola.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/192: PROPOSAL - 3.3.1: are real values for ranges allowed?
Date: Fri, 09 May 2003 10:31:30 -0600

Shalom Bresticker wrote:
>
> I propose the following modification. If it seems reasonable, you can put it in
> the FIX field.
>
> 1. In 3.3.1:
>
> REPLACE the 2nd paragraph:
>
> "Both msb constant expression and lsb constant expression shall be
> constant expressions. The msb and lsb constant expressions can be
> any value -- positive, negative or zero. The lsb constant expresson
> can be a greater, equal, or lesser value than the msb constant
> expression."
>
> WITH:
>
> "Both the msb constant expression and the lsb constant expression
> shall be constant integer expressions. The msb and lsb constant
> expressions can be any integer value -- positive, negative or
> zero. The lsb value can be greater than, equal to, or
> less than the msb value."

OK

> 2. In 3.9.1, add items to the dashed list:
>
> "-- Real number bit range specifications of vectors (see 3.3.1)
> -- Real number address range specifications of array dimensions (see 3.10)"

I was torn as to whether to propose adding another bullet or two to
this section. I initially decided against it because the context of this
section is talking about real operands (not real expressions) and which
operators can be applied to real operands; i.e. it references table 4-7,
and additionally states that edge descriptors and bit/part select can't be
applied to real variables (not expressions).

The third bullet states a restriction on part/bit selects, which I feel
would be better placed where they are defined in 4.2.1, and which you
propose in your part 4.

So, if one agrees that the existing 3rd bullet is misplaced, I think
the two additional ones you propose would be misplaced as well. The
two restrictions you list are either already there, or you propose
adding them, so I think that is enough.

> 3. In 3.10, para. 2, change sentence 2 FROM:
>
> "The expression(s) that specify the indices of the array shall be constant
> expressions."
>
> TO:
>
> "The expressions that specify the indices of the array shall be constant integer
> expressions."

OK.

> 4. In 4.2.1, in para. 3, CHANGE
>
> "Both expressions shall be constant expressions."
>
> TO
>
> "Both expressions shall be constant integer expressions."

I would propose:

"Both the msb_expr and lsb_expr shall be constant integer expressions."

> In para. 5, CHANGE:
>
> "The width_expr shall be a constant expression."
>
> TO:
>
> "The width_expr shall be a constant integer expression". (Note: see errata/228.)

I would propose:

"Each of the msb_base_expr, lsb_base_expr and width_expr shall be constant integer expressions."

> 5. In 4.2.2:
>
> In para. 5, CHANGE
>
> "The addr_expr can be any expression;"
>
> TO:
>
> "The addr_expr can be any integer expression".

OK.

> In para. 9, CHANGE:
>
> "The syntax for access to the array ... an expression for each addressed
> dimension:"
>
> TO:
>
> "The syntax for access to the array ... an integer expression for each addressed
> dimension:"

OK.

> In para. 10, CHANGE:
>
> "As before, the addr_expr can be any expression."
>
> TO:
>
> "As before, the addr_expr can be any integer expression."

OK.


Dennis

From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: Dennis Marsa <drm@xilinx.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/192: PROPOSAL - 3.3.1: are real values for ranges allowed?
Date: Sun, 11 May 2003 17:38:41 +0300

> > 4. In 4.2.1, in para. 3, CHANGE
> >
> > "Both expressions shall be constant expressions."
> >
> > TO
> >
> > "Both expressions shall be constant integer expressions."
>
> I would propose:
>
> "Both the msb_expr and lsb_expr shall be constant integer expressions."

OK


> > In para. 5, CHANGE:
> >
> > "The width_expr shall be a constant expression."
> >
> > TO:
> >
> > "The width_expr shall be a constant integer expression". (Note: see errata/228.)
>
> I would propose:
>
> "Each of the msb_base_expr, lsb_base_expr and width_expr shall be constant integer expressions."

No, only width_expr must be constant. msb_base and lsb_base may be variables.



From: Dennis Marsa <drm@xilinx.com>
To: Shalom Bresticker <Shalom.Bresticker@motorola.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/192: PROPOSAL - 3.3.1: are real values for ranges allowed?
Date: Mon, 12 May 2003 08:13:56 -0600

Shalom Bresticker wrote:
>
> Precedence: bulk
>
> The following reply was made to PR errata/192; it has been noted by GNATS.
>
> > > In para. 5, CHANGE:
> > >
> > > "The width_expr shall be a constant expression."
> > >
> > > TO:
> > >
> > > "The width_expr shall be a constant integer expression". (Note: see errata/228.)
> >
> > I would propose:
> >
> > "Each of the msb_base_expr, lsb_base_expr and width_expr shall be constant integer expressions."
>
> No, only width_expr must be constant. msb_base and lsb_base may be variables.
>

Yes. Thank you.

How about:

"The msb_base_expr and lsb_base_expr shall be integer expressions, and the width_expr
shall be a constant integer expression."

Dennis

From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: Dennis Marsa <drm@xilinx.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/192: PROPOSAL - 3.3.1: are real values for ranges allowed?
Date: Mon, 12 May 2003 18:41:20 +0300

See below.

> > > > In para. 5, CHANGE:
> > > >
> > > > "The width_expr shall be a constant expression."
> > > >
> > > > TO:
> > > >
> > > > "The width_expr shall be a constant integer expression". (Note: see errata/228.)
> > >
> > > I would propose:
> > >
> > > "Each of the msb_base_expr, lsb_base_expr and width_expr shall be constant integer expressions."
> >
> > No, only width_expr must be constant. msb_base and lsb_base may be variables.
>
> How about:
>
> "The msb_base_expr and lsb_base_expr shall be integer expressions, and the width_expr
> shall be a constant integer expression."

OK.

Take into account that #228 (etf-passed) added the sentence "The value of the width_expr shall be a
positive integer."

Also, I think we can delete the next sentence, "It shall also not be affected by run-time parameter
assignments."

I am still thinking about 3.9.1.


From: Peter Flake <Peter.Flake@synopsys.com>
To: Shalom Bresticker <Shalom.Bresticker@motorola.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/192: PROPOSAL - 3.3.1: are real values for ranges
allowed?
Date: Mon, 12 May 2003 17:26:52 +0100

Hi,

The advantage of allowing real values for ranges is that it allows the
power operator to always return a real, which simplifies implementation.

The real values should of course have zero fractions.

Peter.

At 07:40 11/05/2003 -0700, Shalom Bresticker wrote:
>Precedence: bulk
>
>The following reply was made to PR errata/192; it has been noted by GNATS.
>
>From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
>To: Dennis Marsa <drm@xilinx.com>
>Cc: etf-bugs@boyd.com
>Subject: Re: errata/192: PROPOSAL - 3.3.1: are real values for ranges allowed?
>Date: Sun, 11 May 2003 17:38:41 +0300
>
> > > 4. In 4.2.1, in para. 3, CHANGE
> > >
> > > "Both expressions shall be constant expressions."
> > >
> > > TO
> > >
> > > "Both expressions shall be constant integer expressions."
> >
> > I would propose:
> >
> > "Both the msb_expr and lsb_expr shall be constant integer expressions."
>
> OK
>
>
> > > In para. 5, CHANGE:
> > >
> > > "The width_expr shall be a constant expression."
> > >
> > > TO:
> > >
> > > "The width_expr shall be a constant integer expression". (Note: see
> errata/228.)
> >
> > I would propose:
> >
> > "Each of the msb_base_expr, lsb_base_expr and width_expr shall be
> constant integer expressions."
>
> No, only width_expr must be constant. msb_base and lsb_base may be
> variables.
>
>



From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, Peter.Flake@synopsys.com
Cc:
Subject: Re: errata/192: PROPOSAL - 3.3.1: are real values for ranges allowed?
Date: Mon, 12 May 2003 17:59:09 -0400 (EDT)

> The advantage of allowing real values for ranges is that it allows the
> power operator to always return a real, which simplifies implementation.

I suppose that making the power operator always return a real might save
some time for a few simulator implementors. It is hardly a convincing
argument. We could make the same argument about eliminating integer
addition, subtraction, multiplication, division and comparison operations,
and just producing reals for those too. I don't think users would be
happy about that.

Making the power operator produce reals from integer inputs would
1. Make it inconsistent with all other operators in the Verilog language.
2. Make it impossible to get a correct value for integral results larger
than 56 bits.
3. Call for the use of expensive floating point operations instead of
cheaper integer operations.
4. Make synthesis of any expression with a power operator problematic.

Steven Sharp
sharp@cadence.com


From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: Dennis Marsa <drm@xilinx.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/192: PROPOSAL - 3.3.1: are real values for ranges allowed?
Date: Mon, 19 May 2003 17:36:57 +0300

I apologize for not responding till now.
See my response below.

> > 2. In 3.9.1, add items to the dashed list:
> >
> > "-- Real number bit range specifications of vectors (see 3.3.1)
> > -- Real number address range specifications of array dimensions (see 3.10)"
>
> I was torn as to whether to propose adding another bullet or two to
> this section. I initially decided against it because the context of this
> section is talking about real operands (not real expressions) and which
> operators can be applied to real operands; i.e. it references table 4-7,
> and additionally states that edge descriptors and bit/part select can't be
> applied to real variables (not expressions).
>
> The third bullet states a restriction on part/bit selects, which I feel
> would be better placed where they are defined in 4.2.1, and which you
> propose in your part 4.
>
> So, if one agrees that the existing 3rd bullet is misplaced, I think
> the two additional ones you propose would be misplaced as well. The
> two restrictions you list are either already there, or you propose
> adding them, so I think that is enough.

I could say that it also says,
"Real number constants and real variables are also prohibited in the following cases:",
which I could interpret as meaning more generally, not just operands.

However, if you wish to delete the third bullet, since it is already covered in 4.2.1,
then I do not object. If we want to list ALL the places where reals may not appear,
I suspect we will find many more situations as well, so maybe it is better not to list them at all.

I do, however, have the following comments on the wording:

A. The sentence "Real number constants and real variables are also prohibited in the following
cases:"
is wrong because the following cases apply only to variables.

B. The restrictions are not on the variables, but on the permitted ways to manipulate them.

C. This entire section should reference "realtime" as well as "real" variables. In fact, there are
several places in the LRM where "realtime" should be added to mention of "real". And even though
3.9 says that "realtime" shall be treated synonomously with "real", nevertheless in the vast
majority of places, "realtime" was still mentioned explicitly. And there are places where there IS
a distinction between them.

D. "Edge descriptors" is an incorrect description of posedge and negedge. "Edge descriptors" are
something else. posedge and negedge could be called "edge event controls"? By the way, the BNF does
not restrict them, so this is a semantic restriction.

So, I suggest you update the proposal and let's file my complaints about 3.9.1 as a new issue.

--
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



Unformatted



Hosted by Boyd Technology