| Number | 625
|
| Category | errata
|
| Synopsis | arithmetic shifts
|
| State | closed
|
| Class | errata-simple
|
| Arrival-Date | Sep 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