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

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,
>>
>> [...]
>>
>> 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.

Ah right, I forgot about free quantities.  My understanding is that
they weren't often used but at least we have something that would
work with AMS.

[...]

> 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 would prefer to name that interface_list_declaration, which
describes more accurately: this construct just gives a name
to an interface_list.

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

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

Make sense.

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


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

> The interface configuration may appear in a package.

The override may appear anywhere an interface may appear.

[...]

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

Tristan.


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