distrib/docxml2/text/doc/yagle_user/performingAbs.xml

   1 <?xml version="1.0" encoding="ISO-8859-1" ?>
   2 <chapter>
   3 <section niv='1'><title>Performing the Abstraction</title>
   4
   5 &file_loading;
   6
   7 <section niv='2'><title>General Configuration</title>
   8
   9 &power_supplies;
  10
  11 </section>
  12
  13 <section niv='2'><title>Invoking Functional Abstraction</title>
  14 <p>The functional abstraction routine is invoked by the
  15 <f>yagle</f> command, which takes as argument the name of a sub-circuit. The sub-circuit must be among
  16 the previously loaded netlists. If the sub-circuit contains instances it
  17 will be flattened to the transistor-level.  In such a case, signal naming
  18 respects the hierarchical paths. The name of a signal is the concatenation of
  19 the names of the successive instances that appear in the hierarchical path leading to the physical node the signal
  20 is associated with.
  21
  22 The typical Tcl command for invoking functional abstraction is:</p>
  23 <code>yagle my_design</code>
  24 <p>where <f>my_design</f> is the name of the <f>.SUBCKT</f> to treat. If flatten is impossible (i.e. transistor level sub-circuits
  25 are missing for leaf cells), with no further configuration, the tool will issue an error and exit.</p>
  26 <p>The default configuration creates a VHDL description.</p>
  27 </section>
  28
  29 <section niv='2'><title>Timing Back-Annotation</title>
  30 <section niv='3'><title>Defining Simulation Temperature</title>
  31 <p>Temperature can be deined either with the <f>simTemperature</f> configuration variable or through
  32 a <f>.TEMP</f> statement in the Spice file.</p>
  33 </section>
  34 <section niv='3'><title>Back-Annotation Level</title>
  35 <p>The level of accuracy used for the back-annotation is <f>yagleTasTiming</f></p>
  36 </section>
  37 </section>
  38
  39 <section niv='2'><title>Output Files</title>
  40 <section niv='3'><title>CNS, CNV files</title>
  41 <p>The <f>.cns</f> file describes the partitions (cones), and their interconnections, resulting from the disassembly process.
  42 This file is very useful for debugging purposes, and necessary for the spice deck generation of timing paths. The
  43 file can be generated with the following configuration:</p>
  44 <code>
  45 <cl>avt_config yagleGenerateConeFile yes</cl>
  46 </code>
  47 <p>The <f>.cns</f> file is intented to be re-read by &tool; and therefore is not very human-readable. A more friendly
  48 version can be generated by setting:</p>
  49 <code>
  50 <cl>avt_config avtVerboseConeFile yes</cl>
  51 </code>
  52 </section>
  53
  54 <section niv='3'><title>VHDL and Verilog files</title>
  55 <p>VHDL file is generated in default mode. a Verilog file can be generated instead by using the following
  56 configuration:</p>
  57 <code>
  58 <cl>avt_config avtOutputBehaviorFormat vlg</cl>
  59 </code>
  60
  61 </section>
  62
  63
  64 </section>
  65
  66 <section niv='2'><title>Special Elements</title>
  67 <section niv='3'><title>Transmission Gate Multiplexers</title>
  68 <p>The detection of multiplexors is done purely algorithmically. The cone partitioning strategy implemented in &tool; perfectly
  69 fits with the detection and modeling of transmission-gate based multiplexers, provided that the correlations
  70 between the commands can be resolved within the design. The only reason why detection may fail, is because the
  71 schematic of the design itself prevents to identify those correlations, for example when commands are input pins.
  72 In such a case, correlations (mutual exclusion) should be set externally with INF commands.</p>
  73 <p>The following diagram shows two situations. In the left-hand design, the mutual exclusion between <f>sel</f> and <f>nsel</f>
  74 is not ensured by the design. There is no way for the tool to identify inputs and outputs, and it constructs
  75 false current paths. In the right-hand design, the mutual exclusion between
  76 <f>sel</f> and <f>nsel</f> is ensured by the invertor, and therefore the tool correctly models the multiplexer. </p>
  77 <imgsize namehtml="mux.gif" namepdf="mux.svg"/>
  78 <p>To avoid the construction of false current paths in the left-hand design, the following mutual exclusion
  79 configuration should be set:</p>
  80 <code>
  81 <cl>inf_DefineMutex cmpUP {sel nsel}</cl>
  82 </code>
  83 <p>If the transmission gate toppology is more complex, and setting of mutual exclusion constraints
  84 become too much difficult, another orientation mechanism is available. Let's consider the next design:</p>
  85 <imgsize namehtml="mux2.gif" namepdf="mux2.svg"/>
  86 <p>Here orientation can be done by setting levels on signals <f>i0</f>, <f>i1</f>, <f>s</f> and <f>out</f>.
  87 The transistors are oriented by assuming the current is going from the signals with the higher level to
  88 the signals with the lower level. Levels should be set as follow:</p>
  89 <code>
  90 <cl>inf_DefineDirout i0  3</cl>
  91 <cl>inf_DefineDirout i1  3</cl>
  92 <cl>inf_DefineDirout s   2</cl>
  93 <cl>inf_DefineDirout out 1</cl>
  94 </code>
  95
  96 <p>The default orientation value of signals is <f>-1</f>.</p>
  97
  98 </section>
  99
 100 <section niv='3'><title>Latches</title>
 101 <p>Two algorithms exist in &tool; to detect latches. The first one is based on pattern-matching. The tool tries to
 102 match in the design built-in latch patterns. This algorithm is enabled with the <f>yagleStandardLatchDetection</f>
 103 (default behavior is enabled). The second algorithm is based upon the Boolean analysis of gate loops and an electrical
 104 analysis of conflicts. This algorithm is enabled with the <f>yagleAutomaticLatchDetection</f> variable (default behavior
 105 is not enabled). The two algorithms can be enabled together, in such a case the standard latch detection is performed
 106 before the automatic latch detection.</p>
 107 </section>
 108
 109 <section niv='3'><title>Dynamic Latches</title>
 110 <p>Dynamic latches are typically tristate nodes followed by a capacitance. In default mode,
 111 tristate nodes are not marked as latches. This behavior can be changed with the <f>yagleMarkTristateMemory</f>
 112 configuration variable.</p>
 113 <p>Dynamic latches can also be identified with the INF commands <f>inf_DefineDLatch</f> and <f>inf_DefineNotDLatch</f></p>
 114
 115 </section>
 116
 117 </section>
 118 <section niv='2'><title>Case Analysis</title>
 119 <p>Case analysis, such as Scan Mode analysis or Functional mode analysis, is available in the &tool; platform. It
 120 is performed by sticking input connectors or internal signals to logical low or logical high values. It is done by adding in the Tcl
 121 script the SDC command <f>set_case_analysis</f>.</p>
 122 <p>The logical value stuck on the input connector or logical signal is propagated through the design, with regard
 123 to the behavior of the gates it crosses. A report of the stuck signals is available in the <f>.rep</f> file:</p>
 124 <code>
 125 <cl>[WRN 30] Signal 'ram_na3' is stuck at Zero</cl>
 126 <cl>[WRN 31] Signal 'ram_a43r_net6' is stuck at One</cl>
 127 </code>
 128
 129 </section>
 130 </section>
 131 </chapter>
 132
 133