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

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 



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.