multi-bit signal in sensitivity list with partial use

[Dipu]

HI,

We have a 8 bit signal in1[7:0]. We are using only 2 LSB bits in side
a combinatorial always process. Is it ok to use the complete bus in
the sensitivity list? Can there be any problem during simulation? We
are not able to come up with an error case. If anyone out there has
experience with this, we would like to hear from them.

For example,

wire [7:0] in1;
....
...

always @ ( in1, ..<other signals>...) begin
out1 = in1[1:0] + <other signals>;
end

vs

always @ ( in1[1:0], ..<other signals>...) begin
out1 = in1[1:0] + <other signals>;
end


The add function is just an example. We have a complex MUX logic here
which makes it impractical to with a "?:" procedural statement.

Thanks.

-Dipu

 

[Jon Beniston]

. We are using only 2 LSB bits in side
a combinatorial always process. Is it ok to use the complete bus in
the sensitivity list?

It depends. For sythesizable stuff, you should be fine, although DC
will probably give you a warning. However, you can never win because
other tools will give you a warning if you don't use the full signal.

Can there be any problem during simulation? We
are not able to come up with an error case.

Here's an example, but this is just muppet coding:

always @(in1)
$display(in[1:0]);

always @(in1[1:0])
$display(in[1:0]);

Depending on which code is used, $display could be called a different
number of times.

Cheers,
Jon

 

[Steven Sharp]

dipumisc@hotmail.com (Dipu) wrote in message news:<d074680d.0411111032.154f1189@posting.google.com>...

jon@beniston.com (Jon Beniston) wrote in message news:<e87b9ce8.0411110322.3660925a@posting.google.com>...

Depending on which code is used, $display could be called a different
number of times.


I can you see your point here. But can there be any functional problem
or even a difference between an RTL simulation and a gate simulation?

There should not be. If the always block is truly combinational, it
should not matter if it gets re-evaluated extra times when its inputs
have not changed. It will just keep setting the result to the same
value again, which has no effect. It is only an issue of simulation
efficiency.

If the always block is not truly combinational then you could see
functional differences. For example, the $display issue that was
mentioned, or a counter that counts how many times the block was
executed. Or if the result is also assigned in another procedural
block (which would not be synthesizable).

 

[Dipu]

jon@beniston.com (Jon Beniston) wrote in message news:<e87b9ce8.0411110322.3660925a@posting.google.com>...

. We are using only 2 LSB bits in side
a combinatorial always process. Is it ok to use the complete bus in
the sensitivity list?

It depends. For sythesizable stuff, you should be fine, although DC
will probably give you a warning. However, you can never win because
other tools will give you a warning if you don't use the full signal.

We are not too concerned about synthesis. As you said different tools
will give us warning messages differently. But most of them
synthesizes it correctly. We are concerned if the simulation can have
some problem.

Can there be any problem during simulation? We
are not able to come up with an error case.

Here's an example, but this is just muppet coding:

always @(in1)
$display(in[1:0]);

always @(in1[1:0])
$display(in[1:0]);

Depending on which code is used, $display could be called a different
number of times.

I can you see your point here. But can there be any functional problem
or even a difference between an RTL simulation and a gate simulation?

-Dipu

 

[Vikram]

jon@beniston.com (Jon Beniston) wrote in message news:<e87b9ce8.0411110322.3660925a@posting.google.com>...

. We are using only 2 LSB bits in side
a combinatorial always process. Is it ok to use the complete bus in
the sensitivity list?

It depends. For sythesizable stuff, you should be fine, although DC
will probably give you a warning. However, you can never win because
other tools will give you a warning if you don't use the full signal.

Can there be any problem during simulation? We
are not able to come up with an error case.

Here's an example, but this is just muppet coding:

always @(in1)
$display(in[1:0]);

always @(in1[1:0])
$display(in[1:0]);

Depending on which code is used, $display could be called a different
number of times.

Cheers,
Jon

The easiest way to avoid warnings about the partial usage of the
multi-bit signal is to simply define another wire and use that in
place of the original signal.

For your example,

wire [7:0] in1;
wire [1:0] in2;

assign in2 = in1[1:0];

always @(in2[1:0], ..<other signals>...)
out1 = in2[1:0] + <other signals>;

-Vikram