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

 From your interface suggestions, I thought that I'd detail and adapt them to a 
possible solution.

It looks quite concise and a nice first attempt.

What do you think?

So the record and signals:-

    type r_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 r_cpu_bus;

    signal s_rst:     std_logic;
    signal s_clk:     std_logic;
    signal s_cpu_bus: r_cpu_bus;



The interface definition to associate the modes for master and slave ports with 
the record type.

I've included the short attribute option (defining the slave port) as a comment
with an attribute of converse/conjugate/inverse/opposite etc, at the end:-

interface i_cpu_bus of r_cpu_bus is
    port master(
       adr: out;
       dat: inout;
       cs:  out;
       we:  out;
       en:  out;
       ack: in;
       err: in
    );
    port slave(
       adr: in;
       dat: inout;
       cs:  in;
       we:  in;
       en:  in;
       ack: out;
       err: out
    );
--   port slave(master'converse);
end interface i_cpu_bus;



This is how they would be used to encapsulate the mode and type together in an
entity declarations:-

entity cpu_master is
    port(
       rst:     in std_logic;
       clk:     in std_logic;
       cpu_bus: i_cpu_bus.master
    );
end entity cpu_master;

entity cpu_slave is
    port(
       rst:     in std_logic;
       clk:     in std_logic;
       cpu_bus: i_cpu_bus.slave
    );
end entity cpu_slave;



And finally the normal record use when instantiating components:-

cpu_master_inst: cpu_master
    port map(
       rst      => s_rst,
       clk      => s_clk,
       cpu_bus  => s_cpu_bus
    );

cpu_slave_inst: cpu_slave
    port map(
       rst      => s_rst,
       clk      => s_clk,
       cpu_bus  => s_cpu_bus
    );



  On 28/02/2015 18:01, Tristan Gingold wrote:
> 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.
>
>


-- 

Regards,

         Brent Hayhoe.

Aftonroy Limited                            Telephone: +44 (0)20-8449-1852
135 Lancaster Road,
New Barnet,                                    Mobile: +44 (0)79-6647-2574
Herts., EN4 8AJ,  U.K.                          Email: Brent.Hayhoe@Aftonroy.com

Registered Number: 1744190 England.
Registered Office:

4th Floor, Imperial House,
15 Kingsway,
London, WC2B 6UN, U.K.


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