VHDL Issue Number:        2068

Language_Version          VHDL-93
Classification            Language Definition Problem
Summary                   Entity instantiation with space before the entity name
Relevant_LRM_Sections     6.3 Selected Names
Related_Issues            
Key_Words_and_Phrases     
Authors_Name              Farrell Ostler
Authors_Phone_Number      505-822-8972
Authors_Fax_Number        
Authors_Email_Address     farrell.ostler@xilinx.com
Authors_Affiliation       Xilinx
Authors_Address1          
Authors_Address2          
Authors_Address3          

Current Status:           Submitted

Superseded By:

------------------------
Date Submitted:           6 May 2005
Date Analyzed:		  7 May 2005
Author of Analysis:	  Peter Ashenden
Revision Number:          1
Date Last Revised:	  7 May 2005

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

Please refer to a component instantiation using the entity option of this form:
    
    INSTANCE_LAB :
    entity lib_name. entity_name
    
    Note the space between the period and entity_name.

    Some tools were observed to handle this construct as if the space
    were absent (ModelSim, Synplify, XST) while one tool (NCSim)
    failed to bind the instance during elaboration.
    
    The issue is whether or not the selected name with the extra space is valid VHDL.
    
    Does the LRM make clear when "white space" is allowed or required?
    

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



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

The syntax for a selected name is

  selected_name ::= prefix . suffix

In the example, the suffix is a simple_name, which is an identifier.
Similarly, the prefix is a name in the form of a simple_name, also an
identifier.  Thus, the selected name is formed from three lexical
elements.

Lexical elements are described in clause 13.2:

  The text of each design unit is a sequence of separate lexical
  elements. Each lexical element is either a delimiter, an identifier
  (which may be a reserved word), an abstract literal, a character
  literal, a string literal, a bit string literal, or a comment.

Also in that clause are the following:

  In some cases an explicit separator is required to separate adjacent
  lexical elements (namely when, without separation, interpretation as
  a single lexical element is possible). A separator is either a space
  character (SPACE or NBSP), a format effector, or the end of a
  line. A space character (SPACE or NBSP) is a separator except within
  an extended identifier, a comment, a string literal, or a space
  character literal.

  ...

  One or more separators are allowed between any two adjacent lexical
  elements, before the first of each design unit or after the last
  lexical element of a design file. At least one separator is required
  between an identifier or an abstract literal and an adjacent
  identifier or abstract literal.

  A delimiter is either one of the following special characters (in
  the basic character set):

    & ' ( ) * + , - . / : ; < = > | [ ]

  ...

Thus, the selected name in the example is composed of an identifier, a
period delimiter and another identifier, and has a separator between
the period and the second identifier.

The quoted text in clause 13.2 specifies what characters form
separators, when they are permitted and when they are required.
According to that text, the space separator in the selected name in
the example is permitted but not required. A tool that does not accept
the space separator in that context does not conform to the standard.


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

No change.  The analysis provides an explanation in response to the
issue author's question.


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

No change.


-------------END OF IR----------------