Re: [vhdl-200x] Directional records proposal

Hello Olof,
I like your idea. It took me a while to digest what you've written, but I
guess I get your point.
Basically, you declare a record type whose direction of the elements are
not defined until it is being used later on at the entity ports. And some
of those elements are defined such that it's direction is reversed from the
other elements. So, when you use it at the entity ports, those few elements
will have their directions reversed depending on whether the entity port
used the type as an input or an output. Both Master and Slave can use the
same record type, and still have their directions clearly defined. Cool!

I use record types in procedure arguments as well, and I'm wondering if we
could extend this concept to procedures? For example, we may have some
procedures that do bus writes and reads:

procedure cpu_busWrite(signal request:out t_cpu_bus; -- request
to write to bus
        address : in std_logic_vector(15 downto 0); --Address
        data : in std_logic_vector(15 downto 0) --Data from master to
slave
);

procedure cpu_busRead(signal request:in t_cpu_bus; -- request to
read from bus
        address : in std_logic_vector(15 downto 0); --Address
        data : in std_logic_vector(15 downto 0) --Data from master to
slave
);

And for every request initiated from the Master, the "ack" direction
depends on whether it's a write request or a read request.
If the Master initiates a write request to the Slave, then it expects the
"ack" from the slave, means it should be an input to the Master (which is
the case, since t_cpu_bus is defined as "out").
If the Master initiates a read request to the Slave, then the Master is
supposed to assert the "ack" once it has done reading, and in this case,
the "ack" should be an output from the Master (again, this is the case,
since t_cpu_bus is defined as "in" for the read procedure).

Thoughts?

regards, daniel

On 13 July 2012 08:26, <ryan.w.hinton@l-3com.com> wrote:

