Bhasker's HDL Synthesis question

[Roosta]

Anyone know why you have to use IntA and IntB in this example (found
in Bhasker's book)

module NotEquals (A, B, Z)
input [0:3] A, B;
output Z;
reg Z;

always @ (A or B)
begin: DF_LABEL
integer IntA, IntB

IntA = A; <--- why is this a necessary step
IntB = B;
Z = IntA != IntB;
end
endmodule

Im interested in why you could not have omitted the whole integer
assignment, unless you have to explicity use the integer module
declaration to compare signed numbers. If so, then to compare
unsigned numbers, I guess you could omit it...

Thanks in advance.

 

[Jason Zheng]

I'm not sure whether it's the intended effect. But assigning a wire to
an integer asks the simulator to perform an implicit conversion. While
most of the time converting from a 4-bit wire to an integer is boring,
things gets interesting when the 4-bit wire contains x or z.

Both Verilog 1995 and 2001 defines that when wire or reg type is
assigned to real types, x or z gets treated as 0's. No such definition
applies to net/reg -> integer conversion.

So IMO this is really a gray area of the language. The compiler could
convert them in the same fashion as converting to real, or another
possible outcome is a runtime warning.

On Wed, 9 Jul 2008 15:07:23 -0700 (PDT) Roosta <opehund@gmail.com>
wrote:

Anyone know why you have to use IntA and IntB in this example (found
in Bhasker's book)

module NotEquals (A, B, Z)
input [0:3] A, B;
output Z;
reg Z;

always @ (A or B)
begin: DF_LABEL
integer IntA, IntB

IntA = A; <--- why is this a necessary step
IntB = B;
Z = IntA != IntB;
end
endmodule

Im interested in why you could not have omitted the whole integer
assignment, unless you have to explicity use the integer module
declaration to compare signed numbers. If so, then to compare
unsigned numbers, I guess you could omit it...

Thanks in advance.

--
I'm not afraid of death -- I just don't want to be there when it
happens. -- Woody Allen

 

[Mike Treseler]

Roosta wrote:

Im interested in why you could not have omitted the whole integer
assignment, unless you have to explicity use the integer module
declaration to compare signed numbers. If so, then to compare
unsigned numbers, I guess you could omit it...

Try values of -1 and 15 both ways.

-- Mike Treseler

 

[Muzaffer Kal]

On Wed, 9 Jul 2008 15:07:23 -0700 (PDT), Roosta <opehund@gmail.com>
wrote:

Anyone know why you have to use IntA and IntB in this example (found
in Bhasker's book)

module NotEquals (A, B, Z)
input [0:3] A, B;
output Z;
reg Z;

always @ (A or B)
begin: DF_LABEL
integer IntA, IntB

IntA = A; <--- why is this a necessary step
IntB = B;
Z = IntA != IntB;
end
endmodule

Im interested in why you could not have omitted the whole integer
assignment, unless you have to explicity use the integer module
declaration to compare signed numbers. If so, then to compare
unsigned numbers, I guess you could omit it...

Thanks in advance.

To me it's completely redundant. In Verilog '95 or '01 bit vectors are
treated as 2's complement numbers so equality is accomplished by bit
by bit comparison independent of signedness. The only case two 4 bit
numbers would be equal if their bit patterns identically didn't match
is if one uses 1's complement and the code above is definitely not
adequate for that purpose anyway.
Unless X or Z is treated differently when cast to integer a simple
!(A==B) would suffice.
In the standard section 3.2.2 says integers get initialized to X
(unlike reals) so if A or B have any X in them it should be possible
to assign them to an integer identically. Also section 2.5.1 claims
that one can use X & Z in integer constants which suggests to me that
a reg to integer assignment might survive embedded X & Z terms too.
So I really don't think there is any need for the integer conversion
in here.

 

[Jonathan Bromley]

On Wed, 9 Jul 2008 16:54:22 -0700, Jason Zheng
<Xin.Zheng@jpl.nasa.gov> wrote:

I'm not sure whether it's the intended effect. But assigning a wire to
an integer asks the simulator to perform an implicit conversion. While
most of the time converting from a 4-bit wire to an integer is boring,
things gets interesting when the 4-bit wire contains x or z.

Both Verilog 1995 and 2001 defines that when wire or reg type is
assigned to real types, x or z gets treated as 0's. No such definition
applies to net/reg -> integer conversion.

I disagree. Verilog 'integer' is a 4-state data type and can
contain x/z bits. In almost every respect it behaves the same
as "reg signed [31:0]".
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Jonathan Bromley]

On Wed, 09 Jul 2008 17:28:32 -0700, Mike Treseler
<mike_treseler@comcast.net> wrote:

Roosta wrote:

Im interested in why you could not have omitted the whole integer
assignment, unless you have to explicity use the integer module
declaration to compare signed numbers. If so, then to compare
unsigned numbers, I guess you could omit it...

Try values of -1 and 15 both ways.

Look on my works, ye mighty, and despair.....

Copying a 4-bit wire or reg to an integer will zero-extend,
NOT sign-extend. Sign-extension on copy is controlled by
the signedness of the right-hand-side expression, and is
unaffected by the signedness of the left-hand-side target.
Had the two inputs been declared as "input signed [3:0]",
then the copies to integers IntA, IntB would sign-extend.

In summary, there is no meaningful way to apply the
value "-1" to an input of that design. It just looks
like 15, whatever you do with copying to integers.

I suspect that Bhasker's intent for the example was to
illustrate the use of local variables in a named
begin...end block, and to show why they don't need to
appear in the enclosing always block's sensitivity list;
but I don't know his book very well, so I can't be sure.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Jason Zheng]

On Thu, 10 Jul 2008 08:31:18 +0100
Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote:

On Wed, 9 Jul 2008 16:54:22 -0700, Jason Zheng
Xin.Zheng@jpl.nasa.gov> wrote:

I'm not sure whether it's the intended effect. But assigning a wire
to an integer asks the simulator to perform an implicit conversion.
While most of the time converting from a 4-bit wire to an integer is
boring, things gets interesting when the 4-bit wire contains x or z.

Both Verilog 1995 and 2001 defines that when wire or reg type is
assigned to real types, x or z gets treated as 0's. No such
definition applies to net/reg -> integer conversion.

I disagree. Verilog 'integer' is a 4-state data type and can
contain x/z bits. In almost every respect it behaves the same
as "reg signed [31:0]".

You are right Jonathan. My mistake for thinking integer is 2-state. But
you said "in almost every respect it behaves the same," are there cases
they behave differently?

--
I'm not afraid of death -- I just don't want to be there when it
happens. -- Woody Allen

 

[Jonathan Bromley]

On Thu, 10 Jul 2008 08:18:16 -0700 (PDT), Roosta wrote:

[me]

Verilog 'integer' is a 4-state data type and can
contain x/z bits.  In almost every respect it behaves the same
as "reg signed [31:0]".

[Jason]

You are right Jonathan. My mistake for thinking integer is 2-state. But
you said "in almost every respect it behaves the same," are there cases
they behave differently?

As far as I know, the only difference in standard Verilog is
that integer is guaranteed to be AT LEAST 32 bits, rather than
exactly 32 bits; that's (one reason) why you are not allowed
to put integers in a concatenation. There are some weird
subtleties in SystemVerilog: you are not permitted to make
packed arrays of built-in vector types such as integer or byte.

[Roosta]

Here is what Bhasker said in his book from above this snippet of
code.. I don't think the idea here is to just show local variables.

"Note that in this case, the operands of the equality operator are of
integer type because values of this type represent signed numbers."

Oh.

It is indeed true that integer is a signed type.

It is also true that, as I said, copying an unsigned thing
that's narrower than 32 bits into an integer will always
yield a positive value, because it will be zero-extended
to 32 bits. So, as you originally suspected, the copy
is harmless but futile.

Welcome to the head-messing world of arithmetic
bit-width and signedness in Verilog.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Roosta]

