RE: [sv-bc] unsized number literals

>From: "Loganath Ramachandran" <lrcrsr@hotmail.com>

>1) An unsized literal should at least contain 32 bits (page 37 of LRM)

This statement does not apply to the single-bit literal being discussed
here. It applies to "an unsized number (which is a simple decimal number
or a number with a base specifier but no size specification)". This single-
bit literal is not a simple decimal number, nor does it have a base
specifier. It is an "unsized single-bit value", which has different rules.

An unsized number is 32 bits (The "at least" part is now obsolete text,
still technically true, but inexact and misleading. Integers are now
exactly 32 bits, and unsized numbers are specified to be the same size as
integers, if you know where to look.) An unsized single-bit value has a
natural size of 1 bit instead.

It was clearer that these two were distinct things before the standards
were merged, since the single-bit literals were described in their own
section of the 1800 standard. Now they are described in the same section
as unsized numbers, in the very next paragraph, leading to confusion.

>2) All bits of the unsized value shall be set to the value of the
>specified bit. (page 37 of LRM)

A poor description, unfortunately. The value itself only has one bit.
It is not the bits of the unsized value that get set, it is the bits of
the value it gets extended to become, due to its context.

>So in this example, the actual is at least 32bits wide with value of
>"1111...111", while the
>formal is 2-bits wide.

The actual is 1 bit wide, but it will be extended to the width of the
context, even if that is wider than 32 bits. Your explanation would
only provide 32 bits of ones. The actual explanation provides as many
bits of ones as are required by the context.

In this case, the context is 2 bits wide. A port connection is specified
to be equivalent to a continuous assignment, and in an assignment, the
width of the left-hand side (the port formal in this case) is part of the
context for the right-hand side. So the 1-bit literal will be extended
to 2 bits, and all those bits will be ones.

>In my opinion, a warning would be nice, but I am not sure if LRM requires
>this because of the unsized nature of the constant.

The LRM doesn't require a warning for a size mismatch. Tools can provide
them. It would be reasonable for such tools not to produce one in this
case, since this is a type of constant designed to be used where an
arbitrary width is called for.

Note that the mismatch would not be between 2 bits and 32 bits, it would
be between 2 bits and 1 bit, which is the actual size of this constant.
The LRM muddles this up by talking about the extended value as if it were
the value of the literal, and the 1-bit width in a self-determined context
were a special case. The proper way to describe the literal is as having
a 1-bit width, and that bit's value being used for all bits when the literal
is extended in a wider context, the same way that the sign bit of a signed
value extends in a wider signed context.

I still agree with your conclusion, that the correct result is 2'b11 here.

Steven Sharp | Architect | Cadence

P: 508.459.1436 M: 774.535.4149 www.cadence.com

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.