{Disarmed} Re: [vhdl-200x] Directional records proposal

Hi Ryan,
In-line again I think:
On 23/07/2012 14:26, ryan.w.hinton@L-3com.com wrote:
>
> 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_
<javascript:popup_imp('/imp/compose.php',700,650,'to=owner-vhdl-200x%40eda.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.
This is a direct problem for the top level structure. The problem I encounter time
and again is that VHDL structure, particularly at a device top level, is seen to
be too complicated. Often the solution to this is to mandate schematic entry tools
for top level design, which inevitably moves the source control from VHDL to the
schematic tool's proprietary data file format.
Records have the ability to simplify the structure. The (necessary) complexity is
in the declaration (component) structure which can be hidden from the top level
code by declaring it within a package. The solution of using record pairs doubles
the complexity and in more cases than I care to remember, has led to record
structure usage (within RTL designs) being abandoned completely by engineers.
The existing solution of using pairs of records is, in my opinion, a necessary
bodge due to the lack of support for record types in the first place. The record
type itself is just a bundle, a conduit, a composite set of varied types. It has
nothing to do with directionality and should have nothing to do with it. The
logical place for I/O declarations is at the entity/component level (+ procedures)
and maintains visibility of this for the compiler and more importantly the coder
at this level. Top level structure needs to be about interconnectivity and not
I/O structure. This has always been handled within the blocks themselves. This
enables what was always used in manually drawn diagrams, namely buses of named
elements (as opposed to numbered elements) a facility which many schematic tools
still do not support today. Why was it done this way in hand drawn diagrams? To
make it simple and easy to understand. This in itself provides enough value to
outweigh any cost.
<WISHBONE stuff snipped>
> >
> > 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.
The alternative to this is more complexity. It's either directional composite
ports or don't use a record for this type of example.
> >
> > > 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.
Syntax is always up for discussion. To my mind this is just an obvious way to
extend
port structures into an hierarchical form and I would have thought it the most
obvious way to do it. Maybe my mind has become too convoluted, but it is very
VHDL-ish <sarcasm-on> it's verbose! <sarcasm-off>
> >
> > 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.
But it does of necessity, it has the record type itself. The elements follow
implicitly
from that.
> >
> > 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 think that this is/has/will be covered in the requirement section of the 'Record
Introspection' item in the 'Collected Requirements' on the Twiki site.
>
> 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).
Ah, but as I said above, it's not about what you can do with it, but rather how it
improves comprehension of the code.
The rest is the icing, record use in interfaces, in linked lists, at the test
bench level, etc.
>
>
> Enjoy!
>
> - Ryan
>
> >
> >
> > > Thanks!
> > >
> > > - Ryan
> > >
> > An I think that probably wraps up my thoughts, though not concisely!
> >
> >
> > Cheers,
> >
> >
> > Brent.
>>>>>>>>>>>>>>>>>>>

-- 
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.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.