<b>signal</b> s1 : INTEGER;
     <b>begin</b>
         s1 &lt;= p1;
         Inst1 : and_gate <b>port</b> <b>map</b> (s1, p2(I), p3);
     <b>end</b> <b>generate</b> LABL;

     --  is equivalent to the following two block statements:

     LABL : <b>block</b>
         <b>constant</b> I : INTEGER := 1;
         <b>signal</b> s1 : INTEGER;
     <b>begin</b>
         s1 &lt;= p1;
         Inst1 : and_gate <b>port</b> <b>map</b> (s1, p2(I), p3);
     <b>end</b> <b>block</b> LABL;

     LABL : <b>block</b>

         <b>constant</b> I : INTEGER := 2;
         <b>signal</b> s1 : INTEGER;
     <b>begin</b>
         s1 &lt;= p1;
         Inst1 : and_gate <b>port</b> <b>map</b> (s1, p2(I), p3);
     <b>end</b> <b>block</b> LABL;

     --  The following generate statement:

     LABL : <b>if</b> (g1 = g2) <b>generate</b>
         <b>signal</b> s1 : INTEGER;
     <b>begin</b>
         s1 &lt;= p1;
         Inst1 : and_gate <b>port</b> <b>map</b> (s1, p4, p3);
     <b>end</b> <b>generate</b> LABL;

     --  is equivalent to the following statement if g1 = g2;
     --  otherwise, it is equivalent to no statement at all:

     LABL : <b>block</b>
         <b>signal</b> s1 : INTEGER;
     <b>begin</b>
         s1 &lt;= p1;
         Inst1 : and_gate <b>port</b> <b>map</b> (s1, p4, p3);
     <b>end</b> <b>block</b> LABL;
