LAB 3-1: sample

This lab provides an easy opportunity to gain familiarity with the build environment that will be used for all labs throughout the course.

LAB 4-1: oadump

This lab builds a simple, OA design data listing tool that some labs will use to validate their results.

LAB 5-1: grafig

This lab builds an OA-to-PostScript translator used to display geometric objects in OA designs. It requires no coding – merely building and verification. The resulting graFig tool will be installed in the bin/ directory and used by the labs that create Figs as a visual debugging aid. For information about setting up the environment for automated rendition of the resulting PostScript on a monitor or printer, refer to the section in the front matter, "Labs Graphics Utility: grafig".

LAB 6-1: basic

This lab takes the simple program framework developed in Exercise 6-3 and adds a couple of easy manipulations of the oaString utility class.

LAB 8-1: namespaces

This lab illustrates some issues involved in the initial interpretation of a string as a Name within the context of a particular NameSpace and in converting that Name from one NameSpace to another.

LAB 9-1: liblist

This lab illustrates the relationships between the logical oaLib object used by an OA application to house its DesignObjects, and its association to the library definition list file mapping information.

LAB 10-1: libcellview

The libcellview.cpp module allows interactive creation of Designs by name and ViewType.

LAB 11-1: inverter

To create a simple leaf cell (Figure 11-13), all that is needed is to define the logical interface it will present to other Designs that instantiate it. This interface consists of the Terms used by the leaf to connect internal Nets to external logic. As explained in 11.4.2 a Net for that internal logic must first be created in order to create the Term.

Figure 11-13: Inverter (Courtesy of Cadence Design Systems, Inc.)

LAB 11-2: netlist

This Lab implements a netlist view of a full adder as a hierarchical Design containing Insts of two half adder Designs, each of which contains Insts of And and Xor leaf Designs.

LAB 11-3: multibit

The multibit Lab implements a netlist for the design represented by Figure 11-23:

• Several Nets/Terms are "differential pairs" (with + and – signal components) modeled as a Bundle of Scalars, or a Bundle of Busses.
• One rectangular block is used to represent the 16-bit wide VectorInst r[0:15]. Each bit's b InstTerm is connected to the BundleNet that+[0:7],that-[0:7], which in turn consists of two BusNets, each 8 bits wide
• Single Net objects are used to represent collections of single-bit Nets, such as the bundleNets "new...", "this...", and "that...", and the busNet n[0:2].
• One Term n[0:2] object is 3-bits wide.
• Single InstTerms are used for the differential InstTerm pairs.
• The pair of red squares joined by an arc represent "patch cords" between two Nets that patch selected bit[s] from one Net to selected bits of the other Net.
• One patches that+[0:7],that-[0:7] to a reordering of the bits, as corresponding differential pairs:
• that+[0],that-[0]
• that+[1],that-[1]
• ... and so on.
• The other patch swaps bits of differential pair new and the Bus of pairs, that+[0],that-[0].

These patch cords are represented as Insts of a Design that has only 3 shapes in it (no nets or terms) and a property that encodes in a string the mapping of bits of one net to the other.

• The thin lines intersecting thicker net lines represent "taps" of one or more bits of the thicker Net. For example:
• The Term n[0:2] is connected to a Net of the same name from which are two taps:
• bits 1,2 connecting to InstTerm in+,in- of Inst i1 (whose Term is the BundleTerm in+,in-)
• bit 0, connecting to InstTerm in+ of Inst i0 (which requires that an explicit Term in+ be created in addition to the BundleTerm in+,in-)
• The 0th differential pair that+[0],that-[0] is tapped from that+[0:7],that-[0:7]
• a and b are separately tapped out of bundleNet a,b
• The BundleNet this+,this- is 16 bits wide, connecting the 8 members of VectorInst i0[0:7] in parallel to the 2-bit-wide InstTerm corresponding to differential pair out+,out- of i1 repeated 8 times.

This lab calls functions from a library in the emhlister/ utility. The dumpUtils.o object linked in should be built automatically by the makefile dependencies.

LAB 12-1: module

This lab "converts" a simplistic Verilog description (Figure 12-10) of a 3-bit adder into a Module hierarchy. It builds on the leaf cells from the "cell library" created in the netlist lab 11-2 adding HalfAdder and FullAdder Module hierarchy levels to produce the Design illustrated in Figure 12-12, 12-14

LAB 12-2: modprop

This lab illustrates propagation of edits from the Module to Block Domains illustrated in Figures 12-15, 12-16, and 12-17.

LAB 13-1: occ

This lab "converts" a simplistic Verilog description (Figure 12-10) of a 3-bit adder into a Module hierarchy. It builds on the leaf cells from the "cell library" created in the netlist lab 11-2 adding HalfAdder and FullAdder Module hierarchy levels to produce the Design illustrated in Figures 12-11 and 12-13.

LAB 13-2: occtraverser

This lab illustrates use of the oaOccTraverser class to simplify traversal of the Occurrence hierarchy.

