Yes, I've been hoping for something like this for some time now. On 14 April 2015 at 21:45, Degroat, Joanne <degroat.1@osu.edu> 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 > > > Yes. I'd also like to specify the range of mySignal2 based on the length of mySignal1. Something like: signal mySignal2: std_logic_vector(myRange + mySignal1'length); I believe, with your definition of '+', the boundaries will move up based on mySignal1's length, which would fit the intention nicely. > 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 > > > We can perhaps define "*" as having the resultant range of the length of the range multiplied by the multiplier: mySignal3'high = size of myRange * multiplier + lowest boundary of myRange - 1 = 8 * 4 + 0 - 1 (for this case) mySignal3'low = lowest boundary of myRange = 0 (for this case) > b) > > What is range3 := range1 + range2? > > Ok length3 equals lenth1 + length2, but what about range3'low and 'high? > > > Should we allow null ranges in between or not? Say we have the following ranges: type range1 is range 6 downto -1; type range2 is range 11 downto 9; so, range3 intuitively would mean the concatenation of range1 and range2, so I think range3 should be implicitly defined as: type range3 is range (11 downto 9, 6 downto -1); Say we have: signal s: unsigned(range3); so perhaps we can have the following aggregate: s <= (11 downto 9 => '1', 6 downto -1 => '0'); and allow all sub-slices that are within these ranges, otherwise it would be an error. s(8 downto 7) should be a null range. As usual, any overlapping assignments would result in an error. So it would be an error if we had: type range1 is range 7 downto 0; type range2 is range 3 downto -1; and range3 := range1 + range2; -- overlapping range 3 downto 0, error. > c) > > How to handle zero-length ranges (and negative ranges)? > I feel we got ourselves pretty much covered on negative ranges, or maybe I may still be missing something? Perhaps it's also time for us to interpret zero-length ranges the same way as accessing a single index of an array? E.g. s(8 downto 8) is the same as s(8)? Regarding operations on null ranges, the result of a range assignment should also be a null range IMO: type range1 is range 2 downto 3; type range2 is range 6 downto 0; range3 := range1 + range2; -- should be null range? -daniel -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Apr 14 09:03:35 2015
This archive was generated by hypermail 2.1.8 : Tue Apr 14 2015 - 09:03:55 PDT