ISSUE 428

Edit Proposal  Edit Class, Environment, or Release
Number 428
Category errata
Synopsis 2.5.1: value of 16'shc, request for clarification
State proposal
Class errata-discuss
Arrival-DateAug 22 2003
Originator "Brad Pierce" <Brad.Pierce@synopsys.com>
Release 2001c: 2.5.1
Environment
Description
As I interpret section 2.5.1, the following V2K should display

|0000000000001100|0000000000001100|0000000000001100|

module m( output reg [15:0] o1, o2, output reg signed [15:0] o3 ) ;
always begin
o1 = 16'shc ;
o2 = 16'sh000c ;
o3 = 16'shc ;
$displayb("|%b|%b|%b|", o1, o2, o3) ;
end
endmodule

Is that the correct interpretation?

-- Brad


Fix
2004-11-29: This includes changes discussed in ETF meeting
today. However, the ETF did not vote to approve it, due to
lack of time.


In 2.5.1:

1. In para. 2, CHANGE

"an optional size constant"

TO

"an optional size specification"


2. At the end of the second paragraph, append
the following sentence --

"It shall be legal to macro substitute these
three tokens."


3. REPLACE

"The first token, a size constant, shall specify
the size of the constant in terms of its exact
number of bits.

WITH

"The first token, a size specification, shall specify
the size of the constant in terms of its exact
number of bits."


4. In para. 7, CHANGE

"Simple decimal numbers without the size and the base format"

TO

"Simple decimal numbers without the size specification and the base format"


5. CHANGE

"A plus or minus operator preceding the size constant is a unary plus or minus operator."

TO

"A plus or minus operator preceding the size specification is a unary plus or minus operator."


6. REPLACE

"If the size of the unsigned number is smaller
than the size specified for the constant, the
unsigned number shall be padded to the left
with zeros. If the leftmost bit in the unsigned
number is an x or a z, then an x or a z shall
be used to pad to the left respectively."

WITH

"If a sized constant has an unsigned number
(i.e., third token) with a value that has
fewer bits than are specified by its size specification
(i.e., first token), the value of the unsigned
number shall be extended to the specified number
of bits by padding it to the left with zero (even
if the constant is signed), unless the leftmost bit
in the unsigned number is x or z, in which case
it shall be padded to the left with x or z
respectively."


7. REPLACE

"Unsized unsigned constants where the high order bit is
unknown (X or x) or three-state (Z or z) shall be extended
to the size of the expression containing the constant."

WITH

"The number of bits that
make up an unsized integer constant (which is
a simple decimal number or a based constant
without a size specification) shall be at least 32.
Unsized unsigned constants where the high order bit is
unknown (X or x) or three-state (Z or z) shall be extended
to the size of the expression containing the constant."


8. In Example 4

REPLACE

reg[11:0] a, b, c, d;
initial begin
a = 'h x; // yields xxx
b = 'h 3x; // yields 03x
c = 'h z3; // yields zz3
d = 'h 0z3; // yields 0z3
end
reg [84:0] e, f, g;

e = 'h5; // yields {82{1'b0}, 3'b101}
f = 'hx; // yields {85{1'hx}}
g = 'hz; // yields {85{1'hz}}


WITH

reg[11:0] a, b, c, d;
initial begin
a = 'h x; // a gets 12'h xxx
b = 'h 3x; // b gets 12'h 03x
c = 'h z3; // c gets 12'h zz3
d = 'h 0z3; // d gets 12'h 0z3
end
reg [31:0] e, f, g, h, i;
reg signed [31:0] j, k;

e = 'h5; // e gets 32'h0000_0005
f = 'hx; // f gets 32'hxxxx_xxxx
g = 'hz; // g gets 32'hzzzz_zzzz
h = 4'hx; // h gets 32'h0000_000x
i = 16'ox; // i gets 32'h0000_xxxx
j = 16'sb110; // j gets 32'h0000_0006
k = 3'sb110; // k gets 32'hffff_fffe


8. REMOVE NOTES 2 and 3.

Audit-Trail
From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, Brad.Pierce@synopsys.com
Cc:
Subject: Re: errata/428: 2.5.1, value of 16'shc, request for clarification
Date: Fri, 22 Aug 2003 11:12:45 -0400 (EDT)

That is correct. The LRM says:

"If the size of the unsigned number [i.e. the third token of the constant,
which provides the actual value] is smaller than the size specified for
the constant, the unsigned number shall be padded to the left with zeros."

It would be clearer if the term "unsigned number" were not used here to
mean the third token, since I presume that is the cause of your uncertainty
when the overall constant is a signed number.

Steven Sharp
sharp@cadence.com


From: Shalom.Bresticker@motorola.com
To: brad.pierce@synopsys.com
Cc: etf-bugs@boyd.com
Subject: Re: errata/428: PROPOSAL - 2.5.1, value of 16'shc, request for
clarification
Date: Thu, 28 Aug 2003 09:54:05 +0300 (IDT)

> reg signed [84:0] h;
>
> h = 16'sb110; // yields {{82{1'b0}}, 3'b110}

Yes, but note that

h = 3'sb110 would yield { {82{1'b1}}, 3'b110}

by NOTE 1 following Example 5, which states that

"Sized negative constant numbers and sized signed constant numbers are
sign-extended when assigned to a reg data type,
regardless of whether the reg itself is signed or not."

The 3 notes there should be normative, by the way, whereas NOTES are
informative only, by IEEE Standard rules.

And if that was not confusing enough, then you also have the following:

8'hx is equivalent to 8'hxx, whereas

a[7:0] = 4'hx gives 8'h0x,

just the opposite of the above rules for sign-bit extension vs.
left-zero padding.

--
Shalom Bresticker Shalom.Bresticker@motorola.com
Design & Reuse Methodology Tel: +972 9 9522268
Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478


From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, Brad.Pierce@synopsys.com
Cc:
Subject: Re: errata/428: PROPOSAL - 2.5.1, value of 16'shc, request for clarification
Date: Thu, 28 Aug 2003 17:33:40 -0400 (EDT)

>Each of the three tokens for specifying a number
>shall be macro substituted.

