[sv-bc] 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
Received on Thu Jun 21 17:48:31 2012