The Batch Check button in the DRC Menu provides the DRC Run Control panel. This panel allows initiation of a batch DRC job, running either in the foreground or background. By ``batch'', it is meant that the job is not intended to be interactive. Such jobs may take a long time to run.
The panel has two pages, tabbed Run and Jobs. The Run page is generally of most interest and is the default page.
The top two entries in the Run page allow a Cell Hierarchy Digest (CHD) to specify the source cells for the DRC run. A CHD is a small database of cell offsets into a large layout file, which allows access to the content of the file without reading it into Xic. With limited memory, this allows huge files to be accessed, that would otherwise fail to load due to memory limitation. The first line contains a text entry area into which the user enters the CHD name. This will be ignored unless the Use button, to the left of the text entry, is pressed. The second line is optional, and may contain the name of a cell referenced by the CHD. This will be taken as the top-level cell in design rule checking. If no entry is given, the default top-level cell of the CHD is used.
These entry areas mirror the values of the DrcChdName and DrcChdCell variables. The variables are set when the corresponding entry area contains text, unset otherwise. The variables can be set directly, however in any case the Use button must be pressed for the values to have any effect during the DRC run.
In order to gain any memory-saving benefit from using a CHD, a partition grid should generally be used. This is set in the third row of the Run page. When the partition grid is enabled, the area to test is divided into a grid of the specified size. The DRC testing is performed sequentially for each grid area. In the case of CHD input, only the geometry needed to represent the current grid area is in memory, which should be a small fraction of the geometry of the total test area (if the test area is very small, partitioning is not needed).
To set up a partition grid, un-press the button with the None label. This will un-gray the text entry area to the right. This area should be set to the side length in microns of the square grid cell. The size should be small enough so that the geometry needed to represent the area will easily fit in memory, but not so small that the overhead inherent in the gridding increases run time appreciably. The best value is very dependent on the technology, and the user should experiment.
The partition setting entry and button control, and are controlled by, the DrcPartitionSize variable. When this variable is set to a number, that number is taken as the partition grid spacing. The partition size can be set and the use of partitioning enabled by setting this variable directly.
The partition grid also applies when the current cell is the target of the design rule checking. It is not clear at present that the partition grid provides any advantage in this case. Some operations may be performed faster when gridded as opposed to processing the entire layout, due to scaling properties. The use of the partition grid provides something for the user to experiment with.
By default, a DRC test run will test the entire area of the target cell (either the current cell, or the cell implied from the CHD). The group of controls below the Partition grid size entries allows the testing area to be set to an arbitrary rectangular window. Of course, the window coordinates should overlap the cell coordinates, or no testing will be done.
When the Set button is pressed, a command is active where if the user drags, or clicks twice to define the corners of a rectangle, those values will set the numerical entries on the panel. This can be used to visually set the test area to an area of interest in the displayed layout. This works whether or not the window is actually used, i.e., whether or not the numeric coordinate entry areas are grayed.
The window will be ignored unless the Use Window check box is checked. When checked, the numerical coordinate entry areas become un-grayed, and the user can manually enter the window coordinates.
The Flatten check box is un-grayed only when the Use (use CHD) button is pressed. When checked, as geometry is being read into memory with the CHD, it will be flattened into a single cell. Thus, DRC tests will be applied to a flat cell, which can be more efficient than processing a hierarchy. However, there is overhead in flattening, and the flat representation can take much more memory than a hierarchical representation. This should generally be employed only when using a partition grid or small window. The feature is rather experimental and obscure.
Near the bottom of the Run page are large Check and Check in Background buttons. These will launch a DRC run in the foreground or background. The run will observe the other settings in the panel (and in the DRC Parameter Setup panel).
When a job is started in the foreground with the Check button, the button remains pressed until the job completes. If the user un-presses the button, the job will be paused, and can be terminated by the user. The job can also be paused by pressing Ctrl-c when Xic has keyboard focus. Other operations are locked out while DRC is running. Violations are recorded in a file named drcerror.log.cellname which is written in the current directory. Additionally, if not using a CHD, violating objects are marked, and the error region highlighted.
When a foreground job is running, Xic is busy and unusable. When a job is started in the background, however, Xic is available for other tasks. There can be multiple spawned processes executing concurrently. A pop-up window will appear alerting the user that a job has completed.
Unlike the foreground run, violations are not marked on-screen. The Update Highlighting button can be used to generate the highlighting after a background run completes. If the Show Errors mode is active, and the current cell is the same as that being checked, when a background job terminates, the error display window is popped down and the mode terminates.
The spawned process is set to ignore the SIGHUP signal, so that the process will continue to run if the user's shell is destroyed and/or the user logs out. This is the preferred method by which large, batch DRC jobs can be performed.
This process will create an errors file in the current directory named drcerror.log.cellname.PID where PID is the process id of the spawned process.
Under Windows, this works by executing a batch-mode Xic process in the background. Presently, this doesn't allow background jobs to use a CHD or partitioning.
The Jobs page provides a list of background jobs currently running. Jobs can be selected by clicking on the text. When a job is selected, the Abort job button becomes un-grayed. Pressing this button will halt the selected job. Be aware that there is no confirmation, and it is not possible to restart a job that is halted in this manner. The spawned process can also be stopped or killed using the job control functionality of the user's shell.