RE: [vhdl-200x] Interfaces with normal, conjugated and monitor flavours

From: <John.Aasen@kongsberg.com>
Date: Fri Mar 20 2015 - 02:34:06 PDT
I have written a proposal covering Attributes for Interfaces: http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/InterfaceAttributes

This only covers the attributes part of this discussion, as I think attributes may be used for several of the competing proposals for interfaces.

Comments and improvements are welcome!

John

> -----Original Message-----
> From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On
> Behalf Of Ernst Christen
> Sent: 10. mars 2015 02:52
> To: Tristan Gingold
> Subject: Re: [vhdl-200x] Interfaces with normal, conjugated and monitor
> flavours
>
> On Mon, 09 Mar 2015 08:06:32 +0100, Tristan Gingold <tgingold@free.fr>
> wrote:
>
> > On 07/03/15 01:53, Ernst Christen wrote:
> > > On Fri, 06 Mar 2015 08:05:54 +0100, Tristan Gingold <tgingold@free.fr>
> wrote:
> > >
> > >> On 05/03/15 21:14, Ernst Christen wrote:
> > >>> Brent, Andy, Tristan,
> >
> > [...]
> >
> > > As a general concern, I feel that defining a functionality by example is
> prone to lead to misunderstandings. I am guilty of this as much as the next
> person. Of course, working out every detail is not worthwhile in the early
> stages, but at least some context should be provided. Here is my attempt  to
> make what I proposed somewhat more formal (with reserved words
> between **):
> > >
> > > interface_unit_declaration ::=
> > >    *interface* identifier *is*
> > >       interface_list
> > >    *end* [*interface*] [interface_simple_name] ;
> >
> > I would prefer to name that interface_list_declaration, which
> > describes more accurately: this construct just gives a name to an
> > interface_list.
> >
> No problem, but I think in the end the name for the production should
> correspond to where the construct may appear. I had tried to parallel
> generic_list, parameter_list and port list, but interface list was already taken.
>
> > > I use interface_unit_declaration because there is already an
> interface_declaration in VHDL. Let's for now postulate it is a package
> declarative item. I am not sure yet how to make it useful if declared
> elsewhere (except as a separate design unit, but this doesn't sound right).
> >
> > Or maybe we can rename interface_declaration.  I think this could be
> > declared in any declarative part, as this could be used for
> > subprograms too.
> >
> Makes sense. The reason for my postulate was that in order to allow a
> reference to an interface in a generic clause or a port clause of an entity, it
> has to be declared in a package because the entity declarative region follows
> generic clause and port clause. I hadn't considered other uses yet.
>
> > [...]
> >
> > > Modes: There is a choice to be made whether an interface configuration
> should be able to override a mode appearing in one of the interface
> elements. If not, then interface object declarations must not have a mode.
> This is not a problem because in all interface object declarations with modes
> the mode is optional.
> >
> > For the simpler, I would allow modes in interfaces, and allow overrides.
> >
> There is also a question to the use model. Should a user be able to declare an
> interface "object" by itself, similar to a declaration of a signal object? I can
> see some value in this, but I put "object" in quotes because an interface isn't
> an object in the VHDL sense, but an ordered collection of objects. I called this
> somewhat inconsistently "instantiation" in the next paragraph. Another
> ordered collection of objects is the group, but it's heavy weight because the
> related group template that has to be declared first.
> >
> > > I would argue that if an interface can be instantiated outside of an
> interface list then modes should not be allowed as part of the interface list.
> There may also be some other issues, for example a local signal may be
> declared as a *register* while an interface signal cannot. In addition, there is
> the staticness of an initial value expression: for an interface object the
> expression must be static, for a local object there is no such restriction.
> > >
> > > interface_unit_configuration ::=
> > >    *configuration* identifier *of* interface_simple_name *is*
> > >       interface_unit_configuration_list
> > >    *end* [*configuration*] [configuration_simple_name] ;
> >
> > I don't like that syntax (in particular the use of *configuration*).
> > I would prefer the reuse of *interface*:
> >
> > interface_list_declaration ::=
> >    *interface* identifier *is* *new* name *with*
> >       interface_list_declaration_override
> >    *end* [*interface*] [simple_name]
> >
> > This is of course is addition to the previous rule.
>
> Sure, why not.
> >
> > [...]
> >
> > > There is an issue here: support for genericity. This would require
> combining an interface declaration containing generic types and possibly
> subprograms and packages with an interface declaration containing interface
> object declarations. I have not looked at how this could be done.
> >
> > Genericity is achieved by using generic packages.
>
> I was thinking about an entity declaration with a type generic that is
> referenced in a port declaration of the entity. No package is involved here.
> To bring the same capability to the world of interfaces would require a port
> interface to refer to a generic interface. I have not thought about to make
> this work.
>
> Ernst
>
>
>
>
> --
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
>


________________________________

CONFIDENTIALITY
This e-mail and any attachment contain KONGSBERG information which may be proprietary, confidential or subject to export regulations, and is only meant for the intended recipient(s). Any disclosure, copying, distribution or use is prohibited, if not otherwise explicitly agreed with KONGSBERG. If received in error, please delete it immediately from your system and notify the sender properly.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri Mar 20 02:34:33 2015

This archive was generated by hypermail 2.1.8 : Fri Mar 20 2015 - 02:34:54 PDT