Hi all, This is my first time commenting on this list so maybe a short introduction: I'm Lieven Lemiengre and I work on the VHDL compiler for Sigasi (If you don't know us, we make a VHDL IDE with a type-time compiler). I've been watching this list for a while, maybe it's time that I try to contribute. First of all, I really like the record introspection proposal but I as a compiler developer, allow me to become a bit defensive. Since all of this should be somewhat type-checkable I don't think that the existing member selection ( a.b ) or array indexing ( a(b) ) syntax should be overloaded further. For member selection ( a.b ), the scope of b solely depends on the type of a, this proposal suggests that we should also consider the outer scope to resolve b. This will cause the expression to become ambiguous if both are possible. You could of course give one priority of the other but then you have overloaded member selection & added a special ambiguity resolving rule just for record introspection. For array indexing ( a(b) ), I find this weird because arrays in vhdl aren't heterogeneous, the return type of a(b) would depend on the static _value_ (not type) of b, that is very different from normal array selection or even function application where it depends on the _type_ of the arguments. The only part of the vhdl expressions where return types depend on the _values_ of the arguments is for the predefined attributes on arrays (for example arr'low(2)). So I believe that accessing record elements through introspection should reuse this mechanism. Instead of a.field or a(field) it should be a'element(field), I know that this syntax is more verbose but you will not be using record introspection everywhere in your code. This is a small (but powerful) feature, small features should not have a large footprint on the spec. Something that I miss in these proposals is a way to generically convert any record into a std_logic_vector (and make that part of the standard library). Would it be possible to define a function attribute on types (user defined, but for the standard types part of the standard library) and use that attribute to do the conversion? kind regards, Lieven Lemiengre 2014-06-06 7:47 GMT+02:00 Brent Hayhoe <Brent.Hayhoe@aftonroy.com>: > 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. > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Jun 6 02:38:33 2014
This archive was generated by hypermail 2.1.8 : Fri Jun 06 2014 - 02:39:07 PDT