expression bit lengths in gate primitive terminals

[Mike]

Hi,

The verilog spec says that for the gate primitives (buf, not, and,
nand, or, nor, xor, xnor)
implicit scalar wires (or default nettype) are declared. This seems
to imply that
the terminals to gate primitives are only 1-bit wide. What does this
mean for input
terminal expressions that more the 1-bit wide? Is the gate terminal
simply bit[0] of the
expression or is the expression tested for zero to yield a 1-bit
result?

Thanks in advance,
Mike

 

On Nov 12, 3:49 pm, Mike <hammero...@yahoo.com> wrote:

This seems to imply that
the terminals to gate primitives are only 1-bit wide.

Yes.

What does this mean for input
terminal expressions that more the 1-bit wide? Is the gate terminal
simply bit[0] of the
expression or is the expression tested for zero to yield a 1-bit
result?

As you noted, the LRM does not address this. In such cases, for
behavior that was in Verilog-1995, the behavior of the original
implementation in Verilog-XL is usually accepted as the de facto
standard. In this case, Verilog-XL tests the expression for zero.
This is equivalent to performing a reduction-0R on the vector value
and using the result.

This is not what it does for the similar case of a vector attached
to a scalar port of a module. In that case, it uses bit[0]. In
that case, the LRM is also clearer.

 

[Mike]

On Nov 12, 4:32 pm, sh...@cadence.com wrote:

On Nov 12, 3:49 pm, Mike <hammero...@yahoo.com> wrote:

This seems to imply that
the terminals to gate primitives are only 1-bit wide.

Yes.

What does this mean for input
terminal expressions that more the 1-bit wide? Is the gate terminal
simply bit[0] of the
expression or is the expression tested for zero to yield a 1-bit
result?

As you noted, the LRM does not address this. In such cases, for
behavior that was in Verilog-1995, the behavior of the original
implementation in Verilog-XL is usually accepted as the de facto
standard. In this case, Verilog-XL tests the expression for zero.
This is equivalent to performing a reduction-0R on the vector value
and using the result.

This is not what it does for the similar case of a vector attached
to a scalar port of a module. In that case, it uses bit[0]. In
that case, the LRM is also clearer.

OK. Then is it the same when we have continuous assigns instead of
gates?

If the LHS lvalue is 1 bit wide and the RHS expression is a vector,
then the lvalue
gets bit[0] of the RHS expression? and if the RHS is an expression,
then the
lvalue gets the reduction OR of the RHS expression?

 

[Mike]

On Nov 12, 4:32 pm, sh...@cadence.com wrote:

On Nov 12, 3:49 pm, Mike <hammero...@yahoo.com> wrote:

This seems to imply that
the terminals to gate primitives are only 1-bit wide.

Yes.

What does this mean for input
terminal expressions that more the 1-bit wide? Is the gate terminal
simply bit[0] of the
expression or is the expression tested for zero to yield a 1-bit
result?

As you noted, the LRM does not address this. In such cases, for
behavior that was in Verilog-1995, the behavior of the original
implementation in Verilog-XL is usually accepted as the de facto
standard. In this case, Verilog-XL tests the expression for zero.
This is equivalent to performing a reduction-0R on the vector value
and using the result.

This is not what it does for the similar case of a vector attached
to a scalar port of a module. In that case, it uses bit[0]. In
that case, the LRM is also clearer.

It looks like verilog XL does handle expressions differently:

<code snippet>
buf (c0, 2'h0);
buf (c1, 2'h1);
buf (c2, 2'h2);
buf (c3, 2'h3);

buf (d0, 2'h0 + 2'h0);
buf (d1, 2'h0 + 2'h1);
buf (d2, 2'h0 + 2'h2);
buf (d3, 2'h0 + 2'h3);

$display("%b, %b, %b, %b", c0, c1, c2, c3);
$display("%b, %b, %b, %b", d0, d1, d2, d3);

gives this result in my verilog XL simulator at work:
0, 1, 0, 1
0, 1, 1, 1

 

On Nov 13, 11:41 am, Mike <hammero...@yahoo.com> wrote:

OK. Then is it the same when we have continuous assigns instead of
gates?

No.

If the LHS lvalue is 1 bit wide and the RHS expression is a vector,
then the lvalue
gets bit[0] of the RHS expression? and if the RHS is an expression,
then the
lvalue gets the reduction OR of the RHS expression?

The lvalue gets bit[0]. This is the general rule for assignments in
Verilog. If the LHS is 2 bits wide and the RHS is 3 bits wide, the
LHS will get bit[1:0]. And if the RHS is 2 bits wide, the LHS will
get bit[1:0], i.e. the full value. There is no way to generalize the
reduction-OR treatment to multiple bits, so it is not surprising that
it is not used there. And since module port connections are defined
to be equivalent to continuous assignments, they work the same way as
continuous assignments.

This reduction-OR treatment is applied in a number of places in
Verilog-XL. All of them involve things that inherently need a single
bit value. One of them is the use of a multi-bit value as the
condition in an if-statement. Another is when posedge/negedge is
applied to a multi-bit value (though this was not understood when the
first IEEE standard was being written, so the standard says that
bit[0] is used instead).

Applying it to gate terminals is rather strange, since you would
expect them to act more like 1-bit module ports instead. Personally,
I would avoid doing this in designs, given that the behavior is odd
and not defined in the standard.

 

On Nov 13, 11:46 am, Mike <hammero...@yahoo.com> wrote:

It looks like verilog XL does handle expressions differently:

0, 1, 0, 1
0, 1, 1, 1

That is unexpected. Some experimentation shows that it is not
expressions that are treated differently. Instead, it is literal
constants that are treated differently. If you replace the literal
constant 2'h2 in your (c2, 2'h2) with a parameter that has the same
constant value, it will produce a 1 output. Perhaps there was an
optimization put in for literal constants that did not perform the
usual reduction-OR.