VHDL Issue Number:      0197
Classification:         Language Definition Problem
Language Version:       VHDL-87
Summary:                VPI Issue 21 -- Same-named architectures of an entity
Related Issues:         0180, 1096
Relevant LRM Sections:  11.1, 11.4
Key Words and Phrases:  secondary unit
Current Status:         Analyzed
1076-1993 Disposition:  Closed (All Issues Completely Addressed)
Disposition Rationale:  The author seems to have misinterpreted the LRM.
                        There are no issues to resolve.
Superseded By:          N/A
-----------------------
Date Submitted:         1991/03/15
Author of Submission:   J. R. Armstrong
Author's Affiliation:   Virginia Polytechnic Institute and State University
Author's Post Address:  Bradley Department of Electrical Engineering
                        Virginia Polytechnic Institute and State University
                        Blacksburg, VA 24061
Author's Phone Number:  (703) 231-4723
Author's Fax Number:    
Author's Net Address:   JRA@VTVM1.CC.VT.EDU
-----------------------
Date Analyzed:          1991/12/13
Author of Analysis:     Steve Bailey
Revision Number:        $Revision: 1.8 $
Date Last Revised:      $Date: 1995/05/13 19:34:42 $


Description of Problem
----------------------
  Can two architecture bodies associated with the
  same entity have the same name?

  Test File: ch11/s01/03030202.vhd

  The test point (110100_030302) clearly specifies  that  each
  architecture body associated with a given entity must have a
  unique  name.  Thus, this test should be an "expect failure"
  test.  However, considering that a file containing an entity
  and an architecture body associated with it can be  analyzed
  twice  without  any problem, it test should be considered as
  an "expect success" test.  This point should be clarified by
  the VASG committee.


  -- ##B10033224G8FF********************************************************
  --
  --+ File: [SUITE.CH11.S01]03030202.vhd
  --
  --+ Copyright: (c) 1989 by Virginia Tech. All rights reserved.
  --
  --+ LRM_Version: IEEE Std. 1076-1987
  --
  --+ Subsets: All
  --
  --+ Description:
  --
  --+ Test_point - (110100_030302) "Each architecture body associated with a
  --  given entity declaration must have a simple name that is unique within
the
  --  set of names of the architecture bodies associated with that entity
  --  declaration."
  --
  --+ Test_objective (2) - Test that an error is when two architecture bodies
  --  associated with an entity declaration have the same simple name.
  --
  --+ References: None
  --
  --+ Instructions: None
  --
  --+ Keywords: architecture body, entity declaration
  --
  --+ Test_Results: Expect_Failure. Output_Checked. Approximate error message:
  --  "Architecture bodies associated with a given entity declaration must
  --   have unique simple names"
  --
  --+ Test_Type: Dynamic Semantic
  --
  --+ History: Created KSC/VTech 4-25-90
  --
  --+ Comments: None
  --
 
--****************************************************************************
  entity test is
  end test;

  architecture behav of test is
   type MVL is ('0', '1', 'Z') ;
  begin
  end ;

  architecture behav of test is            ---- Failure_here
   signal S1 : bit;
  begin
    S1 <= '1' after 20 ns;
  end ;


Proposed Resolution
-------------------
TBD


VASG-ISAC Analysis & Rationale
------------------------------
   The LRM does specify that the simple name of an architecture body be
   unique within the set of archtecture bodies associated with an entity.
   However, it is not an error to re-analyze the same unit and this is
   all that the analyzer sees -- that architecture body "behav" is
   being replaced by a new version of "behav."

   To require this situation to be an error, would force the user to
   explicitly delete an existing version of an architecture in the library
   before analyzing a newer version of it.  This is unacceptable.


VASG-ISAC Recommendation for IEEE Std 1076-1987
-----------------------------------------------
   No change to the LRM is required.


VASG-ISAC Recommendation for Future Revisions
---------------------------------------------
   None.