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

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,
>
> [...]
>
> Focusing on the pure AMS part:
>
> > I am advocating that an interface be more flexible than this, that it should be extensible to allow the inclusion of terminals and quantities. This precludes a type as a starting point, and it makes the interface concept a new construct that bundles object declarations, something like
> >
> >    interface r_cpu_bus is
> >        adr:  std_logic_vector(15 downto 0);  -- Address
> >        dat:  std_logic_vector(15 downto 0);  -- Data between master and slave
> >        cs:   std_logic_vector(7 downto 0);   -- ChipSelect-bus from master
> >        we:   std_logic;                      -- Write enable from master
> >        en:   std_logic;                      -- Enable from master
> >        ack:  std_logic;                      -- Acknowledge from slave
> >        err:  std_logic;                      -- Error from slave
> >        terminal t1: electrical_vector(7 downto 0);  -- Added to demonstrate VHDL-AMS
> >            quantity q: real                    -- Added to demonstrate VHDL-AMS
> >    end interface r_cpu_bus;
>
> To my understanding, there is an issue with 'quantity': a 
> interface_quantity_declaration is very different from a 
> quantity_declaration, so you cannot create objects using an interface:
>
The two declarations have a different form. The interface quantity declaration corresponds roughly to a free quantity declaration with the mode added, pretty much the same way as a signal declaration differs from an interface signal declaration. Besides that, quantity ports have modes (just in or out) and constraints related to the modes for port association elements. Again, similar to signals. However, I do not see a difficulty that would make a quantity creation impossible.

> interface xxx : r_cpu_bus;
>
> This works with signals and terminals but not with a quantity.
> I might be wrong, but to my understanding this is a serious issue when
> considering AMS.  (And unfortunately, I have no ideas to solve that
> except big hammer rule as explained below but I am not an AMS expert).
>
I am not sure what you are referring to here, i.e. why you think that a quantity as part of an interface would not work. Are you talking about instantiating an interface by itself, not as part of an interface list? If so, there may be some restrictions for quantities in an interface, but I don't see this as a major issue. It may even be possible to overcome it in some fashion, but the details should be addressed by P1076.1. Right now I am only concerned that the construct to be defined is not DOA for AMS.

> According to your syntax, we could add object class like constant (?), 
> variable or signal (the latter being the default).  That would be nice,
> but don't forget that variable and signal are almost always
> incompatible.  One possible solution is to not allow object declaration
> from an interface where not possible (this would include quantity).

I added interface constant, interface variable and interface file to accommodate the formal parameters of subprograms. Depending on where an interface is instantiated (in a port list, a parameter list, a generic list, ...), semantic rules would have to exclude certain interface declarations, just like it's done for an interface list that is the basis of a generic clause, a port clause, and a formal parameter list. Some ideas are sketched out below.

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 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).

The interface elements in the interface_list are restricted depending on where the interface unit is instantiated:
- in a port list: interface signal declaration, for 1076.1 also interface terminal declaration and interface quantity declaration
- in a generic list: interface constant declaration, interface type declaration, interface subprogram declaration, interface package declaration, for 1076.1 also interface nature declaration
- in a formal parameter list: interface signal declaration, interface constant declaration, interface variable declaration, interface file declaration
It's possible to syntactically annotate the use of an interface list, by declaring it as *port interface*, *generic interface*, or *parameter interface*. No new reserved words, except *interface* are required. Doing this explicitly or just semantically is a choice to be made.

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. 

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] ;

The interface configuration may appear in a package. Should it be allowed somewhere else? I can think of an entity declaration, but it would have to precede the generic clause, or alternatively we would have to define an interface_unit_configuration as another interface element. This would also make it available in a subprogram declaration, but I haven't thought through the implications.

interface_unit_configuration_list ::=
   interface_unit_configuration_element { ; interface_unit_configuration_element }

interface_unit_configuration_element ::=
   interface_element_simple_name : interface_qualifier

interface_qualifier ::=
   mode | type_name | subprogram_name | package_name

The interface qualifier supports configuring the mode and the generic type, subprogram, or package, depending on the kind of the interface element. The allowable mode for an interface element depends on the object class of the interface element.

To allow an interface to be used, the existing interface declaration has to be extended:

interface_declaration ::= 
     interface_object_declaration
   | interface_type_declaration
   | interface_subprogram_declaration
   | interface_package_declaration
   | interface_unit_declaration

This would also allow an interface to become part of an interface.

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.

Ernst

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.