Re: [vhdl-200x] Directional records proposal

Associating the mode of a port via the type or subtype definition is not the right way to go. Mode is orthogonal to type and it should be specified in a way that is orthogonal to the (sub)type definition. What is relevant about the (sub)type is the granularity at which the mode can be specified. Use the (sub)type definition of a port to guide how the mode can be specified, but don't confuse mode and type.

------------
Stephen Bailey
Director of Emerging Technologies, DVT
Mentor Graphics
www.Mentor.com

From: Ryan Hinton <ryan.w.hinton@L-3com.com<mailto:ryan.w.hinton@L-3com.com>>
Reply-To: "vhdl-200x@eda.org<mailto:vhdl-200x@eda.org>" <vhdl-200x@eda.org<mailto:vhdl-200x@eda.org>>
Date: Friday, July 13, 2012 2:57 PM
To: "vhdl-200x@eda.org<mailto:vhdl-200x@eda.org>" <vhdl-200x@eda.org<mailto:vhdl-200x@eda.org>>
Subject: RE: [vhdl-200x] Directional records proposal

Regarding resolution functions, it doesn't make sense to have a user-defined mode for a type with a resolution function. I suggest that such a model be illegal. Then the situation is simple: the resolution functions for the element types kick in as necessary for any conflicting OUT mode elements.

- Ryan

From: owner-vhdl-200x@eda.org<mailto:owner-vhdl-200x@eda.org> [mailto:owner-vhdl-200x@eda.org] On Behalf Of Daniel Kho
Sent: Friday, July 13, 2012 2:55 AM
To: vhdl-200x@eda.org<mailto:vhdl-200x@eda.org>
Subject: Re: [vhdl-200x] Directional records proposal

Hi Olof,
_Apart from resolution functions, signal/variable assignments is still
a bit of a grey area. Only allowing it on individual record members
would simplify things a bit, but would that be sufficient?_

I was using the "signal" keyword, though I didn't mean to make any signal / variable assignments. So the usage of the signal notation could be inappropriate there.
The intention is to have the same custom mode definitions as Andy's, in a more compact form.

regards, daniel
On 13 July 2012 15:54, Olof Kindgren <olof.kindgren@orsoc.se<mailto:olof.kindgren@orsoc.se>> wrote:
This sparked quite a discussion. Seems like I wasn't the only one with
this problem :)

I think that Andy's custom modes are a great idea. An added benefit is
that this would allow grouping signals that have the same direction on
both master and slave ports, such a clock, reset and error signals.
It's also a cleaner syntax than introducing a new keyword such as
"rev" in my proposal. It would also be more in line with current VHDL
syntax compared to something like SV modports

The blockInterfaces proposal
(http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/BlockInterfaces) was an
interesting read. That proposal covers a bit more, such as transaction
models, but the things we are outlining here at least doesn't seem to
clash with any of the potential requirements in ch 2 of the PDF.

Apart from resolution functions, signal/variable assignments is still
a bit of a grey area. Only allowing it on individual record members
would simplify things a bit, but would that be sufficient?

--
Olof Kindgren
______________________________________________
ORSoC
Website: www.orsoc.se<http://www.orsoc.se>
Email: olof.kindgren@orsoc.se<mailto:olof.kindgren@orsoc.se>
______________________________________________
FPGA, ASIC, DSP - embedded SoC design
2012/7/13 Daniel Kho <daniel.kho@gmail.com<mailto:daniel.kho@gmail.com>>:
> 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<mailto: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<mailto: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> [mailto: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<mailto: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> [mailto:owner-vhdl-200x@eda.org<mailto:owner-vhdl-200x@eda.org>] On Behalf
>>> Of ryan.w.hinton@L-3com.com<mailto:ryan.w.hinton@L-3com.com>
>>> Sent: Thursday, July 12, 2012 1:00 PM
>>> To: vhdl-200x@eda.org<mailto: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> [mailto: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<mailto: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<http://www.orsoc.se>
>>> Email: olof.kindgren@orsoc.se<mailto:olof.kindgren@orsoc.se>
>>> ______________________________________________
>>> FPGA, ASIC, DSP - embedded SoC design
>>>
>