Si2oaD/Quick Start

From oacwiki

Jump to: navigation, search

The following steps can be used as a guide to get started with Si2oaD:

  • Verify any prerequisites
  • Download the latest oaD release (and any extra packages needed)
  • Unpack the tarball[s]
  • Check the package contents
  • Check the environment
  • Check configuration options
  • Build the code
  • Test the build
  • Install the package

Contents

1 Prerequisites

The batch version consists of straightforward C++ code and should build with any ANSI compiler.

  • Si2oaD is built as a shared library: libsi2oadebug.so
  • si2dis is the stand-alone executable that (dynamically) links with libsi2oadebug.so

The first versions of the code were built on Solaris 9. However, the lion's share of releases to date have been tested only on Linux with gdb, and WinXP with VisualStudio (.NET). Not every release has been tested on every platform combination listed in Table 1 (due to resource limitations). The fervent hope is that the various tool/OS mixes that have been used have shaken out almost all the cross-platform problems, at least within the universe covered by the table.

Table 1: Si2oaD Configurations Tested
OS Compiler Bits Browser
SuSE 10 gcc 4.1.0 32 firefox 1.5.0.4
firefox 2.0
SuSE 10.1 gcc 4.1.0 64 firefox 1.5.0.3
firefox 2.0
SuSE 10.2 gcc 4.1.2 64 firefox 2.0.0.10
konqueror 3.5.5
SuSE 10.3 gcc 4.2.1 32 firefox 3.0.1
seamonkey 1.1.9
SuSE 11.3 gcc 4.5.0 64 firefox 3.6.2
RH EL 30 gcc 3.2.3 32 mozilla 1.4
RH EL 40 gcc 3.4.3 32 mozilla 1.7.7
XP VisualStudio 2003 32 firefox 2.0
XP VisualStudio 2005 32 firefox 2.0
mozilla 1.7.13
XP sp2 VisualStudio 9 (Free Express8) 32 firefox 2.0.0.16

1.1 Console Output

If linked in and called from within an application, any ANSI linker should work. However, the makefiles are set up to insert that lib into an executable to enable its use with a debugger using LD_PRELOAD, which may not be available on all platforms.

1.2 GUI Output

Using the GUI (browser) to view the output pulls in a bunch of other dependencies:

  • A browser to display the either the
  • A decent amount of Javascript code using several DOM features (notoriously supported with varying consistency across browser implementations)

There is a wide variation in browser support at the level needed for this GUI display. Platform/browser combinations other than those shown above may also work with varying degrees of success.

1.3 Tcl

If the Tcl interface is needed,

  • A pre-built (with SWIG) siioadtcl.cpp is included with the
  • The siioadtcl.cpp interface module can be build directly from the siioadtcl.i file; however, an appropriate version of SWIG must be installed.

2 Download the Release Tarball(s)

Get the latest release from the Si2 project page for Si2oaD.

2.1 OA Release Compatibility

Each Si2oaD release ID is followed by the OA build ID (in parentheses) used to test it. An Si2oaD release should work OK with a couple (even a few) prior (minor) OA releases because as new Si2oaD versions are tested with new OA releases, recent OA API and behavioral changes are likely to be identified. These OA differences are addressed in the Si2oaD code with

  • #ifdefs for model 4 changes, plus
  • some run-time tests (against specific OA build IDs) in the code will avoid known OA problems in older releases.

A recent Si2oaD release might even work with a very old OA release, since these changes are cumulative; however, little effort is made to test each Si2oaD release against older OA builds. Also, there is little chance a model-4 Si2oaD would work at all with a model-3 OA package, primarly because no attention at all was given to backward compatibility in those days.

Feel free to report on this forum such problems you discover so more checks can be added to the code as it matures to improve backward compatibility.

Some Si2oaD releases have the OA build version with which they were tested in parenthesis after the release ID. But that has not been made consistent (yet).

Read the Release Notes for each Si2oaD Files entry list tested platform[s] details. If the Release Notes are missing the "tested with OA release #", then it is the same OA release used for the prior Si2oaD release.

