distrib/docxml2/text/doc/hitas_tutorial/old/lab4_pathsim.xml

   1 <?xml version="1.0" encoding="ISO-8859-1" ?>
   2 <chapter>
   3 <section niv='1'><title>Lab4. Path Simulation</title>
   4 <p>This lab shows explains the hypothesis and limitations inherent to Static Timing Analysis. It
   5 also illustrates the timing modeling of &tool;. It gives guidelines for the use of the
   6 Critical Path Extraction (CPE) feature of &tool;, which allows to make pertinent comparisons
   7 between &tool; STA results and a dynamic simulation.</p>
   8 <p>This lab is based upon the adder design studied in the previous lab.</p>
   9
  10 <section niv='2'><title>Accuracy </title>
  11
  12 <section niv='3'><title>Static Timing Analysis Hypothesis</title>
  13
  14 <p>The propagation time of a given timing path is dependant on the electrical states of signals
  15 within the surrounding logic. We will give examples of such behavior in the subsequent sections.</p>
  16
  17 <p>Dynamic simulation allows to know exactly the electrical state of the surrounding logic, and can then
  18 compute a very accurate propagation time. The drawback of dynamic simulation is that: first it requires input stimuli.
  19 Second, due to the considerable possible combinations of
  20 surrounding logic electrical states, dynamic simulation can only give accurate results for a small
  21 number of paths.</p>
  22
  23 <p>The base idea of Static Timing Analysis is to construct all possible timing paths
  24 between given points, and then ensure complete coverage. A related requirement of static timing analysis
  25 is that no input stimuli are needed. Therefore, static timing analysis has no a-priori knowing of the
  26 electrical state of the surrounding logic. It implies that a timing path must be characterized
  27 by a set a values depending on the possible states taken by the surrounding
  28 logic.</p>
  29 <p>As we said, the considerable number of possible states prevents to get them all. Typically, timing paths
  30 are characterized by minimum and maximum values. This implies
  31 that a certain number of hypothesis are made regarding the electrical state of the surrounding logic.</p>
  32
  33 <section niv='4'><title>Propagation Times</title>
  34 <p>Propagation times are computed between an event (rising or falling transition) on one input
  35 and the propagated event on the output. Other inputs are supposed to be stable, in a state that
  36 allow event propagation.</p>
  37
  38 <p>Multiple input configurations may exist, resulting in MIN and MAX propagation times,
  39 collisions (multiple inputs switching together) are not handled</p>
  40 <imgsize namehtml="min_max_times.gif" namepdf="min_max_times.gif"/>
  41
  42 </section>
  43 <section niv='4'><title>Internal Nodes Initialization</title>
  44 <p>Internal nodes are always initialized at the same levels. History can not be taken into account as in a dynamic simulation.</p>
  45 </section>
  46 <section niv='4'><title>Out-of-path Capacitances</title>
  47 <p>Out-of-path capacitances through transmission-gates may influence the timing.
  48 Depending on the state of the transmission-gate commands, the effective capacitance may greatly vary,
  49 implying MIN and MAX propagation times.</p>
  50 <imgsize namehtml="opc.gif" namepdf="opc.gif" wpdf="220pt"/>
  51
  52 </section>
  53 </section>
  54
  55 <section niv='3'><title>&tool; Modeling Hypothesis</title>
  56 <section niv='4'><title>Slope Modeling</title>
  57 <p>In order to operate rapidly, the slopes are not modeled as PWL, just like in standard electrical simulators,
  58 because this would lead to a large number of computations. In &tool;, the slope is modeled as a mathematical
  59 function (hyperbolic tangent curve), that can be analytically integrated for delay calculation.
  60 The shape of the hyperbolic tangent curve is mapped to the actual shape of the slope (PWL).
  61 This shape is such that, if you integrate it over time, you retrieve the same charge transfer as with the original PWL.
  62 Furthermore, the curve maps as exactly as possible the regions of the PWL that directly affects the switching of the
  63 following gate (the beginning of the transition for instance).</p>
  64
  65 <imgsize namehtml="slope_modeling.gif" namepdf="slope_modeling.gif"/>
  66 </section>
  67 <section niv='4'><title>Error Accumulation</title>
  68 <p>A side effect is that Vdd/2 is not so much important to this regard (the output of the gate has switched long before its input reaches Vdd/2). The mapped curve used as input may deviate from the PWL on that point without impact on the output switching. This can lead to deviations in the delay measurement (see diagram below), but not in the global accuracy.</p>
  69 <imgsize namehtml="accumulation.gif" namepdf="accumulation.gif"/>
  70 </section>
  71 </section>
  72 <section niv='2'><title>Database Generation</title>
  73 <p>The database generation is done in the same way as in the previous lab:</p>
  74 <code>
  75 <cl>avt_LoadFile bsim3_018.tech spice</cl>
  76 <cl>avt_LoadFile adder.spi spice</cl>
  77 <cl> </cl>
  78 <cl>set fig [hitas adder]</cl>
  79 </code>
  80 </section>
  81
  82 <section niv='2'><title>Path Simulation</title>
  83 <p>The CPE engine is dedicated to validate the timing results given by &tool;, with regard
  84 to the hypothesis made for static timing analysis. Indeed, the electrical state of the surrounding
  85 logic is explicitely set by CPE: the input patterns are set in the SPICE deck in order
  86 to propagate the transitions in the same way &tool; does. The CPE feature is ideal to validate
  87 &tool; modeling and make pertinent comparisons (it also set input waveforms as hyperbolic tangents,
  88 in the same way &tool; interprets them.)</p>
  89 <p>The <f>simu.tcl</f> script performs the following steps:</p>
  90 <list>
  91 <item>Loading of the timing database previously generated</item>
  92 <item>Searching for max critical path in the design</item>
  93 <item>Generating the SPICE deck for the path</item>
  94 <item>Optionally simulating the SPICE deck and retrieving results</item>
  95 </list>
  96 <p>As no electrical simulator is available in the training labs, we provide
  97 simulations results from the ELDO simulator. The <f>cmd_adder_ext.chi</f> file gives
  98 simulation results of the critical path of the design. Instead of calling ELDO, the script
  99 calls the <f>echo</f> command:</p>
 100 <code>
 101 <cl>avt_config avtSpiceString "echo $"</cl>
 102 </code>
 103 </section>
 104
 105 <section niv='2'><title>Exercises</title>
 106 <list>
 107 <item>Ex 4.1. Launch the <f>simu.tcl</f> script and observe the generated files</item>
 108 <item>Ex 4.2. Activate the simulation and re-launch the script. Observe the generated files</item>
 109 <item>Ex 4.3. Set <f>simOutLoad</f> to <f>dynamic</f>. What is changing?</item>
 110 <item>Ex 4.4. Uncomment the <f>ttv_GetPathDetail</f> and <f>ttv_DriveSpiceDeck</f>. What is changing?</item>
 111 </list>
 112
 113 </section>
 114 </section>
 115 </section>
 116
 117 </chapter>
 118