"Shall" means that it must happen. But you can't macro substitute a token
unless it was a macro. You may have wanted to say that this capability to
macro substitute each token is a requirement of an implementation, but this
particular use of "shall" doesn't work. I think the wording needs work.

Steven Sharp
sharp@cadence.com


From: Shalom.Bresticker@motorola.com
To: Brad.Pierce@synopsys.com
Cc: etf-bugs@boyd.com
Subject: Re: errata/428: PROPOSAL - 2.5.1, value of 16'shc, request for
clarification
Date: Sun, 7 Sep 2003 18:07:22 +0300 (IDT)

What you write is all correct, but a few points bother me:

- The three notes (with or without the word "NOTE") come after
an example which depends on them.

- In the first note, the phrase "Sized negative constant numbers
and sized unsigned constant numbers" is unclear, in that I had
trouble understanding why it did not simply say
"sized constant numbers".

- Steven Sharp mentioned an unclear use of the phrase
"unsigned number".

- More generally, the whole subject of size-extension is not
described clearly, consistently, and comprehensively in a single
place in all its aspects. Other issues relating to this are
#106 and #463, and I think there may be one other.

Shalom


> In Example 4 of 2.5.1
>
> REPLACE
>
> reg[11:0] a, b, c, d;
> initial begin
> a = 'h x; // yields xxx
> b = 'h 3x; // yields 03x
> c = 'h z3; // yields zz3
> d = 'h 0z3; // yields 0z3
> end
> reg [84:0] e, f, g;
>
> e = 'h5; // yields {82{1'b0}, 3'b101}
> f = 'hx; // yields {85{1'hx}}
> g = 'hz; // yields {85{1'hz}}
>
>
> WITH
>
> reg[11:0] a, b, c, d;
> initial begin
> a = 'h x; // yields 12'h xxx
> b = 'h 3x; // yields 12'h 03x
> c = 'h z3; // yields 12'h zz3
> d = 'h 0z3; // yields 12'h 0z3
> end
> reg [84:0] e, f, g, h, i;
> reg signed [84:0] j, k;
>
> e = 'h5; // yields {{82{1'b0}}, 3'b101}
> f = 'hx; // yields {85{1'bx}}
> g = 'hz; // yields {85{1'bz}}
> h = 4'hx; // yields {{81{1'b0}}, 4'hx}
> i = 16'ox; // yields {{69{1'b0}}, {16{1'bx}}}
> j = 16'sb110; // yields {{82{1'b0}}, 3'b110}
> k = 3'sb110; // yields {{82{1'b1}}, 3'b110}
>
> and
>
> REPLACE
>
> NOTES:
>
> 1) Sized negative constant numbers and sized unsigned
> constant numbers are sign-extended when assigned to a
> reg data type, regardless of whether the reg itself is
> signed or not.
>
> 2) Each of the three tokens for specifying a number
> may be macro substituted.
>
> 3) The number of bits that make up an unsized number
> (which is a simple decimal number or a number without
> the size specification) shall be at least 32.
>
> WITH
>
> Sized negative constant numbers and sized unsigned
> constant numbers shall be sign-extended when assigned to a
> reg data type, regardless of whether the reg itself is
> signed or not.
>
> It shall be legal to macro substitute the three tokens
> for specifying a number.
>
> The number of bits that make up an unsized number
> (which is a simple decimal number or a number without
> the size specification) shall be at least 32.
>
> http://boydtechinc.com/cgi-bin/issueproposal.pl?cmd=view&pr=428
>

--
Shalom Bresticker Shalom.Bresticker@motorola.com
Design & Reuse Methodology Tel: +972 9 9522268
Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478



Fix replaced by Brad.Pierce@Synopsys.com on Mon Oct 27 23:00:13 2003
In 2.5.1, in the first paragraph, REPLACE

"The second form specifies a sized constant"

WITH

"The second form specifies a based constant"

In 2.5.1, at the end of the first paragraph, append
the following sentence --

"It shall be legal to macro substitute these
three tokens."

In 2.5.1, at the end of the paragraph beginning
"The first token", append the following sentence --

"The number of bits that make up an unsized number
(which is a simple decimal number or a number without
the size specification) shall be at least 32."

In 2.5.1, at the end of the paragraph beginning
"Simple decimal numbers", append the following sentence --

"Sized constant numbers shall be sign-extended
when assigned to a reg data type, regardless of
whether the reg itself is signed or not."

In 2.5.1, in the paragraph beginning "If the size
of the unsigned number", REPLACE

"If the size of the unsigned number is smaller
than the size specified for the constant, the
unsigned number shall be padded to the left
with zeros. If the leftmost bit in the unsigned
number is an x or a z, then an x or a z shall
be used to pad to the left respectively."

WITH

"If the size of the third token is smaller
than the size specified for the constant, the
the token shall be padded to the left
with zeros, unless the leftmost bit in the token
is an x or a z, in which case x's or z's shall
be used to pad to the left respectively."


In Example 4 of 2.5.1

REPLACE

reg[11:0] a, b, c, d;
initial begin
a = 'h x; // yields xxx
b = 'h 3x; // yields 03x
c = 'h z3; // yields zz3
d = 'h 0z3; // yields 0z3
end
reg [84:0] e, f, g;

e = 'h5; // yields {82{1'b0}, 3'b101}
f = 'hx; // yields {85{1'hx}}
g = 'hz; // yields {85{1'hz}}


WITH

reg[11:0] a, b, c, d;
initial begin
a = 'h x; // yields 12'h xxx
b = 'h 3x; // yields 12'h 03x
c = 'h z3; // yields 12'h zz3
d = 'h 0z3; // yields 12'h 0z3
end
reg [84:0] e, f, g, h, i;
reg signed [84:0] j, k;

e = 'h5; // yields {{82{1'b0}}, 3'b101}
f = 'hx; // yields {85{1'bx}}
g = 'hz; // yields {85{1'bz}}
h = 4'hx; // yields {{81{1'b0}}, 4'hx}
i = 16'ox; // yields {{69{1'b0}}, {16{1'bx}}}
j = 16'sb110; // yields {{82{1'b0}}, 3'b110}
k = 3'sb110; // yields {{82{1'b1}}, 3'b110}

