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

On 21/02/15 17:46, David Koontz wrote:
[...]

 > An alternative
> --------------
>
> So is there away to provide mode to record elements without mixing the concepts of type and objects?
>
> The idea is to use a specification, "...which may be used to associate additional information with a VHDL description. A specification associates additional information with a named entity that has been previously declared. There are three kinds of specifications: attribute specifications, configuration specifications, and disconnection specifications."
>
> Implemented by adding a fourth specification class for providing mode to record types in interface lists.
>
> How about something like:
>
> type i_cpu_bus is record
>      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
> end record;
>
> A mode map specification:
>
> map master (
>      adr => out,
>      dat => inout,
>      cs  => out,
>      we  => out,
>      en  => out,
>      ack => in,
>      err => in
> );

I think you need to specify that the map refer to i_cpu_bus type. See below.

> And an interface object declaration:
>
>      port (
>          somebus:  map(master)  i_cpu_bus
>      );
>
> The two uses of the reserved word map would be unique either where a
 > specification is appropriate or a mode can be provided.
>
> There could be rules requiring mapped mode to be only used on record
 > types, named mode association to have a matching element, default mode
 > in for elements not mentioned, and others mode. Positional mode
 > association could be possible, but doesn't make a lot of sense.
>
> The parentheses indicate a a separate scope, not preventing the mode
 > map identifier from being used elsewhere in the description.
>
> A mode map specification would not occur in an interface declaration.
>
> As long as this isn't "map master of i_cpu_bus (" this is the equivalent
 > of a compound association of mode with element names and not element 
type.
 > A mode map could be used for any compatible record type, where for
 > instance the subtype indication of record elements could vary in two
 > different types, or be in different order with named mode association.

I really think that this should be 'master of i_cpu_bus', so that the 
left part of associations are known.  This then could even be a subtype.

> The idea of 'conjugated' doesn't map onto mode gracefully. The mode
 > of an interface object is additional information, not an object to be
 > manipulated. Because mode isn't a value you can't manipulate it with
 > operators, functions or attributes. Mode isn't associated with type.

I don't agree with that point of view.  To me, mode in interfaces are
just mode to be used for interfaces.  There is no real need to
manipulate the mode (it's not unlike resolution function).

> A mode map wouldn't be eligible for configuration, requiring the
 > design description to conform to limitations for mode.
 >  This reasoning includes generics.

I much prefer the interface notation: much easier to understand, safer
and finally shorter.

Tristan.


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