</pre>
<p>NOTE--The repetition of the block labels in the case of a for generation scheme does not produce multiple declarations of the label on the generate statement.  The multiple block statements represented by the generate statement constitute multiple references to the same implicitly declared label.
<h3><a name="12.4.3">  <a href = "1076_12.HTM#12.4.3"> 12.4.3 </a>   Component instantiation statements</a></h3>
<p>Elaboration of a component instantiation statement that instantiates a component declaration has no effect unless the component instance is either fully bound to a design entity defined by an entity declaration and architecture body or bound to a configuration of such a design entity.  If a component instance is so bound, then elaboration of the corresponding component instantiation statement consists of the elaboration of the implied block statement representing the component instance and (within that block) the implied block statement representing the design entity to which the component instance is bound.  The implied block statements are defined in   <a href = "1076_9.HTM#9.6.1"> 9.6.1 </a>  .
<p>Elaboration of a component instantiation statement whose instantiated unit denotes either a design entity or a configuration declaration consists of the elaboration of the implied block statement representing the component instantiation statement and (within that block) the implied block statement representing the design entity to which the component instance is bound.  The implied block statements are defined in   <a href = "1076_9.HTM#9.6.2"> 9.6.2 </a>  .
<h3><a name="12.4.4">  <a href = "1076_12.HTM#12.4.4"> 12.4.4 </a>   Other concurrent statements</a></h3>
<p>All other concurrent statements are either process statements or are statements for which there is an equivalent process statement.
<p>Elaboration of a process statement proceeds as follows:
<ol type="a">
<li>The process declarative part is elaborated.<br>
<li>The drivers required by the process statement are created.<br>
<li>The initial transaction defined by the default value associated with each scalar signal driven by the process statement is inserted into the corresponding driver.
</ol>
<p>Elaboration of all concurrent signal assignment statements and concurrent assertion statements consists of the construction of the equivalent process statement followed by the elaboration of the equivalent process statement.
<h2><a name="12.5">  <a href = "1076_12.HTM#12.5"> 12.5 </a>   Dynamic elaboration</a></h2>
<p>The execution of certain constructs that involve sequential statements rather than concurrent statements also involves elaboration.  Such elaboration occurs during the execution of the model.
<p>There are three particular instances in which elaboration occurs dynamically during simulation. These are as follows:
<ol type="a">
<li>Execution of a loop statement with a for iteration scheme involves the elaboration of the loop parameter specification prior to the execution of the statements enclosed by the loop (see   <a href = "1076_8.HTM#8.9"> 8.9 </a>  ).  This elaboration creates the loop parameter and evaluates the discrete range.
<li>Execution of a subprogram call involves the elaboration of the parameter interface list of the corresponding subprogram declaration; this involves the elaboration of each interface declaration to create the corresponding formal parameters.  Actual parameters are then associated with formal parameters.  Finally, if the designator of the subprogram is not decorated with the 'FOREIGN attribute defined in package STANDARD, the declarative part of the corresponding subprogram body is elaborated and the sequence of statements in the subprogram body is executed.  If the designator of the subprogram is decorated with the 'FOREIGN attribute defined in package STANDARD, then the subprogram body is subject to implementation-dependent elaboration and execution.
<li>Evaluation of an allocator that contains a subtype indication involves the elaboration of the subtype indication prior to the allocation of the created object.
</ol>
<p>NOTE--It is a consequence of these rules that declarative items appearing within the declarative part of a subprogram body are elaborated each time the corresponding subprogram is called; thus, successive elaborations of a given declarative item appearing in such a place may create items with different characteristics.  For example, successive elaborations of the same subtype declaration appearing in a subprogram body may create subtypes with different constraints.
<h2><a name="12.6">  <a href = "1076_12.HTM#12.6"> 12.6 </a>   Execution of a model</a></h2>
<p>The elaboration of a design hierarchy produces a <i>model</i> that can be executed in order to simulate the design represented by the model.  Simulation involves the execution of user-defined processes that interact with each other and with the environment.
<p>The <i>kernel process</i> is a conceptual representation of the agent that coordinates the activity of user-defined processes during a simulation.  This agent causes the propagation of signal values to occur and causes the values of implicit signals [such as S'Stable(T)] to be updated.  Furthermore, this process is responsible for detecting events that occur and for causing the appropriate processes to execute in response to those events.
<p>For any given signal that is explicitly declared within a model, the kernel process contains a variable representing the current value of that signal.  Any evaluation of a name denoting a given signal retrieves the current value of the corresponding variable in the kernel process.  During simulation, the kernel process updates that variable from time to time, based upon the current values of sources of the corresponding signal.
<p>In addition, the kernel process contains a variable representing the current value of any implicitly declared GUARD signal resulting from the appearance of a guard expression on a given block statement.  Furthermore, the kernel process contains both a driver for, and a variable representing the current value of,any signal S'Stable(T), for any prefix S and any time T, that is referenced within the model; likewise, for any signal S'Quiet(T) or S'Transaction.
<h3><a name="12.6.1">  <a href = "1076_12.HTM#12.6.1"> 12.6.1 </a>   Drivers</a></h3>
<p>Every signal assignment statement in a process statement defines a set of <i>drivers</i> for certain scalar signals.  There is a single driver for a given scalar 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.  Each such signal assignment statement is said to be <i>associated</i> with that driver.  Execution of a signal assignment statement affects only the associated driver(s).
<p>A driver for a scalar signal is represented by a <i>projected output waveform</i>.  A projected output waveform consists of a sequence of one or more <i>transactions</i>, where each transaction is a pair consisting of a value component and a time component.  For a given transaction, the value component represents a value that the driver of the signal is to assume at some point in time, and the time component specifies which point in time.  These transactions are ordered with respect to their time components.
<p>A driver always contains at least one transaction.  The initial contents of a driver associated with a given signal are defined by the default value associated with the signal (see   <a href = "1076_4.HTM#4.3.1.2"> 4.3.1.2 </a>  ).
<p>For any driver, there is exactly one transaction whose time component is not greater than the current simulation time.  The <i>current</i> <i>value</i> of the driver is the value component of this transaction.  If, as the result of the advance of time, the current time becomes equal to the time component of the next transaction, then the first transaction is deleted from the projected output waveform and the next becomes the current value of the driver.
<h3><a name="12.6.2">  <a href = "1076_12.HTM#12.6.2"> 12.6.2 </a>   Propagation of signal values</a></h3>
<p>As simulation time advances, the transactions in the projected output waveform of a given driver (see   <a href = "1076_12.HTM#12.6.1"> 12.6.1 </a>  ) will each, in succession, become the value of the driver.  When a driver acquires a new value in this way, regardless of whether the new value is different from the previous value, that driver is said to be <i>active</i> during that simulation cycle.  For the purposes of defining driver activity, a driver acquiring a value from a null transaction is assumed to have acquired a new value.  A signal is said to be <i>active</i> during a given simulation cycle
<ul>
<p>--  If one of its sources is active
<p>--  If one of its subelements is active
<p>--  If the signal is named in the formal part of an association element in a port association list and the corresponding actual is active
<p>--  If the signal is a subelement of a resolved signal and the resolved signal is active
</ul>
<p>If a signal of a given composite type has a source that is of a different type (and therefore a conversion function or type conversion appears in the corresponding association element), then each scalar subelement of that signal is considered to be active if the source itself is active.  Similarly, if a port of a given composite type is associated with a signal that is of a different type (and therefore a conversion function or type conversion appears in the corresponding association element), then each scalar subelement of that port is considered to be active if the actual signal itself is active.
<p>In addition to the preceding information, an implicit signal is said to be active during a given simulation cycle if the kernel process updates that implicit signal within the given cycle.
<p>If a signal is not active during a given simulation cycle, then the signal is said to be <i>quiet</i> during that simulation cycle.
<p>The kernel process determines two values for certain signals during any given simulation cycle.  The <i>driving value</i> of a given signal is the value that signal provides as a source of other signals.  The <i>effective value</i> of a given signal is the value obtainable by evaluating a reference to the signal within an expression.  The driving value and the effective value of a signal are not always the same, especially when resolution functions and conversion functions or type conversions are involved in the propagation of signal values.
<p>A <i>basic signal</i> is a signal that has all of the following properties:
<ul>
<p>--  It is either a scalar signal or a resolved signal (see   <a href = "1076_4.HTM#4.3.1.2"> 4.3.1.2 </a>  );
<p>--  It is not a subelement of a resolved signal;
<p>--  Is not an implicit signal of the form S'Stable(T), S'Quiet(T), orS'Transaction (see   <a href = "1076_14.HTM#14.1"> 14.1 </a>  ); and
<p>--  It is not an implicit signal GUARD (see   <a href = "1076_9.HTM#9.1"> 9.1 </a>  ).
</ul>
<p>Basic signals are those that determine the driving values for all other signals.
<p>The driving value of any basic signal S is determined as follows:
<ul>
<p>--  If S has no source, then the driving value of S is given by the default value associated with S (see   <a href = "1076_4.HTM#4.3.1.2"> 4.3.1.2 </a>  ).
<p>--  If S has one source that is a driver and S is not a resolved signal (see   <a href = "1076_4.HTM#4.3.1.2"> 4.3.1.2 </a>  ), then the driving value of S is the value of that driver.
<p>--  If S has one source that is a port and S is not a resolved signal, then the driving value of S is the driving value of the formal part of the association element that associates S with that port (see   <a href = "1076_4.HTM#4.3.2.2"> 4.3.2.2 </a>  ).  The driving value of a formal part is obtained by evaluating the formal part as follows:  If no conversion function or type conversion is present in the formal part, then the driving value of the formal part is the driving value of the signal denoted by the formal designator.  Otherwise, the driving value of the formal part is the value obtained by applying either the conversion function or type conversion (whichever is contained in the formal part) to the driving value of the signal denoted by the formal designator.