From: Stuart Sutherland (stuart@sutherland.com)
Date: Tue Dec 09 1997 - 09:45:45 PST
BAD MSG:
Tom,
-Lines: 110
Content-Type: text/plain; charset="us-ascii"
Content-Length: 4820
X-Status: $$$$
X-UID: 0000000295
Status: RO
I have a couple of questions on the signed arithmetic proposal, and one
general note:
1. General Note: IEEE legal-eeze does not allow the use of the words "will"
and "can". If a certain behavior is mandated by the standard, then IEEE
requires the word "shall", and if a behavior can be different in various
implementations, IEEE requires the word "can". I noticed the proposal uses
the word "will" in many places and "may" in at least one place.
2. For section "4.5.1 Rules for expression types", item 4:
>4. Parameters are signed if and only if the RHS expression assigned to the
> parameter is signed .
The proposal should explicitly define the behavior of parameter
redefinition. e.g.: what happens in these three examples?
parameter n = 3;
defparam n = 4'd3;
parameter m = 8'sd12;
defparam m = 8'd12;
parameter r = 1'b1;
defparam r = 3.2;
Since the defparam can occur from anywhere in the design hierarchy, from
within the hierarchy of another top-level module, or possibly from an
invocation option, It is necessary to define the affect of redefining a
parameters type or sign, or to explicitly make certain redefinitions illegal.
<p>3. The proposal does not cover implicit net declarations. I suggest adding
a note that implicit nets shall always be unsigned. This should go into
the sections that discuss signed data types and section 3.5 on implicit
data types. (Note that section 3.5 has other problems as well, since it
mandates that implicit declarations will always be scalar, which is not true).
<p>4. I have several issues with the port declaration syntax:
>Syntax 12-4 (p. 142)
>input_declaration ::= input [signed] [range] list_of_port_identifiers;
>output_declaration ::= output [signed] [range] list_of_port_identifiers;
>inout_declaration ::= inout [signed] [range] list_of_port_identifiers;
>
>Section 12.3.2 (p. 142 - 2nd paragraph)
>
>A port can be declared in both a port declaration and a net or register
>declaration. If a port is declared as a vector, the range specification
>between the two declarations of a port shall be identical. If a port is
>declared as signed, then the corresponding net or register shall also be
>declared as signed.
>
a). The proposal should explicitly define what happens with the converse of
the last sentence, when the port is declared as unsigned and the net or
register is signed? The circumstance already exists in the current
language, where ports are always unsigned but can have an integer data type
connected to the port.
b). What about implicit data types that are connected to a port? Do they
inherit the sign of the port? e.g.:
output [signed] [7:0] foo;
assign foo = a + b;
c). Depending on the answers to a) and b), perhaps there is no need to
declare ports as signed or unsigned at all. Could they not always inherit
the sign of the internal data type? Implicit data types in this case would
always be unsigned (consistent with current language behavior). The BTF
will need to make a strong case on why ports need to be explicitly signed
to get my vote on this.
d). The port declaration syntax/semantics would be much more clear with the
addition of a few examples.
<p>5. Finally, the PLI task force thanks you for thinking of us! (please note
that the values of
the constants might change due to other enhancements in the PLI.) I have
two questions:
a). Is the following a typo? (I assume the constant should be
vpiSysFuncSignedSized)
>New system taskfunc properties /* subtype of vpiSysFuncType */
>#define vpiSysFuncSignesSized 5 /* returns signed sized */
^
b). Is it the BTF's intent that PLI system functions need to return both
unsigned and signed values? Currently, the PLI just returns a sized, and
I'm not aware of any place in the LRM that states how the HDL should
interpret the return value in expressions (but I believe Verilog-XL treats
them as signed). Adding explicitly signed or unsigned returns will have an
impact on the PLI. It will not be possible with the TF and ACC routines.
It would probably require changes to a shared structure definition in the
VPI, which could affect other VPI routines. I suggest the signed
arithmetic proposal should explicitly state that returns from PLI system
functions are always treated as SIGNED.
<p>Stu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland Sutherland HDL Inc.
stuart@sutherland.com 22805 SW 92nd Place
phone: 503-692-0898 Tualatin, OR 97062
www.sutherland.com
Specializing in Verilog HDL consulting and training. Publisher of the
popular Verilog HDL and Verilog PLI quick reference guides.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:52:32 PDT
and
sponsored by Boyd Technology, Inc.