// -*- C++ -*- /*! \mainpage * * \section secMainDoc Software Architecture * * * \subsection ssecUniqueInstance Unique Instance-Cell Relationship * * MetaTransistor and Device are derived classes of Cell and are the * building blocks of all analogic designs. * - MetaTransistor(s) are used to build the Devices, and \e only them. * - Device(s) are then assembled into more complex design. * * The important point to remember is that Device and MetaTransistor * \b are Cell(s). * * \note An analogy can be made between the Devices and the Standard Cells * in the numeric world. * * 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 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. * * Method 1: name matching. * * 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: * \code Instance* instance = parentCell->getInstance( cell->getName() ); \endcode * * Method 2: Slave instance. * * 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: * \code Instance* instance = cell->getSlaveInstances().getFirst(); \endcode * * * \subsection ssecWhyMetaTrans Why Meta-Transistor * * 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 (\c G , \c S , \c D , * \c B ) and a comprenhensive set of electrical parameters. * * It is meant to represent a complete transistor, not a finger * of a larger one, it \b is the larger one... * * * \subsection ssecClassOrg Class Organization * * Almost UML schema of the Device related classes. * * \image html device_schema_1_uml.png * * For the Transistor device: * * -# The netlist is fixed and generated (in C++) in the Transistor, by * instanciating one MetaTransistor. * * -# The layout is generated on the fly by calling the relevant * python script. * * -# 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. * * -# The Device::getParameters() method is implemented at this level * and returns a reference to the set of parameters. * * -# Parameters are used to set up the Device characteristics, either * programmatically or through the graphical interface. * * The layout Python generation scripts also uses the Parameter * to know the settings of a device. * * Deprecateds: * * -# Arguments where fully redundant with Parameters, so * we did remove them. * * The Arguments must be removed from the UML schema. * * * \subsection ssecOpenQuestions Open questions * * -# In Bora::channelRouting, what is implemented is in fact an * interval tree (or segment tree). We should try to use their * \c Boost implementation. * * -# 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 \e upward in the class * hierarchy. */