bitwise or logical operators

[ajcrm125]

I'm trying to establish a coding format in which I'm going to start
coding all of my future RTL.
I'm poking though other designs to see in what direction they went and
some use bitwise operators (even in cases where they are considering
single bit signals) and others choose to use logical operators. For
example:

assign signalD = signalA & ~(signalB | signalC);
versus
assign signalD = signalA && !(signalB || signalC);

Is there a justifiable preference either way? I'm pretty sure they'll
synthesize the same way.
Thanks for any insight....
-Adam

 

[mrfirmware]

On Jan 24, 10:43 am, ajcrm125 <ajcrm...@gmail.com> wrote:

I'm trying to establish a coding format in which I'm going to start
coding all of my future RTL.
I'm poking though other designs to see in what direction they went and
some use bitwise operators (even in cases where they are considering
single bit signals) and others choose to use logical operators. For
example:

assign signalD = signalA & ~(signalB | signalC);
versus
assign signalD = signalA && !(signalB || signalC);

Is there a justifiable preference either way? I'm pretty sure they'll
synthesize the same way.

If they synthesize the same, I'd code for "author's intent". That is,
if you are concerned with logical truth or falsehood of an equation
I'd use logical AND and OR, even on single bit operands. If there is
some synthesis inefficiency for using logical operators, I'd use
bitwise and comment that you really intend logical.

- Mark

 

[Jonathan Bromley]

On Thu, 24 Jan 2008 10:53:58 -0800 (PST),
mrfirmware <mrfirmware@gmail.com> wrote:

If they synthesize the same, I'd code for "author's intent". That is,
if you are concerned with logical truth or falsehood of an equation
I'd use logical AND and OR, even on single bit operands. If there is
some synthesis inefficiency for using logical operators, I'd use
bitwise and comment that you really intend logical.

For single-bit operands, logical and bitwise operators
do EXACTLY the same thing. As mrfirmware says, code for
your intent. And be paranoid: if one of the operands is
a single-bit vector (as opposed to a scalar), remember
that one day some gorilla might make it an N-bit vector
instead.

I'd be glad of a sanity check from Steven Sharp, but I'm
pretty sure that you can always convert the logic operators
into bitwise operators by appealing to the reduction-OR
operator. For *any* scalar or vector operands A, B:

A && B is the same as (|A) & (|B)
A || B is the same as (|A) | (|B)
!A is the same as ~(|A)
if (A) is the same as if (|A)

But be careful:

A && B is NOT exactly the same as |(A & B)

and so forth.

The fact that |A returns, as a single bit, the "truth value"
of A has saved me some trouble on many occasions.
--
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.

 

[Rajkumar]

On Jan 25, 1:21 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On Thu, 24 Jan 2008 10:53:58 -0800 (PST),

mrfirmware <mrfirmw...@gmail.com> wrote:
If they synthesize the same, I'd code for "author's intent". That is,
if you are concerned with logical truth or falsehood of an equation
I'd use logical AND and OR, even on single bit operands. If there is
some synthesis inefficiency for using logical operators, I'd use
bitwise and comment that you really intend logical.

For single-bit operands, logical and bitwise operators
do EXACTLY the same thing. As mrfirmware says, code for
your intent. And be paranoid: if one of the operands is
a single-bit vector (as opposed to a scalar), remember
that one day some gorilla might make it an N-bit vector
instead.

I'd be glad of a sanity check from Steven Sharp, but I'm
pretty sure that you can always convert the logic operators
into bitwise operators by appealing to the reduction-OR
operator. For *any* scalar or vector operands A, B:

A && B is the same as (|A) & (|B)
A || B is the same as (|A) | (|B)
!A is the same as ~(|A)
if (A) is the same as if (|A)

But be careful:

A && B is NOT exactly the same as |(A & B)

and so forth.

The fact that |A returns, as a single bit, the "truth value"
of A has saved me some trouble on many occasions.
--
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.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com

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

Hi,
If you are concerned only about synthesizeable RTL, then you should
not require Logical operators.
If you visualise the hardware before coding, then you should get away
using only the bitwise operators.

Rajkumar...

 

On Jan 24, 3:21 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

I'd be glad of a sanity check from Steven Sharp, but I'm
pretty sure that you can always convert the logic operators
into bitwise operators by appealing to the reduction-OR
operator.  For *any* scalar or vector operands A, B:

  A && B  is the same as   (|A) & (|B)
  A || B  is the same as   (|A) | (|B)
  !A      is the same as   ~(|A)
  if (A)  is the same as   if (|A)

Yes, I believe this is true.

BTW, one subtle difference you might see between the logical and
bitwise operators is whether a particular implementation will short-
circuit the evaluation when the result becomes known. This does not
matter unless there are function calls that could have side-effects
when evaluated, so it isn't an issue in purely combinational code, but
it could matter in other situations. The LRM allows, but does not
require, short-circuiting on either operator. However,
implementations may make different choices for them. For example, if
there are function calls, NC-Verilog will always short-circuit logical
operators and never short-circuit bitwise operators. This matches
what most C programmers would expect.

 

[gabor]

On Jan 28, 1:17 pm, sh...@cadence.com wrote:

On Jan 24, 3:21 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com
wrote:



I'd be glad of a sanity check from Steven Sharp, but I'm
pretty sure that you can always convert the logic operators
into bitwise operators by appealing to the reduction-OR
operator. For *any* scalar or vector operands A, B:

A && B is the same as (|A) & (|B)
A || B is the same as (|A) | (|B)
!A is the same as ~(|A)
if (A) is the same as if (|A)

Yes, I believe this is true.

BTW, one subtle difference you might see between the logical and
bitwise operators is whether a particular implementation will short-
circuit the evaluation when the result becomes known. This does not
matter unless there are function calls that could have side-effects
when evaluated, so it isn't an issue in purely combinational code, but
it could matter in other situations. The LRM allows, but does not
require, short-circuiting on either operator. However,
implementations may make different choices for them. For example, if
there are function calls, NC-Verilog will always short-circuit logical
operators and never short-circuit bitwise operators. This matches
what most C programmers would expect.

Isn't there also a difference in the order of execution of bitwise
vs logical operators? Could this affect code without parentheses
to force the order?

 

On Jan 29, 9:23 am, gabor <ga...@alacron.com> wrote:

Isn't there also a difference in the order of execution of bitwise
vs logical operators?  Could this affect code without parentheses
to force the order?

Yes, definitely. The bitwise operators have a higher precedence than
the logical ones. So if you used a mixture of the two, you might get
some surprises. For example, (b&c|d) means ((b&c)|d), and (b&&c||d)
also means ((b&&c)||d). But (b&&c|d) means (b&&(c|d)). But the
bitwise and logical operators are all lower precedence than anything
but the conditional operator, so if you stick with one or the other,
you should be fine.

 

[gurucharapathy]

On Jan 30, 1:17 am, sh...@cadence.com wrote:

On Jan 29, 9:23 am, gabor <ga...@alacron.com> wrote:



Isn't there also a difference in the order of execution of bitwise
vs logical operators?  Could this affect code without parentheses
to force the order?

Yes, definitely.  The bitwise operators have a higher precedence than
the logical ones.  So if you used a mixture of the two, you might get
some surprises.  For example, (b&c|d) means ((b&c)|d), and (b&&c||d)
also means ((b&&c)||d).  But (b&&c|d) means (b&&(c|d)).  But the
bitwise and logical operators are all lower precedence than anything
but the conditional operator, so if you stick with one or the other,
you should be fine.

Hi,
How about the usage in terms of code coverage, will the usage of
bitwise operators exclude the expressions for conditional coverage ?