Re: [vhdl-200x] Directional records proposal

Ryan:
<quote>If you make the mode token a value from an enumerated type, you're
limited to a value from the current type. In short, VHDL doesn't allow you
to extend an enumerated type.</quote>

Yes, my previous proposal was to have the port modes only accept valid
modes, such as in, out, inout, and buffer. So, initially I had a separate
type that gives the valid types.
For Andy's proposal, this is implicit to the meaning / definition of "port
mode" itself. Means that when a port mode is defined, it becomes implicit
to the compiler that the modes should be restricted to valid ones, such as
in, out, inout, etc.

I'm not disputing the rules for a port interface. In fact, the following
port definitions

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

fit into the
    identifier : [mode] subtype_indication ;

port interface definition pretty well.

This was in Andy's original proposal, and it is not my intention to change
that.
What I was suggesting earlier was to explicitly define a record type to
hold all valid modes (the "mode" type). But this depends on whether we want
this implicitly defined when using "port mode", or we want to be more
explicit.

regards, daniel

On 14 July 2012 02:58, <ryan.w.hinton@l-3com.com> wrote:

> Daniel:****
>
> ** **
>
> I don't think this works for several reasons.****
>
> ** **
>
> * The syntax rule for a port interface item is basically****
>
> ** **
>
> identifier : [mode] subtype_indication ;****
>
> ** **
>
> If you make the mode token a value from an enumerated type, you're limited
> to a value from the current type. In short, VHDL doesn't allow you to
> extend an enumerated type.****
>
> ** **
>
> * Records and arrays are different in significant ways. It doesn't work
> to use an array to describe the modes of record elements. (I can elaborate
> if desired.)****
>
> ** **
>
> I like Andy's syntax better so far. If we want to make it shorter, I
> would do something like the following.****
>
> ** **
>
> port mode m_master of t_cpu_bus is****
>
> adr, dat, we, en : out;****
>
> sdt, ack, err : in;****
>
> end port mode m_master;****
>
> ** **
>
> I also want a "reversed" syntax similar to Olof's original suggestion,
> something like one of the following.****
>
> ** **
>
> port mode m_slave of t_cpu_bus is reversed m_master;****
>
> port mode m_slave of t_cpu_bus : reversed m_master;****
>
> ** **
>
> I don't think the first syntax will work without adding REVERSED as a VHDL
> reserved word. So I don't like it. The second syntax looks more like an
> object (constant, variable, signal) declaration -- different from Andy's
> type declaration-like syntax. So I don't really like it, either. :-) But
> for this very common case it would be silly not include a shorthand to
> reverse the directions.****
>
> ** **
>
> - Ryan****
>
> ** **
>
> From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf
> Of Daniel Kho
> Sent: Thursday, July 12, 2012 11:27 PM
>
> To: vhdl-200x@eda.org
> Subject: Re: [vhdl-200x] Directional records proposal****
>
> ** **
>
> I was thinking that the "port modes" definitions could be further
> simplified to contain only a list of modes:
>
>
> type mode is (in,out,inout); -- not too sure if there is already an
> existing definition for this in the standard.
> type mode_vector is array (natural range <>) of mode;
>
> signal m_master: mode_vector(0 to 6) := (0 to 3 => out, others => in);
> signal m_slave: mode_vector(0 to 6) := (0 to 3 => in, others => out);
> signal m_monitor: mode_vector(0 to 6) := (others => in);
>
> where "mode_vector" is the data structure for holding the list of
> directions, and the signal definitions are similar to the concept of "port
> modes" by Andy.
>
> I'm not sure if the use of "signals" is appropriate here. Perhaps another
> keyword (such as "port mode") may be more appropriate. Anyway, it's good to
> explore a compact notation such as the one given above.
> Modifying the above to use the "port mode" notation, we could have
> something like this:
>
> port mode m_master: mode_vector(0 to 6) := (0 to 3 => out, others => in);
> port mode m_slave: mode_vector(0 to 6) := (0 to 3 => in, others => out);
> port mode m_monitor: mode_vector(0 to 6) := (others => in);
>
> The rest of the code remains unchanged from Andy's.
>
> Comments are welcome.
>
> regards, daniel****
>
> On 13 July 2012 11:59, Daniel Kho <daniel.kho@gmail.com> wrote:****
>
> 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 Fri Jul 13 13:20:33 2012