Closely Related Record Types

Proposal Information

• Who Updates: RyanHinton
• Date Proposed: 2012-11-08
• Date Last Updated: 2012-11-29
• Priority:
• Complexity:
• Focus: General Language

Language change specification

LCS2016_075

Summary

Define closely-related record types to allow type conversions between record types. This is analogous to the definition for closely-related types (1076-2008 section 9.3.6). The rules for closely-related types are summarized here for easy reference.

• A type is closely related to itself.
• Any abstract numeric type is closely related to any other abstract numeric type.
• Two array types are closely related if and only if the types have the same dimensionality and the element types are closely related.

No other types are closely related.

Requirements

Support type conversions between record types.

Related Issues: None = General

2016_MeetingOctober20 - can be handled by map functions. (RyanHinton, 2016-12-20:) A hand-written conversion function would be much simpler than using a map function. This proposal addresses a simpler and more fundamental issue, though the use cases given are similar to those handled by interfaces.(end RyanHinton)

Competing Issues: None at this time

Candidate: Conversion by name and/or position

Contributors: RyanHinton,

There are several options for how to define closely-related record types.

1. Match record elements by name.
2. Match record elements by position.
3. Match record elements by name and position.

The fourth alternative, matching record elements solely by type, is not tenable since the element types will not be distinct in general. Of course, each option requires that the corresponding record elements are of closely-related types. Following are some brief arguments for/against each rule.

• Rule 3 is the most restrictive and least ambiguous. In other words, it's the safest. 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.

For example, consider the following types.

type foo is record 
  a : integer;
  b : real;
  c : boolean;
end record;

type bar is record
  c : boolean;
  b : real;
  a : integer;
end record;

type baz is record
  c : integer;
  b : real;
  a : boolean;
end record;  

By rule 1, foo and bar are closely-related. By rule 2, foo and baz are closely-related. By rule 3, none of the types are closely-related (except to themselves). The narrowest, most-restrictive option is rule 3. And it's probably not too restrictive for the use cases I have in mind. But in other cases I can imagine being frustrated that I can't convert between record types with the same names in a different order, or the exact same types (same order) but with different names. In particular, converting from or to a type in a third-party package is a key use case.

Use cases

Converting between package versions

Contributors: RyanHinton,

Imagine one of the proposed packages that uses record types is standardized in VHDL-2014, but I've been using the VHDL-2008 compatible package for a few years while the process progresses. This is similar to the current situation with the fixed-point packages. So now I'm starting a design using a record type from the new standard package, but I have old packages and components that use the record type from the compatibility package. To interface new code to old code, I need either

• to modify the compatibility package to convert to/from the new standard types (bad idea, won't compile with old standard any more),
• the new package to reference the compatibility package (bad idea),
• to write a new package that defines conversion functions back and forth,
• to hand-code or write conversion functions wherever I need to use one of my legacy design units,

or similar. None of these are great options, though the new package is probably the least offensive. Adding closely-related record types to the standard should allow me to use type conversions to convert back and forth -- the perfect solution, no new code.

Interfacing between library or third-party code

Contributors: RyanHinton,

Design units in a company "library" and design units from IP cores (possibly encrypted) may define their own record types. I want to use type conversions to interface between blocks that have identical record definitions. This is a case where both record types are "closed", i.e. I can't modify either component to use the type from the other component/package. So again I have to write a third package or convert manually.

This is the case where conversion rules (2) may come in handy. Some people like to use 1-3 letter record element names, while others like to use very long, descriptive element names. So it's quite likely that the records from different sources will have different names. For example,

type complex1 is record
  real_part : real;
  imag_part : real;
end record;

type complex2 is record
  re : real;
  im : real;
end record;

(Yes, there is already a standardized math_complex package. This is just for illustration.) Of course, packages from different sources are just as likely to define the record elements in a different order as to use different element names, so this is not a strong argument for allowing rule (2).

How hard are the conversions?

Contributors: JimLewis - 2012-12-20,

If we were to only support rule 3, record elements must match by name and position and field types must be closely related, how hard is to use existing VHDL language constructs to handle the remaining conversions (names or positions differ).

Using Complex1 and Complex2 as defined above we can do the following:

 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) ; 

We can handle these in a similar fashion in port maps:

U1 : E port map ( 
  ... 
  A.real_part => X.re, 
  A.imag_part => X.im, 
  ... 
) ; 

The current language includes a delta cycle delay when the following are done, maybe we should consider removing that:

U1 : E port map ( 
  ... 
  A => (X.re, X.im), 
  B => (real_part => Y.re, imag_part => Y.im), 
  ... 
 ) ;

Supporters

-- RyanHinton - 2013-05-02 -- Brent Hayhoe -2013-15-02

Add your signature here to indicate support for this proposal.