I'd like to clarify the requirement for type conversions in port maps
when associating resolved objects with non-resolved objects.  I have
seen previous articles in this group mention type conversions in this
case.  I am also getting type errors from the analyzer I am using when I
don't include type conversions.  These are at odds with my understanding
of the LRM, so hopefully someone might be able to put me on the right
track.

Case 1:  Suppose we have a scalar resolved signal declared as:

  signal s : std_logic;

My analyzer allows me to associate the signal with scalar unresolved
ports, for example:

  b1 : block is
    port ( p : in std_ulogic );
    port map ( p => s );
  begin
  end block b1;

  b2 : block is
    port ( p : out std_ulogic );
    port map ( p => s );
  begin
  end block b2;

I'm happy with this.  Seems ok by the LRM.  Any problems?

Case 2:  Suppose we have a scalar unresolved signal declared as:

  signal s : std_ulogic;

My analyzer allows me to associate it with a scalar resolved port, for
example:

  b2 : block is
    port ( p : out std_logic );
    port map ( p => s );
  begin
  end block b2;

The is fine too - the port b2.p gets resolved, and the result becomes
the driving value for signal s.  Ok so far?

Now suppose we declare two constrained array subtypes, with unresolved and
resolved element types respectively:

  subtype std_ulogic_word is std_ulogic_vector(31 downto 0);
  subtype std_logic_word is std_logic_vector(31 downto 0);

Case 3:  We declare a signal of the array-of-resolved-elements subtype:

  signal s : std_logic_word;

My analyzer does not allow me to associate this signal with ports of the
array-of-unresolved-elements subtype, for example:

  b1 : block is
    port ( p : in std_ulogic_word );
    port map ( p => s );
  begin
  end block b1;

  b2 : block is
    port ( p : out std_ulogic_word );
    port map ( p => s );
  begin
  end block b2;

The analyzer complains that it was expecting type std_ulogic_word for
the actual.  I though the association would be ok, since the LRM just
requires the type of the actual and formal to be the same (as opposed to
the subtypes).  I understood that inclusion of a resolution function
name in a subtype simply specified that any signal declared to be of
that subtype would be resolved.  I thought the subtype still had the
same base type.  Is my understanding wrong, or my analyzer?  If I'm
wrong, which chapter/verse of the LRM says so?

Case 4 (similar to case 3): Given the same subtypes declared above,
suppose we declare a signal of the array-of-unresolved-elements subtype:

  signal s : std_ulogic_word;

My analyzer does not allow me to associate this signal with ports of the
array-of-resolved-elements subtype, for example:

  b2 : block is
    port ( p : out std_logic_word );
    port map ( p => s );
  begin
  end block b2;

This time the analyzer complains that it was expecting type
std_logic_word for the actual.  Again, is my understanding wrong, or my
analyzer?  If I'm wrong, which chapter/verse of the LRM says so?

If you can shed some light on this subject, I'd be glad to hear from
you.

Thanks molto!

Cheers,

PA

-------------------------------------------------------------------------

Dept. Computer Science           /      \      
University of Adelaide           \_.--*_/       Ph:  +61 8 303 4477
SA  5005, Australia                    v        Fax: +61 8 303 4366

                http://www.*-*-*.com/ ~petera/
--
-------------------------------------------------------------------------

Dept. Computer Science           /      \      
University of Adelaide           \_.--*_/       Ph:  +61 8 303 4477
SA  5005, Australia                    v        Fax: +61 8 303 4366

                http://www.*-*-*.com/ ~petera/

Since the two types are distinct, then cases 3 and 4 fail to match.  This
is a ROYAL PAIN in the ... but is just 1 of the costs paid for the benefits
of using a strongly typed language.  However, the appropriate application
of the correct types should minimize the need for these conversions.  The
resolved types are only needed for special instances (although quite common)
where there a multiple drivers and the 'wire' must resolve the final result.
In the cases where a non-resolved signal is derived from the resolved
signal (ie. a tri-stated databus is used as in input only) having the
explicit conversion from std_logic_vector to std_ulogic_vector serves as a
reminder that the full capabilities of the bus are not being used.

BY THE WAY:  Where I get frustrated with the typing aspects is in attempts
to abstract communication through multiple levels.  For example:  There are
two blocks, A and B, and they communicate with each other with 2 handshake
signals from A to B, two from B to A, and a bidirectional databus between
A and B.  At the top level I wish to abstract and model this as a cable,
'hiding' the details until a lower level is reached.  Once you manage to
get through all the type conversions required for compilation then you must
deal with the 'U' states during simulation.

Good Luck and Happy Modeling!

... deleted ...

SHELOR ENGINEERING              VHDL Training, Consulting, and models
3308 Hollow Creek Rd

(817) 467-9367

The answer to your problem has really to do with the strong typing mechanism
of VHDL.

Below a part of the std_logic_1164 package is given.

Notice that std_logic IS a subtype of std_ulogic, hence
you may connect them. (At works, you showed it)

But std_ulogic_vector and std_logic_vector are different types,
hence you need a type conversion function.

PACKAGE std_logic_1164 IS

    TYPE std_ulogic IS ......

    TYPE std_ulogic_vector IS ARRAY ( NATURAL RANGE <> ) OF std_ulogic;

    FUNCTION resolved ( s : std_ulogic_vector ) RETURN std_ulogic;

    SUBTYPE std_logic IS resolved std_ulogic;

    TYPE std_logic_vector IS ARRAY ( NATURAL RANGE <>) OF std_logic;

    ....

Bert Molenkamp
Dept. of Computer Science
University of Twente
PO Box 217
7500 AE  Enschede
the Netherlands