Re: [vhdl-200x] Directional records proposal

Hi Andy,
Yes.

bus : m_master t_cpu_bus
bus : m_slave t_cpu_bus
bus : m_monitor t_cpu_bus

I especially like the fact that you could define your own custom direction
for the ports, using what you call port modes. :)

regards, daniel

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

> 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 21:00:18 2012