2019 02 17

Hierarchical DRC functions

Many DRC features are now available as hierarchical operations. To enable hierarchical operations, use the "deep" statement:

report("deep 2")

# enable deep (hierarchical) operations
deep

poly = input(3)

spc = poly.space(0.5)
spc.output("poly space >0.5")

"deep" is not compatible with tiling. "tiles" will disable "deep" and vice versa. To disable deep mode, use "flat".

Deep processing is a layer property. After "deep" has been specified, layers derived with "input" are declared to be deep - i.e. hierarchical operations are enabled on them. Operations on deep layers will usually render other deep layers. This is also true for edge and edge pair layers. For example, the "space" operation above will render a hierarchical edge pair layer.

In binary operations such as boolean operations, the operation is performed hierarchically, if both involved layers are deep. A layer can be explicitly converted to a flat layer using "flatten".

To check whether a layer is deep, use "is_deep?".

report("deep 2")

# enable deep (hierarchical) operations
deep

poly = input(3)
puts poly.is_deep?   # -> true
poly.flatten
puts poly.is_deep?   # -> false

Most operations are hierarchy enabled, with a few exceptions. The following operations do not support hierarchical mode:

• "corners"
• "extents"
• "grid_check" with anisotropic grid (gx != gy)
• "snap" and "snapped" with anisotropic grid (gx != gy)

Some operations may create cell variants. This means that when writing the layout back, new versions of cells will appear. Such versions need to be created for example in the "snap" feature if the cell's instances are not all on-grid. Most functions need to create variants only when the same cell is instantiated with different magnification factors.

When sending the output of hierarchical operations to a report database, the markers will be listed under the cell name they appear. A sample cell instance is provided within the marker database to allow visualizing the marker in at least one context.

Limitations

Functions which require merged polygons utilize the net clustering algorithm to form the merged polygons. All connected shapes are collected and merged into a bigger polygon. This happens in the lowest possible level on the hierarchy where the shape clusters are complete. In some cases - when the shapes from big coherent regions - this may happen on the top cell level and the resulting polygon will be very big. This will lead to poor performance.

The XOR function is implemented as two NOT functions because of limitation of the underlying hierarchical processor. Hence XOR executes slower than AND or NOT. If both inputs of the XOR function originate from different layouts, hierarchy mapping has to happen to combine both contributions. This will consume even more time.

Next Steps

The current implementation needs some polishing. The remaining functions need to be ported and tests for DRC scripts need to be written.