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

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.com
>
>
>


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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