Hi Daniel, I included the square brackets intentionally to promote such discussion. For single element referencing we have: std_array(elementx) -- for arrays and std_record.elementx -- for records I wanted to maintain the distinction between the two composite types in the way they select a range, hence the square brackets. Standard parentheses maybe better but I think we should retain the dot notation: std_array(elementx to elementy) -- for arrays and std_record.(elementx to elementy) -- for records Brent. On 06/06/2014 03:00, Daniel Kho wrote: > Hi Brent, > Yes, I just noticed your proposal, and am liking almost every bit of it. > > The only thing I found peculiar was the use of square brackets to denote > element ranges. > I was pondering upon your idea of retaining the dot notation for ranges of > record elements. I'm not sure if dropping the dot notation makes more sense? > > Declaration: > subtype sub_std_record is std_record(element1 to element3); > > And for access: > my_sub_sig(element2 to element3) <= (others => 'Z'); > > regards, daniel > > > On 6 June 2014 04:31, Brent Hayhoe <Brent.Hayhoe@aftonroy.com > <mailto:Brent.Hayhoe@aftonroy.com>> wrote: > > Hi Daniel, > > Actually, the first probably deals more with the problem and how to > achieve it. > > It has been merged for tracking reasons, but is entitled: > > Record Introspection & Indexing > > and proposes an implicit enumerated type generated when a record is > declared. The elements are accessed using the same attribute. > > Brent > > > > On 05/06/2014 17:31, Daniel Kho wrote: > > Hi Martin, > Thanks, I believe the Record Introspection proposal is what I'm > looking for. > > Cheers, Dan > > > On 5 June 2014 16:05, Martin.J Thompson <Martin.J.Thompson@trw.com > <mailto:Martin.J.Thompson@trw.com> <mailto:Martin.J.Thompson@trw.com > <mailto:Martin.J.Thompson@trw.com>>> wrote: > > Daniel, > > Do these proposals not meet your needs? > > http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/RecordMemberAttribute > > http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/RecordIntrospection > > The latter one provides “for element in record_type'elements loop“ > which looks like it would work for you? > > > Cheers, > Martin > > *From:*owner-vhdl-200x@eda.org <mailto:owner-vhdl-200x@eda.org> > <mailto:owner-vhdl-200x@eda.org <mailto:owner-vhdl-200x@eda.org>> > [mailto: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:* 05 June 2014 05:15 > *To:* vhdl-200x@eda.org <mailto:vhdl-200x@eda.org> > <mailto:vhdl-200x@eda.org <mailto:vhdl-200x@eda.org>> > *Subject:* [vhdl-200x] Iterating across a Record Type > > > Hi friends, > > I know this question has been asked before in some forums, but I > feel it > hasn't been adequately answered. My intent is to loop across all > elements > of a record type, similar to how we could do it with an array: > > for i in vect'range loop > > vect(i)<=i; > > end loop; > > where "vect" is an array vector of naturals for example. > > The question is, if I had a record type with several sub-elements, how > would I be able to iterate across all the sub-elements? For example, > assume we have a record: > > type rec is record > > a:std_ulogic; > > b:std_ulogic_vector(15 downto 0); > > c:signed(7 downto 0); > > end record rec; > > I prefer to not have to write out all the sub-elements individually: > > function resolve(r:rec) return rec is begin > > if is_x(r.a) then ... end if; > > if is_x(r.b) then ... end if; > > if is_x(r.c) then ... end if; > end function resolve; > > Currently, I feel having an option for iterating across record > structures > will be very useful especially when writing resolution functions, > but I > believe this usefulness can be applied to many other scenarios as > well. > Another application I can think of which makes having such a feature > useful, is to apply them for initializers. > > Some languages (e.g. scripting languages) have something like > "child" or > "next" keywords which we can use to access neighbouring elements of a > structure. I was thinking of having something like this for VHDL: > > function resolve(r:rec) return rec is begin > > for i in r'range loop -- okay, 'range only works for arrays > now, > -- but you get the idea. > > if is_x(r.child(i)) then ... end if; > > end loop; > > end function resolve; > > Of course, "child" may as well be some other keyword, e.g. > "element", or > picked from a suitable existing VHDL keyword. > > Best regards, > Daniel > > > -- 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. > > > > -- > > Regards, > > Brent Hayhoe. > > Aftonroy Limited Telephone: +44 (0)20-8449-1852 > <tel:%2B44%20%280%2920-8449-1852> > 135 Lancaster Road, > New Barnet, Mobile: +44 (0)79-6647-2574 > <tel:%2B44%20%280%2979-6647-2574> > Herts., EN4 8AJ, U.K. Email: > Brent.Hayhoe@Aftonroy.com > > Registered Number: 1744190 England. > Registered Office: > > 4th Floor, Imperial House, > 15 Kingsway, > London, WC2B 6UN, U.K. > > > > -- > 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. -- Regards, Brent Hayhoe. Aftonroy Limited Telephone: +44 (0)20-8449-1852 135 Lancaster Road, New Barnet, Mobile: +44 (0)79-6647-2574 Herts., EN4 8AJ, U.K. Email: Brent.Hayhoe@Aftonroy.com Registered Number: 1744190 England. Registered Office: 4th Floor, Imperial House, 15 Kingsway, London, WC2B 6UN, U.K. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Jun 5 22:48:04 2014
This archive was generated by hypermail 2.1.8 : Thu Jun 05 2014 - 22:48:40 PDT