NaN has an explicit definition as well as a specific valid bit pattern in floating point. There is no equivalent state in fixed point arithmetic. All fixed point integer bit patterns map to an integer value. As such, I have a lot of heartburn calling this NaN. I think that what you really want is the addition of metavalues to the integer type. My problem with that is twofold: a) it isn't just the to_integer function that is affected, it is all integer functions and operations. In order for the metavalue to be useful, it needs to be propagated. Otherwise you end up with exactly the same situation where you have a function that spits out a warning message but outputs an otherwise valid value. My second reservation is adding a metavalue to the integer type involves a very significant processing overhead increase for every integer operation and function in order to detect and propagate the metavalue when appropriate. Warnings do provide a reasonable way to alert the designer to an unknown value without forcing a burdensome structure (most simulators will include the simulation time with the warning, so it is easy to track it down...but it does require you to review the warnings). On 10/27/2014 11:26 AM, Daniel Kho wrote: > Hi all, > I just bumped into an issue that I remember facing again and again. > Specifically, the current implementation of to_integer in numeric_std > returns an integer value of zero when nulls and metavalues are > detected in the input argument. > > 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. > > Best regards, > Daniel > > On 19 October 2014 21:56, Daniel Kho <daniel.kho@tauhop.com > <mailto:daniel.kho@tauhop.com>> wrote: > > I think Jim's suggestions drew some parallels to what David Koontz > mentioned earlier? Dave's earlier example also uses a record type. > The only catch, as Jim mentioned, is that it would be more > difficult assigning things with a record type (need to assign > every element), as compared to the straightforward manner of > assigning integers. > > -dan > > > On 19 October 2014 21:52, Daniel Kho <daniel.kho@tauhop.com > <mailto:daniel.kho@tauhop.com>> wrote: > > Hi Andy, > One of the goals of my resolution function was to make sure > there is only one valid driver at any time. If I were to have > the resolution function sum up all drivers, and if the design > wrongly has two or more drivers driving different values at > the same time, then the resolution function would, > incorrectly, resolve to the summed value, which is not the > intent of the resolution function. > > If I were to use 0 as the undriven value, but also have 0 as a > valid integer value (e.g. I may want my design to settle to a > zero value during initialisation or IDLE state), then how > could I tell which driver is the one driving? Since we must > have only 1 driver at any time, i.e. it would be incorrect if > the design were to have all drivers driving 0 at the same > time. Let's assume that the design specification dictates that > only one driver would drive 0 (or any other valid integer > value) at any time, while all other drivers must release the > bus to an undriven state. > > Jim, > Perhaps your suggestions and proposals on "Implicit Numeric > Conversions" could work for me. But sorry I haven't yet gone > through your proposals in detail so I wouldn't know for sure. > I hope I could spend some time this week to study them. > > Cheers, Dan > > > > On 17 October 2014 09:55, Jones, Andy D <andy.d.jones@lmco.com > <mailto:andy.d.jones@lmco.com>> wrote: > > You don’t need to reserve an unused number, just make the > bus resolve to that number if everyone drives it. > > For an integer resolution function, you can use 0 as the > undriven value, and the resolution function just sums the > drivers. If more than one driver is on (non-zero), have > the resolution function assert a warning, and report the > non-zero values if you like. The only thing that won’t > catch is if all but one driver are intending to drive 0, > and one mistakenly does not. > > Andy > > *From:* owner-vhdl-200x@eda.org > <mailto:owner-vhdl-200x@eda.org> > [mailto:owner-vhdl-200x@eda.org > <mailto:owner-vhdl-200x@eda.org>] *On Behalf Of *Daniel Kho > *Sent:* Monday, October 13, 2014 9:29 PM > *To:* vhdl-200x@eda.org <mailto:vhdl-200x@eda.org> > *Subject:* EXTERNAL: Re: [vhdl-200x] Update to proposal > for arbitrary integers > > Hi Martin, > > Thanks for this. One thing that has been bothering me > quite often these days is that integers, booleans, bits > (and possibly other types from the std.standard package) > do not have the concept of resolution. > > While I support the idea of having a > completely-unconstrained universal_integer type, I still > would like to have the ability to assign an "invalid" or > "undriven" value to an integer. Like this: > > signal i: integer; > ... > > begin > > i <= NaN; > > where NaN is an invalid value for an integer. I find > myself needing the ability to assign integers to an > invalid / undriven state, during initialisation/reset for > example, or when I would want to have a driver explicitly > "release" the bus, while have another driver drive it. > > In the past, I tried writing resolution functions for > integers to do exactly this, but found my solution > inadequate as I need to reserve a valid integer, e.g. > x"ffff_ffff" to act as my invalid/undriven integer. I find > that when writing such resolution functions, I do need > checks against an undriven state. For std_logic, we > already have the function "is_x" (and I also have my own > "is_01") which we could use when resolving std_ulogic type > signals. But for integer and boolean types, I can't think > of a way to do the same thing as an "is_x" function would > for std_logic. My dirty hack was just to reserve a very > large integer to act as my invalid value. > > My opinion is that it would be great if we can do similar > things with integers, booleans, and bits. It is often > easier to design using these datatypes than with > std_logic(_vector). > > What do you think? > > Best regards, > Daniel > > On 10 October 2014 19:07, Martin.J Thompson > <Martin.J.Thompson@trw.com > <mailto:Martin.J.Thompson@trw.com>> wrote: > > Hi all, > > > After the discussions in the last telecon, I have updated > the Arbitrary Integers page: > > http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/ArbitraryIntegers > > In summary, the proposal is to > > · Expose universal_integer as a completely unconstrained > integer type, (and possibly make INTEGER a constrained > subtype of this. Each tool will constrain the INTEGER to > the range it currently provides for backwards compatibility.) > > · Create universal_integer’high and ‘low > > · Allow logical and shift operations on universal_integers > > · Question: should conversions between UNIVERSAL_INTEGER > and INTEGER be implicit or explicit? > > Any comments you have will be gratefully received as always :) > > Thanks, > > Martin > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* > <http://www.mailscanner.info/>, and is > believed to be clean. > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* > <http://www.mailscanner.info/>, and is > believed to be clean. > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* > <http://www.mailscanner.info/>, and is > believed to be clean. > > > > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is > believed to be clean. -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Oct 27 15:44:27 2014
This archive was generated by hypermail 2.1.8 : Mon Oct 27 2014 - 15:44:42 PDT