RE: [vhdl-200x] Directional records proposal

This bounced before. I'm sure the eda.org reflector couldn't possibly find any flaw in my reasoning... :-)

=========================
From: Hinton, Ryan W @ CSG - CSW
Sent: Friday, July 13, 2012 3:40 PM
To: vhdl-200x@eda.org
Subject: RE: [vhdl-200x] Directional records proposal

Right.  I agree.  Almost.  Type and mode *do* intersect when it comes to resolution functions.  If I associate a signal with OUT-mode ports of two entities, I need a resolution function for that signal type or its (eventual) element type(s).  No such need arises for two IN-mode ports.  Resolution functions are an aspect of the data type.  qed

So the current LRM requires a resolution function in the case of associating a signal with two OUT-mode ports.  What do we do if we associate a signal with two user-defined mode ports?  In this case, a resolution function on the port record type (with the per-element varying modes) doesn't make any sense because the resolution function takes an unconstrained array type of the record, but only a few of the elements may need to be resolved.  And hooking up the signal to three or more entities may result in a varying number of elements needing to be resolved -- and the analogous situation with array slices is illegal already.

Here's an example.  Start with Andy's example (some repeated here).

  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;

  port mode m_master of t_cpu_bus is
    adr, dat, we, en : out;
    sdt, ack, err    : in;
  end port mode m_master;

  port mode m_reset of t_cpu_bus is
    adr, dat, sdt    : open;
    we, en, ack, err : out;
  end port mode

  -- perhaps there is an external reset manager
  entity reset_manager
    port (
      clk : in      std_logic;
      rst : in      std_logic;
      bus : m_reset t_cpu_bus);
  end entity;

  -- instantiations
  i_master1 : master
    port map (
      clk => clk,
      bus => cpu_bus);

  i_master2 : master
    port map (
      clk => clk,
      bus => cpu_bus);

  i_reset_mgr : reset_manager
    port map (
      clk => clk,
      rst => rst,
      bus => cpu_bus);

So in this admittedly contrived scenario, we *don't* want a resolution function for type t_cpu_bus.  It doesn't even make sense because only parts -- in fact different parts -- of the record are driven by each entity.  But we *do* want resolution functions for the elements of t_cpu_bus.  That's all I'm trying to say.

Enjoy!

- Ryan

=========================
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Bailey, Stephen
Sent: Friday, July 13, 2012 3:11 PM
To: vhdl-200x@eda.org
Subject: 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>
Reply-To: "vhdl-200x@eda.org" <vhdl-200x@eda.org>
Date: Friday, July 13, 2012 2:57 PM
To: "vhdl-200x@eda.org" <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

<snip remaining to avoid bouncing?>
 
Received on Fri Jul 13 15:32:20 2012