Date: Mon Oct 27 2014 - 15:21:18 PDT
NaNs are supported only by IEEE floating point hardware. Given that none of the integer arithmetic hardware on all widely used computer platforms supports an integer NaN of any kind, this kind of requirement can greatly reduce simulation speed. Added test and trap code would be required for each and every integer arithmetic operation. Joe Gwinn From: Daniel Kho <daniel.kho@tauhop.com> To: "vhdl-200x@eda.org" <vhdl-200x@eda.org> Date: 10/27/2014 04:05 PM Subject: Re: EXTERNAL: Re: [vhdl-200x] Update to proposal for arbitrary integers Sent by: owner-vhdl-200x@eda.org Yes, that's what's going to happen now. Hence the proposal to add something like NaN as an integer value, similar to how it was done for the float type. Cheers, dan On 28 October 2014 01:44, <tgingold@free.fr> wrote: > Another use case for this is when we are modelling memories, one > could possibly apply the to_integer function on an address bus to > read contents of a memory. For example: > > q <= rom(to_integer(addr)) when rising_edge(clk); > > If "addr" contains 'X's, then zero would be returned. Yes, the > simulator would warn us of a meta-value detection, but wouldn't it > be better if the to_integer were to return something that > corresponds to NaN for example? I think seeing a red line on the > databus in simulation whenever the address lines are invalid would > give the designer better insight to what went wrong, as compared to > a few warning messages. But then the simulation would immediately stop as 'rom(NaN)' is not defined. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