2.2 Integrity Validation

Before unpacking, verify the integrity of the download by verifying the md5sum shown at the top of the Release Notes for that release. 

 $ md5sum si2dis-2010.09.02.tar.gz
 e6ce1759b9da83c28d2eaf723ebb34ed  si2dis-2010.09.02.tar.gz

md5sum is a standard Linux utility (documented in the man pages) and also is available free in the GNU coreutils.

3 Unpack the Release Tarballs

3.1 Si2OoaD Code

The code release package is created on Linux

  • for UNIX using tar, gzip
  • for Windows using zip

The package name includes the packing date (YYYY.MM.DD). For example, to unpack the 1.10 release for Linux, the following commands would be used: 

$ PATH2DEFS=`pwd`
$ gunzip  -c  si2dis2010.09.02.tar.gz  |  tar xvf -

Call the directory into which this tarball was unzipped PATH2DEFS (i.e., the path to the makefile.defs common gmake component used by the subdirectories under it).

3.2 XSLT processor (OPTIONAL)

Si2oaD's raw output format is XML.

3.2.1 output

If the output option (4.1.4) is set to

  • "console" – the output, unchanged, will be sent to stdout
  • "gui" – the output will be opened in a browser. Without further option settings, that browser will display the same, raw XML output. Nevertheless, most modern browsers display XML with a couple of conveniences: Nested tags can have their content expanded/collapsed with a mouse click, remembering all nested internal expansion positions even as a parent tag is collapsed. Since the Si2oaD XML format maps the OA Object owner hierarchy to tag nesting, in a browser, even the raw XML can give a pretty good picture of the RTM at the point it was generated.

3.2.2 xsltype

Transforming the raw XML into HTML will add a significant amount of active content, making the result much more readable, especially as the volume of output gets larger. This is accomplished via XSLT either using

  • the browser's native XSLT capability (a feature of Mozilla, Netscape, and other browsers)
  • a stand-alone processor (useful for browser with XSL transformation engines that do not work properly)

The xsltype option selects which these two methods will be used, "processor" or "browser", respectively. If that option is "none" or if XSL transormation fails, the raw XML will be sent to the browser – which may still be better than console display since many browsers will add collapse/expand features to XML content automatically.

3.2.3 External XSLT Location

If the browser does not have XSLT capability then an external XSLT processor must be used. The following options must be set to tell Si2oaD how to access that code:

  • xslexe defines the path to the XSLT processor executable
  • xsllib defines the colon-separated paths to libs needed by the xslexe processor.

For example, the Xalan processor (and xerces XML parser) can be used for the transformation (8). A self-contained package of these tools is available for download separately from the Si2 OpenAccess Debug project area of the OpenEDA.org site. The following log illustrates unpacking these tools for use. 

$ gunzip -c XML.tar.gz | tar xvf -
XML/
XML/bin/
XML/bin/Xalan
XML/lib/
XML/lib/libxalan-c.so
XML/lib/libxalan-c.so.19
XML/lib/libxalan-c.so.19.0
XML/lib/libxalanMsg.so
XML/lib/libxalanMsg.so.19
XML/lib/libxalanMsg.so.19.0
XML/lib/libxerces-c.so
XML/lib/libxerces-c.so.26
XML/lib/libxerces-c.so.26.0
XML/lib/libxerces-depdom.so
XML/lib/libxerces-depdom.so.26
XML/lib/libxerces-depdom.so.26.0
XML/Xalan.LICENSE
XML/xerces.LICENSE

3.3 Example Testdata (OPTIONAL)

Near the bottom of the same OAC project page that has the OAD code download packages is a separate section of downloads called, [Example TestData]. This tarball includes several Lib directories of simple example data that can be used to try out OAD. A couple of the make targets are set up to use some of this Example TestData to validate the install. For example, the default settings in the Makefile for the INPUT make variable use the sample/ test data library. The llf target is used first to construct a lib.defs in . that points to the sample/ directory. 

 make llf
 make run
 make check

