Coriolis User's Guide

Release 1.0.1475

This is the first preliminary release of the Coriolis 2 framework.

This release mainly ships the global router Knik and the detailed router Kite. Together they aim to replace the Alliance Nero router. Unlike Nero, Kite is based on an innovating routing modeling and ad-hoc algorithm. Although it is released under gpl license, the source code will be avalaible later.

1. A graphical user interface (viewer only).
2. The Knik global router.
3. The Kite detailed router.

• Alliance vst (netlist) & ap (physical) formats.
• Even if there are some references to the Cadence lefdef format, its support is not included because it depends on a library only available to Si2 affiliated members.

Release 1.0.1963

Release 1963 is alpha. All the tools from Coriolis 1 have been ported into this release.

1. The Stratus netlist capture language (GenLib replacement).
2. The Mauka placer (still contains bugs).
3. A graphical user interface (viewer only).
4. The Knik global router.
5. The Kite detailed router.
6. Partially implemented python support for configuration files (alternative to xml).
7. A documentation (imcomplete/obsoleted in Hurricane's case).

Release 1.0.2049

Release 2049 is Alpha.

1. The Hurricane documentation is now accurate. Documentation for the Cell viewer and CRLcore has been added.
2. More extensive Python support for all the components of Coriolis.
3. Configuration is now completly migrated under Python. xml loaders can still be useds for compatibilty.
4. The cgt main has been rewritten in Python.

Release v2.0.1

1. Migrated the repository from svn to git, and release complete sources. As a consequence, we drop the distribution packaging support and give public read-only access to the repository.
2. Deep rewrite of the Katabatic database and Kite detailed router, achieve a speedup factor greater than 20...

Release v2.1

1. Replace the old simulated annealing placer Mauka by the analytical placer Etesian and its legalization and detailed placement tools.
2. Added a Blif format parser to process circuits generated by the Yosys and ABC logic synthetizers.
3. The multiples user defined configuration files are now grouped under a common hidden (dot) directory .coriolis2 and the file extension is back from .conf to .py.

Release v2.2

1. Added JSON import/export of the whole Hurricane DataBase. Two save mode are supported: Cell mode (standalone) or Blob mode, which dump the whole design down and including the standard cells.

Fixed Directory Tree

In order to simplificate the work of the ccb installer, the source, build and installation tree is fixed. To successfully compile Coriolis you must follow it exactly. The tree is relative to the home directory of the user building it (noted ~/ or $HOME/). Only the source directory needs to be manually created by the user, all others will be automatically created either by ccb or the build system.

Building Coriolis

First step is to install the prerequisites. Currently, only RapidJSON. As RapidJSON is evolving fast, if you encounter compatibility problems, the exact version we compiled against is given below.

dummy@lepka:~$ mkdir -p ~/coriolis-2.x/src/support
dummy@lepka:~$ cd ~/coriolis-2.x/src/support
dummy@lepka:~$ git clone http://github.com/miloyip/rapidjson
dummy@lepka:~$ git checkout ec322005072076ef53984462fb4a1075c27c7dfd

The second step is to create the source directory and pull the git repository:

dummy@lepka:~$ mkdir -p ~/coriolis-2.x/src
dummy@lepka:~$ cd ~/coriolis-2.x/src
dummy@lepka:~$ git clone https://www-soc.lip6.fr/git/coriolis.git

Third and final step, build & install:

dummy@lepka:src$ ./bootstrap/ccb.py --project=support  \
                                    --project=coriolis \
                                    --make="-j4 install"
dummy@lepka:src$ ./bootstrap/ccb.py --project=support  \
                                    --project=coriolis \
                                    --doc --make="-j1 install"

We need to separate to perform a separate installation of the documentation because it do not support to be generated with a parallel build. So we compile & install in a first stage in -j4 (or whatever) then we generate the documentation in -j1

Under rhel6 or clones, you must build using the devtoolset2:

dummy@lepka:src$ ./bootstrap/ccb.py --project=coriolis \
                                    --devtoolset-2 --make="-j4 install"

If you want to uses Qt 5 instead of Qt 4, you may add the --qt5 argument.

The complete list of ccb functionalities can be accessed with the --help argument. It also may be run in graphical mode (--gui).

dummy@macos:~$ port install boost +python27
dummy@macos:~$ port select python python27
dummy@macos:-$ export DYLD_FRAMEWORK_PATH=/opt/local/Library/Frameworks

Packaging Coriolis

Packager should not uses ccb, instead bootstrap/Makefile.package is provided to emulate a top-level autotool makefile. Just copy it in the root of the Coriolis git repository (~/corriolis-2.x/src/coriolis/) and build.

Sligthly outaded packaging configuration files can also be found under bootstrap/:

• bootstrap/coriolis2.spec.in for rpm based distributions.
• bootstrap/debian for Debian based distributions.

Hooking up into Alliance

Coriolis relies on Alliance for the cell libraries. So after installing or packaging, you must configure it so that it can found those libraries.

This is done by editing the one variable cellsTop in the Alliance helper (see Alliance Helper). This variable must point to the directory of the cells libraries. In a typical installation, this is generally /usr/share/alliance/cells.

Setting up the Environment (coriolisEnv.py)

To simplify the tedious task of configuring your environment, a helper is provided in the bootstrap source directory (also installed in the directory .../install/etc/coriolis2/) :

~/coriolis-2.x/src/coriolis/bootstrap/coriolisEnv.py

Use it like this:

dummy@lepka:~> eval `~/coriolis-2.x/src/coriolis/bootstrap/coriolisEnv.py`

alias c2r='eval "`~/coriolis-2.x/src/coriolis/bootstrap/coriolisEnv.py`"'

General Software Architecture

Coriolis has been build with respect of the classical paradigm that the computational instensive parts have been written in C++, and almost everything else in Python. To build the Python interface we used two methods:

• For self-contained modules boost::python (mainly in vlsisapd).
• For all modules based on Hurricane, we created our own wrappers due to very specific requirements such as shared functions between modules or C++/Python secure bi-directional object deletion.

First Stage: Symbolic Technology Selection

Thoses files must provides only two variables, the name of the symbolic technology and the one of the real technology. For example:

# -*- Mode:Python -*-

symbolicTechno = 'cmos'
realTechno     = 'hcmos9'

Second Stage: Technology Configuration Loading

Configuration Helpers

To ease the writing of configuration files, a set of small helpers is available. They allow to setup the configuration parameters through simple assembly of tuples. The helpers are installed under the directory:

<install>/etc/coriolis2/

Where <install>/ is the root of the installation.

cellsTop = '/usr/share/alliance/cells/'

allianceConfig = \
    ( ( 'SYMBOLIC_TECHNOLOGY', helpers.sysConfDir+'/technology.symbolic.xml'   )
    , ( 'REAL_TECHNOLOGY'    , helpers.sysConfDir+'/technology.cmos130.s2r.xml')
    , ( 'DISPLAY'            , helpers.sysConfDir+'/display.xml'               )
    , ( 'CATALOG'            , 'CATAL')
    , ( 'WORKING_LIBRARY'    , '.')
    , ( 'SYSTEM_LIBRARY'     , ( (cellsTop+'sxlib'   , Environment.Append)
                               , (cellsTop+'dp_sxlib', Environment.Append)
                               , (cellsTop+'ramlib'  , Environment.Append)
                               , (cellsTop+'romlib'  , Environment.Append)
                               , (cellsTop+'rflib'   , Environment.Append)
                               , (cellsTop+'rf2lib'  , Environment.Append)
                               , (cellsTop+'pxlib'   , Environment.Append) ) )
    , ( 'SCALE_X'            , 100)
    , ( 'IN_LO'              , 'vst')
    , ( 'IN_PH'              , 'ap')
    , ( 'OUT_LO'             , 'vst')
    , ( 'OUT_PH'             , 'ap')
    , ( 'POWER'              , 'vdd')
    , ( 'GROUND'             , 'vss')
    , ( 'CLOCK'              , '^ck.*')
    , ( 'BLOCKAGE'           , '^blockageNet*')
    )

import os

homeDir = os.getenv('HOME')

allianceConfig = \
    ( ('WORKING_LIBRARY'    , homeDir+'/worklib')
    , ('SYSTEM_LIBRARY'     , ( (homeDir+'/mylib', Environment.Append) ) )
    , ('POWER'              , 'vdd.*')
    , ('GROUND'             , 'vss.*')
    )

# Etesian parameters.
parametersTable = \
    ( ('etesian.aspectRatio'    , TypePercentage, 100    , { 'min':10, 'max':1000 } )
    , ('etesian.spaceMargin'    , TypePercentage, 5      )
    , ('etesian.uniformDensity' , TypeBool      , False  )
    , ('etesian.routingDriven'  , TypeBool      , False  )
    , ("etesian.effort"         , TypeEnumerate , 2
      , { 'values':( ("Fast"    , 1)
                   , ("Standard", 2)
                   , ("High"    , 3)
                   , ("Extreme" , 4) ) }
      )
    , ("etesian.graphics"       , TypeEnumerate , 2
      , { 'values':( ("Show every step"  , 1)
                   , ("Show lower bound" , 2)
                   , ("Show result only" , 3) ) }
      )
    )

layoutTable = \
    ( (TypeTab   , 'Etesian', 'etesian')

    , (TypeTitle , 'Placement area')
    , (TypeOption, "etesian.aspectRatio"   , "Aspect Ratio, X/Y (%)", 0 )
    , (TypeOption, "etesian.spaceMargin"   , "Space Margin"         , 1 )
    , (TypeRule  ,)
    , (TypeTitle , 'Etesian - Placer')
    , (TypeOption, "etesian.uniformDensity", "Uniform density"      , 0 )
    , (TypeOption, "etesian.routingDriven" , "Routing driven"       , 0 )
    , (TypeOption, "etesian.effort"        , "Placement effort"     , 1 )
    , (TypeOption, "etesian.graphics"      , "Placement view"       , 1 )
    , (TypeRule  ,)
    )

Hacking the Configuration Files

Asides from the symbols that gets used by the configuration helpers like allianceConfig or parametersTable, you can put pretty much anything in <CWD>/.coriolis2/settings.py (that is, written in Python).

For example:

# -*- Mode:Python -*-

defaultStyle = 'Alliance.Classic [black]'

# Regular Coriolis configuration.
parametersTable = \
    ( ('misc.catchCore'           , TypeBool      , False  )
    , ('misc.info'                , TypeBool      , False  )
    , ('misc.paranoid'            , TypeBool      , False  )
    , ('misc.bug'                 , TypeBool      , False  )
    , ('misc.logMode'             , TypeBool      , True   )
    , ('misc.verboseLevel1'       , TypeBool      , False  )
    , ('misc.verboseLevel2'       , TypeBool      , True   )
    , ('misc.minTraceLevel'       , TypeInt       , 0      )
    , ('misc.maxTraceLevel'       , TypeInt       , 0      )
    )

# Some ordinary Python script...
import os

print '       o  Cleaning up ClockTree previous run.'
for fileName in os.listdir('.'):
  if fileName.endswith('.ap') or (fileName.find('_clocked.') >= 0):
    print '          - <%s>' % fileName
    os.unlink(fileName)

See Python Interface to Coriolis for more details those capabilities.

Stratus Netlist Capture

Stratus is the replacement for GenLib procedural netlist capture language. It is designed as a set of Python classes, and comes with it's own documentation (Stratus Documentation)

The Hurricane Data-Base

The Alliance flow is based on the mbk data-base, which has one data-structure for each view. That is, Lofig for the logical view and Phfig for the physical view. The place and route tools were responsible for maintaining (or not) the coherency between views. Reflecting this weak coupling between views, each one was stored in a separate file with a specific format. The logical view is stored in a vst file in vhdl format and the physical in an ap file in an ad-hoc format.

The Coriolis flow is based on the Hurricane data-base, which has a unified structure for logical and physical view. That data structure is the Cell object. The Cell can have any state between pure netlist and completly placed and routed design. Although the memory representation of the views has deeply changed we still use the Alliance files format, but they now really represent views of the same object. The point is that one must be very careful about view coherency when going to and from Coriolis.

As for the second release, Coriolis can be used only for three purposes :

• Placing a design, in which case the netlist view must be present.
• Routing a design, in that case the netlist view and the layout view must be present and layout view must contain a placement. Both views must have the same name. When saving the routed design, it is advised to change the design name otherwise the original unrouted placement in the layout view will be overwritten.
• Viewing a design, the netlist view must be present, if a layout view is present it still must have the same name but it can be in any state.

Synthetizing and loading a design

Coriolis supports several file formats. It can load all file format from the Alliance toolchain (.ap for layout, behavioural and structural vhdl .vbe and .vst), BLIF netlist format as well as benchmark formats from the ISPD contests.

It can be compiled with LEF/DEF support, although it requires acceptance of the SI2 license and may not be compiled in your version of the software.

Etesian -- Placer

The Etesian placer is a state of the art (as of 2015) analytical placer. It is within 5% of other placers' solutions, but is normally a bit worse than ePlace. This Coriolis tool is actually an encapsulation of Coloquinte which is the placer.

The placement area is defined by the top cell abutment box.

When placing a complete hierarchy, the abutment boxes of the cells (models) other than the top cell are sets identical to the one of the top cell and their instances are all placed at position (0,0,ID). That is, all the abutments boxes, whatever the hierarchical level, defines the same area (they are exactly superposed).

We choose this scheme because the placer will see all the instances as virtually flattened, so they can be placed anywhere inside the top-cell abutment box.

The placement area is computed using the etesian.aspectRatio and etesian.spaceMargin parameters only if the top-cell has an empty abutment box. If the top-cell abutment box has to be set, then it is propagated to all the instances models recursively.

Once a placement has been done, the placer cannot reset it (will be implemented later). To perform a new placement, you must restart cgt. In addition, if you have saved the placement on disk, you must erase any .ap file, which are automatically reloaded along with the netlist (.vst).

Etesian supports standard cells and fixed macros. As for the Coriolis 2.1 version, it doesn't support movable macros, and you must place every macro beforehand. Timing and routability analysis are not included either, and the returned placement may be unroutable.

Knik -- Global Router

The quality of Knik global routing solutions are equivalent to those of FGR 1.0. For an in-depth description of Knik algorithms, you may download the thesis of D. Dupuis avalaible from here~: Knik Thesis.

The global router is (not yet) deterministic. To circumvent this limitation, a global routing solution can be saved to disk and reloaded for later uses.

A global routing is saved into a file with the same name as the design and a kgr extention. It is in Box Router output format.

• .

• .

Kite -- Detailed Router

Kite no longer suffers from the limitations of Nero. It can route big designs as its runtime and memory footprint is almost linear (with respect to the number of gates). It has successfully routed design of more than 150K gates.

• Works only with SxLib standard cell gauge.
• Works always with 4 routing metal layers (M2 through M5).
• Do not allow (take into account) pre-routed wires on signals other than power or ground.

After each run, Kite displays a set of completion ratios which must all be equal to 100% if the detailed routing has been successfull. In the event of a failure, on a saturated design, you may decrease the edge saturation ratio (argument --edge) to balance more evenly the design saturation. That is, the maximum saturation decrease at the price of a wider saturated area and increased wirelength. This is the saturation of the global router Knik, and you may increase/decrease by steps of 5%, which represent one track. The maximum capacity of the SxLib gauge is 10 tracks in two layers, that makes 20 tracks by Knik edge.

Routing a design is done in four ordered steps:

1. Detailed pre-route
   .
2. Global routing
   .
3. Detailed routing
   .
4. Finalize routing
   .

It is possible to supply to the router a complete wiring for some nets that the user's wants to be routed according to a specific topology. The supplied topology must respect the building rules of the Katabatic database (contacts must be, terminals, turns, h-tee & v-tee only). During the first step Detailed Pre-Route the router will solve overlaps between the segments, without making any dogleg. If no pre-routed topologies are present, this step may be ommited. Any net routed at this step is then fixed and become unmovable for the later stages.

After the detailed routing step the Kite data-structure is still active (the Hurricane wiring is decorated). The finalize step performs the removal of the Kite data-structure, and it is not advisable to save the design before that step.

You may visualize the density (saturation) of either Knik (on edges) or Kite (on GCells) until the routing is finalized. Special layers appears to that effect in the The Layers&Go Tab.

Executing Python Scripts in Cgt

Python/Stratus scripts can be executed either in text or graphical mode.

A Python/Stratus script must contains a function called ScriptMain() with one optional argument, the graphical editor into which it may be running (will be set to None in text mode). The Python interface to the editor (type: CellViewer) is limited to basic capabilities only.

Any script given on the command line will be run immediatly after the initializations and before any other argument is processed.

For more explanation on Python scripts see Python Interface to Coriolis.

Printing & Snapshots

Printing or saving into a pdf is fairly simple, just uses the File -> Print menu or the CTRL+P shortcut to open the dialog box.

The print functionality uses exactly the same rendering mechanism as for the screen, beeing almost WYSIWYG. Thus, to obtain the best results it is advisable to select the Coriolis.Printer look (in the Controller), which uses a white background and much suited for high resolutions 32x32 pixels patterns

There is also two mode of printing selectable through the Controller Settings -> Misc -> Printer/Snapshot Mode:

Memento of Shortcuts in Graphic Mode

The main application binary is cgt.

Category	Keys	Action
Moves	Up, Down Left, Right	Shift the view in the according direction
Fit	f	Fit to the Cell abutment box
Refresh	CTRL+L	Triggers a complete display redraw
Goto	g	apperture is the minimum side of the area displayed around the point to go to. It's an alternative way of setting the zoom level
Zoom	z, m	Respectively zoom by a 2 factor and unzoom by a 2 factor
	Area Zoom	You can perform a zoom to an area. Define the zoom area by holding down the left mouse button while moving the mouse.
Selection	Area Selection	You can select displayed objects under an area. Define the selection area by holding down the right mouse button while moving the mouse.
	Toggle Selection	You can toggle the selection of one object under the mouse position by pressing CTRL and pressing down the right mouse button. A popup list of what's under the position shows up into which you can toggle the selection state of one item.
	S	Toggle the selection visibility
Controller	CTRL+I	Show/hide the controller window. It's the Swiss Army Knife of the viewer. From it, you can fine-control the display and inspect almost everything in your design.
Rulers	k, ESC	One stroke on k enters the ruler mode, in which you can draw one ruler. You can exit the ruler mode by pressing ESC. Once in ruler mode, the first click on the left mouse button sets the ruler's starting point and the second click the ruler's end point. The second click exits automatically the ruler mode.
	K	Clears all the drawn rulers
Print	CTRL+P	Currently rather crude. It's a direct copy of what's displayed in pixels. So the resulting picture will be a little blurred due to anti-aliasing mechanism.
Open/Close	CTRL+O	Opens a new design. The design name must be given without path or extention.
	CTRL+W	Close the current viewer window, but do not quit the application.
	CTRL+Q	CTRL+Q quit the application (closing all windows).
Hierarchy	CTRL+Down	Go one hierarchy level down. That is, if there is an instance under the cursor position, load it's model Cell in place of the current one.
	CTRL+Up	Go one hierarchy level up. if we have entered the current model through CTRL+Down reload the previous model (the one in which this model is instanciated).

Cgt Command Line Options

Appart from the obvious --text options, all can be used for text and graphical mode.

Some Examples :

• Run both global and detailed router, then save the routed design :

  > cgt -v -t -G -R --cell=design --save-design=design_kite
  

• Load a previous global solution, run the detailed router, then save the routed design :

  > cgt -v -t --load-global -R --cell=design --save-design=design_kite
  

• Run the global router, then save the global routing solution :

  > cgt -v -t -G --save-global --cell=design
  

Miscellaneous Settings

The Look Tab

You can select how the layout will be displayed. There is a special one Printer.Coriolis specifically designed for Printing & Snapshots. You should select it prior to calling the print or snapshot dialog boxes.

The Filter Tab

The filter tab let you select what hierarchical levels of your design will be displayed. Hierarchy level are numbered top-down: the level 0 correspond to the top-level cell, the level one to the instances of the top-level Cell and so on.

There are also check boxes to enable/disable the processing of Terminal Cell, Master Cells and Compnents. The processing of Terminal Cell (hierarchy leaf cells) is disabled by default when you load a hierarchical design and enabled when you load a single Cell.

You can choose what kind of form to give to the rubbers and the type of unit used to display coordinates.

The Layers&Go Tab

Control the individual display of all layers and Gos.

• Layers correspond to a true physical layer. From a Hurricane point of view they are all the BasicLayers (could be matched to GDSII).
• Gos stands from Graphical Objects, they are drawings that have no physical existence but are added by the various tools to display extra information. One good exemple is the density map of the detailed router, to easily locate congested areas.

For each layer/Go there are two check boxes:

• The normal one triggers the display.
• The red-outlined allows objects of that layer to be selectable or not.

The Netlist Tab

The Netlist tab shows the list of nets... By default the tab is not synched with the displayed Cell. To see the nets you must check the Sync Netlist checkbox. You can narrow the set of displayed nets by using the filter pattern (supports regular expressions).

An very useful feature is to enable the Sync Selection, which will automatically select all the components of the selected net(s). You can select multiple nets. In the figure the net auxsc35 is selected and is highlited in the Viewer.

The Selection Tab

The Selection tab list all the components currently selecteds. They can be filtered thanks to the filter pattern.

Used in conjunction with the Netlist Sync Selection you will all see all the components part of net.

In this list, you can toggle individually the selection of component by pressing the t key. When unselected in this way a component is not removed from the the selection list but instead displayed in red italic. To see where a component is you may make it blink by repeatedly press the t key...

The Inspector Tab

This tab is very useful, but mostly for Coriolis developpers. It allows to browse through the live DataBase. The Inspector provide three entry points:

• DataBase: Starts from the whole Hurricane DataBase.
• Cell: Inspect the currently loaded Cell.
• Selection: Inspect the object currently highlited in the Selection tab.

Once an entry point has been activated, you may recursively expore all it's fields using the right/left arrows.

The Settings Tab

Here comes the description of the Settings tab.

Chip Placement

Automatically perform the placement of a complete chip. This plugin, as well as the other P&R tools expect a specific top-level hierarchy for the design. The top-level hierarchy must contains the instances of all the I/O pads and exactly one instance of the chip's core model.

The designer must provide a configuration file that define the rules for the placement of the top-level hierarchy (that is, the pads and the core). This file must be named after the chip's name, by appending _chip.py (obviously, it is a Python file). For instance if the chip netlist file is called amd2901_crl.vst, then the configuration file must be named amd2901_crl_chip.vst.

Example of chip placement configuration file (for AM2901):

chip = \
  { 'pads.south'     : [ 'p_a3'     , 'p_a2'     , 'p_a1'     , 'p_r0'
                       , 'p_vddick0', 'p_vssick0', 'p_a0'     , 'p_i6'
                       , 'p_i8'     , 'p_i7'     , 'p_r3'     ]
  , 'pads.east'      : [ 'p_zero'   , 'p_i0'     , 'p_i1'     , 'p_i2'
                       , 'p_vddeck0', 'p_vsseck0', 'p_q3'     , 'p_b0'
                       , 'p_b1'     , 'p_b2'     , 'p_b3'     ]
  , 'pads.north'     : [ 'p_noe'    , 'p_y3'     , 'p_y2'     , 'p_y1'
                       , 'p_y0'     , 'p_vddeck1', 'p_vsseck1', 'p_np'
                       , 'p_ovr'    , 'p_cout'   , 'p_ng'     ]
  , 'pads.west'      : [ 'p_cin'    , 'p_i4'     , 'p_i5'     , 'p_i3'
                       , 'p_ck'     , 'p_d0'     , 'p_d1'     , 'p_d2'
                       , 'p_d3'     , 'p_q0'     , 'p_f3'     ]
  , 'core.size'      : ( 1500, 1500 )
  , 'chip.size'      : ( 3000, 3000 )
  , 'chip.clockTree' : True
  }

The file must contain one dictionnary named chip.

Configuration parameters, defaults are defined in etc/coriolis2/<STECHNO>/plugins.conf.

Clock Tree

Insert a clock tree into a block. The clock tree uses the H strategy. The clock net is splitted into sub-nets, one for each branch of the tree.

• On chips design, the sub-nets are createds in the model of the core block (then trans-hierarchically flattened to be shown at chip level).

• On blocks, the sub nets are created directly in the top block.

• The sub-nets are named according to a simple geometrical scheme. A common prefix ck_htree, then one postfix by level telling on which quarter of plane the sub-clock is located:

  1. _bl: bottom left plane quarter.
  2. _br: bottom right plane quarter.
  3. _tl: top left plane quarter.
  4. _tr: top right plane quarter.

  We can have ck_htree_bl, ck_htree_bl_bl, ch_htree_bl_tl and so on.

The clock tree plugin works in four steps:

1. Build the clock tree: creates the top-block abutment box, compute the levels of H tree neededs and place the clock buffers.
2. Once the clock buffers are placed, calls the placer (Etesian) to place the ordinary standart cells, whithout disturbing clock H-tree buffers.
3. At this point we know the exact positions of all the DFFs, so we can connect them to the nearest H-tree leaf clock signal.
4. Leaf clock signals that are not connecteds to any DFFs are removed.

Netlist reorganisation:

• Obviously the top block or chip core model netlist is modificated to contains all the clock sub-nets. The interface is not changed.
• If the top block contains instances of other models and those models contains DFFs that get re-connecteds to the clock sub-nets (from the top level). Change both the model netlist and interface to propagate the relevant clock sub-nets to the instanciated model. The new model with the added clock signal is renamed with a _clocked suffix. For example, the sub-block model ram.vst will become ram_clocked.vst.

Configuration parameters, defaults are defined in etc/coriolis2/<STECHNO>/plugins.conf.

Recursive-Save (RSave)

Perform a recursive top down save of all the models from the top cell loaded in cgt. Force a write of any non-terminal model. This plugin is used by the clock tree plugin after the netlist clock sub-nets creation.