RE: [vhdl-200x] Directional records proposal

Hi Guys,

It might also be nice to have the slices as scalar.

For example, usually, all master outputs have a single source, but all inputs (hready, hrdata, hresp) come from each slave.

So, perhaps something like
==Master entity==
entity master is
   port (
      clk : in std_logic;
      bus : m_master t_cpu_bus(3)); -- three slaves
end entity;

i_slave0 : slave
   port map (
      clk => clk,
      bus => cpu_bus(0)); -- connects to cpu_bus.hready(0) etc.
i_slave1 : slave
   port map (
      clk => clk,
      bus => cpu_bus(1)); -- connects to cpu_bus.hready(1) etc.

Jakko

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

I apologise for not being clear.

Below is what I meant (modified from Andy's code):

==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;

type mode is (in,out,inout);
type mode_vector is array (natural range <>) of mode;

        ==Master Mode definition==
port mode m_master: mode_vector(0 to 6) := (0 to 3 => out, others => in);

        ==Slave Mode definition==
port mode m_slave: mode_vector(0 to 6) := (0 to 3 => in, others => out);

        ==Monitor Mode definition==
port mode m_monitor: mode_vector(0 to 6) := (others => in);

==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);

regards, daniel
On 13 July 2012 16:55, Daniel Kho <daniel.kho@gmail.com<mailto:daniel.kho@gmail.com>> wrote:
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
>>>
>
Legal Disclaimer: This e-mail communication (and any attachment/s) is confidential and contains proprietary information, 
some or all of which may be legally privileged. It is intended solely for the use of the individual or entity to which it
is addressed. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.
Please consider the environment before printing this e-mail