Unpack the exampleData.tar.gz into the PATH2DEFS install root (i.e., ../si2dis). It doesn't have to be located there; but if it is not, change the Makefile or manually edit the lib.defs to point where that sample/ directory ends up.

4 Check Package Contents

Change directory to the top of the release tree ($PATH2DEFS) and look at the contents. 

$ cd $PATH2DEFS
$ ls -F
makedefs.gcc*   purgeIDsFromOadOutput.sh*  si2assert.h*  si2distest/
makefile.defs*  README.txt                 si2dis/

There should be

  • A top-level README.txt file to help understanding of the build/install/run procedures.
  • A few makefile components
  • The main .si2dis/ directory which houses both the
    • Si2oaD library code
    • Stand-alone si2dis executable useful for batch display of a persistent design
  • The si2distest/ directory containing testcases to practice the use of Si2oaD with linked executables that have various kinds of OA data
  • The purgeIDsFromOadOutput.sh which is useful for cleaning things that always differ from run to run (e.g. the created time) from Si2oaD output files so that they can be more easily diff'd. (The si2dis/testrelease.sh script automatically runs this on the outputs before diff.)

4.1 si2dis/

The si2dis/ directory has the Si2oaD code in it: 

$ cd si2dis
$ ls -F
abort.html                    si2logotrim.gif           si2oadSortUniversal.cpp
apiLinkTable.js               si2oadCMapViewer.cpp      si2oadutil.cpp
Doxyfile                      si2oadcoll.h              si2oadutil.h
favicon.ico                   si2oad.cpp                si2oadwin.h
findUnimplementedClasses.sh*  si2oad.css                si2oadwww.cpp
formatCfiles.el               si2oadDataViewer.cpp      si2oadwww.h
LICENSE.html                  si2oadglob2.cpp           si2oadxml.cpp
LICENSE.txt                   si2oadglob.cpp            si2oadxml.h
Makefile                      si2oadglob.h              si2oad.xsl
od.sh*                        si2oad.h                  siioadtcl.cpp
quit.html                     si2oadheader.js           siioadtcl.h
README.txt                    si2oadmutex.h             siioadtcl.i
regexChoices.html             si2oadObserve.cpp         snapshot.sh*
regexError.html               si2oadregex.cpp           Solution/
si2dis.cpp                    si2oadregex.h             status.html
si2disErrObserver.cpp         si2oadSortInfoType.cpp    testrelease.gold
si2disErrObserver.h           si2oadSortLayer.cpp       testreleaseguts.sh*
si2dis.sh*                    si2oadSortName.cpp        testrelease.sh*
si2disutil.h                  si2oadSortOaTypeName.cpp

4.2 si2distest/

The si2distest/ directory has a few test cases that can help exercise Si2oaD: 

Makefile*  parasitics1.cpp*  Solution/  test1.cpp*  README.txt  tcl1.tcl*

5 Check Environment and Configuration Options

5.1 Win XP Version

For information about building a WIN version of Si2oaD with VisualStudio, read the following files:

  • 2005: si2dis/README.Win32.txt
  • 2008 (free version): si2dis/VS2008/README_Win32_vc9.txt

Two additional components may need to be installed to take advantage of the full capability of the tool. Both can be downloaded either from their source sites or from the OpenEDA Redistributed Components page.

5.1.1 RemoteLib

The insertDLL code is used to inject the OAD libs into a process (in place of the LD_PRELOAD technique used on UNIX platforms). If not explicitly linking the OAD libs in with the executable (meaning that the .exe has a call to an OAD symbol that needs resolution), then this library (or equivalent) must be downloaded and unpacked in the si2dis/ directory.

5.1.2 GNU regex

For the free version of VS2008 (which does not come with ATL), the GNU regex library will also be needed (if regular expression filters are to be used with Si2oaD).

5.2 UNIX Version

Try running the environment test target in the si2dis/Makefile to get information about any files or make variable settings that might need attention: 

$ cd ../si2dis; make envtest

The $PATH2DEFS/si2dis/Makefile expects that key settings are exported in from the environment. 

