1076_5.html

basic exemple. Do an ADD of two 4 bits numbers

            <b>port</b> (Comp_I: <b>in</b> Bit; Comp_O: <b>out</b> Bit);
         <b>end</b> <b>component</b>;

         --  A binding indication; generic and port map aspects within a binding indication
         --  associate actuals (Comp_I, etc.) with formals of the design entity interface 
         --  (Input_pin, etc.):
         <b>for</b> UUT: Buf
              <b>use</b> <b>entity</b> Work.Buf(DataFlow)
                   <b>generic</b> <b>map</b> (Buf_Delay => Comp_Buf_Delay)
                   <b>port</b> <b>map</b> (Input_pin => Comp_I, Output_pin=> Comp_O);
         <b>signal</b> S1,S2: Bit;
     <b>begin</b>

         --  A component instantiation statement; generic and port map aspects within a
         --  component instantiation statement associate actuals (S1, etc.) with the 
         --  formals of a component (Comp_I, etc.):
         UUT: Buf
            <b>generic map</b>(Comp_Buf_Delay => 50 ns)
            <b>port map</b>(Comp_I => S1, Comp_O => S2);

         --  A block statement; generic and port map aspects within the block header of a block
         --  statement associate actuals (4, etc.) with the formals defined in the block header:
         B: <b>block</b>
            <b>generic</b> (G: INTEGER);
            <b>generic</b> <b>map</b>(G => 4);
         <b>begin</b>
         <b>end</b> <b>block</b>;
     <b>end</b> Structure;
</pre>
<p>NOTE--A local generic (from a component declaration) or formal generic (from a block statement or from the entity declaration of the enclosing design entity) may appear as an actual in a generic map aspect.  Similarly, a local port (from a component declaration) or formal port (from a block statement or from the entity declaration of the enclosing design entity) may appear as an actual in a port map aspect.
<h3><a name="5.2.2">  <a href = "1076_5.HTM#5.2.2"> 5.2.2 </a>   Default binding indication</a></h3>
<p>In certain circumstances, a default binding indication will apply in the absence of an explicit binding indication.  The default binding indication consists of a default entity aspect, together with a default generic map aspect and a default port map aspect, as appropriate.
<p>If no visible entity declaration has the same simple name as that of the instantiated component, then the default entity aspect is <b>open</b>.  A <i>visible entity declaration</i> is either
<ul>
<p>a)  An entity declaration that has the same simple name as that of the instantiated component and that is directly visible (see   <a href = "1076_10.HTM#10.3"> 10.3 </a>  ), or
<p>b)  An entity declaration that has the same simple name as that of the instantiated component and that would be directly visible in the absence of a directly visible (see   <a href = "1076_10.HTM#10.3"> 10.3 </a>  ) component declaration with the same simple name as that of the entity declaration
</ul>
<p>These visibility checks are made at the point of the absent explicit binding indication that causes the default binding indication to apply.
<p>Otherwise, the default entity aspect is of the form
<pre>     <b>entity</b> <i>entity</i>_name ( <i>architecture</i>_identifier )
</pre>
<p>where the entity name is the simple name of the instantiated component, and the architecture identifier is the same as the simple name of the most recently analyzed architecture body associated with the entity declaration.  If this rule is applied either to a binding indication contained within a configuration specification or to a component configuration that does not contain an explicit inner block configuration, then the architecture identifier is determined during elaboration of the design hierarchy containing the binding indication.  Likewise, if a component instantiation statement contains an instantiated unit containing the reserved word <b>entity</b> but does not contain an explicitly specified architecture identifier, this rule is applied during the elaboration of the design hierarchy containing a component instantiation statement.  In all other cases, this rule is applied during analysis of the binding indication.
<p>It is an error if there is no architecture body associated with the entity interface denoted by an entity name that is the simple name of the instantiated component.
<p>The default binding indication includes a default generic map aspect if the design entity implied by the entity aspect contains formal generics.  The default generic map aspect associates each local generic in thecorresponding component instantiation (if any) with a formal of the same simple name.  It is an error if such a formal does not exist or if its mode and type are not appropriate for such an association.  Any remaining unassociated formals are associated with the actual designator <b>open</b>.
<p>The default binding indication includes a default port map aspect if the design entity implied by the entity aspect contains formal ports.  The default port map aspect associates each local port in the corresponding component instantiation (if any) with a formal of the same simple name.  It is an error if such a formal does not exist or if its mode and type are not appropriate for such an association.  Any remaining unassociated formals are associated with the actual designator <b>open</b>.
<p>If an explicit binding indication lacks a generic map aspect, and if the design entity implied by the entity aspect contains formal generics, then the default generic map aspect is assumed within that binding indication.  Similarly, if an explicit binding indication lacks a port map aspect, and the design entity implied by the entity aspect contains formal ports, then the default port map aspect is assumed within that binding indication.
<h2><a name="5.3">  <a href = "1076_5.HTM#5.3"> 5.3 </a>   Disconnection specification</a></h2>
<p>A disconnection specification defines the time delay to be used in the implicit disconnection of drivers of a guarded signal within a guarded signal assignment. 
<pre>     disconnection_specification ::=
         <b>disconnect </b>guarded_signal_specification <b>after </b><i>time</i>_expression ;

     guarded_signal_specification ::=
         <i>guarded</i>_signal_list : type_mark

     signal_list ::=
            <i>signal</i>_name { , <i>signal</i>_name }
      | <b>others</b>
      | <b>all</b>
