VHDL Issue Number:      1117
Classification:         Language Definition Problem
Language Version:       VHDL-93
Summary:                Problem with Composite Resolved Signal
Related Issues:         
Relevant LRM Sections:  12.6.1
Key Words and Phrases:  composite signals, drivers, resolved signals
Current Status:         Analyzed   
1076-1993 Disposition:  N/A
Disposition Rationale:  N/A
Superseded By:          N/A
-----------------------
Date Submitted:         1995/07/26
Author of Submission:   Yosi Veller (entered by Charles Swart)
Author's Affiliation:   
Author's Post Address:  
Author's Phone Number:  
Author's Fax Number:    
Author's Net Address:   veller@sd.co.il
-----------------------
Date Analyzed:          1997/09/15
Author of Analysis:     Peter Ashenden
                        Phil Wilsey 
Revision Number:        $Revision: 1.1 $
Date Last Revised:      $Date: 1995/07/26 16:56:07 $


Description of Problem
----------------------

The following is an issue that Paul Menchini and me got to a
conclusion that it uncovered a deficiency in the LRM.

First let us look at the following example:
-----------

type xxx is array ( positive range <> ) of std_logic ;

type txx is array (... range <>) of xxx ( 1 to 8 ) ;

function func (Drivers: txx) return xxx;


signal xx : func xxx ( 1 to 8 ) ;
begin

p1:process 
begin
  xx <= ...;
end process;


p2:process 
begin
  xx(3) <= ...;
end process;

p3:process 
begin
  xx <= ...;
end process;

end ;
-----------

Process p2 has an assignment to xx(3), according to the first section
of 12.6.1 in the 93 LRM, process p2 defines a set of drivers that
include only the scalar signal xx(3).

But xx has a composite resolution function, hence xx is to be resolved
as a whole, you can't have three sources for some of the elements and
only two for the others.

There does need to be a driver for every element of xx in p2--another way
of saying that there needs to be a driver for all of xx in p2.  So the
LRM seems to be deficient.

Proposed Resolution
-------------------

There can be a solution for the problem by rephrasing the first section
of 12.6.1 in the 93 LRM like the following:

Every signal assignment statement in a process statement defines a set
of drivers for certain BASIC signals. There is a single driver for a
given BASIC signal S in a process statement, provided that there is at
least one signal assignment statement in that process statement and
that the longest static prefix of the target signal of that signal
assignment statement denotes S or denotes a composite signal of which
S is a subelement OR DENOTES A SUBELEMENT OR S.

(note that the definition of a basic signal comes at a subsequent
paragraph).



VASG-ISAC Analysis & Rationale
------------------------------

The LRM is not deficient - it explicitly makes the example model
illegal.


4.3.1.2 lines 196-198 specify:

        If a subelement of a resolved signal of composite type has a
        driver in a given process, then every scalar subelement of
        that signal must have a driver in the same process, and the
        collection of all of those drivers taken together constitute
        one source of the signal.

In the example, process p2 has a driver for xx(3), but not for any
other element of xx.

The intention of the author's proposed resolution is to specify that
if a process has a driver for any scalar sublement of a composite
resolved signal, it implicity has drivers for all scalar subelements
of the signal.  Presumably those drivers for which there was no
assignment would assume the default initial value and remain
unchanged.  This is analogous to the case where the longest static
prefix of a signal assignment target is a composite signal, but only
some elements are dynamically assigned to.

The intended resolution would render the quoted part of 4.3.1.2
redundant.  It appears that the author overlooked 4.3.1.2 and assumed
that the intention of the LRM was that a process such as p2 in the
example should implicitly have a driver for the non-target elements of
the composite resolved signal.


VASG-ISAC Recommendation for IEEE Std 1076-1993
-----------------------------------------------

No change.


VASG-ISAC Recommendation for Future Revisions
---------------------------------------------

Include a note after 12.6.1, referring to 4.3.1.2, indicating that
there are requirements for inclusion of drivers in processes.