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>
<mailto: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 11:24:02 2012
This archive was generated by hypermail 2.1.8 : Thu Jul 19 2012 - 11:25:02 PDT