RE: [vhdl-200x] Directional records proposal

That's the cleanest, most general solution I've seen for this problem so
far. Naturally, if a record signal element is connected to multiple
user-defined ports with OUT modes for that element, the resolution
function for that (sub)type is invoked. What happens to the role of
resolution functions on the composite type? I'm not too clear on how
these rules work currently, so I'll study up and provide further
analysis later.

Great idea!

- Ryan

-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf
Of Jones, Andy D
Sent: Thursday, July 12, 2012 8:15 PM
To: vhdl-200x@eda.org
Subject: RE: [vhdl-200x] Directional records proposal

The only change I would recommend, to allow more flexibility than just
forward and reverse mode variants (all-input monitors, etc.), would be
to create user-defined modes for a record type. This keeps the current
record declaration unchanged.

User defined modes could be nested as well. If a record contains an
element that is another record, then the defined modes for the parent
record would specify one of the defined modes for the child record.

The same modes could be used for procedures as well.

For a multi-slave bus, you could either rely upon resolved data types
for the slave-driven record elements, or you could code up a bus switch
with one slave port and N master ports.

Andy D Jones
Electrical Engineering
Lockheed Martin Missiles and Fire Control Dallas TX

Modifying Olof's example, the syntax for mode declarations is open for
debate. If we used '=>' instead of ':', then you could use "others =>
in", etc.

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 : std_logic_vector(15 downto 0); --Data from slave to master
   ack : std_logic; --Acknowledge from slave
   err : std_logic; --Error from slave
end record;

        ==Master Mode definition==
port mode m_master of t_cpu_bus is
   adr : out; --Address
   dat : out; --Data from master to slave
   we : out; --Write enable from master
   en : out; --Enable from master
   sdt : in ; --Data from slave to master
   ack : in ; --Acknowledge from slave
   err : in ; --Error from slave
end port mode m_master;

        ==Slave Mode definition==
port mode m_slave of t_cpu_bus is
   adr : in ; --Address
   dat : in ; --Data from master to slave
   we : in ; --Write enable from master
   en : in ; --Enable from master
   sdt : out; --Data from slave to master
   ack : out; --Acknowledge from slave
   err : out; --Error from slave
end port mode m_slave;

        ==Monitor Mode definition==
port mode m_monitor of t_cpu_bus is
   adr : in ; --Address
   dat : in ; --Data from master to slave
   we : in ; --Write enable from master
   en : in ; --Enable from master
   sdt : in ; --Data from slave to master
   ack : in ; --Acknowledge from slave
   err : in ; --Error from slave
end port mode m_monitor;
        
==Master entity==
entity master is
   port (
      clk : in std_logic;
      bus : m_master t_cpu_bus);
end entity;

==Slave entity==
entity slave is
   port (
      clk : in std_logic;
      bus : m_slave t_cpu_bus);
end entity;

==Monitor entity==
entity monitor is
   port (
      clk : in std_logic;
      bus : m_monitor t_cpu_bus);
end entity;

==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);
       
i_monitor : monitor
   port map (
      clk => clk,
      bus => cpu_bus);

-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf
Of ryan.w.hinton@L-3com.com
Sent: Thursday, July 12, 2012 1:00 PM
To: vhdl-200x@eda.org
Subject: EXTERNAL: RE: [vhdl-200x] Directional records proposal

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] 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 19:40:32 2012