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

On 19/02/2015, at 3:40 am, John.Aasen@kongsberg.com wrote:

You can demonstrate the desirability to use bused 'pins' all the way back schematics. It's a form of abstraction that 'hides' information not infers information (noting there's a default mode for interface lists).

The thing you're trying to accomplish is associating mode with an interface object that is a subtype of a record type in an interface list.  Essentially different record elements can have different interface modes. An interface mode declares the direction of information flow.

Mode conveys whether an interface object can be read and/or updated during simulation.

Should there be limits on the record type, such as not having elements that are record types? This can be asked another way, should there be limits to the level of abstraction you can have on an interface list, and where are those limits?  

You can't declare a type multiple times, each declaration in VHDL is unique. For an interface object to be compatible it has to share the same type declaration. 

An interface object's mode is seen as distinct from it's subtype indication (constraint), associated with the declared interface object(s) and not an attribute as defined in 6.7 (value, function, type, signal or constant that may be associated with one or more named entities in a description).  It's information about the interface object provided to the analyzer, incidentally also human readable in a design specification.

An object of a composite type represents a collection of objects, one for each element of the composite object. A record type is a composite type, objects of which consist of named elements. (5.3.1)

We want to associate mode with objects not types or subtypes. Mode isn't a value, it isn't a function, it isn't a type it isn't a signal or constant object and it isn't a constraint. There isn't a way to determine mode programmatically in a VHDL design description.

John Aasen's proposal
---------------------

Assuming that the declaration of mode is required (or desirable) This looks like the equivalent of  a record type declaration, with added mode:

> interface i_cpu_bus is
>   adr : out   std_logic_vector(15 downto 0);  --Address
>   dat : inout std_logic_vector(15 downto 0);  --Data between master and slave
>   cs  : out std_logic_vector(7 downto 0);  -- ChipSelect-bus from master
>   we  : out std_logic;    --Write enable from master
>   en  : out std_logic;    --Enable from master
>   ack : in std_logic;    --Acknowledge from slave
>   err : in std_logic;    --Error from slave
> end interface;
>  
> --Master entity
> entity master is
>   port (
>     clk : in std_logic;
>     bus : interface i_cpu_bus
>     );
> end entity;

The alternative is that you've created a new object class (interface).

If this were the equivalent of a type declaration, then these would be constraints:

> entity slave is
>   port (
>     clk : in std_logic;
>     bus : conjugated i_cpu_bus
>   );
>  
> -- bus monitor - all interface elements are 'in'
>   port (
>     clk : in std_logic;
>     bus : monitor i_cpu_bus
>   );
>  


given as mode provided with new reserved words. 

You could note that as a mode the concepts of master, slave and monitor may be unduly restrictive.  They could likely be required to be associated with interface object elements (and map to today's modes).  Otherwise your limiting the use of an interface object to a preconceived model, something more likely to occur in some an other HDL rather than VHDL.

Other than potentially for synthesis eligible assertions monitor appear better suited for a primary unit class, convenient for sweeping up all those verification constructs that aren't targets of synthesis.

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

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.

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.

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




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