Andy:
Great summary. I agree with each of your points -- especially despising
lazy INOUTs.
Let me be more precise. I don't like the proposed syntax for array
element modes. But I think we need to address it, otherwise we can't
have e.g. an array of user-defined mode interfaces to an bank of UART
components.
1. Do we need to allow different array elements to have different
modes, i.e. element 0 is IN while element 1 is OUT? The answer I'm
expecting is a "killer app" for this language feature.
2. Is there better syntax for user-defined modes for array types?
I'm coming up blank on these two questions. I'm inviting brainstorming
here.
Thanks!
- Ryan
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf
Of Jones, Andy D
Sent: Monday, July 23, 2012 9:13 AM
To: vhdl-200x@eda.org
Subject: RE: [vhdl-200x] Directional records proposal
Regarding justification of composite, directional modes for records, one
of the biggest drawbacks to writing/reviewing structural VHDL over a
graphical representation is that the lack of ability to use records to
simplify the VHDL interfaces, thus perpetuating the "can't see the
forest for the trees" syndrome. Simplifying the interfaces with records
can be used to raise the forest above all the individual trees. The
single most limiting factor in using records in ports is either having
to divide the record into separate ports for different directions, or
using universally inout ports, with resolved types and countless default
assignments for signals that are actually used only as inputs.
The benefits of using records on interfaces is not just one of reduced
coding effort. It raises the level of abstraction, thereby improving the
readability of the design, and increasing the effectiveness of reviews
and re-use.
Another huge benefit of the use of record ports, enhanced by the
flexibility we are considering, is the "conduit" effect. An electrician
can pre-plumb a building with conduit during construction, then decide
what wires to pull through that conduit when the building is prepared
for a new occupant. The use of records, especially in multidirectional
interfaces, allows this same approach to be applied to VHDL design
maintenance and re-use.
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 ryan.w.hinton@L-3com.com
Sent: Thursday, July 19, 2012 1:24 PM
To: vhdl-200x@eda.org
Subject: EXTERNAL: RE: [vhdl-200x] Directional records proposal
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. I t'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 P DT
>
> 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
&n bsp; ack_l : std_logic; -- Acknowledge
from slave
err_l : std_logic; -- Error from slave
end record slave_r;
< o:p>
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;
&nbs p;
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 ( < /p>
clk_i : in std_logic;
bus_rio : record (
master_rl : out master_r;
slave_al : in slave_at
) cpu_bus_r;
&nbs p; 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;
&nbs p; ) 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
r ecord 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
&n bsp; generic map (
inst_jg => 1
)
port map (
clk_i => clk_s,
bus_rio => cpu_bus_rs,
rst_i &nb sp; => 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 Mon Jul 23 14:34:26 2012
This archive was generated by hypermail 2.1.8 : Mon Jul 23 2012 - 14:34:29 PDT