RE: [vhdl-200x] Directional records proposal

Andy's full example showed the facility used with a signal on a port.
And that matches the "port mode" idea. But I think it could apply
equally as well to a signal or variable in a procedure call. You can
have OUT mode signals just as well as OUT mode variables. So a M_MASTER
mode signal on a procedure parameter interface list makes sense just as
a M_MASTER mode signal in an interface list -- just as a M_MASTER mode
formal in a port interface list. Framing it as a "user-defined mode" as
Andy has done gives a simple, consistent, and bounded extension to the
language.

- Ryan

From: 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
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> 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
Email: olof.kindgren@orsoc.se
______________________________________________
FPGA, ASIC, DSP - embedded SoC design
2012/7/13 Daniel Kho <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> 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
>>>
>