<liclass="toctree-l4"><aclass="reference internal"href="../UsersGuide/Installation.html#building-the-devel-branch">Building the Devel Branch</a></li>
<liclass="toctree-l4"><aclass="reference internal"href="../UsersGuide/Installation.html#additionnal-requirement-under-macos">Additionnal Requirement under <spanclass="sc">MacOS</span></a></li>
<liclass="toctree-l3"><aclass="reference internal"href="../UsersGuide/Installation.html#hooking-up-into-alliance">Hooking up into <spanclass="sc">Alliance</span></a></li>
<liclass="toctree-l3"><aclass="reference internal"href="../UsersGuide/Installation.html#setting-up-the-environment-coriolisenv-py">Setting up the Environment (coriolisEnv.py)</a></li>
</ul>
</li>
<liclass="toctree-l2"><aclass="reference internal"href="../UsersGuide/Configuration.html">Coriolis Configuration & Initialisation</a><ul>
<liclass="toctree-l3"><aclass="reference internal"href="../UsersGuide/Configuration.html#hacking-the-configuration-files">Hacking the Configuration Files</a></li>
</ul>
</li>
<liclass="toctree-l2"><aclass="reference internal"href="../UsersGuide/ViewerTools.html">CGT - The Graphical Interface</a><ul>
<liclass="toctree-l3"><aclass="reference internal"href="../UsersGuide/ViewerTools.html#viewer-tools">Viewer & Tools</a><ul>
<liclass="toctree-l4"><aclass="reference internal"href="../UsersGuide/ViewerTools.html#synthetizing-and-loading-a-design">Synthetizing and loading a design</a></li>
<liclass="toctree-l4"><aclass="reference internal"href="../UsersGuide/ViewerTools.html#executing-python-scripts-in-cgt">Executing Python Scripts in Cgt</a></li>
<liclass="toctree-l4"><aclass="reference internal"href="../UsersGuide/ViewerTools.html#printing-snapshots">Printing & Snapshots</a></li>
<liclass="toctree-l4"><aclass="reference internal"href="../UsersGuide/ViewerTools.html#memento-of-shortcuts-in-graphic-mode">Memento of Shortcuts in Graphic Mode</a></li>
<liclass="toctree-l4"><aclass="reference internal"href="../UsersGuide/ViewerTools.html#cgt-command-line-options">Cgt Command Line Options</a></li>
<liclass="toctree-l2"><aclass="reference internal"href="../PythonCpp/DBoHierarchy.html">4. Case 2 - Hierarchy of DBo Derived Classes</a><ul>
<liclass="toctree-l3"><aclass="reference internal"href="../PythonCpp/DBoHierarchy.html#base-class-header">4.1 Base Class Header</a></li>
<liclass="toctree-l3"><aclass="reference internal"href="../PythonCpp/DBoHierarchy.html#base-class-file">4.2 Base Class File</a></li>
<liclass="toctree-l3"><aclass="reference internal"href="../PythonCpp/DBoHierarchy.html#intermediate-class-header">4.3 Intermediate Class Header</a></li>
<liclass="toctree-l3"><aclass="reference internal"href="../PythonCpp/DBoHierarchy.html#intermediate-class-file">4.4 Intermediate Class File</a></li>
<liclass="toctree-l3"><aclass="reference internal"href="../PythonCpp/DBoHierarchy.html#terminal-class-header">4.5 Terminal Class Header</a></li>
<liclass="toctree-l3"><aclass="reference internal"href="../PythonCpp/DBoHierarchy.html#terminal-class-file">4.6 Terminal Class File</a></li>
<pclass="last">Not all association of object and symbolic layers are meaningful.
For instance you cannot associate a contact to a <ttclass="docutils literal"><spanclass="pre">NTRANS</span></tt> layer.</p>
</div>
<divclass="admonition note">
<pclass="first admonition-title">Note</p>
<pclass="last">The symbolic layer associated with blockages is prefixed by a <ttclass="docutils literal"><spanclass="pre">T</span></tt>,
for <em>transparency</em>, which may seems silly. It is for historical reasons,
it started as a true transparency, but at some point we had to invert
the meaning (blockage) with the rise of over-the-cell routing, but the
name stuck...</p>
</div>
</div>
<divclass="section"id="symbolic-segments">
<h2>Symbolic Segments<aclass="headerlink"href="#symbolic-segments"title="Permalink to this headline">¶</a></h2>
<p>In <spanclass="sc">Alliance</span>, segments are oriented (up, down, left, right). This disambiguate
the left or right side when using the <ttclass="docutils literal"><spanclass="pre">LCW</span></tt> and <ttclass="docutils literal"><spanclass="pre">RCW</span></tt> rules in the <spanclass="sc">rds</span> file.
It allows to generate, if needed, asymetric object in the real layout file.</p>
<h2>The <ttclass="docutils literal"><spanclass="pre">MBK_TO_RDS_SEGMENT</span></tt> table<aclass="headerlink"href="#the-mbk-to-rds-segment-table"title="Permalink to this headline">¶</a></h2>
<p>The <ttclass="docutils literal"><spanclass="pre">MBK_TO_RDS_SEGMENT</span></tt> table control the way segments are translated into
real rectangles. Be aware that we are translating <em>segments</em> and not <em>rectangles</em>.
Segments are defined by their axis (source & target points) and their width.
The geometrical transformations are described according to that model.
Obviously, they are either horizontal or vertical.</p>
<p>The translation method of a symbolic segment is as follow:</p>
<olclass="arabic">
<li><pclass="first">The segment is translated into one or more physical rectangles.
The generated rectangles depends on the tool which is actually
using <spanclass="sc">rds</span> and the flag for the considered real layer.
For instance, real layers flagged with <ttclass="docutils literal"><spanclass="pre">DRC</span></tt> will be generated
for <ttclass="docutils literal"><spanclass="pre">s2r</span></tt> (for the <ttclass="docutils literal"><spanclass="pre">cif</span></tt> or <ttclass="docutils literal"><spanclass="pre">gds</span></tt>) and <ttclass="docutils literal"><spanclass="pre">druc</span></tt>, but will not
be shown under <ttclass="docutils literal"><spanclass="pre">graal</span></tt>.</p>
</li>
<li><pclass="first">Translation into one real layer. <em>First</em> the source & target coordinates and width
of the symbolic segment are multiplied by the <ttclass="docutils literal"><spanclass="pre">LAMBDA</span></tt> value to obtain a real
segment. <em>Then</em> one of the <ttclass="docutils literal"><spanclass="pre">VW</span></tt>, <ttclass="docutils literal"><spanclass="pre">LCW</span></tt> or <ttclass="docutils literal"><spanclass="pre">RCW</span></tt> transformation is applied to
that segment to get the final real rectangle.</p>
<ul>
<li><pclass="first"><ttclass="docutils literal"><spanclass="pre">VW</span></tt> for Variable Width, expand the real layer staying centered from the
original one. In those rules, the third number is not used, it is only here
<li><pclass="first"><ttclass="docutils literal"><spanclass="pre">LCW</span></tt> or <ttclass="docutils literal"><spanclass="pre">RCW</span></tt> for Left/Right Constant Width, create an off-center rectangle
of fixed width relatively to the real segment. Note that the <ttclass="docutils literal"><spanclass="pre">SP</span></tt> number
is the distance <em>between the edge</em> of the real segment and the edge of the
generated real rectangle (<em>not</em> from the axis). It is often zero.</p>
<p><imgalt="RDS Left Constant Width Rule"class="align-middle"src="../_images/RDS_LCW.png"style="width: 40%;"/></p>
<p><spanclass="fboxtt">Case 1</span> the <ttclass="docutils literal"><spanclass="pre">ALU1</span></tt> is translated in exacltly one real rectangle of
<ttclass="docutils literal"><spanclass="pre">RDS_ALU1</span></tt>, both ends are extended by 0.18µm and it’s width is increased
by 0.09µm.</p>
<p><spanclass="fboxtt">Case 2</span> the <ttclass="docutils literal"><spanclass="pre">NDIF</span></tt> will be translated into only one segment
under <ttclass="docutils literal"><spanclass="pre">graal</span></tt>, for symbolic visualization. And into three real rectangles
for <ttclass="docutils literal"><spanclass="pre">s2r</span></tt> and <ttclass="docutils literal"><spanclass="pre">druc</span></tt>.</p>
<p><spanclass="fboxtt">Case 3</span> the <ttclass="docutils literal"><spanclass="pre">NTRANS</span></tt>, associated to a transistor is a little bit
more complex, the generated shapes are different for the extractor <ttclass="docutils literal"><spanclass="pre">cougar</span></tt>
in one hand, and for both <ttclass="docutils literal"><spanclass="pre">druc</span></tt>&<ttclass="docutils literal"><spanclass="pre">s2r</span></tt> in the other hand.</p>
<ul>
<li><pclass="first">For the extractor (<ttclass="docutils literal"><spanclass="pre">EXT</span></tt>&<ttclass="docutils literal"><spanclass="pre">ALL</span></tt> flags) there will be four rectangles
<li>The left diffusion of the transistor (source or drain) (<ttclass="docutils literal"><spanclass="pre">RDS_NDIF</span></tt>).</li>
<li>The right diffusion of the transistor (drain or source) (<ttclass="docutils literal"><spanclass="pre">RDS_NDIF</span></tt>).</li>
<li>The active area (<ttclass="docutils literal"><spanclass="pre">RDS_ACTIV</span></tt>).</li>
</ol>
<p>As the extractor must kept separate the source and the drain of the transistor,
they are generated as two offset rectangles, using the <ttclass="docutils literal"><spanclass="pre">LCW</span></tt> and <ttclass="docutils literal"><spanclass="pre">RCW</span></tt> directives.</p>
</li>
<li><pclass="first">For <ttclass="docutils literal"><spanclass="pre">s2r</span></tt> and <ttclass="docutils literal"><spanclass="pre">druc</span></tt> (<ttclass="docutils literal"><spanclass="pre">DRC</span></tt> and <ttclass="docutils literal"><spanclass="pre">ALL</span></tt>), five rectangles are generateds:</p>
<li>The diffusion, as one rectangle that covers both the <ttclass="docutils literal"><spanclass="pre">LCW</span></tt> and the <ttclass="docutils literal"><spanclass="pre">RCW</span></tt> (<ttclass="docutils literal"><spanclass="pre">RDS_NDIF</span></tt>).</li>
<li>The active area (<ttclass="docutils literal"><spanclass="pre">RDS_ACTIV</span></tt>).</li>
<li>The N implantation (<ttclass="docutils literal"><spanclass="pre">RDS_NIMP</span></tt>).</li>
</ol>
<p>In the layout send to the foundry, the source & drain are draw as one rectangle
across the gate area (the transistor being defined by the intersection of both
rectangles).</p>
</li>
</ul>
<p></p>
</div>
<divclass="section"id="the-mbk-to-rds-via-table">
<h2>The <ttclass="docutils literal"><spanclass="pre">MBK_TO_RDS_VIA</span></tt> table<aclass="headerlink"href="#the-mbk-to-rds-via-table"title="Permalink to this headline">¶</a></h2>
<p>This table is to translate <em>default</em> VIAs into real via. In the symbolic layout
the default VIA is simply a point and a set of layers. All layers are converted
in squares shapes centered on the VIA coordinate. The one dimension given is the
size of the side of that square.</p>
<p>Note that although we are refering to VIAs, which for the purists are between two
metal layers, this table also describe <em>contacts</em>.</p>
<pclass="last"><strong>In CONT_DIF_P</strong> you may see that only three layers will be shown under
<ttclass="docutils literal"><spanclass="pre">graal</span></tt>, but five will be generated in the <ttclass="docutils literal"><spanclass="pre">gds</span></tt> layout.</p>
<h2>The <ttclass="docutils literal"><spanclass="pre">MBK_TO_RDS_BIGVIA_HOLE</span></tt> table<aclass="headerlink"href="#the-mbk-to-rds-bigvia-hole-table"title="Permalink to this headline">¶</a></h2>
<p>In <ttclass="docutils literal"><spanclass="pre">s2r</span></tt>, when generating BIGVIAs, the matrix of holes they contains is
not draw relative to the position of the BIGVIA itself, but on a grid which
is common througout all the design real layout. This is to allow overlap
between two BIGVIA without risking the holes matrix to be not exactly overlapping.
As a consequence, when visualizing the <ttclass="docutils literal"><spanclass="pre">gds</span></tt> file, the holes may not be centerend
inside one individual BIGVIA.</p>
<p>The <ttclass="docutils literal"><spanclass="pre">MBK_TO_RDS_BIGVIA_HOLE</span></tt> table define the global hole matrix for the whole
design. The first number is the individual hole side and the second the grid step
(edge to edge). The figure below show the hole generation.</p>
<pclass="last"><strong>BIGVIA demotion.</strong> If the size of the bigvia is too small, there is
a possibility that no hole from the global matrix will be under it.
To avoid that case, if the either side of the BIGVIA is less than
<ttclass="docutils literal"><spanclass="pre">1.5</span><spanclass="pre">*</span><spanclass="pre">step</span></tt>, the BIGVIA is demoted to a simple VIA.</p>
<h2>The <ttclass="docutils literal"><spanclass="pre">MBK_TO_RDS_BIGVIA_METAL</span></tt> table<aclass="headerlink"href="#the-mbk-to-rds-bigvia-metal-table"title="Permalink to this headline">¶</a></h2>
<p>This table describe how the metal part of a BIGVIA is expanded (for the hole
part, see the previous table <ttclass="docutils literal"><spanclass="pre">MBK_TO_RDS_BIGVIA_HOLE</span></tt>). The rule give for each
metal:</p>
<olclass="arabic simple">
<li>The <em>delta-with</em> (have to ask Franck).</li>
<li>The <em>overhang</em>, the length the real rectangle is expanded on each side from
<h2>The <ttclass="docutils literal"><spanclass="pre">MBK_WIRESETTING</span></tt> table<aclass="headerlink"href="#the-mbk-wiresetting-table"title="Permalink to this headline">¶</a></h2>
<p>From a strict standpoint this table shouldn’t be here but put in a separate
configuration file, because it contains informations only used by the symbolic
<ahref="index.html"class="btn btn-neutral"title="Symbolic to Real Conversion in Alliance"accesskey="p"><spanclass="fa fa-arrow-circle-left"></span> Previous</a>
</div>
<hr/>
<divrole="contentinfo">
<tableclass="footer1">
<tr>
<tdclass="LFooter"><small>
Generated by <ahref="http://sphinx-doc.org/">Sphinx</a>
