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 type
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
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 get 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] On Behalf
Of Daniel Kho
Sent: Friday, July 13, 2012 1:14 PM
To: 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 port 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 concept 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);
regards, daniel
On 13 July 2012 23:17, Peter Flake <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] On Behalf
Of
Bailey, Stephen
Sent: 13 July 2012 15:03
To: 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
On 7/13/12 8:56 AM, "Paul Colin Gloster" <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 13:55:06 2012
This archive was generated by hypermail 2.1.8 : Fri Jul 13 2012 - 13:55:13 PDT