141 lines
4.4 KiB
ReStructuredText
141 lines
4.4 KiB
ReStructuredText
.. -*- Mode: rst -*-
|
|
.. include:: ../etc/definitions.rst
|
|
.. include:: ./definitions.rst
|
|
|
|
|
|
1. Introduction
|
|
===============
|
|
|
|
This tutorial is aimed at two goals :
|
|
|
|
* Presenting how to use Python scripts to control |Coriolis|.
|
|
|
|
* Make a basic introduction about the |Hurricane| database and its
|
|
concepts.
|
|
|
|
While this tutorial is aimed at presenting the |Hurricane| database,
|
|
do not feel limited by it. You can use |Hurricane| objects as attributes
|
|
of |Python| objects or use |Python| containers to store them.
|
|
The only limitation is that you may not use |Hurricane| classes as base
|
|
classes in |Python|.
|
|
|
|
All |Hurricane| objects implements the |Python| ``__str__()`` function,
|
|
they print the result of C++ ``::getString()``.
|
|
|
|
|
|
1.1 Terminology
|
|
~~~~~~~~~~~~~~~
|
|
|
|
In the |Hurricane| database, the *logical* (netlist) and *physical* (layout)
|
|
views are fused. As the main goal of the database is to support place & route
|
|
tools, we usually starts with a *pure* netlist which is progessively enriched
|
|
to become a layout. Cell, in particular, is able to be in any intermediate
|
|
state. Many of our objects have self-explanatory names, but some
|
|
don't. Thus we summarize below the more important ones:
|
|
|
|
=============== =====================================================
|
|
**Class** **Meaning**
|
|
=============== =====================================================
|
|
Cell_ The model. A Cell does not have terminals, only nets
|
|
flagged as *external*
|
|
Instance_ An instance of a model
|
|
Net_ A grouping of electrically connected components
|
|
Plug_ A terminal of an instance
|
|
RoutingPad_ A physical connexion (*pin*) to an instance
|
|
=============== =====================================================
|
|
|
|
|
|
1.2 Generalities
|
|
~~~~~~~~~~~~~~~~
|
|
|
|
The C++ API has been exported in Python as closely as possible. Meaning
|
|
that, save for a slight change in syntax, any code written in |Python|
|
|
could be easily transformed into C++ code. There is no specific documentation
|
|
written for the |Python| interface, you may directly use the C++ one.
|
|
|
|
Mostly:
|
|
|
|
* C++ namespaces are exported as |Python| modules.
|
|
* The *scope resolution operator* :fboxtt:`::` converts into :fboxtt:`.`.
|
|
* C++ blocks (between braces :fboxtt:`{}`) are replaced by indentations.
|
|
* In C++, names are managed through a dedicated ``Name`` class.
|
|
It has not been exported to the |Python| interface, you only have
|
|
to use ``string``.
|
|
* Coordinates are expressed in ``DbU`` which are ``long`` with a special
|
|
semantic (see ??).
|
|
|
|
In ``hurricane/Session.h`` header we have:
|
|
|
|
.. code-block:: c++
|
|
|
|
namespace Hurricane {
|
|
|
|
class UpdateSession {
|
|
public:
|
|
static void open ();
|
|
static void close ();
|
|
};
|
|
|
|
}
|
|
|
|
|
|
So we can use it the following way in C++:
|
|
|
|
.. code-block:: c++
|
|
|
|
#include "hurricane/Session.h"
|
|
|
|
using namespace Hurricane;
|
|
|
|
void doSomething ()
|
|
{
|
|
UpdateSession::open();
|
|
// Something...
|
|
UpdateSession::close();
|
|
}
|
|
|
|
|
|
The equivalent |Python| code will be:
|
|
|
|
.. code-block:: Python
|
|
|
|
from Hurricane import *
|
|
|
|
def doSomething ():
|
|
UpdateSession.open()
|
|
# Something...
|
|
UpdateSession.close()
|
|
|
|
|
|
1.3 Various Kinds of Constructors
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Regarding the memory allocation, the |Hurricane| database contains two kind of objects.
|
|
|
|
#. Objects that are linked to others in the database and whose creation or deletion
|
|
implies coherency operations. This is the case for Net_ or Horizontal_.
|
|
They must be created using the static :cb:`create()` method of their class
|
|
and destroyed with their :cb:`destroy()` method.
|
|
|
|
And, of course, they cannot be copied (the copy constructor has been disabled).
|
|
|
|
.. code-block:: Python
|
|
|
|
net = Net.create( cell, 'tmp' ) # Call the static Net.create() function.
|
|
# Work with this net.
|
|
# ...
|
|
net.destroy() # Call the dynamic destroy() method.
|
|
|
|
#. Objects that are *standalone*, like Point_ or Box_, uses the usual construction
|
|
methods. They also use the |Python| garbage collector mechanism and do not need
|
|
to be explicitly deleted.
|
|
|
|
.. code-block:: Python
|
|
|
|
def myfunc():
|
|
bb = Box( DbU.fromLambda( 0.0)
|
|
, DbU.fromLambda( 0.0)
|
|
, DbU.fromLambda(15.0)
|
|
, DbU.fromLambda(50.0) )
|
|
return # bb will be freed at that point.
|