</pre>
<p>Each signal name in a signal list in a guarded signal specification must be a locally static name that denotes a guarded signal (see   <a href = "1076_4.HTM#4.3.1.2"> 4.3.1.2 </a>  ).  Each guarded signal must be an explicitly declared signal or member of such a signal.
<p>If the guarded signal is a declared signal or a slice thereof, the type mark must be the same as the type mark indicated in the guarded signal specification (see   <a href = "1076_4.HTM#4.3.1.2"> 4.3.1.2 </a>  ).  If the guarded signal is an array element of an explicitly declared signal, the type mark must be the same as the element subtype indication in the (explicit or implicit) array type declaration that declares the base type of the explicitly declared signal.  If the guarded signal is a record element of an explicitly declared signal, then the type mark must be the same as the type mark in the element subtype definition of the record type declaration that declares the type of the explicitly declared signal.  Each signal must be declared in the declarative part enclosing the disconnection specification.
<p>Subject to these rules, a disconnection specification <i>applies to</i> the drivers of a guarded signal S of whose type mark denotes the type T under the following circumstances:
<ul>
<p>--  For a scalar signal S, if an explicit or implicit disconnection specification of the form
</ul>
<pre>           <b>disconnect</b> S: T <b>after</b> <i>time</i>_expression;
</pre>
<ul>
<p>      exists, then this disconnection specification applies to the drivers of S.
<p>--  For a composite signal S, an explicit or implicit disconnection specification of the form
</ul>
<pre>           <b>disconnect</b> S: T <b>after</b> <i>time</i>_expression;
</pre>
<ul>
<p>     is equivalent to a series of implicit disconnection specifications, one for each scalar subelement of the signal S.  Each disconnection specification in the series is created as follows: it has, as its single signal name in its signal list, a unique scalar subelement of S.  Its type mark is the same as the type of the same scalar subelement of S.  Its time expression is the same as that of the original disconnection specification.
<p>    The characteristics of the disconnection specification must be such that each implicit disconnection specification in the series is a legal disconnection specification.
<p>--  If the signal list in an explicit or implicit disconnection specification contains more than one signal name, the disconnection specification is equivalent to a series of disconnection specifications, one for each signal name in the signal list.  Each disconnection specification in the series is created as follows:  It has, as its single signal name in its signal list, a unique member of the signal list from the original disconnection specification.  Its type mark and time expression are the same as those in the original disconnection specification.
<p>    The characteristics of the disconnection specification must be such that each implicit disconnection specification in the series is a legal disconnection specification.
<p>--  An explicit disconnection specification of the form
</ul>
<pre>           <b>disconnect</b> <b>others</b>: T <b>after</b> <i>time</i>_expression;
</pre>
<ul>
<p>     is equivalent to an implicit disconnection specification where the reserved word <b>others</b> is replaced with a signal list comprised of the simple names of those guarded signals that are declared signals declared in the enclosing declarative part, whose type mark is the same as T, and that do not otherwise have an explicit disconnection specification applicable to its drivers; the remainder of the disconnection specification is otherwise unchanged.  If there are no guarded signals in the enclosing declarative part whose type mark is the same as T and that do not otherwise have an explicit disconnection specification applicable to its drivers, then the above disconnection specification has no effect.
<p>     The characteristics of the explicit disconnection specification must be such that the implicit disconnection specification, if any, is a legal disconnection specification.
<p>--  An explicit disconnection specification of the form
</ul>
<pre>           <b>disconnect</b> <b>all</b>: T <b>after</b><i> time</i>_expression;
</pre>
<ul>
<p>     is equivalent to an implicit disconnection specification where the reserved word <b>all</b> is replaced with a signal list comprised of the simple names of those guarded signals that are declared signals declared in the enclosing declarative part and whose type mark is the same as T; the remainder of the disconnection specification is otherwise unchanged.  If there are no guarded signals in the enclosing declarative part whose type mark is the same as T,then the above disconnection specification has no effect.
<p>     The characteristics of the explicit disconnection specification must be such that the implicit disconnection specification, if any, is a legal disconnection specification.
</ul>
<p>A disconnection specification with the signal list <b>others</b> or <b>all</b> for a given type that appears in a declarative part must be the last such specification for the given type in that declarative part.  No guarded signal of the given type may be declared in a given declarative part following such a disconnection specification.
<p>The time expression in a disconnection specification must be static and must evaluate to a non-negative value.
<p>It is an error if more than one disconnection specification applies to drivers of the same signal.
<p>If, by these rules, no disconnection specification applies to the drivers of a guarded, scalar signal S whose type mark is T (including a scalar subelement of a composite signal), then the following default disconnection specification is implicitly assumed:
<pre>    <b>disconnect</b> S : T <b>after</b> 0 ns;
</pre>
<p>A disconnection specification that applies to the drivers of a guarded signal S is the <i>applicable disconnection specification</i> for the signal S.
<p>Thus the implicit disconnection delay for any guarded signal is always defined,either by an explicit disconnection specification or by an implicit one.
<h4>NOTES</h4>
<p>
<p>1--A disconnection specification supplying either the reserved words<b> others</b> or <b>all</b> may apply to none of the guarded signals in the current declarative part, in the event that none of the guarded signals in the current declarative part meet all of the requirements of the disconnection specification.
<p>2--Since disconnection specifications are based on declarative parts, not on declarative regions, ports declared in an entity interface cannot be referenced by a disconnection specification in a corresponding architecture body.
<p><i>Cross-References:</i>  Disconnection statements,   <a href = "1076_9.HTM#9.5"> 9.5 </a>  ; Guarded assignment,   <a href = "1076_9.HTM#9.5"> 9.5 </a>  ; Guarded blocks,   <a href = "1076_9.HTM#9.1"> 9.1 </a>  ; Guarded signals,   <a href = "1076_4.HTM#4.3.1.2"> 4.3.1.2 </a>  ; Guarded targets,   <a href = "1076_9.HTM#9.5"> 9.5 </a>  ; Signal guard,   <a href = "1076_9.HTM#9.1"> 9.1 </a>  .
<HR>
<a href="../../HTML/HOMEPG.HTM"><img src="HP.GIF"  border=0></a>
<a href="1076_TOC.HTM"><img src="TOP.GIF" BORDER=0></a>
<a href="1076_4.HTM"><img src="LEFT.GIF" BORDER=0></a>
<a href="1076_6.HTM"><img src="RIGHT.GIF" BORDER=0></a>
</body></html>