Make Variable   Default       Description
Si2_ROOT_OA     No default    The absolute path to the OA install MUST be passed set for make.
Si2_OA_BIT      64
Si2_OA_MODE     opt
Si2_PLATFORM                  If unset, $(Si2_ROOT_OA)/bin/sysname will guess it.
PREFIX          $(PATH2DEFS)  The path into which the Si2oaD code will be installed. 
SKIPTCL         0             1 means skip the Tcl build/install parts. If SWIG is not installed
                              the supplied siioadtcl.cpp (SWIG output) may work. If Tcl is not
                              installed (or not wanted) set SKIPTCL=1.

Try the envtest again with some of these variables set to verify they fix many errors (using values appropriate for the current platform and install locations, of course): 

$ make envtest  Si2_ROOT_OA=/OpenAccess/p064  Si2_OA_BIT=32  Si2_OA_MODE=dbg

Edit makefile.defs to set custom values for a few other variables depending on need) in the CUSTOMIZE block near the top: 

#__________________________________________
#
#              CUSTOMIZE 
#__________________________________________

The rest of the makefile.defs consists of settings derived from these key variables. For example, OA lib/ and bin/ locations are derived from the ROOT_OA location using these values: 

DIR_INC_OA = $(ROOT_OA)/include/oa
DIR_LIB_OA = $(ROOT_OA)/lib/$(PLATFORM)_$(OA_BIT)/$(OA_MODE)
DIR_BIN_OA = $(ROOT_OA)/bin/$(PLATFORM)_$(OA_BIT)/$(OA_MODE)

Some engineers use a TCL_HOME (exported into make from the environment) to set automatically locations for the Tcl includes and libraries. 

TCL_HOME = /usr/lang/tcl

Alternatively, individual variables can be set for 

INCLUDES_TCL =
TCLSH        =/usr/bin/tclsh8.5
LIB_TCL      =/usr/lib64/libtcl8.4.so

It is possible other changes may be needed near the top of that file for special situations. It may also be necessary to set the #include makedefs.* appropriate for the architecture and tools being used, as well as edit that file to account for other variations in the environment. On a 64 bit platform, the following setting is probably also necessary: 

LIBDL = /lib64/libdl.so.2

The default settings create Si2oaD install bin/, lib/, and data directories in the package root ($PATH2DEFS). If desired, the installation directory can be changed by either modifying the PREFIX setting in makefile.defs or by overriding the PREFIX from the make command line: 

PREFIX = /usr/local
-or-
make install PREFIX=/usr/local

5.3 OpenAccess Data Model 3 vs. Data Model 4

Beginning with OAD v1.4.2, support is available for both DM3 (226p052) and DM4 OA release versions, implemented in both,

  • Source code ─ This should not require manual editing. The oacDataModelRevNumber is checked via #ifdef, skipping code if its value is 4.
  • makefiles ─ These will require manual editing. Seach for “226” in both
    • makefile.defs ─ To point paths to a 226 install and to activate the “D” suffix that was added to OA library names in DM3 releases.
    • Makefiles in the si2dis/ and si2distest/ directories to point path settings to an OpenAccess version 2.2.6 installation.

6 Edit the .si2oadoptions File

The default option settings in the code are designed for limited console output only. Use of the GUI will require several environment-dependent settings. Copy an .si2oadoptions file into one of the following locations:

  • the directory that will be the current working directory at the time the options are read
  • $HOME (the second location tried in case no options file exists in the cwd)

Several key option settings should be evaluated and set

  • to conform to the execution environment
  • for easier start-up
  • for faster execution

