RE: [vhdl-200x] Directional records proposal

From: <ryan.w.hinton@L-3com.com>
Date: Mon Jul 23 2012 - 14:26:55 PDT

No problem about the telecon, just trying to relay some of the
discussion.

 

I'll reply inline below to a few of your comments. Some I'll address in
a reply to Andy's comments.

 

From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf
Of Brent Hayhoe
Sent: Sunday, July 22, 2012 12:49 PM
To: vhdl-200x@eda.org
Subject: 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).

Part of evaluating a new language feature is seeing how it might be
accomplished with existing features. I agree that having one port would
be nice. But how nice? This is the "benefit" part of the equation.
And that's why I called it "icing" -- because all the uses I've seen so
far can be accomplished with a pair of records, one IN and one OUT.
Please don't misunderstand: I like the feature! But I'm having a hard
time swallowing some of the proposed syntax and related extensions --
the "cost" part of the equation.

 

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.

 

Sure, I would love a single WISHBONE type with user-defined port modes
for my SoC bus. The point isn't moot, just trying to reframe the use
case. Basically, I may be "too close" to the bus analogy to feel that
the presented examples are compelling.

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.

Great. I'm onboard so far. I prefer the named port modes that Andy
suggested, but I agree that an in-line port mode declaration like this
has merit in some cases.

 

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?

 

You're right about cost measured in money, e.g. cost of tool vendor
implementation. I'm talking about cost in general terms of impact to
the LRM, of impact to the "look and feel" of the language. How VHDL-ish
is the feature and its syntax? Andy's initial proposal looks great to
me, but I'm not satisfied with the array syntax or the more flexible
record handling proposals. For the directional arrays I haven't decided
if I like the feature -- give me a compelling use case! -- but I don't
like the proposed syntax.

 

Another cost is teaching, learning, using, and maintaining code with the
new syntax. If you're like me, people already grumble about the
less-commonly-used features of VHDL-87 that find their way into your
code! Even if I have a "but look at how amazingly better this is" use
case, the grumbling only gets a little quieter. And this is one reason
I like the syntax to fit very nicely into the existing language. The
ideal case is when newbies use the language extension because it so
obviously ought to be legal, and they didn't know that it used to be
forbidden. I think Andy's original syntax is the closest to this.

 

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.

Absolutely right. I like your latest "immediate" syntax as it doesn't
include any type information. Again, I will probably use the named
custom mode syntax in most cases.

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.

I would like to see an explanation (perhaps in a separate email) about
your "loop support" idea. I'm not sure what you mean by that.

 

I agree that there may be some synergy between the user-defined port
modes and record flexibility proposals. But I like the user-defined
port modes better, so I prefer to keep the proposals separate to see if
the flexibility proposals are good enough to support on their own.

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.

That's an interesting opinion. Perhaps I've been coding with the
record-pair paradigm for so long that I don't see this as an enabling
feature, i.e. I don't see that I will be "able" to do any more with one
record than I can do now with two. The two-to-one compression is great,
but even the simplest proposals so far come at a cost (see above).

 

Enjoy!

 

- Ryan

 

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.
 
Received on Mon Jul 23 14:27:01 2012

This archive was generated by hypermail 2.1.8 : Mon Jul 23 2012 - 14:27:24 PDT