RE: [vhdl-200x] Records with diectional subtypes

I think that adding generics to subtypes, though useful, would require a lot
of work in the implementation.

An alternative is just to use the expression bus.en(id) in the slave
architecture and pass the whole array through the port. The unused wires
would presumably be trimmed by synthesis.

Regards,

Peter Flake

From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of
Brent Hayhoe
Sent: 21 August 2012 23:17
To: vhdl-200x@eda.org
Subject: Re: [vhdl-200x] Records with diectional subtypes

Regardless of what has been suggested so far, I'm going to rewrite the
example with Jim's suggested new syntax and a few modification's of my
own. Please pull it apart and see if it makes sense.

So, types in a package first:

package cpu_bus_pkg is

  type t_cpu_bus is record

    adr : std_logic_vector(15 downto 0); --Address

    dat : std_logic_vector(15 downto 0); --Data from master to slave

    we : std_logic; --Write enable from master

    en : std_logic_vector(7 downto 0); --Enable from master

    sdt : std_logic_vector(15 downto 0); --Data from slave to master

    ack : std_logic; --Acknowledge from slave

    err : std_logic; --Error from slave

  end record;

  subtype t_master is t_cpu_bus port(

                                  adr, dat, we, en : out;

                                  sdt, ack, err : in);

  subtype t_id is natural range 7 downto 0;

  subtype t_slave is t_cpu_bus generic(

                                  j : t_id)

                                port(

                                  adr, dat, we, en(j) : in;

                                  sdt, ack, err : out;

                                  en(others) : null);

end package cpu_bus_pkg;

--Master entity

use work.cpu_bus_pkg.all

entity master is

  port (

    clk : in std_logic;

    bus : t_master

  );

end entity master;

--Slave entity

use work.cpu_bus_pkg.all

entity slave is

  generic (

    id : t_id

  );

  port (

    clk : in std_logic;

    bus : t_slave(id) --generic mapped through to subtype

  );

end entity slave;

--Top level

use work.cpu_bus_pkg.all

  signal cpu_bus : t_cpu_bus;

  i_master : master

    port map (

      clk => clk,

      bus => cpu_bus

    );

  i_slave_id : slave

    generic map (

      id => 4 --internally 'bus.en(id)' is the only enable port that
exists

    )

    port map (

      clk => clk,

      bus => cpu_bus --and is mapped to 'cpu_bus.en(4)'

    );

"JimLewis Question: Can we extend this to also allow open in the subtype?
The
          following slave does not use the we element (perhaps it is read
only): "

BrentHayhoe: I've altered this to 'null' rather than 'open'. To me 'open'
infers
          the port is still there on the slave entity, just not connected. A
'null'
          port would mean it doesn't exist within the slave entity. From the
top
          level instantiation point of view, it is a WOM. It has no driver
and
          cannot be read, but it provides connectivity at this level.

"JimLewis Question: Can we allow some ports to not use all elements? In the
          following, the slave does not use all of the en "

BrentHayhoe: However we look at it, we definitely need a form of generic
          mechanism in the slave subtype.

"JimLewis Question: Inside the slave is en seen as en(1) or just en? Is
there
          a notation that allows just en? "

BrentHayhoe: I think it has to be seen as 'en(id)' as the generic needs to
be
          mapped for the instantiation.

"JimLewis Question: Can we use others with open? "

BrentHayhoe: Using 'others' is cool I think.

This suggestion has added a generic part to the 'port mode' of the record
subtype, is it viable?

Can anyone rewrite this example using deferred mapping as Jim suggested:

    subtype t_slave is t_cpu_bus port(

                                   adr, dat, we, en(array <>) : in;

                                   sdt, ack, err : out;

                                   en(others) : open);

-- 
 
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  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.