RE: EXTERNAL: Re: [vhdl-200x] Directional records proposal

Because the SV folks aren't as bright as the VHDL folks would be my guess. But that's to be expected, after all aren't these the same folks that think Verilog is a good language anyway?

As to the methods and procedures that define interface protocols that you alluded to in an earlier post: Yes an interface would likely want to have protocols defined for how the interface functions, but there is nothing that needs to be extended in the current VHDL allow this. Not even the item being discussed about allowing direction to records is required. However, if allowing procedures to also use the new type of record is implemented, the interface to those procedures could then be simplified to just supply the collection of signals using the record.

The other consideration when using the extension of the record type for use with procedures would be that procedures (unlike entities) can be overloaded. The overloading is based (in part) on the modes of the variables and signals on the interface. Hopefully that is solvable in a way that the compiler can still do the full checking, just tossing this out as something else to keep in mind

Kevin Jennings

________________________________________
From: owner-vhdl-200x@eda.org [owner-vhdl-200x@eda.org] On Behalf Of Bailey, Stephen [stephen_bailey@mentor.com]
Sent: Friday, July 13, 2012 3:26 PM
To: vhdl-200x@eda.org
Subject: Re: EXTERNAL: Re: [vhdl-200x] Directional records proposal

If structs (records) and modports were all that were needed, why did SV
bother creating interfaces?

------------
Stephen Bailey
Director of Emerging Technologies, DVT
Mentor Graphics
www.Mentor.com

On 7/13/12 9:17 AM, "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:54:04 2012