and

REMOVE

NOTES:

1) Sized negative constant numbers and sized unsigned
constant numbers are sign-extended when assigned to a
reg data type, regardless of whether the reg itself is
signed or not.

2) Each of the three tokens for specifying a number
may be macro substituted.

3) The number of bits that make up an unsized number
(which is a simple decimal number or a number without
the size specification) shall be at least 32.



From: Stephen Williams <steve@icarus.com>
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/428: PROPOSAL - 2.5.1, value of 16'shc, request for clarification
Date: Tue, 28 Oct 2003 09:07:33 -0800

Brad.Pierce@synopsys.com wrote:

> In 2.5.1, at the end of the paragraph beginning
> "The first token", append the following sentence --
>
> "The number of bits that make up an unsized number
> (which is a simple decimal number or a number without
> the size specification) shall be at least 32."

I personally do not like this rule. There is already a
statement somewhere where a compiler is not allowed to
truncate unsized integers to less then 32 bits, I think
this is plenty adequate and the above proposed addition
is adding an unnecessary restriction.

Users are already assured that values that have up to
32bits *will* be represented. There is no need to impose
the additional restriction that that size must be 32bits,
even for values that can be represented in 1 bit.

In fact, I would counter-propose that the right to clip
values to 32bits be revoked. "4294967297 == 1" is rather
confusing, especially since it it not required to be true,
just allowed to be true.


--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."

From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, steve@icarus.com
Cc:
Subject: Re: errata/428: Re: errata/428: PROPOSAL - 2.5.1, value of 16'shc, request for clarification
Date: Tue, 28 Oct 2003 13:05:36 -0500 (EST)

> Users are already assured that values that have up to
> 32bits *will* be represented. There is no need to impose
> the additional restriction that that size must be 32bits,
> even for values that can be represented in 1 bit.

I don't think it is a good idea to allow tools to use different
sizes for different unsized constant values. Since the sizes
can affect the widths at which expressions are evaluated, this
would potentially introduce unpredictable and unexpected behavior.

For example, your suggestion would allow a tool to evaluate "1+1"
as 0 instead of 2, because it would be allowed to treat the two
constants as 1 bit, resulting in a 1 bit result size which overflows.

Steven Sharp
sharp@cadence.com

From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: Stephen Williams <steve@icarus.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/428: Re: errata/428: PROPOSAL - 2.5.1, value of 16'shc,
request for clarification
Date: Thu, 30 Oct 2003 16:17:45 +0200

Stephen Williams wrote:

> Brad.Pierce@synopsys.com wrote:
>
> > In 2.5.1, at the end of the paragraph beginning
> > "The first token", append the following sentence --
> >
> > "The number of bits that make up an unsized number
> > (which is a simple decimal number or a number without
> > the size specification) shall be at least 32."
>
> I personally do not like this rule. There is already a
> statement somewhere where a compiler is not allowed to
> truncate unsized integers to less then 32 bits, I think
> this is plenty adequate and the above proposed addition
> is adding an unnecessary restriction.

I searched the LRM.

You are apparently referring to the NOTE in 3.9 (which also should not be a NOTE in
order to be normative):
"Implementations may limit the maximum size of an integer variable, but they shall at
least be 32 bits".
(Gramatically, "it shall" would be better.)

But that currently refers only to variables, not to integer constants.
And if I am reading 2.5.1, I have not reached 3.9 yet.


> Users are already assured that values that have up to
> 32bits *will* be represented. There is no need to impose
> the additional restriction that that size must be 32bits,
> even for values that can be represented in 1 bit.
>
> In fact, I would counter-propose that the right to clip
> values to 32bits be revoked. "4294967297 == 1" is rather
> confusing, especially since it it not required to be true,
> just allowed to be true.

Besides what Steven Sharp wrote,
that would simply break back-compatibility.


--
Shalom Bresticker Shalom.Bresticker@motorola.com
Design & Reuse Methodology Tel: +972 9 9522268
Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478



From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: Brad.Pierce@synopsys.com
Cc: etf-bugs@boyd.com
Subject: Re: errata/428: PROPOSAL - 2.5.1, value of 16'shc, request for
clarification
Date: Thu, 30 Oct 2003 16:42:10 +0200

Brad.Pierce@synopsys.com wrote:

> In 2.5.1, in the first paragraph, REPLACE
>
> "The second form specifies a sized constant"
>
> WITH
>
> "The second form specifies a based constant"

Just to remind everyone, this is vsgpassed issue #267.


> In 2.5.1, at the end of the first paragraph, append
> the following sentence --
>
> "It shall be legal to macro substitute these
> three tokens."

You mean "end of the second paragraph".


> In 2.5.1, at the end of the paragraph beginning
> "The first token", append the following sentence --

>
> "The number of bits that make up an unsized number
> (which is a simple decimal number or a number without
> the size specification) shall be at least 32."
>
> In 2.5.1, at the end of the paragraph beginning
> "Simple decimal numbers", append the following sentence --
>
> "Sized constant numbers shall be sign-extended
> when assigned to a reg data type, regardless of
> whether the reg itself is signed or not."

I think the more logical place more this is following the paragraph beginning
"If the size of the unsigned number ...".

However, this means we will first say that the number will be zero-padded,
then we will say that it will be sign-extended. And that is exactly the confusion
which I would like to clear up. Brad, can you find some way to explain it nicely?


> In 2.5.1, in the paragraph beginning "If the size
> of the unsigned number", REPLACE
>
> "If the size of the unsigned number is smaller
> than the size specified for the constant, the
> unsigned number shall be padded to the left
> with zeros. If the leftmost bit in the unsigned
> number is an x or a z, then an x or a z shall
> be used to pad to the left respectively."
>
> WITH
>
> "If the size of the third token is smaller
> than the size specified for the constant, the
> the token shall be padded to the left
> with zeros, unless the leftmost bit in the token
> is an x or a z, in which case x's or z's shall
> be used to pad to the left respectively."

I suggest leaving the phrases "unsigned number", but change the first mention to
"If the size of the unsigned number (i.e., the third token)".

Also, you wrote "the the token".


