Re: [vhdl-200x] Directional records proposal

Sorry, correction:
What I was suggesting earlier was to explicitly define an *_enumerated*_
type to hold all valid modes (the "mode" type).

regards, daniel

On 14 July 2012 04:20, Daniel Kho <daniel.kho@gmail.com> wrote:

> 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:38:12 2012