RE: [vhdl-200x] Record slices (branched from Directional records proposal)

Ryan,

You bring up some good points.

Regarding ambiguity between an enumerated type and a set of record element names, it seems to me that if it is legal to use this (assuming t1 and t2 had elements of some subtype of integer):

Constant const_t1 : t1 := (others => 0);
Constant const_t2 : t2 := (others => 0);

Then the complier ought to be able to figure out ranges that use the same identifying strings, based on the context and therefore type of the aggregate expression. And if not, you could always use T1'(others => 0);

As far as record slice ranges, perhaps the syntax from your example should be:

    var1 := const_T1.a; -- normal record syntax
    var2 := const_T1.(a to b); -- what type is this? a new anonymous record type?
    var3 := const_T2(a to b); -- and now a record (above) looks like an array?!

Note the addition of dot notation before the range on const_t1.

Var2 would have had to have been declared with a named subtype of T1, since T1 is not unconstrained. Therefore the type in question is not anonymous.

Subtype v2 is t1 range a to b;
Variable var2 : v2;

So you could also write:
Var2 := const_t1.v2; -- ?!

Andy D Jones
Electrical Engineering
Lockheed Martin Missiles and Fire Control
Dallas TX

From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of ryan.w.hinton@L-3com.com
Sent: Friday, July 13, 2012 3:55 PM
To: vhdl-200x@eda.org
Subject: EXTERNAL: RE: [vhdl-200x] Record slices (branched from Directional records proposal)

Andy and Daniel:

VHDL doesn't currently allow ranges for record elements. Ranges are limited to scalar types. Currently you can use | and OTHERS in record aggregates.

I think it's dangerous to allow slicing records. Perhaps not wrong, but dangerous. The effect is an implicitly declared enumerated typ e including the element identifiers in the order they are given in the record type declaration. But what if there is a conflict with another enumerated type? Because the record element names type is implicitly declared, you can't use a selected name. Here's a contrived example.

  type T1 is record
    a : integer;
    b : real;
    c : std_logic;
    d : time;
  end record;
  -- with the record slices feature, we have an implicitly declared enumerated
  -- type with values {a, b, c, d}

  type T2 is (a, b, c, d); -- now conflicting identifiers require selected names
&nbs p; type T3 is (a, b, c, d); -- more conflicts

  type AT2 is array (T2) of integer;
  type AT3 is array (T3) of integer;

  constant const_T1 : T1 := (a => 0, b => 1.0, c => 'X', d => 0 ns);
  constant const_T2 : T2 := (a => 0, b => 100, c => 200, d => 3456);

  ...

    for ii in T1'range loop -- should the record type then have a range attribute?
      null;
    end loop;

    for ii in a to d loop --ILLEGAL: we can't create a loop over the T1 fields
      write(ln, const_T1.ii); -- allow "indexing" by variable? this feels wrong
    end loop;

    for ii in T2'(a) to T2'(d) loop -- but we CAN create a loop over the T2 fields
      write(ln, const_T2(ii));
    end loop;

    var1 := const_T1.a; -- normal record syntax
    var2 := const_T1(a to b); -- what type is this? a new anonymous record type?
    var3 := const_T2(a to b); -- and now a record (above) looks like an array?!

Interestingly, the record literal syntax already looks very much like the array literal syntax. This is making it hard for me to unequivocally reject your idea. :-)

Do we allow "indexing" the record by a variable or constant? It seems the only way to do this is in a loop or to create an object of this type -- which we can't do since in the example above because the enumerated type is implicit and conflicted.

I suppose we could ge t access to the type through an attribute, something like T1'RANGE_TYPE or just T1'RANGE. That would solve some of the problems. But it still feels messy.

There are so many open issues that I'm leery of the idea. You may be able to sway me with a brilliant new syntax, but I'm against record slices for now.

- Ryan

From: owner-vhdl-200x@eda.org<mailto:owner-vhdl-200x@eda.org> [mailto:owner-vhdl-200x@eda.org] On Behalf Of Daniel Kho
Sent: Friday, July 13, 2012 1:14 PM
To: vhdl-200x@eda.org<mailto:vhdl-200x@eda.org>
Subject: Re: EXTERNAL: Re: [vhdl-200x] Directional records proposal

