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> [mailto:owner-vhdl-200x@eda.org] On Behalf Of Brent Hayhoe
Sent: Tuesday, July 17, 2012 3:38 PM
To: vhdl-200x@eda.org<mailto: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<mailto:Brent.Hayhoe@Aftonroy.com>
Registered Number: 1744190 England.
Registered Office:
4th Floor, Imperial House,
15 Kingsway,
London, WC2B 6UN, U.K.