6.1 Environment Options

  • browser – If you want to use a browser other than mozilla, specify your favorite browser, such as "firefox". If the browser is not in the PATH of the executing process, use a full path.
  • xsltype – If the XML/ directory will not be installed, or if the browser is to be used to perform the XSL transformation from Si2oaD's XML output to HTML, then set this to "browser".
  • oadoc – When the output option is set to "gui", OA class names appear as hyperlinks. Click on the link and the documentation for that class appears in a browser. Set oadoc to the URL or absolute path of the OA doc/oa/html/ documentation directory.
  • xslexe – If xsltype was set to "processor", set this to the correct absolute path of the XSL processor, which could be the XML/ directory available as a companion download (2.2.2).
  • xsllib – If xsltype was set to processor, set this to the correct absolute path of any shared objects needed by the XSL processor identified in option xslexe (2.2.2).

6.2 Start-Up Simplicity, Performance

  • output – Begin with output set to "console". This will eliminate problems associated with browser configuration and the complexities of XMLHttpRequest communications. Once the basic setup for oad and the debugger has been perfected, change output to "gui" in order to display the database in a browser.
  • maxcollentries - If output is "gui", and the test design is large, a huge amount of HTML (megabytes!) can be generated. This can take a long time to display, perhaps more than an hour, if the browser doesn't crash first! Setting maxcollentries to 1 limits the amount of data sent to the browser to small increments. The ... sentinel at the end of each Collection can then be clicked to access each successive item incrementally. If the entire data dump must be seen, consider leaving output set to "console". The resulting XML file can later be fed to a browser. If the program crashes, at least the XML file can be inspected with a text editor like emacs.
  • maxownerlevels - The same advice given for maxcollentries applies to maxownerlevels.
  • expandocc – Begin by setting expandocc to "f" to avoid a potentially large amount of Occurrence data from being automatically included in the output. 
*loadnetworks – Begin by setting loadnetworks to "f" to avoid a potentially large amount of Parasitic data from being automatically included in the output.

There are also many other settings available in the .si2oadoptions file.

7 Build/Install the Code

7.1 Build

The code can be built in-place (where it was unpacked into $PATH2DEFS/si2dis) as follows: 

$ make build  Si2_ROOT_OA=/data/OA/p064  Si2_OA_BIT=32  Si2_OA_MODE=dbg

Setting a PREFIX will cause the various Si2oaD pieces to be installed at a desired root location, grouped together in a way that they can be located automatically at run-time. If not set, PREFIX defaults to the Si2oaD package install root (i.e., the directory parent of the si2dis/ and si2distest/ directories).

7.2 Install

The same hierarchical structure used for the OA tree has been copied for the Si2oaD install in order to

  • Enable coexistence of multiple version combinations for executables and libraries involving
    • PLATFORM
    • NBITS
    • MODE
  • Simplify user understanding of the install layout by using the same scheme for
    • bins, with executables for
      • OA tools, like oa2lef, oa2spef, ...
      • Si2oaD tools (si2dis)
    • libs, for
      • OA release link modules (liboaCommon.so, liboaBase.so, ...)
      • Si2oaD modules (like libsi2oadebug.so, siioadtcl.so)
  • Leverage the same "platform-guessing" scheme provided by the OA release code in order to
    • Reuse code many already know by heart
    • Benefit from future upgrades, platform support "automatically" with new OA releases

Figure 1 illustrates the parallel nature of the OA and oaD install trees. ERRATA: In each of the 4 pairs of trees in Figure 1, one branch should be labelled: linux_rhel40_64.

Figure 1: Install Layout Scheme

Image:OadInstallPlan.gif

The Si2oaD package can be installed into the OA install tree (along side the OA libs and translator executables) simply by setting PREFIX=OA_ROOT (assuming the installer has write permission into the OA tree).

