The CommandTool command BuildIcPack take two arguments. The first is the name of a device which has been previously saved using a call to PWCore.Store. The three files: DeviceNm.core, DeviceNmLayout.dale andDeviceNmShell.dale are therefore expected to be present. The second argument is the name of a package into which the device is to be bonded. Various standard unbonded and prebonded packages are exported by IcPackdf. Prebonded packages may be used for devices which use a standard pad ring. Two files are created by BuildIcPack. The first, named DeviceIcPackCache.core is just a copy of the public wire of the device with some extra decorations representing the positions of the devices bonding pads. This file is then used to create a chipndale object which is a scale model of the device. In this model, pads of public wires with Vdd in their names are shown in red, those with Gnd in their names are shown in green and others are shown in blue. This model is inserted in a copy of the package and saved as the file DeviceIcPack.dale. After the BuildIcPack command has completed, a viewer on this ChipNDale file is opened. If the package used was not prebonded, the bonding wires may be included at this time (using Middle B to draw the wires).

C switch - Use Cache: If for some reason, you would like to rerun the BuildIcPack command and the Device's public wire, pad locations and assignments have not changed, then the -c switch can be used to greatly speed up the reconstruction. This switch causes the DeviceIcPackCache.core file to be used instead of re-extracting the device layout.

O switch - Keep Outside Pins: On devices with two rows of pins, the outside row is typically Vdd or Gnd and for clarity may be left out of the diagram. The -o switch may be used to cause the pins to be included. These outside pins will be put on odd grid 1 locations to prevent clashes with the signal pins which are constrained to grid 2 locations.

Recommendation: Draw schematics in schematics mode: grid 2

Since BuildIcPack provokes an extraction of the layout it can take a couple of hours to run depending on the size of the chip. Since it probably only needs to be run once, this should not be a problem. If this is a problem, calling the procedure IcPack.BuildIcPack directly can be used to speed up the process. This needs to be done at the point in your count-down where you have extracted the layout for some other reason (for running the connection check, for instance) Interpreting the procedure IcPack.BuildIcPack giving the source celltype as its argument has the same effect as the CommandTool command except that the source celltype is also decorated with the pad locations and these decorations will survive CoreIO. (See also MarkBondingPads and FlushBondingPads)