Andy,
<quote>
One potential problem with the mode_vector is that there is nothing until the port declaration that binds a port mode declaration to a record type. How are the indices mapped to the record elements? Is the first record element always mapped to index 0, or just 'left, or what? Having a por t mode bound to a record type in its declaration allows the compiler to check the declaration for you (say, in a package, before it is ever used or associated with a port).

Another potential issue is, how would we extend type_mode to handle records of records (where the sub-record has its own mode_vector)?
</quote>

Yes, your concerns are valid.
Using record types in this case would make the solution clear and unambiguous. At first, I didn't think we needed to bind the port mode to the record type, but after reading your comments, I tend to agree that using arrays would raise more questions on ambiguity (such as how indices are mapped).

Your suggestion on extending the concep t of slices to record types makes sense. Not too sure if that's possible with the current version of the standard.
However, I believe we could specify ranges for record types?
(Just as an example, not to be used with the concept of port modes):
signal m_master: t_cpu_bus := (adr to dat => someData, sdt => someData, others => gnd);

Anyway,
<quote>
Port mode m_master of t_cpu_bus is (t_cpu_bus_mosi => out, others => in);
Port mode m_slave of t_cpu_bus is (t_cpu_bus_mosi => in, others => out);
Port mode m_monitor of t_cpu_bus is (others => in);
</quote>

Yes, brilliant use of record slices for port mode definition. But please also allow specifying record ranges as well (the following should be equivalent to using record slices):
Port mode m_master of t_cpu_bus is (adr to en => out, others => in);
Port mode m_slave of t_cpu_bus is (adr to en => in, others => out);
Port mode m_monitor of t_cpu_bus is (others => in);

rega rds, daniel
On 13 July 2012 23:17, Peter Flake <flake@elda.demon.co.uk<mailto:flake@elda.demon.co.uk>> wrote:
The SV interface does not have directions. The equivalent construct is
"modport", as was mentioned earlier in this thread.

Since VHDL already has the ability to bundle signals in a record, it does
not need a new construct for the simplest usage of "interface".

So what is needed is something that is a record with directions and can be
connected to a record without directions, maybe with subsetting rules.

Peter Flake

-----Original Message-----
From: owner-vhdl-200x@eda.org<mailto:owner-vhdl-200x@eda.org> [mailto:owner-vhdl-200x@eda.org<mailto:owner-vhdl-200x@eda.org>] On Behalf Of
Bailey, Stephen
Sent: 13 July 2012 15:03
To: vhdl-200x@eda.org<mailto:vhdl-200x@eda.org>
Subject: Re: EXTERNAL: Re: [vhdl-200x] Directional records proposal

The equivalent construct in SystemVerilog is "interface." Not equivalent to
user-defined modes, but equivalent to the general capability of this
discussion: bundling all the elements of an interface in a handy package.
 Once you go down this route, it becomes clear that it is more than bundling
of interface elements of different modes. Interfaces have their own
behavioral (functional) and annotatable characteristics.

------------
Stephen Bailey
Director of Emerging Technologies, DVT
Mentor Graphics
www.Mentor.com<http://www.Mentor.com>

On 7/13/12 8:56 AM, "Paul Colin Gloster" <Colin_Paul_Gloster@ACM.org<mailto:Colin_Paul_Gloster@ACM.org>>
wrote:

>On Friday the 13th of July 2012, Jones, Andy D emailed:>|----------------------------------------------------------------------
>|---
>--|
>|"VHDL has built in types, but also allows the user to define new types
> |
>|and subtypes in terms of built-in types or previously defined types.
> |
>|
> |
>|VHDL has built-in port modes (in, out, inout, buffer, etc.). [. . .]"
> |
>|----------------------------------------------------------------------
>|---
>--|
>
>Andy,
>
>VHDL also allows a user to create a new type (enumeration)
>independently of already existing types. I was asking for clarification
>as to whether you wanted to be able to create completely new modes, or
>whether you wanted what everyone else correctly assumed you meant.
>
>|----------------------------------------------------------------------
>|---
>--|
>|"User-defined modes is what I am calling this ability to define new
> |
>|composite modes for composite (record) types. [. . .]
> |
>|
> |
>|Maybe something like "composite modes" is a more appropriate
>nomenclature? |
>|
> |
>|I'm not married to any nomenclature for this feature; [. . .]"
> |
>|----------------------------------------------------------------------
>|---
>--|
>
>One name is not necessarily better than another.
>
>Yours sincerely,
>Colin Paul
Received on Fri Jul 13 15:25:26 2012