!number LCS-0025(2)
!title Direct instantiation
!requirements-addressed-herein VHDL92-DG-1 (partial)
!history-log
(1) Nov 14, 1991 -- Initial version
(2) Jan 28, 1992 -- Clarified semantics; extended to cover issue of
       absent architecture name; changed syntax to require ENTITY, etc.

!brief-overview-of-problem
One problem with VHDL 87 is the amount of syntax required to
instantiate and bind a simple component to an existing design
entity.  The user must have a visible component declaration and
component instantiation within an architecture in order to
place a structural element into a design.  In order to bind
this component to a design entity, the designer must also include
either a configuration specification within the architecture or
a component configuration inside a configuration declaration.
Alternatively, the designer can duplicate the name of the entity
and its interface elements within the component declaration
and allow the rules of default binding perform the configuration.
In many situations, the designer knows what design entity
is required and, yet, is still required to include all of these
syntactic elements.

A second VHDL problem that we address here concerns the optional
architecture identifier that is allowed in an entity aspect.  The
LRM does not actually say what it means when the parenthesized
architecture name following the entity name is absent in this
context.  This has resulted in a certain amount of confusion.

!proposed-solution
We propose to extend the capabilities of the component 
instantiation statement to allow direct instantiation of 
design entities (i.e., not require the instantiation to
go through a component.)  In particular, an entity/architecture
pair or configuration can be used directly within the 
instantiation statement.  The syntax for this approach
would look like:

  component_instantiation_statement ::=
    instantiation_label :
      instantiated_unit
        [generic_map_aspect]
        [port_map_aspect];

  instantiated_unit ::=
      [ COMPONENT ] component_name
    | ENTITY entity_name [(architecture_identifier)]
    | CONFIGURATION configuration_name

The semantics of a component instantiation whose instantiated
unit is a component is the same as in VHDL 87 (i.e., the double-
nested block equivalence is described in LRM 9.6.1).  The
semantics of a component instantiation whose instantiated unit
is an entity or configuration is similar with the one important
exception that it is equivalent to a single nested block rather
than a pair of nested blocks.  In particular, this single
nested block contains ports/generics that correspond to the
formal ports/generics of the entity or configuration and contains
port/generic maps that correspond to the map aspects appearing
in the component instantiation statement.
  
Instantiations whose instantiated unit is an entity or configuration
may not be "re-configured" with a configuration specification or
with a component configuration containing an explicit binding
indication.

Finally, we come to the issue of what the absence of the
optional parenthesized architecture identifier in an instantiated
unit means.  This is optional in this context for uniformity with
the syntax of an entity aspect.  A meaning needs to be defined for
the case it is missing in either an instantiated unit or in
the entity-aspect binding indication.  The most obvious
interpretation here is to borrow from the "default binding"
semantics of the language and say that what is meant in this case
is the "most-recently analyzed" architecture of the named entity.
Most-recently analyzed at what particular point in time?  Please
refer to the issue of "binding time" discussed in LCS-0045.  In
order to be consistent with the inter-unit dependency suggestions
made there the rules should be that by "most-recently" we mean
"most-recently at time of elaboration" for instantiated units (see
above), for binding indications in configuration specifications,
and for binding indications in component configurations without
an explicit inner block configuration.  Furthermore, we should
mean "most-recently at analysis time of the configuration
declaration" for binding indications in component configurations
with an explicit (inner) block configuration. 

!rationale
The extra level of binding implied by component declarations is
extremely useful for top-down design.  The component essentially
represents a template for a needed component which can later be
bound to a particular design entity in a library.  However, if 
the designer is trying to instantiate design entities which 
already exist in a library, the use of component declarations adds
redundancy and seems cumbersome.  In addition, users often are
confused about the extra level of resolution which is introduced
when both the component and entity ports are resolved.  This can
lead to inefficient simulation and unexpected results.  Many
designers complain about the amount of code which must be written
to perform a simple instantiation.

This proposal addresses these needs in a straightforward way.
The capabilities for top-down design are not sacrificed but the
complexity of direct instantiations of library units is decreased.

The use of the reserved words ENTITY and CONFIGURATION in an
instantiated unit is intended to provide uniformity with the VHDL
entity aspect of a binding indication.  The obvious reason for 
making COMPONENT optional (as opposed to required) was
upward-compatibility.
 
Our proposed semantics for a missing parenthesized architecture
identifier following an entity name seems straightforward and
consistent with the line of thinking expressed in LCS-0045.
We considered making the architecture identifier mandatory and
also considered saying that a missing architecture identifier
was equivalent to an OPEN entity aspect but neither of these
seemed very satisfactory.

!lrm-sections-affected 9.6, 9.6.1

!examples
entity AND_GATE is 
    generic (tLH, tHL : time := 5 ns);
    port (I1, I2 : in Bit; O : out Bit);
end AND_GATE;

architecture BEHAVIOR of AND_GATE is
begin
  ...
end BEHAVIOR;

entity TEST_AND_GATE is end TEST_AND_GATE;

architecture TEST of TEST_AND_GATE is
    signal S1, S2, S3 : Bit;
begin
    L1 : entity WORK.AND_GATE(BEHAVIOR)
        generic map (7 ns, 8 ns)
        port map (S1, S2, S3);
end TEST;
    
!upward-compatibility
This proposal is upward compatible.

!implementation-impact
There is some amount of impact here on implementations.  However, the
new forms of instantiation should be a simpler implementation of 
capabilities which must be available for processing the current
language.

!other-alternatives-considered

!open-issues

!verification-tests

!reservations-about-the-requirements