Re: [vhdl-200x] Directional records proposal

Hi Ryan,

Firstly, I apologize for not taking part in the teleconference but unfortunately
my work situation precludes it.

My comments are embedded below:

On 19/07/2012 19: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.
>
I'd rather think of this as a simple example to show complex functionality.
Breaking signals out of the record is the only option that has been available
since day 1. Keeping the record intact through port structures (and providing
directional capability) would enable top level simplified structural
interconnect and in so doing make the need for 'block diagramming' tools less
important (a pet hate of mine).

> 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.
>
My first brief look at the WISHBONE bus leads me to suggest that this would
benefit hugely from record directional port capability, but I guess this is moot.

I am trying to move away from the obvious master-slave examples, as in my view
this is a 'use' simplification. Whenever I explain records to new engineers they
are excited about their named bus element capability and then soon complain
about the directionality problem which essentially doubles the amount of buses
(and may explain the lack of use, in general, within RTL code design?). One of
the first 'use' case that I wanted for records at the RTL level (many years ago
now!), was the encapsulation of the main clock(s) and reset(s) signals. This
(simplistically) requires the following types of entity declarations:

    entity clk_gen is
      port (
        candr_rio : record (
          clk_o : out;
          rst_u : unconn
          )candr_rio
      );
    end entity clk_gen;

    entity rst_sync is
      port (
        candr_rio : record (
          clk_i : in;
          rst_o : out
          )candr_rio
      );
    end entity rst_sync;

    entity use_block is
      port (
        candr_rio : record (
          clk_i : in;
          rst_i : in
          )candr_rio;
        ....
      );
    end entity use_block;

which is an example of a non-master/slave record use and requires the
directionality be resolved at the port level.

> 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.
>
Firstly, I thought that it has been stated (unless my memory fails) that cost
should not be a contributing factor in deciding language enhancements? Secondly,
isn't 'icing on the cake' one of the main reasons for this whole language
revision procedure?

At the end of the day it is tool manufacturers who will dictate whether or not
features are implemented and, in turn, they are driven by the users demands on
those tool providers.

I would advocate the port extension route solution, as to my mind, it is the
correct logical place to solve the directionality problem. The type declaration
is used to declare the data structure of the wire/net/bus/signal/port and should
have nothing to do with directionality.

I also think this would lead to some provision of record support features e.g.
loop support for the assignment of record elements, and attribute additions such
as "R'element" providing an enumerated type of the ordered list of record
elements, but I realize that this discussion may be broken out into a different
thread.

My overriding thought is that these additions will be 'enablers' for users
coding at both the RTL and test bench levels, something that has been sorely
lacking in the language thus far.

> Thanks!
>
> - Ryan
>
An I think that probably wraps up my thoughts, though not concisely!

Cheers,

Brent.

> *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.