One really needs to have these expression mechanisms on BOTH SIDES of the equation. Remember that these need especially to be able to describe hardware at any level. To have those expressions only on the RIGHT side of a statement greatly limits the target description statement to be only a simple target. We at Honeywell Large Systems had such expressions on the left or target side of the description in our "I-Language". The same left or target side mechanisms were also available in DEC's implementation language (sorry, but I don't right now remember what it was called.) I apologize if our target language here already has those properties. Regards, --Steve Grout -------------------- On 4/14/2015 9:45 AM, Degroat, Joanne wrote: > This is a neat idea and is consistent with the philosophy of the language. > > *From:*owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] *On > Behalf Of *Lehmann, Patrick > *Sent:* Monday, April 13, 2015 6:06 PM > *To:* vhdl-200x@eda.org > *Subject:* RE: [vhdl-200x] VHDL-2008: Records and aggregates > > I think it would be nice to have a type RANGE that defines some > operations like add/sub/div/mult of length or shift of boundaries. > > Example definition: > > type myRange is RANGE 7 downto 0; > > This range can then be used in slices. > > signal mySignal1 : std_logic_vector(myRange); -- 7..0 > > signal mySignal2 : std_logic_vector(myRange + 8); -- 15..8 > > signal mySignal3 : std_logic_vector(myRange * 4); -- 31..0 > > Some of this behavior can be emulated by using subtypes of INTEGER with > current set of VHDL features. But there is no short arithmetic defined like: > > subtype myRangeLow is INTEGER range 0 to 7; > > subtype myRangeHigh is myRangeLow'range + 8; > > plus (+) moves both boundaries up. > > Alternatively, it maybe possible to chain attributes like this: > > small0 <= Big(small0'range); > > small1 <= Big(small1'range'shift (small0'length)); > > 'shift(x) moves both boundaries up. > > I think most tools have already an internal representation of RANGE. > > I also know it's not easy to define propper arithmetic on ranges, but > maybe other like the thought of such a RANGE type for slicing or > aggregates, so we could discuss this further. > > Examples for difficult definitions: > > a) > > signal mySignal3 : std_logic_vector(myRange * 4); -- 31..0 > > We expect a range of 4 bytes to be 31..0 but strict arithmetic would say > 28..0 > > b) > > What is range3 := range1 + range2? > > Ok length3 equals lenth1 + length2, but what about range3'low and 'high? > > c) > > How to handle zero-length ranges (and negative ranges)? > > Regards > > Patrick > > -------- Ursprüngliche Nachricht -------- > > Von: Daniel Kho > > Datum:13.04.2015 19:07 (GMT+01:00) > > An: vhdl-200x@eda.org <mailto:vhdl-200x@eda.org> > > Betreff: Re: [vhdl-200x] VHDL-2008: Records and aggregates > > Perhaps it's time for us to revisit aggregates again, hopefully we'll > come up with something more intuitive and usable. > > A couple more things regarding arrays and aggregates: > > 1. I would like an easy way to specify ranges. Imagine you have a "big" > vector which you'd like to split into several smaller slices. > > signal Big: unsigned(63 downto 0); > > small0 <= Big(small0'range); > > small1 <= Big(small1'high + small0'high + 1 downto small0'high > + 1); > > ... > > how about small2, etc? This will get rather lengthy. > > I was thinking in the lines of: > > small0 <= Big(small0'range); > > small1 <= Big(small1'range + offset(small0'length)); > > small2 <= Big(small2'range + offset(small1'length)); > > or something similar to this. Any ideas? These days I try not to > hard-code "magic" numbers [such as Big(15 downto 8) for example], as > more often than not, I will be changing them as requirements change. > > 2. Regarding aggregates. I would like to use the capability in 1) in > aggregates as well: > > a: in unsigned(3 downto 0); > b: in unsigned(7 downto 0); > q: out unsigned(63 downto 0) > > q <= (a'range => a, 12 downto 4 => '0', b'range + offset(a'length) => b, > others => '0'); > > Also, I think we should allow globally-static values as expressions or > ranges in aggregate associations. Some tools give us a warning instead > of a hard error, it means that those tools chose not to comply strictly > with the LRM, for a good reason I believe. > > -daniel > > On 13 April 2015 at 23:21, <tgingold@free.fr <mailto:tgingold@free.fr>> > wrote: > > > Hi Tristan, > > Yes I can see that now. How dense of me. OTOH, the lack of basic > > introspection of single dimensional array aggregates is annoying. > > Yes, aggregate rules aren't very intuitive! > > Tristan. > > > OTOH, there was a significant change to array aggregates in > > VHDL-2008. Basically, they now support concatenation when the > > target is an array type. As a result, even if we add introspection > > to > > recognize single dimensional array aggregates, this one is still > > going to be ambiguous with std_ulogic_vector. > > > > > Thanks for straightening me out on this. > > > > Jim > > -- > 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* <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 Tue Apr 14 09:31:06 2015
This archive was generated by hypermail 2.1.8 : Tue Apr 14 2015 - 09:31:15 PDT