Some more thoughts about this. In the case of q <= (a'range => a, 12 downto 4 => '0', b'range + offset(a'length+9) => b, others => '0'); where 'q' is an unsigned, if the choice of an association matches the type std_ulogic (or an element of unsigned), then the target q will be assigned to that choice for all the bits associated within the range specified. This is how it is as usual: E.g. 12 downto 4 => '0', -- all bits from 12..4 will be assigned to '0' However, if the choice of an association is a vector (or a slice), then the target q will be assigned to that slice for all the bits associated within the range specified. E.g.: a'range => a, -- bits in q that are within a'range are assigned to the slice 'a'. I think in VHDL-2008, we can have slices in aggregates, but I'm not sure if it supports only bit string literals, or other non-locally static choices as well. I think choices in associations can be made non-locally static, while ranges have to be static (can be locally or globally static). What are your thoughts? -daniel On 14 April 2015 at 01:15, Daniel Kho <daniel.kho@gmail.com> wrote: > Sorry, I meant: > q <= (a'range => a, 12 downto 4 => '0', b'range + offset(a'length+9) => b, > others => '0'); > > > > On 14 April 2015 at 01:06, Daniel Kho <daniel.kho@gmail.com> wrote: > >> 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> 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, and is believed to be clean.Received on Mon Apr 13 10:50:22 2015
This archive was generated by hypermail 2.1.8 : Mon Apr 13 2015 - 10:51:09 PDT