LAB 13-3: tclsize

This lab uses a Tcl script to swap out leaf cells in a Design. Each leaf cell is an instance of a buffer or flipflop of a particular size, such as BUFX2 or DFFX8. Given an Inst by name, the script upsizes or downsizes it by replacing its master with a Design representing a larger or smaller buffer or flop. For example, assume that an analysis of the Design recommends that the Inst named FLOP_4_25 needs a smaller flop. The Tcl script can be used to replace the current master DFFX4 with DFFX2.

LAB 14-1: ext

The scenario pictured in Figure 14-9 demonstrates the use of application-defined attributes and objects to model simplified Net coupling data.

The current version of OpenAccess already has an extensive parasitics model – Chapter 21 – which should be used for real coupling data in a design. However, this Lab illustrates one way extension objects could have been used to provide an efficient, robust implementation of coupling before the OA parasitics API became available. This same concept could be applied to any kind of data that has not yet been incorporated into the Standard.

Write an OpenAccess program that creates objects of a custom extension class and stores them in the database.

LAB 15-1: text

Using the information discussed about Transforms (15.2) and oaText attributes (15.3.3.1), test cases similar to those represented in Figures 15-13, 15-14, 15-15, 15-16, 15-17, and 15-18, can be generated to provide experience with use of various positioning techniques for Text labels.

LAB 15-2: textlink

This lab implements an in-memory IText interface, excluding ITextInvalidate.

LAB 15-3: bbplugin

This lab experiments with the principles outlined in this Chapter to create a custom bounding box calculator as a PlugIn module (17.8.2).

LAB 15-4: symbol

With the information about Shapes discussed so far it is now possible to create simple, schematic symbols for the cells created in lab 11-2. Simple block outlines and Text labels can be drawn to produce graphic representations that eventually can be placed on schematics that use these cells.

LAB 15-5: pins

Simple rectangle and line Shapes will be used to add representations for the Pins associated with the Terms on the symbol Designs created in lab 15-4.

LAB 15-6: schematic

The schematic symbols created in Lab 15-4 can now be used to create a schematic view of the halfadder and fulladder cells.

LAB 15-7: flat1

The process of converting a folded design to its "flat" equivalent illustrates several of the key issues involved in hierarchical representation. The flat1 lab will begin this process by working on just the Insts, converting the hierarchical Insts from the input design into their flattened counterparts.

Figure 15-30 illustrates the design created by the "sample" lab, 3-1. This lab must have been run successfully prior to execution of flat1. It is this design that will be flattened.

LAB 15-8: rq

A simple RegionQuery is created for Shapes to use as an experimental framework for other RegionQuery investigations by the student.

Figure 15-33 illustrates the Shapes that result in the top Block. The application will move a 20 x 20 DBU window diagonally upward across the grid. The Shapes are deliberately placed to illustrate that contact with any point on the window's edges, corners, or interior will select the Shape, assuming it meets the filterSize criterion.

Figure 15-33: Lab rq Shapes

LAB 15-9: rqeasy

This interactive lab illustrates the results of changing the window, start level, stop level and size filter when performing a region query. The lab uses a very small design with a via, two insts, two distinctive shapes, three levels of hierarchy, and two blockages.

By entering a change such as the window or filter size, then peforming a query, the user can see which Objects are selected and which are not.

Figure 15-34 illustrates the "Design".

Figure 15-34: Lab rqeasy Design

LAB 16-1: observer

A simple, interactive example – with a user explicitly causing events that invoke Observer handlers – is probably the easiest way to begin to understand the potential of tight loop cooperation. This lab provides that opportunity.

LAB 17-1: pcell

This lab experiments with the principles outlined in this Chapter to create a Pcell in-line as part of application code.

LAB 17-2: pcellfile

This lab experiments with the principles outlined in this Chapter to read the SubMaster cached in the pcell lab.

LAB 17-3: pcplugin

This lab experiments with the principles outlined in this Chapter to create a Pcell as a PlugIn module (17.8.2).

LAB 17-4: pccpp

This lab configures a PlugIn module for the oaPcellCPP wrapper for C++ Pcell PlugIns (17.8.3).

LAB 18-1: route

The schematics created in Lab 15-6 can now be used to add wires. Though it is common to use another Shape Object, oaPath, to represent wires in schematics, this lab will use symbolic Routes and related Objects instead.

LAB 20-1: constraint

This lab experiments with the various classes and methods involved in defining Constraints and related objects.

LAB 21-1: detpara

The routes created in Lab 18-1 (Figure 18-27) can now be used to add detailed parasitics to represent the output results of a greatly simplified "extraction tool".

LAB 27-1: mdparies

This lab provides some test data (courtesy of UCLA, Computer Science Department) that can be used for experimentation with the OpenAccess API and translator tools. It consists of LEF and DEF descriptions of a small microprocessor, mdp_aries, that is converted into OA libraries and then re-exported to various formats