> http://boydtechinc.com/cgi-bin/issueproposal.pl?cmd=view&database=default&pr=428

--
Shalom Bresticker Shalom.Bresticker@motorola.com
Design & Reuse Methodology Tel: +972 9 9522268
Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478



From: Stephen Williams <steve@icarus.com>
To: Shalom Bresticker <Shalom.Bresticker@motorola.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/428: PROPOSAL - 2.5.1, value of 16'shc, request for clarification
Date: Thu, 30 Oct 2003 09:21:17 -0800

Shalom Bresticker wrote:
> Stephen Williams wrote:
>
>
>> Brad.Pierce@synopsys.com wrote:
>>
>> > In 2.5.1, at the end of the paragraph beginning
>> > "The first token", append the following sentence --
>> >
>> > "The number of bits that make up an unsized number
>> > (which is a simple decimal number or a number without
>> > the size specification) shall be at least 32."
>>
>> I personally do not like this rule. There is already a
>> statement somewhere where a compiler is not allowed to
>> truncate unsized integers to less then 32 bits, I think
>> this is plenty adequate and the above proposed addition
>> is adding an unnecessary restriction.
>
>
> I searched the LRM.
>
> You are apparently referring to the NOTE in 3.9 (which also should not be a NOTE in
> order to be normative):
> "Implementations may limit the maximum size of an integer variable, but they shall at
> least be 32 bits".
> (Gramatically, "it shall" would be better.)
>
> But that currently refers only to variables, not to integer constants.
> And if I am reading 2.5.1, I have not reached 3.9 yet.

Some real implementations (not mine!) of Verilog do truncate
unsized constant values to 32bits, especially if it is part
of a constant expression. I'm rattling my brain trying to find
the justification in the standard, but I believe it is there
(albeight obscure) because I clearly remember being surprised
when I stumbled on it.


>
>
>> Users are already assured that values that have up to
>> 32bits *will* be represented. There is no need to impose
>> the additional restriction that that size must be 32bits,
>> even for values that can be represented in 1 bit.
>>
>> In fact, I would counter-propose that the right to clip
>> values to 32bits be revoked. "4294967297 == 1" is rather
>> confusing, especially since it it not required to be true,
>> just allowed to be true.
>
>
> Besides what Steven Sharp wrote,
> that would simply break back-compatibility.

What backward compatibility? The value of the expression
"4294967297 == 1" is already defined to be implementation
specific. I wish I could find that murky corner of the LRM
that said so.

... Ah wait, I found it:

2.5.1 Integer constants
[all the way to the end...]
NOTES: 3) The number of bits that make up an unsized number
(which is a simple decimal number or a number without the
size specification) shall be at least 32.

Apparently, some compiler writers interpreted this to mean that
it needn't be larger then 32, so long as it is at least 32. Thus,
for those compilers "4294967297 == 1" --> 1, whereas compilers
that save more bits (mine for example) will evalulate that to 0.

--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."

From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, steve@icarus.com
Cc:
Subject: Re: errata/428: Re: errata/428: PROPOSAL - 2.5.1, value of 16'shc, request for clarification
Date: Thu, 30 Oct 2003 13:28:11 -0500 (EST)

> Apparently, some compiler writers interpreted this to mean that
> it needn't be larger then 32, so long as it is at least 32. Thus,
> for those compilers "4294967297 == 1" --> 1, whereas compilers
> that save more bits (mine for example) will evalulate that to 0.

My understanding of it is that the size is 32 bits, just as if you
had specified a sized constant like 32'b0. The "at least 32" is to
allow for machines where 32 is not the natural word size, and it is
more convenient for tools to use something larger (like for int in C).

There was no intent to have different sizes for different unsized
constant values, which would create a variety of problems. The standard
was documenting the behavior of Verilog-XL, which has a fixed size for
all unsized constants. That can be clarified, but I certainly don't
think it should be changed at this point. That could create backward
compatibility issues, as Shalom says.

Steven Sharp
sharp@cadence.com

From: Shalom.Bresticker@motorola.com
To: Stephen Williams <steve@icarus.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/428: PROPOSAL - 2.5.1, value of 16'shc, request for
clarification
Date: Thu, 30 Oct 2003 23:01:26 +0200 (IST)

Stephen,

See my comments inside.


On Thu, 30 Oct 2003, Stephen Williams wrote:

> Shalom Bresticker wrote:
> > Stephen Williams wrote:
> >
> >
> >> Brad.Pierce@synopsys.com wrote:
> >>
> >> > In 2.5.1, at the end of the paragraph beginning
> >> > "The first token", append the following sentence --
> >> >
> >> > "The number of bits that make up an unsized number
> >> > (which is a simple decimal number or a number without
> >> > the size specification) shall be at least 32."
> >>
> >> I personally do not like this rule. There is already a
> >> statement somewhere where a compiler is not allowed to
> >> truncate unsized integers to less then 32 bits, I think
> >> this is plenty adequate and the above proposed addition
> >> is adding an unnecessary restriction.
> >
> >
> > I searched the LRM.
> >
> > You are apparently referring to the NOTE in 3.9 (which also should not be a NOTE in
> > order to be normative):
> > "Implementations may limit the maximum size of an integer variable, but they shall at
> > least be 32 bits".
> > (Gramatically, "it shall" would be better.)
> >
> > But that currently refers only to variables, not to integer constants.
> > And if I am reading 2.5.1, I have not reached 3.9 yet.
>
> Some real implementations (not mine!) of Verilog do truncate
> unsized constant values to 32bits, especially if it is part
> of a constant expression. I'm rattling my brain trying to find
> the justification in the standard, but I believe it is there
> (albeight obscure) because I clearly remember being surprised
> when I stumbled on it.

I don't understand the problem. You had been earlier talking about
truncating to less than 32 bits, now you talk about 32 bits.
And actually we are not talking about truncation here, we are talking about
the number of bits in an integer type, meaning the largest number supported.
After all, no one expects all simulators to support the number
999999999999999999999999999999999999999999999999999999999999999999999999999999,
I hope.


