67 lines
4.3 KiB
TeX
67 lines
4.3 KiB
TeX
|
\hypertarget{index_secMainDoc}{}\section{Software Architecture}\label{index_secMainDoc}
|
||
|
|
\hypertarget{index_ssecUniqueInstance}{}\subsection{Unique Instance-\/\+Cell Relationship}\label{index_ssecUniqueInstance}
|
||
|
|
Meta\+Transistor and Device are derived classes of Cell and are the building blocks of all analogic designs.
|
||
|
|
\begin{DoxyItemize}
|
||
|
|
\item Meta\+Transistor(s) are used to build the Devices, and {\itshape only} them.
|
||
|
|
\item Device(s) are then assembled into more complex design.
|
||
|
|
\end{DoxyItemize}
|
||
|
|
|
||
|
|
The important point to remember is that Device and Meta\+Transistor {\bfseries are} Cell(s).
|
||
|
|
|
||
|
|
\begin{DoxyNote}{Note}
|
||
|
|
An analogy can be made between the Devices and the Standard Cells in the numeric world.
|
||
|
|
\end{DoxyNote}
|
||
|
|
In Analog designs, Devices and Meta\+Transistors are all parametriseds in such a way that each one become effectively unique. So any Device or Meta\+Transistor is only instanciated once with it\textquotesingle{}s specific set of parameter\textquotesingle{}s values, thus there is a {\bfseries unique} relationship between a Device and it\textquotesingle{}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.
|
||
|
|
|
||
|
|
{\bfseries 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\+:
|
||
|
|
|
||
|
|
|
||
|
|
\begin{DoxyCode}
|
||
|
|
Instance* instance = parentCell->getInstance( cell->getName() );
|
||
|
|
\end{DoxyCode}
|
||
|
|
|
||
|
|
|
||
|
|
{\bfseries 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\+:
|
||
|
|
|
||
|
|
|
||
|
|
\begin{DoxyCode}
|
||
|
|
Instance* instance = cell->getSlaveInstances().getFirst();
|
||
|
|
\end{DoxyCode}
|
||
|
|
\hypertarget{index_ssecWhyMetaTrans}{}\subsection{Why Meta-\/\+Transistor}\label{index_ssecWhyMetaTrans}
|
||
|
|
The Hurricane database does not have true support for transistor as Cell(s), only a dedicated layer for Segment. Hence the implementation of the Meta\+Transistor in Hurricane/\+Analog. It provides a Cell derived class with four connectors ({\ttfamily G} , {\ttfamily S} , {\ttfamily D} , {\ttfamily B} ) and a comprenhensive set of electrical parameters.
|
||
|
|
|
||
|
|
It is meant to represent a complete transistor, not a finger of a larger one, it {\bfseries is} the larger one...\hypertarget{index_ssecClassOrg}{}\subsection{Class Organization}\label{index_ssecClassOrg}
|
||
|
|
Almost U\+ML schema of the Device related classes.
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
For the Transistor device\+:
|
||
|
|
|
||
|
|
|
||
|
|
\begin{DoxyEnumerate}
|
||
|
|
\item The netlist is fixed and generated (in C++) in the Transistor, by instanciating one Meta\+Transistor.
|
||
|
|
\item The layout is generated {\itshape on the fly} by calling the relevant python script.
|
||
|
|
\item The parameters, which are commons to all the Transistor based devices are created in Transistor\+Family. 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 Transistor\+Family level.
|
||
|
|
\item The Device\+::get\+Parameters() method is implemented at this level and returns a reference to the set of parameters.
|
||
|
|
\item 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.
|
||
|
|
\end{DoxyEnumerate}
|
||
|
|
|
||
|
|
Deprecateds\+:
|
||
|
|
|
||
|
|
|
||
|
|
\begin{DoxyEnumerate}
|
||
|
|
\item {\ttfamily Arguments} where fully redundant with Parameters, so we did remove them.
|
||
|
|
|
||
|
|
{\bfseries The Arguments must be removed from the U\+ML schema.}
|
||
|
|
\end{DoxyEnumerate}\hypertarget{index_ssecOpenQuestions}{}\subsection{Open questions}\label{index_ssecOpenQuestions}
|
||
|
|
|
||
|
|
\begin{DoxyEnumerate}
|
||
|
|
\item In Bora\+::channel\+Routing, what is implemented is in fact an interval tree (or segment tree). We should try to use their {\ttfamily Boost} implementation.
|
||
|
|
\item In Bora\+::\+Slicing\+Tree, 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 {\itshape upward} in the class hierarchy.
|
||
|
|
\end{DoxyEnumerate}
|