Hi Peter, I understand about the concern about errors and I think that Ryan and Jim think likewise, however I believe that the language enhancements should not be limited in order to avoid programmer errors. I agree that these should be of concern, but they are not insurmountable. A major point (which I believe has already been mentioned) is the matter of coding standards, particularly with regard to multiple authors. As you may have noticed in some of my infamous examples, I tend to append object identifiers to my names in order to more easily track and identify my code. My record element names tend to be appended with '_l' (for eLement). Now matching by name would mean that I could (probably 100%) never be closely related to other people's defined records (without compromising my coding standards). Now this in itself is not a major problem, but the concept of matching by name is limiting record element naming to exact alphanumeric matching, even though the language compiler has no concept of the meaning of these names. My point is, leave the functionality of the naming (and thus the power of the language) to the users, with this benefit goes the responsibility of identifying and fixing any arising errors. With regard to the element associated types; I am assuming that any solution to this proposal must allow the type matching to be closely related, whether we decide on position only or both position and name Cheers, Brent. P.S. with regard to vectors, I can only remember the nightmare I encountered in having to convert some DSP code defined with 'std_logic_arith' into 'numeric_std' signed/unsigned vectors... aaaargh! On 10/12/2012 13:12, Peter Flake wrote: > Hi Brent, > > I am concerned that option 2 would be a source of errors, especially when > records are defined in different packages written by different people. > > I do not think that the vector types can lead to the same kind of errors. > > BTW do the fields of the records need to have identical types, or just > closely-related types? > > Regards, > > Peter. > -----Original Message----- > From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of > Brent Hayhoe > Sent: 09 December 2012 21:51 > To: vhdl-200x@eda.org > Subject: Re: [vhdl-200x] Closely related record types > > Hi Ryan, > At first I looked at this and was in total agreement with everyone else, use > > option 3. > And then I started thinking; we need to provide this function in the > language > without limiting the user. > Thinking about the difference in the closely related Std_Logic_Vector and > Signed/Unsigned vector types, there is of course no difference in the > actual > vector element types. The difference is in the inferred meanings - > Signed/Unsigned are overloaded with numerical functions whereas > Std_Logic_Vector > has no inferred meaning. (Often the user may generate these vectors as > concatenations of various signal bits, i.e. a bundle of signals.) > My point is, the user decides the meaning of the Std_Logic_Vector and in a > similar manner the user decides the meaning of the record element names when > > he/she defines a record type. > Therefore I suggest we take option 2 'match by position' and leave the > element > name matching under the user's control. > In the case of the complex number record: > type complex1 is record > real_part : real; > imag_part : real; > end record; > type complex2 is record -- reversed order of real and imaginary part. > im : real; > re : real; > end record; > The user then can decide whether close type conversion is valid and in this > given case, it is up to the user to provide an element swap function for the > > conversion (or in fact he/she may want to make use of the implied swap > function). > Regards, > Brent. > > > On 30/11/2012 17:27, Jim Lewis wrote: >> Hi Ryan, >> I agree with Peter. I think 3 would be appropriate as a first >> pass. One of the places we will need this is for converting >> types that are created in different instances of a >> generic package. In this case, the types would be >> structured exactly identically. Just for this use case, >> this is may prove to be a really valuable feature. >> >> A slight modification to your example demonstrates >> how mapping by position (case 2) is dangerous and >> how mapping by name (case 1) is unlikely to apply in >> broader situations (as your example also demonstrated): >> >> type complex1 is record >> real_part : real; >> imag_part : real; >> end record; >> >> type complex2 is record -- reversed order of real and imaginary part. >> im : real; >> re : real; >> end record; >> >> I tried playing with syntax for converting two objects >> of the above types and could not come up with anything >> better than what we already have: >> >> signal A, B : complex1 ; >> signal X, Y : complex2 ; >> ... >> >> -- handling elements individually >> A.real_part <= X.re ; >> A.imag_part <= X.im ; >> >> -- using aggregates >> A <= (X.re, X.im) ; >> A <= (real_part => X.re, imag_part => X.im) ; >> >> >> As far as port maps go, if records cannot be individually >> mapped (I did not have a chance to check) like arrays >> can, then we should make it so: >> U1 : E port map ( >> ... >> A.real_part => X.re, >> A.imag_part => X.im, >> ... >> ) ; >> >> Also, perhaps we allow aggregates that do not have expressions >> on the LHS of an association without incurring a delay: >> >> U1 : E port map ( >> ... >> A => (X.re, X.im), >> B => (real_part => Y.re, imag_part => Y.im), >> ... >> ) ; >> >> >> Best, >> Jim >> >> P.S. I also note that MP 1 proposed a bidirectional >> jumper/switch. Which would allow an association between >> two objects without a delay. Particularly interesting >> if the objects are bidirectional ports to the design. >> >> >>> All: >>> >>> I finished the first cut for a closely-related record types proposal. >>> >>> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/RelatedRecords >>> >>> There is one remaining item to be decided since there are several >>> possible rules for declaring two record types closely related. >>> >>> 1. Match record elements by name. >>> 2. Match record elements by position. >>> 3. Match record elements by name and position. >>> >>> Here is some arguments for/against copied from the TWiki page. >>> >>> Rule 3 is the most restrictive and least ambiguous. In other words, it's >>> the safest. And it satisfies my current needs, so I'm content with it. >>> But it's also the most likely to not be useful in "obvious" cases. >>> >>> Rule 2 is similar to the array rule. Array elements are converted by >>> position. But array indices don't usually convey information like record >>> element names. (The exceptions are the new fixed- and floating-point >>> packages, but they have to jump through some hoops to avoid issues with >>> VHDL's willingness to switch bounds and directions on array dimensions.) >>> Also, array elements are homogeneous while record elements typically are >>> not. >>> >>> Rule 1 uses the element names, which typically represent the designer's >>> intent. However, naming is rarely unique (coming up with good names is >>> often hard), so variations are likely. This is my favorite option. >>> >>> Opinions? Feel free to edit the page or respond via email. I'll try to >>> collect any good ideas from the reflector back to the proposal page. >>> >>> --- >>> Ryan Hinton >>> L-3 Communications / Communication Systems West >>> ryan.w.hinton@L-3com.co -- 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 Tue Dec 11 15:47:57 2012
This archive was generated by hypermail 2.1.8 : Tue Dec 11 2012 - 15:48:29 PST