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

From: <john.aynsley@doulos.com>
Date: Wed Aug 22 2012 - 04:10:29 PDT

Don't you have an issue with the concepts of type vs subtype and the determination of drivers? Types get resolved statically, subtypes are not (in general) determined until run-time. Is it not the case that pushing mode info into the subtype makes it too late to determine the drivers of the signals? How is this supposed to be implemented (in the tool)?

Apart from that, the notion of pushing modes into subtypes seems to contradict the conceptual framework of VHDL. But perhaps that's just me being unimaginative ;-)

Cheers,

John A

-----owner-vhdl-200x@eda.org wrote: -----
To: vhdl-200x@eda.org
From: Brent Hayhoe
Sent by: owner-vhdl-200x@eda.org
Date: 08/21/2012 11:18PM
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 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.
Received on Wed Aug 22 04:11:27 2012

This archive was generated by hypermail 2.1.8 : Wed Aug 22 2012 - 04:11:57 PDT