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 12:14:40 2012