Re: [vhdl-200x] Directional records proposal

Ryan,
I'm fine with Andy's original proposal (or any simple variant). I agree
that implementing different alternatives that do the same thing would
increase the cost of implementation (especially tool vendors).
There are a couple other scenarios where I'd like to use directional
records: with procedures, and possibly also clocked functions (as was
proposed previously for pipelining).

regards, daniel

On 20 July 2012 02:23, <ryan.w.hinton@l-3com.com> wrote:

> Brent:****
>
> ** **
>
> This seems a complicated way to do something simple. By breaking the
> signals out of the record, no new syntax is required. But I think the
> point of your suggestion is to allow keeping all the signals in one record.
> ****
>
> ** **
>
> We discussed this in the telecon this morning. For this particular use
> case (system bus), consider the WISHBONE approach. They define signals for
> a MASTER interface and signals for a SLAVE interface. Then any complexity
> like multiple masters, multiple slaves, arbitration, etc. they encapsulate
> in the INTERCON block. If used appropriately, this encourages reuse: any
> master can connect to a compatible WISHBONE bus, and any slave can connect
> to a compatible WISHBONE bus. They don't need to worry about all the
> possible bus topology permutations.****
>
> ** **
>
> In short, I'm asking for a more compelling use case. Directional records,
> to me, are a convenient, "icing on the cake" type of language feature. It
> makes sense to group related items in one record regardless of whether
> they're inputs or outputs. It's a benefit, but not a huge benefit. But
> the proposals have required increasingly heavy and invasive language
> changes. I am inclined to vote against a feature with a moderate benefit
> that requires significant changes to the language. It's a cost-benefit
> thing.****
>
> ** **
>
> So again, can someone provide a better use case (i.e. increase the
> benefit)? If not, I want to decrease the cost by only implementing
> something like Andy's original proposal.****
>
> ** **
>
> Thanks!****
>
> ** **
>
> - Ryan****
>
> ** **
>
> *From:* owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] *On
> Behalf Of *Brent Hayhoe
> *Sent:* Tuesday, July 17, 2012 3:38 PM
> *To:* vhdl-200x@eda.org
>
> *Subject:* Re: [vhdl-200x] Directional records proposal****
>
> ** **
>
> Hi Guys,****
>
> ****
>
> I'd forgotten just how important having an 'unconnected' port mode is
> until I ****
>
> read Peter's post:****
>
> ****
>
> > ****
>
> > From: Peter Flake <flake@elda.demon.co.uk> <flake@elda.demon.co.uk> ****
>
> > Date: Mon Jul 16 2012 - 03:59:03 PDT****
>
> > ****
>
> > Hi Daniel, ****
>
> > ****
>
> > A bus master may have several slaves, each with a control signal back to
> the ****
>
> > master. To represent the bus with a single record, there must be an
> array ****
>
> > of control signals which are all connected to the master but not all are
> ****
>
> > connected to each slave. This has already been discussed earlier in the
> ****
>
> > thread. ****
>
> > ****
>
> > Brent Hayhoe's recent suggestion tackles this problem. ****
>
> > ****
>
> > ****
>
> > Regards, ****
>
> > ****
>
> > Peter ****
>
> > ****
>
> ****
>
> ****
>
> So, let's re-define the record in a recursive manner: ****
>
> ****
>
> type master_r is ****
>
> record ****
>
> adr_vl : std_logic_vector(15 downto 0); -- Address ****
>
> dat_vl : std_logic_vector(15 downto 0); -- Data from master to
> slave ****
>
> we_l : std_logic; -- Write enable from
> master ****
>
> en_l : std_logic; -- Enable from master ****
>
> ****
>
> end record master_r; ****
>
> ****
>
> type slave_r is ****
>
> record ****
>
> sdt_vl : std_logic_vector(15 downto 0); -- Data from slave to
> master ****
>
> ack_l : std_logic; -- Acknowledge from slave
> ****
>
> err_l : std_logic; -- Error from slave ****
>
> ****
>
> end record slave_r; ****
>
> ****
>
> ****
>
> and we need a means of generically defining slave ports, so lets ****
>
> have an array for 2 slaves:****
>
> ****
>
> subtype slave_jrt is natural range 2 downto 1;****
>
> type slave_at is array(slave_jrt) of slave_r;****
>
> ****
>
> ****
>
> to give us our overall record type of:****
>
> ****
>
> type cpu_bus_r is ****
>
> record ****
>
> master_rl : master_r; -- bus from master ****
>
> slave_al : slave_at; -- buses from slaves ****
>
> ****
>
> end record cpu_bus_r; ****
>
> ****
>
> ****
>
> which now leads to a more compact entity declaration: ****
>
> ****
>
> entity master is ****
>
> port ( ****
>
> clk_i : in std_logic; ****
>
> bus_rio : record ( ****
>
> master_rl : out master_r; ****
>
> slave_al : in slave_at ****
>
> ) cpu_bus_r; ****
>
> rst_i : in std_logic ****
>
> ); ****
>
> end entity master; ****
>
> ****
>
> ****
>
> and generically for the slaves:****
>
> ****
>
> entity slave is ****
>
> generic ( ****
>
> inst_jg : slave_jrt****
>
> );****
>
> port ( ****
>
> clk_i : in std_logic; ****
>
> bus_rio : record ( ****
>
> master_rl : in master_r; ****
>
> slave_al : array (****
>
> inst_jg : out slave_r; ****
>
> others : unconn slave_r****
>
> ) slave_at;****
>
> ) cpu_bus_r; ****
>
> rst_i : in std_logic ****
>
> ); ****
>
> end entity slave; ****
>
> ****
>
> ****
>
> We have to have a new array element port mode assignment similar to the **
> **
>
> record type's mode structure. This gives us the ability to generically
> assign ****
>
> the slave port. I think the compiler should know enough about the array
> type's ****
>
> structure to be able to build a template for instantiation at this point.*
> ***
>
> ****
>
> which then leads to instantiations as shown: ****
>
> ****
>
> ****
>
> signal clk_s : std_logic; ****
>
> signal cpu_bus_rs : cpu_bus_r; ****
>
> signal rst_s : std_logic; ****
>
> ****
>
> ****
>
> master_inst : master ****
>
> port map ( ****
>
> clk_i => clk_s, ****
>
> bus_rio => cpu_bus_rs, ****
>
> rst_i => rst_s ****
>
> ); ****
>
> ****
>
> slave_inst1 : slave ****
>
> generic map ( ****
>
> inst_jg => 1****
>
> )****
>
> port map ( ****
>
> clk_i => clk_s, ****
>
> bus_rio => cpu_bus_rs, ****
>
> rst_i => rst_s ****
>
> ); ****
>
> ****
>
> slave_inst2 : slave ****
>
> generic map ( ****
>
> inst_jg => 2****
>
> )****
>
> port map ( ****
>
> clk_i => clk_s, ****
>
> bus_rio => cpu_bus_rs, ****
>
> rst_i => rst_s ****
>
> ); ****
>
> ****
>
> ****
>
> and this now looks quite compact and tidy. ****
>
> ****
>
> Internally the slave's architecture would have to replicate the drive to
> all ****
>
> ports of the slave array I think.****
>
> ****
>
> Thoughts?****
>
> ****
>
> -- ****
>
> ** **
>
> 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.****
>
>
>
>
Received on Thu Jul 19 12:27:59 2012