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 Sun Dec 9 13:52:17 2012
This archive was generated by hypermail 2.1.8 : Sun Dec 09 2012 - 13:52:50 PST