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.