<p>MetaTransistor and Device are derived classes of Cell and are the building blocks of all analogic designs.</p><ul>
<li>MetaTransistor(s) are used to build the Devices, and <em>only</em> them.</li>
<li>Device(s) are then assembled into more complex design.</li>
</ul>
<p>The important point to remember is that Device and MetaTransistor <b>are</b> Cell(s).</p>
<dlclass="section note"><dt>Note</dt><dd>An analogy can be made between the Devices and the Standard Cells in the numeric world.</dd></dl>
<p>In Analog designs, Devices and MetaTransistors are all parametriseds in such a way that each one become effectively unique. So any Device or MetaTransistor is only instanciated once with it's specific set of parameter's values, thus there is a <b>unique</b> relationship between a Device and it's instance. We can keep tab of only one of the two. As the Cell contains more information, this is the one we choose. But we still need the Instance to perform (store) the placement informations. So, how to get the Instance from one Device.</p>
<p><b>Method 1:</b> name matching.</p>
<p>For the sake of clarity, we impose that the Device name must be identical to the instance name. This way we can lookup for an Instance in the top device with the same name as the current model. We assume that we indeed have the containing Cell in handy:</p>
<p>In the Hurricane data structure, every Device (Cell) keep track of the Instances pointing to it. Since there should be only one in analogic, we can do the following:</p>
<divclass="fragment"><divclass="line">Instance* instance = cell->getSlaveInstances().getFirst();</div></div><!-- fragment --><h2><aclass="anchor"id="ssecWhyMetaTrans"></a>
Why Meta-Transistor</h2>
<p>The Hurricane database does not have true support for transistor as Cell(s), only a dedicated layer for Segment. Hence the implementation of the MetaTransistor in Hurricane/Analog. It provides a Cell derived class with four connectors (<code>G</code> , <code>S</code> , <code>D</code> , <code>B</code> ) and a comprenhensive set of electrical parameters.</p>
<p>It is meant to represent a complete transistor, not a finger of a larger one, it <b>is</b> the larger one...</p>
<h2><aclass="anchor"id="ssecClassOrg"></a>
Class Organization</h2>
<p>Almost UML schema of the Device related classes.</p>
<li>The netlist is fixed and generated (in C++) in the Transistor, by instanciating one MetaTransistor.</li>
<li>The layout is generated <em>on the fly</em> by calling the relevant python script.</li>
<li>The parameters, which are commons to all the Transistor based devices are created in TransistorFamily. The parameters are created through the Device parameter factory and stored at the Device level. A pointer to the concrete type of Parameter is also kept at the TransistorFamily level.</li>
<li>The Device::getParameters() method is implemented at this level and returns a reference to the set of parameters.</li>
<li><pclass="startli">Parameters are used to set up the Device characteristics, either programmatically or through the graphical interface.</p>
<pclass="startli">The layout Python generation scripts also uses the Parameter to know the settings of a device.</p>
</li>
</ol>
<p>Deprecateds:</p>
<oltype="1">
<li><pclass="startli"><code>Arguments</code> where fully redundant with Parameters, so we did remove them.</p>
<pclass="startli"><b>The Arguments must be removed from the UML schema.</b></p>
</li>
</ol>
<h2><aclass="anchor"id="ssecOpenQuestions"></a>
Open questions</h2>
<oltype="1">
<li>In Bora::channelRouting, what is implemented is in fact an interval tree (or segment tree). We should try to use their <code>Boost</code> implementation.</li>
<li>In Bora::SlicingTree, whe should merge the list of user nodes (devices and hierarchical) with the routing nodes (channels and struts) to unify the underlying management. This sould enable us to move lots method implementation <em>upward</em> in the class hierarchy. </li>
