[_CD6_]<autolayout>5.2>Phoenix1>PhoenixDoc.tioga!4

--File: PhoenixDoc.tioga

Last Edited by: CSChow, February 2, 1985 8:23:29 am PST

Placement and Floor-Planning Using Phoenix

Chee-Seng Chow (February 2, 1985)

Filed on: /Indigo/AutoLayout/5.2/Phoenix1/PhoenixDoc.tioga

Abstract: Phoenix is an Interactive Hierarchical Topological Floor-planning Placer. It is intended to be the work-engine for automatic custom IC layout system. It can be used to do both top-down and bottom-up placement. This document introduces Phoenix and shows some sample placement and floor-planning programs written on top of Phoenix.

XEROX Xerox Corporation
Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, California 94304

Starting Phoenix

Follow these steps:

1. Bringover [Indigo]<Autolayout>5.2>top>Phoenix1.df

2. Start-up by typing to the command tool "@FlyPhoenix"

3. You can use Phoenix for interactive editings (using the viewer) or from a program. The former is almost self documentary and the latter information is obtained by studying the examples in [i] PlaceCompsTest.cm, [ii] BinPackTest.cm, and [iii] FloorPlanTest.cm.

4. The font of examples is: TestPhoenix1.df

Overview of Phoenix

1. Inputs: Either 'Rollback' from a <name>.log file or 'GetInput' from a <name>.desc file. (See examples in TestPhoenix1.df.) The former is created by the checkpoint facility in Phoenix. The latter actually contains 4 files: [i] <name>.sch: Rosemary structural, [ii] <name>.dale: ChipNDale input, [iii] <name>.typ: Phoenix's alternative to ChipNDale, and [iv] <name>.init: Phoenix's initialization (eg. initial assignment of instances positions) file.

[ii] xor [iii] can be defaulted (to NIL) or both can be present. By defaults [iii] has higher precedence over [ii] (this can be changed by setting 'ReadCDFirst ← TRUE;' in the input file eg. see 'SloopTest2.desc'.) And note that Phoenix only read in 'type-information' from these two files. Instances are created according to [i], ie. they are created as encountered in Rosemary's structural description. [iv] can be defaulted (to NIL)

2. Output: At present the only means of output is to create a checkpoint which can be Rollback to later. Click 'CheckPoint' and type in the name of the file to be output to. (The convention I use is '.log' for checkpoint files.)

3. What Phoenix does for you:

Currently the system only support hacking and does not allow the designer to do any `real' work because:

(a) No router

(b) No output facilities from Phoenix to ChipNdale. (This is to be supported by the router.)

But you can still do:

(i) 'placement' of the components (net-length as the figure of merit, or perhaps weighted sum of net-length, area, aspect-ratio etc. Study PlaceCompsTest.cm.)

(ii) 'bin-packing' of some dummy blocks (area is the figure of merit. Study BinPackTest.cm.)

(iii) 'floor-planning' (assumes the components are completely soft. Study FloorPlanTest.cm.)

4. The system is forgiving:

The best way to understand the operations provided by Phoenix is to simply 'play' with it. The system is very forgiving, eg. [i] If the input/operation is not valid the system will abort the operation and inform you. [ii] You can abort any operation that request user-input by just hitting <DEL> [iii] Just click `Destroy' if you find the system offensive and start a new one by typing 'IPMainViewer' to the Commander [iv] If an uncaught signal throws you into the debugger window, doing abort (in the debugger) should also abort from the operation that caused it.

Interactive use of Phoenix

Try the following example:

1. Open the 'MainViewer' icon.

2. Click the 'GetInput' button

3. Answer to request: SloopTest2.desc

4. You have now read in the components. To do any topological operations you first need to define channels. Do this by clicking 'DefChs'. Request the system to update geometry by clicking `Geom'

5. Now you are ready to experiment with operations found in [i] EditOps (Edit operations), [ii] OpsExtra (Extra Edit operations), [iii] StkOps (Operation on undo and redo Stack, and solution-collector)

NB: You can learn a lot about the interactive interface of Phoenix simply by tracing from IPMainViewerImpl

Using Phoenix from a program

There are 3 examples to try, but only one is described here, generalize the ideas yourself. To try out the example in BinPackTest.cm:

1. Open the 'MainViewer' icon.

2. Open a viewer on FloorPlanTest.cm

3. Say you want to try out a quick example, TEST#4

4. Use commander to execute from the first line '← IPPlaceBinPackImpl.of1Depth ← 3;' to the last line '← PlaceCompsTest.F2[50];'

5. After ~ 2 to 3 min PlaceCompsTest.F2 returns, now you are ready to view the solutions.

6. Click StkOps, if you had not done so earlier.

7. To look at the best soln for this trial, click 'ToSoln' and type in 1.

8. You can replay the construction sequence by clicks of `Undo1' and `Redo1'

9. After you are through with that solution, fly to any other by clicking 'ToSoln' again.

NB: You 'Force Stopped' by opening up a viewer on the impl and set breakpoints at some vital spot there.

Reference Manual

This section is missing because it is not a big payoff to document these operations as they are best learned by doing. The reader can acquire this missing information by experimenting with Phoenix, tracing through IPMainViewerImpl.mesa, (and IPMVBasicOpsImpl.mesa, IPMVEditOpsImpl.mesa, and IPMVStackOpsImpl.mesa. These are the only files interfacing Phoenix to the user), and asking those who knows.

The reader can also learn how to Phoenix's operations from a program by studying the 3 test-case records in TestPhoenix1.df (a. PlaceCompsTest.cm, b. BinPackTest.cm, and c. FloorPlanTest.cm.)