> >> Users are already assured that values that have up to
> >> 32bits *will* be represented. There is no need to impose
> >> the additional restriction that that size must be 32bits,
> >> even for values that can be represented in 1 bit.
> >>
> >> In fact, I would counter-propose that the right to clip
> >> values to 32bits be revoked. "4294967297 == 1" is rather
> >> confusing, especially since it it not required to be true,
> >> just allowed to be true.
> >
> >
> > Besides what Steven Sharp wrote,
> > that would simply break back-compatibility.
>
> What backward compatibility? The value of the expression
> "4294967297 == 1" is already defined to be implementation
> specific. I wish I could find that murky corner of the LRM
> that said so.

Backward compatibility means, for example, that "0+a" is guaranteed
to be a 32-bit expression, at least.

For example, a common practice is to count the number of 1-bit variables
which are 1 by adding "0+" at the beginning.

If a,b,c are 1-bit variables, then "a+b+c" has a bit-length of 1, and if all
three are 1, then the result is 1'b1, whereas "0+a+b+c" will give me a
result of 3. That won't be true if I truncate the 0 to 1 bit.

> ... Ah wait, I found it:
>
> 2.5.1 Integer constants
> [all the way to the end...]
> NOTES: 3) The number of bits that make up an unsized number
> (which is a simple decimal number or a number without the
> size specification) shall be at least 32.

Well, of course!
That is exactly the statement that Brad is using, just moving it to
a different place in 2.5.1, and making it not a NOTE, because it was
intended to be normative. (In IEEE standards, NOTEs are not normative,
but 1364 used NOTEs without understanding that.)


> Apparently, some compiler writers interpreted this to mean that
> it needn't be larger then 32, so long as it is at least 32.

And that is correct, that is EXACTLY what it means.

> Thus,
> for those compilers "4294967297 == 1" --> 1, whereas compilers
> that save more bits (mine for example) will evalulate that to 0.

--
Shalom Bresticker Shalom.Bresticker@motorola.com
Design & Reuse Methodology Tel: +972 9 9522268
Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478

From: Stephen Williams <steve@icarus.com>
To: Shalom.Bresticker@motorola.com
Cc: etf-bugs@boyd.com
Subject: Re: errata/428: PROPOSAL - 2.5.1, value of 16'shc, request for clarification
Date: Thu, 30 Oct 2003 13:58:10 -0800

Shalom.Bresticker@motorola.com wrote:

> I don't understand the problem. You had been earlier talking about
> truncating to less than 32 bits, now you talk about 32 bits.
> And actually we are not talking about truncation here, we are talking about
> the number of bits in an integer type, meaning the largest number supported.
> After all, no one expects all simulators to support the number
> 999999999999999999999999999999999999999999999999999999999999999999999999999999,
> I hope.

Sure, why not:

wing % cat foo.vl

module test;
initial
$display("%d",
999999999999999999999999999999999999999999999999999999999999999999999999999999);

endmodule

wing % iverilog foo.vl
wing % vvp a.out

999999999999999999999999999999999999999999999999999999999999999999999999999999


