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

Please note that this capability (having some of the elements of a record port unconnected), sets up an additional change to record types that may not be apparent: currently the standard does not allow a subtype of a record type that does not include all elements of the base record type (not exactly sure why, or of what use such all-including subtypes were in the past, but...)

While the record associated with such a port would be the full record, inside the instantiated module, the port would reference such a partial subtype, lacking some of the elements of the base record type.

I am all in favor of allowing record subtypes that are subsets of base record types, but just wanted to make it clear that this represents an additional and perhaps further-reaching change to the language.

Andy D Jones
Electrical Engineering
Lockheed Martin Missiles and Fire Control
Dallas TX

From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Daniel Kho
Sent: Monday, August 20, 2012 3:01 PM
To: vhdl-200x@eda.org
Subject: EXTERNAL: Re: [vhdl-200x] Records with diectional subtypes

Hi Jim,
I like that "en(others)" notation to indicate the rest of the en bits will be left open. And every slave just needs to assign itself to an en bit, and leave the rest open.
Perhaps we could extend its use for other signals in the record as well, not just for elements of signals:
    subtype t_slave is t_cpu_bus port(... en(others): open; others : open);
for the case where we want the rest of the record's elements to be left open.

Also, I'm in favour of having a deferred specification using "<>" like you proposed.

Anyway, allow me to rephrase what you've just mentioned to see if I have the correct understanding.
As for "t_slave(someRange)", we could use this to declare an array of buses, as in the case of multiple slaves.
Then, we could use for-generate as usual:

    -- package
    subtype t_slave is t_cpu_bus port(adr, dat, we, en(array <>) : in; sdt, ack, err : out ; en(others) : open; others : open );

    -- top-level
    signal masterBus : t_master;
    signal slaveBus : t_slave(7 downto 0);

    slaves: for i in 7 downto 0 generate
        i_slave: entity work.slave(rtl) port map(
            clk=>clk,
            bus=>slaveBus(i)
        );
    end generate slaves;

Here, the "<>" notation should match an element from an array of t_slaves. As in the example, slaveBus(7) would map to en(7), and so forth.

regards, daniel
On 21 August 2012 02:47, Jim Lewis <Jim@synthworks.com<mailto:Jim@synthworks.com>> wrote:
Hi Brent,
So if we allow breaking down ports like that, then perhaps we
need something more - maybe it needs to be a slice and the
slice needs to be unconstrained - and then we would need a way
to specify others being open in a more generic sense.

Perhaps we need an unconstrained/deferred specification such as one
of the following (but not necessarily both):
subtype t_slave is t_cpu_bus port(adr, dat, we, en(<>) : in; sdt, ack, err : out ; en(others) : open );
or:
subtype t_slave is t_cpu_bus port(adr, dat, we, en(array <>) : in; sdt, ack, err : out ; en(others) : open );

Then we could use it as one of the following (but not necessarily both):
t_slave(7 downto 7)
or
t_slave(7)

Jim
Hi Peter,
I notice that Jim embedded his comments in the TWiki page. As I know not how
to do this, nor given my verbosity, do I think that I should be allowed
to ;-), I will limit myself to Emails.
My question is embedded below:
On 16/08/2012 21:07, Jim Lewis wrote:
Hi Peter,
In the Block Interface proposal, "Candidate: Records with diectional subtypes":
http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/BlockInterfaces#Candidate_Records_with_direction

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 and never does a write):

subtype t_slave is t_cpu_bus port(adr, dat, en : in; sdt, ack, err : out; we : open);

Can we allow some ports to not use all elements?

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_(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_slave is t_cpu_bus port(adr, dat, we, en(1) : in; sdt, ack, err : out ; en(7 downto 2), en(0) : open );
So if I want to instantiate the full 8 slaves (as per your example) would I need 8 separate subtype declarations?
subtype t_slave0 is t_cpu_bus port(adr, dat, we, en(0) : in; sdt, ack, err : out ; en(7 downto 1) : open );
subtype t_slave1 is t_cpu_bus port(adr, dat, we, en(1) : in; sdt, ack, err : out ; en(7 downto 2), en(0) : open );
...
subtype t_slave5 is t_cpu_bus port(adr, dat, we, en(5) : in; sdt, ack, err : out ; en(7 downto 6),
en(4 downto 0) : open );
...
subtype t_slave7 is t_cpu_bus port(adr, dat, we, en(7) : in; sdt, ack, err : out ; en(6 downto 0) : open );
or have I misunderstood how this is to work?

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

All questions also on the twiki page.

Best,
Jim

--
Regards,
         Brent Hayhoe.
Aftonroy Limited                            Telephone: +44 (0)20-8449-1852<tel:%2B44%20%280%2920-8449-1852>
135 Lancaster Road,
New Barnet,                                    Mobile: +44 (0)79-6647-2574<tel:%2B44%20%280%2979-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* <http://www.mailscanner.info/>, and is
believed to be clean.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com<mailto:Jim@SynthWorks.com>
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787
Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
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<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.