ISSUE 625

Number 625
Category errata
Synopsis arithmetic shifts
State closed
Class errata-simple
Arrival-DateSep 22 2004
Originator Yong Xiao <yongx@tharas.com>
Release 2001b
Description
Hi:

Are arithmetic shifts considered as arithmetic operators?
The LRM says that for "+", "-", "*", "/", "%", if any operand contains
'x' or 'z', the result is all 'x'. Should that apply to arithmetic
shifts, ie, if the first operand of arithmetic shifts contains 'x' or
'z', the result is all 'x'?
I would vote for yes, because if a is an integer variable, a*2 will be
equivalent a <<<1.

Thanks.

Yong


Fix
Propose to close this issue with no change.

Audit-Trail
From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, yongx@tharas.com
Cc:
Subject: Re: errata/625: arithmetic shifts
Date: Thu, 23 Sep 2004 17:32:54 -0400 (EDT)

>Are arithmetic shifts considered as arithmetic operators?

No. The arithmetic operators are those listed in Table 13 in 4.1.5, as
stated by the text there.

>The LRM says that for "+", "-", "*", "/", "%", if any operand contains
>'x' or 'z', the result is all 'x'. Should that apply to arithmetic
>shifts, ie, if the first operand of arithmetic shifts contains 'x' or
>'z', the result is all 'x'?

No. The LRM does specify that if the second operand contains x or z
bits then the result is x, but it does not specify this for the first
operand. The text describes shifting the first operand's bits left or
right, without changing their values. So an x bit shifted to a new
position will still be an x, a z will be a z, a 1 will be a 1, and a
0 will be a 0.

Producing an all x result would be excessively pessimistic, and there
is no good reason for it. Producing accurate results is actually a
little bit more efficient for the simulator in this case.

>I would vote for yes, because if a is an integer variable, a*2 will be
>equivalent a <<<1.

There are many other uses for shifts, and they wouldn't work properly
if shifts worked this way. For example, they are often used in MUXes
to select a chunk out of a vector, particularly before the indexed part
selects were added to the language. An x in an unselected bit should
not affect the output of this. If a design used such a MUX in the
synchronous reset logic, it could never simulate reset properly.

Furthermore, this is not the way that existing simulators work, including
the Verilog-XL simulator that the original LRM was based on. Changing
this behavior would violate backward compatibility with the existing
language.

Steven Sharp
sharp@cadence.com


Fix replaced by Shalom.Bresticker@freescale.com on Mon Oct 18 01:14:08 2004

Propose to close this issue with no change.



Unformatted

Hosted by Boyd Technology