For example, whether /tmp/oad exists already or not, the following install command will create the various install subdirectories as needed. 

 /home/si2dis> make install PREFIX=/tmp/oad
 Install root for si2dis = /tmp/oad
 Created script wrapper to run si2dis by embedding path defs in si2dis.csh
 Created script wrapper to run si2dis by embedding path defs in si2dis.sh
 ...Making wrapper scripts for si2dis
 make[1]: Entering directory `/home/labs/si2dis'
 make[1]: Leaving directory `/home/labs/si2dis'
 ...Installing si2dis and its script wrappers in /tmp/oad/bin
 ...Installing libsi2oadebug.so in /tmp/oad/lib/si2dis
 ...Installing DLLs in /tmp/oad/lib/si2dis:
    si2oadDataViewer.so
    si2oadCMapViewer.so
    si2oadObserve.so
    si2oadSortName.so
    si2oadSortInfoType.so
    si2oadSortOaTypeName.so
    si2oadSortUniversal.so
 ...Installing docroot files in /tmp/oad/etc/si2dis:
    si2logotrim.gif
    si2oad.xsl
    si2oad.css
    apiLinkTable.js
    si2oadheader.js
    favicon.ico
    regexChoices.html
    regexError.html
    quit.html
 ...Installing si2oadtcl.so in /tmp/oad/lib/si2dis
 cp si2oadtcl.so /tmp/oad/lib/si2dis

The resulting oad pieces are grouped as follows: 

../lib/linux_rhel40_32/dbg:
libsi2dff.so         si2oadDataViewer.so    si2oadSortName.so
libsi2oadebug.so     si2oadObserve.so       si2oadSortOaTypeName.so
libsi2obs.so         si2oadSortInfoType.so  si2oadSortUniversal.so
si2oadCMapViewer.so  si2oadSortLayer.so     siioadtcl.so

../lib/linux_rhel40_32/opt:
libsi2dff.so       si2oadCMapViewer.so    si2oadSortLayer.so       siioadtcl.so
libsi2oadebug.so   si2oadDataViewer.so    si2oadSortName.so
libsi2obs.so       si2oadObserve.so       si2oadSortOaTypeName.so
libsi2pcplugin.so  si2oadSortInfoType.so  si2oadSortUniversal.so

../lib/linux_rhel40_64/opt:
... ...

../bin/linux_rhel40_32/dbg:
si2dis

../bin/linux_rhel40_32/opt:
si2dis

../bin/linux_rhel40_64:
... ...

7.3 Uninstall the Code

The cleaninstall target will remove the various oad pieces from their PREFIX root install locations: 

 make uninstall PREFIX=....

8 Test the Build

8.1 Automated Test Script

An automated test script, testrelease.sh, is included in the si2dis/ directory of the tarball. It is one way to test the release package. NOTE: This script requires the example test data package.

The testrelease.sh script expects as an argument the path to the directory where the downloaded tarball is located (default is /tmp). The script will unpack that tarball into a similarly named directory created where the tarball is. 

$ testrelease.sh $DIRparentOFtarball

This script illustrates running the tool with various make configurations and testcases. The output can then be compared against the file, testrelease.gold, to verify the code is working as expected. Since many details (including console prompts, dates, hexadecimal address values, parasitic file identifiers, timestamps, etc.) will likely be different for various install configurations and platforms, an exact diff is not possible. But except for those details, a test run should surface any major problems with the release or its installation. The script will automatically diff the output against a testrelease.gold file as a measure of how well the environment and configuration options are set up, as well as the integrity of the downloaded package.

8.2 Manual Test

Try a simple test of the stand-alone si2dis to display a persistent design.

8.2.1 Make and Run the Code

Use the run target to kick off the stand-alone si2dis tool that has the Si2oaD libraries explicitly linked in and calls oad() directly inside the code. The testrelease.gold file included with the release shows several run examples and their outputs. The simplest, using command-line arguments specified by the INPUT make variable in the si2dis/Makefile, is: 

$ make run

Note, in the default .si2oadoptions file, option output is set to "console", which will cause the output to appear on the console and be copied to si2dis.out which can be diff'd against the file, gold.sample.out. To avoid console output (which could be voluminous), the makefile.defs "run", "gdb", or "oad" targets can be edited to convert the pipe to the tee program into a simple redirect to an output file name. For large XML output, the tee can be overridden as follows: 

$ make run TEE2FILE="" ...send to console only'
$ make run TEE2FILE=">file.txt" ...send to file.txt only'

8.3 Try Other Test Data

Run the same si2dis stand-alone tool on a larger library. First change option output in the .si2oadoptions to be "gui" (this would be an excessive amount of output to send to the console): 

