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

If you want a definite answer as to why unsized constants work that way in Verilog, you would have to ask Phil Moorby why he decided to make them work that way when he invented the language. I can tell you that he did make them work that way, as demonstrated by the fact that they work that way in Verilog-XL. Beyond that I can only speculate on the reasons.

Why does Verilog let you write an unsized decimal constant like 25, instead of making you write 32'd25? Presumably because it is more convenient. In other number bases, you still need to specify a base, so the closest you can get is leaving off the size.

In addition, unsized constants being exactly 32 bits is a recent development. Back when they were invented, they were whatever size was convenient or efficient for the system. So an unsized constant let you specify that the system should use the size that was convenient for it, or the same size as an integer variable.

As far as the concats, there are two reasons for that. The first is again that unsized constants being exactly 32 bits is a recent development. Back when the rule against unsized constants in concats was created, they could vary in size depending on the platform. Depending on their size, the operand to their left in the concat would be shifted by different amounts. Changing platforms or tools could completely change the meaning of your code. Other operators might be affected somewhat by the size of an operand, but not nearly as strongly as a concat. So unsized constants were forbidden in concats. You cannot ignore the historical development of the language when trying to make sense of the current rules.

Even with unsized constants having a fixed size of 32 bits now, there is still a second reason for disallowing them in concats. This is the one that Dave Rich referred to. I have seen testcases where users were trying to use an unsized constant in a concat and complaining that it was rejected. Frequently those testcases proved that the rule was needed to prevent them from making a mistake. They were typically trying to insert a single bit on the right by using {value,0} or {value,1}. They did not want an extra 31 bits of 0 inserted, which is what this would do if allowed. When there isn't an explicit width on the value, they don't always think of how wide it really is and those extra zeros on the left. With most operators, it doesn't matter whether you have a 32-bit one, or a 1-bit one (which gets zero-extended to the width of the expression in many cases). So it doesn't matter that the user doesn't think about those extra bits. But with concatenations it matters a lot.

-----Original Message-----
From: Surya Pratik Saha [mailto:surya.pratik.saha@xilinx.com]
Sent: Friday, June 22, 2012 1:09 AM
To: Gordon Vreugdenhil; 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.