Re: [vhdl-200x] Closely related record types

From: Brent Hayhoe <>
Date: Sun Dec 09 2012 - 13:51:09 PST
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).

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 <= ;
>  A.imag_part <= ;
> -- using aggregates
>   A <= (, ;
>   A <= (real_part =>, imag_part => ;
> 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 =>,
>   A.imag_part =>,
>   ...
>  ) ;
> 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 => (,,
>   B => (real_part =>, imag_part =>,
>   ...
>  ) ;
> 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.
>> 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



         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:

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