$ sed 's/^output .*/output gui/' .si2oadoptions >.si2oadoptions-gui
$ cp .si2oadoptions-gui .si2oadoptions

Create a lib.defs file because this design requires definitions for a Tech in a different Lib but only one Lib mapping can be specified on the command line for si2dis: 

$ echo DEFINE techLib ../mdparies/LibDirTech >lib.defs
$ echo DEFINE mdparies ../mdparies/LibDir >>lib.defs

Now run the tool specifying the Lib, Cell, and View names to be displayed: 

$ make run INPUT="deflib mdp_aries layout"

8.4 Try the GUI

Set the option, output=gui, and then run the tool. Make sure the browser option is set to an executable in the PATH (or includes an absolute path).

If XSL runs successfully (whether via xsl=processor or xsl=browser) to convert the XML to HTML, then there are many active sites on the screen. Unfortunately, to reduce HTML volume for performance reasons, few of these are marked individually with tags; hence, automatic change of the cursor to a “hand” via CSS is impossible. Becoming familiar with the kinds of things are active HTML will be necessary for effective use of the GUI.

9 Debug a Fully-Linked Executable

While the si2dis/si2dis.cpp program has a call to an oad() function embedded in its source code, the si2distest directory has a couple of testcase "nano-apps" that illustrate running Si2oaD with a fully-linked application. Although the Makefile in that directory actually builds a testcase from source, it is then linked with the OAD code at run-time, showing how this can be accomplished with a commercial tool for which source (or even unlinked objects) may not be available.

9.1 Parasitics1

The si2distest/parasitics1.cpp testcase illustrates some parasitics model data, as well as the on-demand binding support of the GUI.

Search for the first pnChild1−>unload() call; say it is at line 181. Run the testcase as follows, getting to that call and stepping past it to cause the Network to be unloaded from RTM: 

make oad TEST=parasitics1
o
break 181
c
n
call oad()

In the GUI, open up the model to the “pnRoot” Network. 

Session
 libs
  oaLib
   designs
    oaDesign name=LibDetPara=FullAdder=routed
     oaBlock
      nets
       oaScalarNet name=netRoot
        parasiticNetworks
         oaParasiticNetwork name=pnRoot
          partitions

The “childPN2” and “childPN0” partitions are loaded already in the RTM (as can be seen by the isLoaded=t attributes, as well as the+ on the entry indicating that there is data to be expanded in the entry). 

+oaParasiticNetwork name=childPN2 ... isLoaded=t ...
oaParasiticNetwork name=childPN1 ... parents=pnRoot ... pn=LOAD
+oaParasiticNetwork name=childPN0 ... isLoaded=t ....

However, the “childPN1” partition has no data to expand, but instead has LOAD sentinel at the end of its attribute list (the isLoaded attribute is not displaying because it is false and the .si2oadoptions file has dofalseBools=f). This ParasiticNetwork is unloaded because the pnChild1−>unload() statement in the code was just executed prior to the call to oad().

Click in the LOAD sentinel and click the OK button on the confirmation. This will cause loading of that ParasiticNetwork partition and its display in a separate browser window.

Open the ParasiticNetwork in the new window, and its partitions. Notice that the only the parent ParasiticNetwork was loaded: its two child partitions remain unloaded, but also can be dynamically loaded by clicking their LOAD sentinels. 

-oaParasiticNetwork name=childPN1...
-partitions
 oaParasiticNetwork name=childPN1b...parents=childPN1|pnRoot...pn=LOAD
 oaParasiticNetwork name=childPN1a...parents=childPN1|pnRoot...pn=LOAD

Click the RETURN TO CONSOLE button, kill the browser windows. Repeat the steps 1 and 2, above. The childPN1 partition is once again unloaded, since OAD automatically unloads any Networks dynamically loaded in this fashion once a return to to the console is performed, leaving the RTM in its original state.

Retrieved from "http://www.si2.org/openeda.si2.org/oacwiki/index.php/Si2oaD/Quick_Start"
Personal tools