Re: B19 - Signed Arithmetic Proposal

From: Thomas Fitzpatrick (tfitz@cadence.com)
Date: Wed Mar 04 1998 - 07:08:20 PST

BAD MSG:
Hi Stu,
-Lines: 172
Content-Type: text/plain; charset="us-ascii"
Content-Length: 7474
X-Status: $$$$
X-UID: 0000000328
Status: RO

I'll be sending out an updated version of the proposal later today, but I
wanted to answer your concerns directly, instead of your having to reread the
proposal to see what changed.

On Dec 9, 9:45am, Stuart Sutherland wrote:
> Subject: Re: B19 - Signed Arithmetic Proposal
>
> 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.

        Thanks. This has been fixed.
>
> 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.

        It doesn't matter where the parameter gets its value. Each individual
parameter is signed or unsiged depending on the value assigned to it. This can
also be true for a parameter in a module that is instantiated twice, where one
instantiation assigns the parameter a signed value and the other an unsigned
value. This is similar to the capability of overriding an integer parameter
with a real value as in your last example.
>
> 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).

        Done. Implicit nets are always unsigned.
>
>
> 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.

        I've modified the proposal so that the signed attribute may be assigned
to either the port or the associated net/reg declaration. If either is declared
signed, then both are considered signed.
>
> 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;

        Yes. In this case, foo is signed.
>
> 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.

        Done. There is no need to declare both the port and the net/reg as
signed. You can if you want to, though. This will also be consistent with the
proposed "ANSI-like" declaration syntax (proposal B09)

   output signed reg [7:0] bar;
>
> d). The port declaration syntax/semantics would be much more clear with the
> addition of a few examples.

        I've added a comprehensive example.
>
>
> 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 */

        You're good. Yes, it is a typo and has been fixed.
> ^
> 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.

        I'll include the answer from my colleague, David Roberts, who is also
on the PLI Task Force:
+ First: the return value from a PLI1.0 system function is treated as
+ "UNSIGNED" and you get the size from the sizetf function or assume 32
+ bits by default.
+
+ Second: the proposal is to enhance VPI so it can return arbitrary sized
+ SIGNED values. This is presently impossible in PLI1.0 and VPI. VPI
+ can presently return signed values in the sizes of 32 (vpiSysFuncInt)
+ or (vpiSysFuncTime) 64.
+
+ Third: you can not blindly change the behavior of the return value from
+ unsigned to signed. There will be diffs in any expression that needs
+ to do size extension when the MSB is set.
+
+ Forth: yes the PLI1.0 will not be able to support, in the sense of
+ putting out signed values. This is OK we have decided not to enhance
+ PLI1.0 beyond it's present level. Allowing VPI to return signed value
+ will not hurt any presentl PLI1.0 application. Nothing should have to
+ change on the PLI1.0 side of things.
+
+ --David
Me again: Based on David's arguments, I believe that the vpiSysFuncSignedSized
property is required to specify that the value returned from a user-defined VPI
system function is signed. Since system functions are always operands, we need
to know if they are signed to be able to tell if the resulting expression is
also signed.

Thanks for your diligence and attention to detail on this.

Regards,
-Tom 

-- 
---------------
Tom Fitzpatrick

Cadence Design Systems           Cobra Technical Marketing Manager
Product Engineering              Logic Design & Verification Business Unit
(978)446-6438                    x6438

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