And if you gave it an explicit size, (i.e. 256'd9) you would most
certainly expect the compiler to handle it. I would also expect
this to work always:

reg [32:0] x = 4294967297; // 'h1_00_00_00_01

I'm pointing out that an implementation *can* support arbitrarily
large unsized literals, even unsized constant expressions, without
dropping significant bits. All the compiler needs to do to make
that work is i.e. mark the constant subexpression as unsized while
it parses (and precalculates) subexpressions. The value need only
be given a size when it is assigned to a limited l-value, for
example.

Now when you are talking about the integer *variable*, that is
a *sized* thingy. All variables have fixed size. Different kettle
of fish.

Anyhow, I think this rant is getting long-winded, so I'd best crawl
back into my hole before I convince folks I'm a troll.
--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."

From: Michael McNamara <mac@verisity.com>
To: Steven Sharp <sharp@cadence.com>
Cc: etf-bugs@boyd.com
Subject: RE: errata/428: Re: errata/428: Re: errata/428: PROPOSAL - 2.5.1, value of 16'shc, request for clarification
Date: Fri, 31 Oct 2003 05:13:47 -0800

Indeed. In the original LRM (Verilog-XL 1.1) it stated:

The number of bits that make up an un-sized number (which is a
simple decimal number or a number without the [size specification])
is the host machine word size, so for most machines this will be 32
bits.

With IEEE-1364 we made it a requirement that if you were writing a
simulator for a machine who's native size was smaller than 32, you
would have to do extra work to support these unsized numbers as 32 bit
quantities. We had the expectation that this would impose little
practical burden on anyone.

-- On Oct 30 2003 at 10:30, Steven Sharp sent a message:
> To: etf-bugs@boyd.com
> Subject: "errata/428: Re: errata/428: Re: errata/428: PROPOSAL - 2.5.1, value of 16'shc, request for clarification"
> The following reply was made to PR errata/428; it has been noted by GNATS.
>
> From: Steven Sharp <sharp@cadence.com>
> To: etf-bugs@boyd.com, steve@icarus.com
> Cc:
> Subject: Re: errata/428: Re: errata/428: PROPOSAL - 2.5.1, value of 16'shc, request for clarification
> Date: Thu, 30 Oct 2003 13:28:11 -0500 (EST)
>
> > Apparently, some compiler writers interpreted this to mean that
> > it needn't be larger then 32, so long as it is at least 32. Thus,
> > for those compilers "4294967297 == 1" --> 1, whereas compilers
> > that save more bits (mine for example) will evalulate that to 0.
>
> My understanding of it is that the size is 32 bits, just as if you
> had specified a sized constant like 32'b0. The "at least 32" is to
> allow for machines where 32 is not the natural word size, and it is
> more convenient for tools to use something larger (like for int in C).
>
> There was no intent to have different sizes for different unsized
> constant values, which would create a variety of problems. The standard
> was documenting the behavior of Verilog-XL, which has a fixed size for
> all unsized constants. That can be clarified, but I certainly don't
> think it should be changed at this point. That could create backward
> compatibility issues, as Shalom says.
>
> Steven Sharp
> sharp@cadence.com
>
From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, steve@icarus.com
Cc:
Subject: Re: errata/428: Re: errata/428: PROPOSAL - 2.5.1, value of 16'shc, request for clarification
Date: Thu, 30 Oct 2003 17:43:37 -0500 (EST)

> I'm pointing out that an implementation *can* support arbitrarily
> large unsized literals, even unsized constant expressions, without
> dropping significant bits. All the compiler needs to do to make
> that work is i.e. mark the constant subexpression as unsized while
> it parses (and precalculates) subexpressions. The value need only
> be given a size when it is assigned to a limited l-value, for
> example.

Yes, the language could have been defined to work that way, and someone
could even interpret the LRM as defining it that way. I won't argue
with that.

But we are talking about how the language is actually defined, and
what the LRM was intended to define. The wording in the LRM may not
do the best job of describing the intent. Some changes have been
proposed to the wording. It seems that you were objecting to the
changes because they contradicted your misinterpretation of the
intent. That would indicate to me that they now do a better job of
describing the actual intent.

I don't think we want to change the intended language definition.
Do you see any further changes to the LRM text that would be needed
to make that intent clear?

Steven Sharp
sharp@cadence.com

From: Shalom.Bresticker@motorola.com
To: Stephen Williams <steve@icarus.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/428: PROPOSAL - 2.5.1, value of 16'shc, request for
clarification
Date: Sat, 1 Nov 2003 19:09:19 +0200 (IST)

> > After all, no one expects all simulators to support the number
> > 999999999999999999999999999999999999999999999999999999999999999999999999999999,
> > I hope.
>
> Sure, why not:
>
> wing % cat foo.vl
>
> module test;
> initial
> $display("%d",
> 999999999999999999999999999999999999999999999999999999999999999999999999999999);
>
> endmodule
>
> wing % iverilog foo.vl
> wing % vvp a.out
>
> 999999999999999999999999999999999999999999999999999999999999999999999999999999

Maybe you do, but VCS says:

Warning-[DCTL] Decimal constant too large
using -1 instead of the given
999999999999999999999999999999999999999999999999999999999999999999999999999999

and NC-Verilog says,

ncvlog: *W,INTOVF (test,4|77): bit overflow during conversion from text [2.5(IEEE)] (32 bits).

and Verilog-XL says,

arning! Number too large for this host
or Redundant digits given in number.
Number value used is -1
It is likely to be inaccurate. [Verilog-RDGN]
"test", 4:

Shalom


Fix replaced by Brad.Pierce@Synopsys.com on Sun Nov 2 21:54:57 2003
In 2.5.1, at the end of the first paragraph, append
the following sentence --

"It shall be legal to macro substitute these
three tokens."

In 2.5.1, REPLACE

"The first token, a size constant, shall specify
the size of the constant in terms of its exact
number of bits. It shall be specified as a
non-zero unsigned decimal number. For example,
the size specification for two hexadecimal
digits is 8, because one hexidecimal digit
requires 4 bits. Unsized unsigned constants
where the high order bit is unknown (X or x)
or three-state (Z or z) shall be extended to
the size of the expression containing the
constant.

WITH

"The first token, a size constant, shall specify
the size of the constant in terms of its exact
number of bits. It shall be specified as a
non-zero unsigned decimal number. For example,
the size specification for two hexadecimal
digits is 8, because one hexidecimal digit
requires 4 bits. The number of bits that
make up an unsized integer constant (which is
a simple decimal number or a based constant
without a size constant) shall be at least 32.
An unsized integer constant shall be extended to
the size of the expression that contains it by
padding to the left with the leftmost bit of the
constant, unless the constant is unsigned and its
leftmost bit is 1, in which case it shall be padded
to the left with zero. If a sized integer constant
is signed, it shall be sign-extended when assigned
to a reg data type, regardless of whether the reg
itself is signed."

In 2.5.1, REPLACE

"If the size of the unsigned number is smaller
than the size specified for the constant, the
unsigned number shall be padded to the left
with zeros. If the leftmost bit in the unsigned
number is an x or a z, then an x or a z shall
be used to pad to the left respectively."

WITH

"If a sized constant has an unsigned number
(i.e., third token) with a value that has
fewer bits than are specified by its size constant
(i.e., first token), the value of the unsigned
number shall be extended to the specified number
of bits by padding it to the left with zero (even
if the constant is signed), unless the leftmost bit
in the unsigned number is x or z, in which case
it shall be padded to the left with x or z
respectively."


In Example 4 of 2.5.1

REPLACE

reg[11:0] a, b, c, d;
initial begin
a = 'h x; // yields xxx
b = 'h 3x; // yields 03x
c = 'h z3; // yields zz3
d = 'h 0z3; // yields 0z3
end
reg [84:0] e, f, g;

e = 'h5; // yields {82{1'b0}, 3'b101}
f = 'hx; // yields {85{1'hx}}
g = 'hz; // yields {85{1'hz}}


WITH

reg[11:0] a, b, c, d;
initial begin
a = 'h x; // yields 12'h xxx
b = 'h 3x; // yields 12'h 03x
c = 'h z3; // yields 12'h zz3
d = 'h 0z3; // yields 12'h 0z3
end
reg [84:0] e, f, g, h, i;
reg signed [84:0] j, k;

e = 'h5; // yields {{82{1'b0}}, 3'b101}
f = 'hx; // yields {85{1'bx}}
g = 'hz; // yields {85{1'bz}}
h = 4'hx; // yields {{81{1'b0}}, 4'hx}
i = 16'ox; // yields {{69{1'b0}}, {16{1'bx}}}
j = 16'sb110; // yields {{82{1'b0}}, 3'b110}
k = 3'sb110; // yields {{82{1'b1}}, 3'b110}

and

REMOVE

NOTES:

1) Sized negative constant numbers and sized unsigned
constant numbers are sign-extended when assigned to a
reg data type, regardless of whether the reg itself is
signed or not.

2) Each of the three tokens for specifying a number
may be macro substituted.

3) The number of bits that make up an unsized number
(which is a simple decimal number or a number without
the size specification) shall be at least 32.



From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: Brad.Pierce@synopsys.com
Cc: etf-bugs@boyd.com
Subject: Re: errata/428: PROPOSAL - 2.5.1, value of 16'shc, request for
clarification
Date: Mon, 03 Nov 2003 12:12:26 +0200

