RE: [vhdl-200x] Directional records proposal

From: Jones, Andy D <andy.d.jones@lmco.com>
Date: Thu Jul 12 2012 - 19:15:16 PDT

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:15:24 2012

This archive was generated by hypermail 2.1.8 : Thu Jul 12 2012 - 19:15:30 PDT