RE: [sv-bc] RE: unsized parameter values

Surya,

I think the intent is to treat an 'unsized' constant as meaning 'not-explicitly sized' regardless of whether it is 'fixed sized' or not. A lot of people think of 0 and 1 as being a single bit, which is not really the case. This rule prohibits people from writing {0,1,0} and requires that they write it as {1'b0,1'b1,1'b0}. I can't think of any other place where an unsized literal is restricted.

Dave
Mentor Graphics

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Surya Pratik Saha
Sent: Thursday, June 21, 2012 10:09 PM
To: Vreugdenhil, Gordon; Mark Hartoog
Cc: Steven Sharp; Maidment, Matthew R; sv-bc@eda.org; Ishita Ghosh
Subject: RE: [sv-bc] RE: unsized parameter values

Hi all,
I have gone through all the mails and specifically Steven's comment that suggesting that an unsized expression size is always 32 bit and it is fixed. If that is the case, then what is the meaning of unsized then?
Why then unsized expression is restricted in some places, for e.g.
inside a concat expression. The following case failed by most of the tools along with the tool which truncates the unsized expression to 32 bit in my original e.g.:

module top;
        wire x;
        assign x = {1};
endmodule

Regards
Surya

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Gordon Vreugdenhil
Sent: 22 June 2012 07:48
To: Mark Hartoog
Cc: Steven Sharp; Maidment, Matthew R; sv-bc@eda.org
Subject: Re: [sv-bc] RE: unsized parameter values

I'm not going to argue on the historical aspects -- the historical interpretation would certainly be inline with what Steven says. I won't even argue that such an interpretation isn't aligned with intent in, say

1364-2001 or so.

However, I would oppose aligning the LRM text with that interpretation (and even intent) at this point.

There are many contexts in which implied size applies to parameters and I think it would be a mistake at this point to strongly re-institute the

"integer" assumption. If an implementation wants to do that for historical reasons or similar, fine. But given the other kinds of type and sizing that happens, it seems more than a little unhelpful to most users to require that "wide" unsized values truncate to 32 bits when used with an untyped parameter.

Gord.

On 6/21/2012 5:53 PM, Mark Hartoog wrote:
> I am just pointing out that the actual text in the LRM is
self-contradictory. It can be interpret as you say, but it can be interpret in other ways also.
>
> -----Original Message-----
> From: Steven Sharp [mailto:sharp@cadence.com]
> Sent: Thursday, June 21, 2012 5:48 PM
> To: Mark Hartoog; Maidment, Matthew R; sv-bc@eda.org
> Subject: RE: unsized parameter values
>
> Are you seriously suggesting that the interpretation should be other
than what I have given? I can provide support for the historical intent from the OVI standard, the Verilog-XL manual, and the behavior of Verilog-XL.
>
> Or are you just pointing out that the LRM text is somewhat unclear? I
will agree with that.
>
>
> -----Original Message-----
> From: Mark Hartoog [mailto:Mark.Hartoog@synopsys.com]
> Sent: Thursday, June 21, 2012 8:36 PM
> To: Steven Sharp; Mark Hartoog; Maidment, Matthew R; sv-bc@eda.org
> Subject: RE: unsized parameter values
>
> As you pointed out, the title for table 11-21 says it is for
self-determined expressions. Table 5-22 in 1364-2005 also says self-determined expressions in its title.
>
> You could argue that when the parameter has no type or range, the
value is a self-determined context, but section 6.20.2 explicitly says at least 32 bits, not the size of an integer. You argued that the rule in 6.20.2 was unnecessary, but it is still in the LRM and does not say that the size of the result should be the size of an integer. It only says at least 32 bits.
>
> -----Original Message-----
> From: Steven Sharp [mailto:sharp@cadence.com]
> Sent: Thursday, June 21, 2012 5:24 PM
> To: Mark Hartoog; Maidment, Matthew R; sv-bc@eda.org
> Subject: RE: unsized parameter values
>
> Table 11-21 says that for an expression that is an unsized constant
number, the bit length is the same as integer.
>
> The main purpose of the table is to specify the rules for propagating
bit lengths upward through expressions involving operators, but it also provides the sizes of constant numbers. It isn't the most obvious place for that, which can lead to strange reasoning that maybe that is something other than the inherent size of the number.
>
>
> -----Original Message-----
> From: Mark Hartoog [mailto:Mark.Hartoog@synopsys.com]
> Sent: Thursday, June 21, 2012 8:15 PM
> To: Steven Sharp; Mark Hartoog; Maidment, Matthew R; sv-bc@eda.org
> Subject: RE: unsized parameter values
>
> "In the SystemVerilog standard, the size of an integer variable was
fixed at 32 bits. The text still says that unsized literals shall be at least 32 bits. However, since they are supposed to be the same size as integer variables, they are actually now fixed at 32 bits also."
>
> Where in the LRM does it say that unsized literals are supposed to be
the same size as integer variables?
>
> That may be your understanding of the intention of the LRM. That was
my guess of what was intended, but I cannot find any place where it says that.
>
> The LRM is not at all clear about this. The text that is in the LRM
can be interpret other ways.
>
> -----Original Message-----
> From: Steven Sharp [mailto:sharp@cadence.com]
> Sent: Thursday, June 21, 2012 4:45 PM
> To: Mark Hartoog; Maidment, Matthew R; sv-bc@eda.org
> Subject: RE: unsized parameter values
>
> I am going to reply to Mark's email before the original question.
>
> That statement in 6.20.2 is unnecessary. The size of a parameter with
no range is determined by the size of the value. There was no need to give a special rule for an "unsized" value, since such values actually have a size, just not one that was explicitly specified.
>
> The "at least 32 bits" thing is out-of-date and appears in several
places.
>
> Originally, integer variables and "unsized" literals were whatever was
the natural integer word size on the machine the tool was executing on.
This was to allow tools to use the native integer type, rather than having to jump through hoops to emulate a different integer size. This is the same as the int data type in K&R C.
>
> This size would be the same for integer variables and unsized
literals. There was a table of expression sizes which specified that unsized literals were the same size as an integer variable.
>
> In the IEEE Verilog standard, this size remained
implementation-dependent, but was required to be at least 32 bits. This is the same thing that was done with ints in ANSI C. It gives users some guarantee of a minimum size, even on a platform with a smaller native word size.
>
> In the SystemVerilog standard, the size of an integer variable was
fixed at 32 bits. The text still says that unsized literals shall be at least 32 bits. However, since they are supposed to be the same size as integer variables, they are actually now fixed at 32 bits also.
>
> This was made less clear due to changes during the standardization.
The table used to say that this was the size of the expression. But it was noted that for many expressions involving operators, this size was only correct in a self-determined context. In context-determined expressions, a wider size might propagate down to the operands, resulting in the size of the expression being wider than this. So the title of the table was changed to specify that it applied for self-determined expressions. But this obscured the meaning for unsized constant numbers. Where it used to say that their size was the same as an integer, now it only technically says that for self-determined expressions. It leaves Surya to assume that they might have a different size in some other context, which was not the intent.
>
> Someone could also look at that table and say that while this is the
size of an unsized constant number when used in an expression, perhaps the number could actually be bigger than that. But this would be silly.
There would be no point in having a number have an inherent size bigger than that, if it were always treated as 32 bits when used in an expression. But this is where the change in the table title comes in.
Someone could assume that they might have a larger size which becomes visible when the constant is used in a context-determined expression.
>
> This was never the intent. Unsized constant numbers have a fixed size
(which is 32 bits in SV), no matter what context they are used in. They don't change their size any more than an integer variable changes size based on the context it is used in.
>
>
>
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Mark Hartoog
> Sent: Thursday, June 21, 2012 6:41 PM
> To: Maidment, Matthew R; sv-bc@eda.org
> Subject: [sv-bc] RE: unsized parameter values
>
> Section 6.20.2 of the LRM says:
>
> "A parameter with no range specification, with either a signed type
specification or no type specification,
> and for which the final value assigned to it is unsized shall have an
implied range with an lsb
> equal to 0 and an msb equal to an implementation-dependent value of at
least 31."
>
> It looks to me like any tool that makes the value 32 bits or more is
compliant with the LRM.
>
> I think the intention of this language was that integers could be more
than 32 bits, so if a tool was using say 64 bit integers, the result would be 64 bits. The LRM has now been changed to say integers are 32 bits, but I don't think this language got changed.
>
> This language makes it hard to say any result of 32 bits or longer is
incorrect.
>
>
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Maidment, Matthew R
> Sent: Thursday, June 21, 2012 3:10 PM
> To: sv-bc@eda.org
> Subject: [sv-bc] unsized parameter values
>
> Sending this for Surya:
>
>
> Hi,
> I have a query on unsized parameter value propagation with more than
32 bits value. Please consider the following case, where there are two parameter declarations, one has no range or type specification overridden by unsized based number. Other one is overridden by the previous parameter.
>
> module top;
> A #(36, 'b010001110111011101110111011101110111) iA();
>
> initial begin
> $display(" parameter values :: iA.p_a %b , iA.iB.p_b %b ",
iA.p_a, iA.iB.p_b);
> end
> endmodule
>
>
> module A;
> parameter w = 2;
> parameter p_a = 'b00100;
> reg [w:0] a;
>
> B #(w, p_a) iB();
>
> endmodule
>
> module B;
> parameter w = 5;
> parameter [(w-1) : 0] p_b = 'b001;
> reg [w:0] a;
>
> endmodule
>
>
> I know, in the context insensitive places, the unsized expression
width becomes same as integer (32), otherwise it should take the size of the context. With that respect, the $display value should print '010001110111011101110111011101110111' for both. But one standard simulator truncates the 'iA.p_a' value to 32 bit and then prints. Though other two shows the result as I understood. What should be the expected result.
>
> Regards
> Surya
>
>
>
>
>
>
>

--
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.