Ouch, this is getting hard to follow, but :

Brad.Pierce@synopsys.com wrote:

> In 2.5.1, at the end of the first paragraph, append
> the following sentence --
>
> "It shall be legal to macro substitute these
> three tokens."

Should be "end of the second paragraph".


> In 2.5.1, REPLACE
>
> "The first token, a size constant, shall specify
> the size of the constant in terms of its exact
> number of bits. It shall be specified as a
> non-zero unsigned decimal number. For example,
> the size specification for two hexadecimal
> digits is 8, because one hexidecimal digit
> requires 4 bits. Unsized unsigned constants
> where the high order bit is unknown (X or x)
> or three-state (Z or z) shall be extended to
> the size of the expression containing the
> constant.
>
> WITH
>
> "The first token, a size constant, shall specify
> the size of the constant in terms of its exact
> number of bits. It shall be specified as a
> non-zero unsigned decimal number. For example,
> the size specification for two hexadecimal
> digits is 8, because one hexidecimal digit
> requires 4 bits. The number of bits that
> make up an unsized integer constant (which is
> a simple decimal number or a based constant
> without a size constant) shall be at least 32.
> An unsized integer constant shall be extended to
> the size of the expression that contains it by
> padding to the left with the leftmost bit of the
> constant, unless the constant is unsigned and its
> leftmost bit is 1, in which case it shall be padded
> to the left with zero. If a sized integer constant
> is signed, it shall be sign-extended when assigned
> to a reg data type, regardless of whether the reg
> itself is signed."

I propose to change the phrase "size constant" to "size specification" everywhere
in this section, to distinguish it more clearly from "sized constant" and in
general the term "constant", which in this section refers to the entire number,
including all its three tokens.

I don't like the second half of this, after "at least 32".
I don't think it belongs here, because this section of the text is briefly
describing the three tokens, and this is diverting the discussion elsewhere.
I also think it makes the paragraph too long.

Furthermore, I am not sure that the rule here "An unsized integer constant ..." is
always true, because there are operators which treat all their operands as unsigned
even if they are signed (e.g., bit-wise &). As far as I can tell, this is new text
from Brad. Also the wording is awkward.

Two more comments below, after the examples:


> In 2.5.1, REPLACE
>
> "If the size of the unsigned number is smaller
> than the size specified for the constant, the
> unsigned number shall be padded to the left
> with zeros. If the leftmost bit in the unsigned
> number is an x or a z, then an x or a z shall
> be used to pad to the left respectively."
>
> WITH
>
> "If a sized constant has an unsigned number
> (i.e., third token) with a value that has
> fewer bits than are specified by its size constant
> (i.e., first token), the value of the unsigned
> number shall be extended to the specified number
> of bits by padding it to the left with zero (even
> if the constant is signed), unless the leftmost bit
> in the unsigned number is x or z, in which case
> it shall be padded to the left with x or z
> respectively."
>
>
> In Example 4 of 2.5.1
>
> REPLACE
>
> reg[11:0] a, b, c, d;
> initial begin
> a = 'h x; // yields xxx
> b = 'h 3x; // yields 03x
> c = 'h z3; // yields zz3
> d = 'h 0z3; // yields 0z3
> end
> reg [84:0] e, f, g;
>
> e = 'h5; // yields {82{1'b0}, 3'b101}
> f = 'hx; // yields {85{1'hx}}
> g = 'hz; // yields {85{1'hz}}
>
> WITH
>
> reg[11:0] a, b, c, d;
> initial begin
> a = 'h x; // yields 12'h xxx
> b = 'h 3x; // yields 12'h 03x
> c = 'h z3; // yields 12'h zz3
> d = 'h 0z3; // yields 12'h 0z3
> end
> reg [84:0] e, f, g, h, i;
> reg signed [84:0] j, k;
>
> e = 'h5; // yields {{82{1'b0}}, 3'b101}
> f = 'hx; // yields {85{1'bx}}
> g = 'hz; // yields {85{1'bz}}
> h = 4'hx; // yields {{81{1'b0}}, 4'hx}
> i = 16'ox; // yields {{69{1'b0}}, {16{1'bx}}}
> j = 16'sb110; // yields {{82{1'b0}}, 3'b110}
> k = 3'sb110; // yields {{82{1'b1}}, 3'b110}

I propose to write j as:

j = 16'sb110 // yields {{69{1'b0}, {13{1'b0}, 3'b110}}

However, now I have a new concern, that we are in 2.5.1, before the concatenation
and replication operators have even been introduced.


> and
>
> REMOVE
>
> NOTES:
>
> 1) Sized negative constant numbers and sized unsigned
> constant numbers are sign-extended when assigned to a
> reg data type, regardless of whether the reg itself is
> signed or not.
>
> 2) Each of the three tokens for specifying a number
> may be macro substituted.
>
> 3) The number of bits that make up an unsized number
> (which is a simple decimal number or a number without
> the size specification) shall be at least 32.
>
> http://boydtechinc.com/cgi-bin/issueproposal.pl?cmd=view&database=default&pr=428

--
Shalom Bresticker Shalom.Bresticker@motorola.com
Design & Reuse Methodology Tel: +972 9 9522268
Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478




Fix replaced by Shalom.Bresticker@freescale.com on Mon Nov 29 04:53:16 2004

2004-11-29: This is based on Brad's last proposal. Shalom


In 2.5.1:

1. In para. 2, CHANGE

"an optional size constant"

TO

"an optional size specification"


2. At the end of the second paragraph, append
the following sentence --

"It shall be legal to macro substitute these
three tokens."


3. REPLACE

"The first token, a size constant, shall specify
the size of the constant in terms of its exact
number of bits.

WITH

"The first token, a size specification, shall specify
the size of the constant in terms of its exact
number of bits."


4. In para. 7, CHANGE

"Simple decimal numbers without the size and the base format"

TO

"Simple decimal numbers without the size specification and the base format"


5. CHANGE

"A plus or minus operator preceding the size constant is a unary plus or minus operator."

TO

"A plus or minus operator preceding the size specification is a unary plus or minus operator."


