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> 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> 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] *On >> Behalf Of *Daniel Kho >> *Sent:* Monday, October 13, 2014 9:29 PM >> *To:* 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> >> 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, and is believed to be clean.Received on Sun Oct 19 06:57:51 2014
This archive was generated by hypermail 2.1.8 : Sun Oct 19 2014 - 06:57:52 PDT