Q: arrays of resolved elements in port maps 
Author Message
 Q: arrays of resolved elements in port maps

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/



Fri, 21 Feb 1997 15:50:31 GMT  
 Q: arrays of resolved elements in port maps

Quote:

>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.

... deleted ...

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

This is where the problem arises.  'std_ulogic_vector'  and 'std_logic_vector'
are two distinctly different TYPEs from the perspective of VHDL.  If you
look in the source specification for 'std_logic_1164' you will notice that
they are defined as separate and distinct array types.  Although the elements
of each of the array types are compatible subtypes, the arrays themselves
are not.

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 ...

Quote:
>-------------------------------------------------------------------------

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

>            http://www.cs.adelaide.edu.au/~petera/

Charles F. Shelor

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

(817) 467-9367



Sat, 22 Feb 1997 21:00:08 GMT  
 Q: arrays of resolved elements in port maps

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



Sat, 22 Feb 1997 21:07:12 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Shifting array element & regex on array element

2. Arrays: Build array in multiple for loops or replace array elements

3. Adding an element in an array of cluster of 2 elements

4. using generic in port slices (port map)

5. Access Array Elements by Arrays Reference

6. for every element of array find bounds in another array

7. Array and creation of the elements of the array

8. Adjustable array dimensions specified via array element?

9. creation of array elements and write traces on an array

10. selecting array elements with a logical array

11. (typep (make-array 10 :element-type 'bit) '(array bit (10)))

12. Do array element traces affect the whole array?

 

 
Powered by phpBB® Forum Software