Stange syntax - what does this mean ?

[Daku]

Could some Verilog guru please help ? I have some inherited code with
statements as:
count <= count + 'd1;
What does 'd1 mean ?
Also I am assuming that 'b00 actually means 2'b00 - am I wrong ??
Thanks in advance for your help.

 

[Jonathan Bromley]

On Jul 16, 2:23 pm, Daku <dakup...@gmail.com> wrote:

Could some Verilog guru please help ? I have some inherited code with
statements as:
count <= count + 'd1;
What does 'd1 mean ?

It's an "unsized" numeric literal. That gives it the same
bit-width as "integer", which is guaranteed to be at least
32 bits but is not defined by the language standard. In
practice it's 32 bits in all mainstream tools.

Also I am assuming that 'b00 actually means 2'b00 - am I wrong ??

No; again it's "unsized", or 32 bits in practice.

Note that you cannot use unsized literals in a concatenation:

{2'b00, 3'b111} // OK, 5 bits result
{'b00, 3'b111} // error, unsized is illegal in concat
{ 0, 3'b111} // error, simple decimal number is also unsized

HTH
--
Jonathan Bromley

 

[Cary R.]

Jonathan Bromley wrote:

On Jul 16, 2:23 pm, Daku <dakup...@gmail.com> wrote:
Could some Verilog guru please help ? I have some inherited code with
statements as:
count <= count + 'd1;
What does 'd1 mean ?

It's an "unsized" numeric literal. That gives it the same
bit-width as "integer", which is guaranteed to be at least
32 bits but is not defined by the language standard. In
practice it's 32 bits in all mainstream tools.

FYI there is no mention of "integer". The wording is "shall be at least
32 bits" (which is the same as the integer wording). This looks clear,
but some simulators interpret this differently. Specifically, some
simulators make an unsized constant always the same width as the integer
width (normally 32 bits). This results in an unsized constant with say
64 effective bits only using the lower 32 (usually with a warning).
Other simulators assume the at least part is dynamic and make the
constant 64 bits for this case and 32 bit for constants with 32 or fewer
effective digits. As expected this difference can produce different
simulation results.

I personally think the dynamically sized constant makes more sense,
since if I specify more digits it's because I want them used. Forcing me
to size the constant when I want more than 32 bits seems wrong. If they
wanted the fixed size they should have specified that unsized constant
have the same width as an integer, but that's not what the standard
says. Which to me implies the size should be dynamic depending on the
bits but always at least 32 bits.

Regards,

Cary

 

[Jonathan Bromley]

[Daku]

What does 'd1 mean ?

[me]

It's an "unsized" numeric literal. That gives it the same
bit-width as "integer", which is guaranteed to be at least
32 bits but is not defined by the language standard. In
practice it's 32 bits in all mainstream tools.

[Cary R.]

FYI there is no mention of "integer".

That is true, indeed. However, I was more wrong than that,
because I was still in Verilog-95 dinosaur mode - sorry.

The wording is "shall be at least
32 bits" (which is the same as the integer wording). This looks clear,
but some simulators interpret this differently. Specifically, some
simulators make an unsized constant always the same width as the integer
width (normally 32 bits). This results in an unsized constant with say
64 effective bits only using the lower 32 (usually with a warning).
Other simulators assume the at least part is dynamic and make the
constant 64 bits for this case and 32 bit for constants with 32 or fewer
effective digits. As expected this difference can produce different
simulation results.

When you say "unsized constant with 64 effective bits", do you
mean something like this?
'hFEDCBA9876543210

If so, yes, I agree with your analysis, and as far as I can
tell the standard doesn't say what should happen. Another
example below.

Verilog-2001 changed the rules about this. I don't have
IEEE Std.1364-2001 handy, but the corresponding wording in
IEEE Std.1800-2009 (which is what counts now!) is...

The number of bits that make up an unsized number (which is a
simple decimal number or a number with a base specifier but
no size specification) shall be at least 32. Unsized unsigned
literal 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 literal constant.

NOTE—In IEEE Std 1364-1995, in unsized literal constants
where the high-order bit is unknown or three-state, the
x or z was only extended to 32 bits.

So we can see that unsized constants that don't have a
leading X or Z get sign- or zero-extended to fit the context.

That still leaves one wrinkle (same as Cary R. mentioned?)
that I'm not sure about. What happens if you supply more
digits than the simulator-specific size can accommodate?
Assuming a simulator that thinks 'h is 32 bits wide:

reg [39:0] R40;
R40 = 'hx; // gives R40 = 40'hxxxxxxxxxx in Verilog >= 2001
// but gave R40 = 40'h00xxxxxxxx in Verilog 1995
R40 = 'h76543210; // gives R40 = 40'h0076543210, no problem
R40 = 'h9876543210; // ??? problem here

The problem is: if the simulator thinks 'h... is 32 bits
wide, then it sees more digits than will fit into 32 bits
and will... throw a warning? truncate the literal? or
magically widen its understanding of 'h to suit? ???
--
Jonathan Bromley

 

[Cary R.]

Jonathan Bromley wrote:

What does 'd1 mean ?

[me]
It's an "unsized" numeric literal. That gives it the same
bit-width as "integer", which is guaranteed to be at least
32 bits but is not defined by the language standard. In
practice it's 32 bits in all mainstream tools.

[Cary R.]
FYI there is no mention of "integer".

That is true, indeed. However, I was more wrong than that,
because I was still in Verilog-95 dinosaur mode - sorry.

The wording is "shall be at least
32 bits" (which is the same as the integer wording). This looks clear,
but some simulators interpret this differently. Specifically, some
simulators make an unsized constant always the same width as the integer
width (normally 32 bits). This results in an unsized constant with say
64 effective bits only using the lower 32 (usually with a warning).
Other simulators assume the at least part is dynamic and make the
constant 64 bits for this case and 32 bit for constants with 32 or fewer
effective digits. As expected this difference can produce different
simulation results.

When you say "unsized constant with 64 effective bits", do you
mean something like this?
'hFEDCBA9876543210

Yes.

If so, yes, I agree with your analysis, and as far as I can
tell the standard doesn't say what should happen. Another
example below.

Verilog-2001 changed the rules about this. I don't have
IEEE Std.1364-2001 handy, but the corresponding wording in
IEEE Std.1800-2009 (which is what counts now!) is...

The number of bits that make up an unsized number (which is a
simple decimal number or a number with a base specifier but
no size specification) shall be at least 32. Unsized unsigned
literal 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 literal constant.

NOTE—In IEEE Std 1364-1995, in unsized literal constants
where the high-order bit is unknown or three-state, the
x or z was only extended to 32 bits.

So we can see that unsized constants that don't have a
leading X or Z get sign- or zero-extended to fit the context.

That still leaves one wrinkle (same as Cary R. mentioned?)
that I'm not sure about. What happens if you supply more
digits than the simulator-specific size can accommodate?
Assuming a simulator that thinks 'h is 32 bits wide:

reg [39:0] R40;
R40 = 'hx; // gives R40 = 40'hxxxxxxxxxx in Verilog >= 2001
// but gave R40 = 40'h00xxxxxxxx in Verilog 1995
R40 = 'h76543210; // gives R40 = 40'h0076543210, no problem
R40 = 'h9876543210; // ??? problem here

The problem is: if the simulator thinks 'h... is 32 bits
wide, then it sees more digits than will fit into 32 bits
and will... throw a warning? truncate the literal? or
magically widen its understanding of 'h to suit? ???

I have only seen two behaviors, truncate with a warning and extend as
needed. Given the at least 32 bits wording I believe extending is the
more correct behavior.

Don't forget the special 'dx/dz constructs and is a plain decimal number
restricted to a certain size. I like to use something like the following
to catch the simulation if communication gets out of sync/is dead locked.

initial begin
#10_000_000_000;
$display("Caught by trap");
$finish;
end

Again some simulators don't allow this because the delay is larger than
32 bits. It's trivial to emulate using repeat(10) #1_000_000_000;, but
why should any number be limited to a certain fixed number of bit? I
think we both agree it should only be limited by what it is assigned to
or the context it is used in (e.g. I'd be fine with a warning if I gave
a delay larger than 64 bits, but that's an extreme corner case).

Cary