6. REPLACE

"If the size of the unsigned number is smaller
than the size specified for the constant, the
unsigned number shall be padded to the left
with zeros. If the leftmost bit in the unsigned
number is an x or a z, then an x or a z shall
be used to pad to the left respectively."

WITH

"If a sized constant has an unsigned number
(i.e., third token) with a value that has
fewer bits than are specified by its size specification
(i.e., first token), the value of the unsigned
number shall be extended to the specified number
of bits by padding it to the left with zero (even
if the constant is signed), unless the leftmost bit
in the unsigned number is x or z, in which case
it shall be padded to the left with x or z
respectively."


7. REPLACE

"Unsized unsigned constants where the high order bit is
unknown (X or x) or three-state (Z or z) shall be extended
to the size of the expression containing the constant."

WITH

"The number of bits that
make up an unsized integer constant (which is
a simple decimal number or a based constant
without a size specification) shall be at least 32.
An unsized integer constant shall be extended to
the size of the expression that contains it by
padding to the left with the leftmost bit of the
constant, unless the constant is unsigned and its
leftmost bit is 1, in which case it shall be padded
to the left with zero.

A sized signed integer constant shall be sign-extended
when assigned to a reg data type, regardless of
whether the reg itself is signed."


8. In Example 4

REPLACE

reg[11:0] a, b, c, d;
initial begin
a = 'h x; // yields xxx
b = 'h 3x; // yields 03x
c = 'h z3; // yields zz3
d = 'h 0z3; // yields 0z3
end
reg [84:0] e, f, g;

e = 'h5; // yields {82{1'b0}, 3'b101}
f = 'hx; // yields {85{1'hx}}
g = 'hz; // yields {85{1'hz}}


WITH

reg[11:0] a, b, c, d;
initial begin
a = 'h x; // yields 12'h xxx
b = 'h 3x; // yields 12'h 03x
c = 'h z3; // yields 12'h zz3
d = 'h 0z3; // yields 12'h 0z3
end
reg [31:0] e, f, g, h, i;
reg signed [31:0] j, k;

e = 'h5; // yields 32'h0000_0005
f = 'hx; // yields 32'hxxxx_xxxx
g = 'hz; // yields 32'hzzzz_zzzz
h = 4'hx; // yields 32'h0000_000x
i = 16'ox; // yields 32'h0000_xxxx
j = 16'sb110; // yields 32'h0000_0006
k = 3'sb110; // yields 32'hffff_fffe


8. REMOVE

"NOTES:

1) Sized negative constant numbers and sized unsigned
constant numbers are sign-extended when assigned to a
reg data type, regardless of whether the reg itself is
signed or not.

2) Each of the three tokens for specifying a number
may be macro substituted.

3) The number of bits that make up an unsized number
(which is a simple decimal number or a number without
the size specification) shall be at least 32."



Fix replaced by Shalom.Bresticker@freescale.com on Mon Nov 29 10:29:36 2004
2004-11-29: This includes changes discussed in ETF meeting
today. However, the ETF did not vote to approve it, due to
lack of time.


In 2.5.1:

1. In para. 2, CHANGE

"an optional size constant"

TO

"an optional size specification"


2. At the end of the second paragraph, append
the following sentence --

"It shall be legal to macro substitute these
three tokens."


3. REPLACE

"The first token, a size constant, shall specify
the size of the constant in terms of its exact
number of bits.

WITH

"The first token, a size specification, shall specify
the size of the constant in terms of its exact
number of bits."


4. In para. 7, CHANGE

"Simple decimal numbers without the size and the base format"

TO

"Simple decimal numbers without the size specification and the base format"


5. CHANGE

"A plus or minus operator preceding the size constant is a unary plus or minus operator."

TO

"A plus or minus operator preceding the size specification is a unary plus or minus operator."


6. REPLACE

"If the size of the unsigned number is smaller
than the size specified for the constant, the
unsigned number shall be padded to the left
with zeros. If the leftmost bit in the unsigned
number is an x or a z, then an x or a z shall
be used to pad to the left respectively."

WITH

"If a sized constant has an unsigned number
(i.e., third token) with a value that has
fewer bits than are specified by its size specification
(i.e., first token), the value of the unsigned
number shall be extended to the specified number
of bits by padding it to the left with zero (even
if the constant is signed), unless the leftmost bit
in the unsigned number is x or z, in which case
it shall be padded to the left with x or z
respectively."


7. REPLACE

"Unsized unsigned constants where the high order bit is
unknown (X or x) or three-state (Z or z) shall be extended
to the size of the expression containing the constant."

WITH

"The number of bits that
make up an unsized integer constant (which is
a simple decimal number or a based constant
without a size specification) shall be at least 32.
Unsized unsigned constants where the high order bit is
unknown (X or x) or three-state (Z or z) shall be extended
to the size of the expression containing the constant."


8. In Example 4

REPLACE

reg[11:0] a, b, c, d;
initial begin
a = 'h x; // yields xxx
b = 'h 3x; // yields 03x
c = 'h z3; // yields zz3
d = 'h 0z3; // yields 0z3
end
reg [84:0] e, f, g;

e = 'h5; // yields {82{1'b0}, 3'b101}
f = 'hx; // yields {85{1'hx}}
g = 'hz; // yields {85{1'hz}}


WITH

reg[11:0] a, b, c, d;
initial begin
a = 'h x; // a gets 12'h xxx
b = 'h 3x; // b gets 12'h 03x
c = 'h z3; // c gets 12'h zz3
d = 'h 0z3; // d gets 12'h 0z3
end
reg [31:0] e, f, g, h, i;
reg signed [31:0] j, k;

e = 'h5; // e gets 32'h0000_0005
f = 'hx; // f gets 32'hxxxx_xxxx
g = 'hz; // g gets 32'hzzzz_zzzz
h = 4'hx; // h gets 32'h0000_000x
i = 16'ox; // i gets 32'h0000_xxxx
j = 16'sb110; // j gets 32'h0000_0006
k = 3'sb110; // k gets 32'hffff_fffe


8. REMOVE NOTES 2 and 3.



Unformatted



Hosted by Boyd Technology