RE: [vhdl-200x] Directional records proposal

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
<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
<mailto: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 <http://www.orsoc.se>
Email: olof.kindgren@orsoc.se
______________________________________________
FPGA, ASIC, DSP - embedded SoC design

 
Received on Thu Jul 12 17:26:10 2012