> Mike:****
>
> ** **
>
> I very respectfully disagree. Composing data types enables expressing
> arbitrary levels of abstraction at any level of design. The "box" may be a
> subcomponent for a module I'm designing all myself. Why should I make my
> port map more complicated by not using a higher-level data type? And
> arrays allow repetition of an arbitrary idea. If my chip has a data stream
> it needs to demux out to 10 UARTs, I want to declare an interface for the
> UART component (and it would be nice to have both IN and OUT elements in
> one place), then declare an array of 10 of them.****
>
> ** **
>
> In any case, the point is somewhat moot. A language spec doesn't tell
> designers what they *should* do. It specifies what they *can* do. I like
> the distinction made by the C++ FAQ between legality and morality (see
> http://www.parashift.com/c++-faq-lite/defn-evil.html and
> http://www.parashift.com/c++-faq-lite/bizarre-syntax.html). The language
> (like the law) tells you what you can and can't do. Social norms and
> taboos (coding guidelines), good sense, and experience tell you what you
> should do. You've raised a moral issue, not a legal issue.****
>
> ** **
>
> Granted, it's only worth the trouble of making something legal if there
> are moral ways to do the thing. So it's only worth adding a language
> feature if there are good use cases where it's preferable to current
> language facilities (i.e. the moral thing to do). That's why I rose to the
> morality debate bait in the first place: to provide rationale and a good
> use case or two where the language feature would be really nice to have. *
> ***
>
> ** **
>
> Of course, if you choose to avoid the new feature for personal moral
> reasons, that's your prerogative. :-)****
>
> ** **
>
> Enjoy!****
>
> ** **
>
> - Ryan****
>
> ** **
>
> *From:* owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] *On
> Behalf Of *Mike Treseler
> *Sent:* Thursday, July 12, 2012 5:45 PM
> *To:* vhdl-200x@eda.org
> *Subject:* Re: [vhdl-200x] Directional records proposal****
>
> ** **
>
> I prefer to keep the complex data types inside the box, not at the edges.*
> ***
>
> ** **
>
> -- Mike Treseler****
>
> On Thu, Jul 12, 2012 at 11:13 AM, Dustyn Blasig <dustyn.blasig@ni.com>
> wrote:****
>
> I am happy to see this idea gaining traction (or at least a following). As
> someone that works on a compiler that generates VHDL, this is quickly
> becoming one of our top annoyances. The dual-rail records you have to
> generate makes the code clunky and harder to understand. If we could narrow
> down the initial support to only in and out ("rev" in Olof's email below),
> that would solve most of our use cases very nicely.
>
>
>
> From: ryan.w.hinton@L-3com.com
> To: <vhdl-200x@eda.org>
> Date: 07/12/2012 01:00 PM
> Subject: RE: [vhdl-200x] Directional records proposal
> Sent by: owner-vhdl-200x@eda.org ****
> ------------------------------
>
>
>
>
> Olof:
>
> You're on the right track -- this idea has come up before! If you want
> more history, you can take a look at the mail and document archives for
> the VHDL-200x effort. For a good summary of the current problem
> concept, see "Jim's old proposal for interfaces" at
> <http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/BlockInterfaces>.
>
> Personally, I think this is a great idea. But I haven't come up with
> any good resolution to the points you bring up and the other
> "implementation details" you allude to (e.g. those in Jim's proposal).
> I would be very happy for you to help this proposal progress by digging
> into the detailed issues and proposing solutions.
>
> Enjoy!
>
> - Ryan
>
> -----Original Message-----
> From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org<owner-vhdl-200x@eda.org>]
> On Behalf
> Of Olof Kindgren
> Sent: Thursday, July 12, 2012 10:34 AM
> To: vhdl-200x@eda.org
> Subject: [vhdl-200x] Directional records proposal
>
> Hi,
>
> I recently found this list and the proposed additions to the next VHDL
> revision. There seem to be plenty of interesting features, but I'm
> missing one feature that irritates me on a daily basis.
>
> VHDL allows us to group signals together with records, but when these
> are passed through entity ports, they need to be unidirectional. Many
> protocols uses a return-channel - in communication interfaces it can be
> some sort of flow-control, and a CPU bus usually has a data/ack/error
> combination.
>
> This requires me to separate my logical bus into two records (unless I
> use inout ports and resolve functions, which is a bit messy)
>
> My proposal is to add an optional directional statement to records to
> allow grouping related bidirectional signals
>
> Example with a simple cpu bus:
>
> ==Type definition==
> type t_cpu_bus is record
> adr : std_logic_vector(15 downto 0); --Address
> dat : std_logic_vector(15 downto 0); --Data from master to slave
> we : std_logic; --Write enable from master
> en : std_logic; --Enable from master
> sdt : rev std_logic_vector(15 downto 0); --Data from slave to master
> ack : rev std_logic; --Acknowledge from slave
> err : rev std_logic; --Error from slave
> end record;
>
> ==Master entity==
> entity master is
> port (
> clk : in std_logic;
> bus : out t_cpu_bus);
> end entity;
>
> ==Slave entity==
> entity slave is
> port (
> clk : in std_logic;
> bus : in t_cpu_bus);
>
> ==Top level==
> signal cpu_bus : t_cpu_bus;
>
> i_master : master
> port map (
> clk => clk,
> bus => cpu_bus);
>
> i_slave : slave
> port map (
> clk => clk,
> bus => cpu_bus);
>
>
> Using "rev" for reverse would reverse the direction of the signal
> compared to what's defined in the entity port.There should also be a
> "bidir" for inout ports.
>
> There are some details that need would need to be worked out for this to
> work.
> 1. This would probably work fine for point-to-point connections, but
> what would happen if the bus is connected to more than one in/out pair?
> Will the normal resolving rules take care of that?
> 2. Would it be legal to declare these as inout, or are just in and out
> valid?
> 3. Can assignments only be done on individual members of the struct,
> i.e. what would happen with cpu_bus := (x"0000", x"0000", '0', '0',
> x"0000", '0', '0')?
>
> I'm sure there are other implementation details that I haven't thought
> about. but I'm interested in your opinions
>
> Best Regards,
> Olof Kindgren
>
> ______________________________________________
> ORSoC
> Website: www.orsoc.se
> Email: olof.kindgren@orsoc.se
> ______________________________________________
> FPGA, ASIC, DSP - embedded SoC design
>
Received on Thu Jul 12 18:59:21 2012