On Jul 10, 9:34 am, Jason Zheng <Xin.Zh...@jpl.nasa.gov> wrote:

On Thu, 10 Jul 2008 08:31:18 +0100





Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote:
On Wed, 9 Jul 2008 16:54:22 -0700, Jason Zheng
Xin.Zh...@jpl.nasa.gov> wrote:

I'm not sure whether it's the intended effect. But assigning a wire
to an integer asks the simulator to perform an implicit conversion.
While most of the time converting from a 4-bit wire to an integer is
boring, things gets interesting when the 4-bit wire contains x or z.

Both Verilog 1995 and 2001 defines that when wire or reg type is
assigned to real types, x or z gets treated as 0's. No such
definition applies to net/reg -> integer conversion.

I disagree.  Verilog 'integer' is a 4-state data type and can
contain x/z bits.  In almost every respect it behaves the same
as "reg signed [31:0]".

You are right Jonathan. My mistake for thinking integer is 2-state. But
you said "in almost every respect it behaves the same," are there cases
they behave differently?

--
I'm not afraid of death -- I just don't want to be there when it
happens. -- Woody Allen- Hide quoted text -

- Show quoted text -

Here is what Bhasker said in his book from above this snippet of
code.. I don't think the idea here is to just show local variables.

"Note that in this case, the operands of the equality operator are of
integer type because values of this type represent signed numbers."