RE: [vhdl-200x-ft] Bugs in Numeric_std

David,

The issue you referenced was one that the ISAC reviewed earlier this year.
Our analysis was that the bug is in the tool mentioned, not in the code in
the standard. We agreed that we should not change the standard just to work
around tool bugs. The standard code should be written to be clear and
concise.

In this particular case, the change suggested by the submitter does not
affect the clarity of the code. However, I'd be circumspect about such
changes in general.

End $0.02.

Cheers,

PA

--
Dr. Peter J. Ashenden                        peter@ashenden.com.au
Ashenden Designs Pty. Ltd.                   www.ashenden.com.au
PO Box 640                                   Ph:  +61 8 8339 7532
Stirling, SA 5152                            Fax: +61 8 8339 2616
Australia                                    Mobile: +61 414 70 9106
> -----Original Message-----
> From: owner-vhdl-200x-ft@eda.org 
> [mailto:owner-vhdl-200x-ft@eda.org] On Behalf Of David Bishop
> Sent: Thursday, 16 December 2004 01:16
> To: vhdl-200x-ft@eda.org
> Subject: [vhdl-200x-ft] Bugs in Numeric_std
> 
> 
> As long as we are on the thread of tracking down old bugs, I 
> was sent the following bug via the Mentor support hotline 
> (VHDL Issue Number 2002, analyzed by Peter Ashenden) and an 
> ESNUG article: http://www.deepchip.com/items/0348-14.html
> 
> Noting the following:
>  > Description of Problem
>  > ----------------------
>  >
>  > If Resize(ARG: UNSIGNED, NEW_SIZE: NATURAL) is called with
>  > Length(Unsigned) = NEW_SIZE, the else statement(line 3192) 
> will try to  > evaluate RESULT(X downto X+1).  This caused a 
> fatal error in the  > RTLcompile tool from IKOS.  >  > 
> Proposed Resolution  > -------------------  > 
> Proposed_Resolution: Change the if statement in line 3190 to 
> use "<="  > nstead of "<", so it reads
> 
> This is an easy fix, which I have put in and tested.
> 
> -- 
> David W. Bishop dbishop@vhdl.org       All standard disclaimers apply.
>