Cell arrays and step-and-repeat: rows, columns, pitch, and AREF

You need sixteen copies of the same small shape, in four rows and four columns, with an even step from each one to its neighbor.

Draw the shape once. That drawing is a cell. The grid of placements is an array: a regular field of instances of that one cell, not sixteen separate drawings. People also call the operation step and repeat, because the file stores the step across and the step down, and it stores a count of repeats instead of a pile of outlines. A step of 1.9 micrometers on a 2.0 micrometer pitch still looks seated in the first column, and by the fourth column the contact has walked 0.3 micrometers off the strap. One array record carries only one turn, so stamps that must face another way are their own instances on the same pitch. The picture at the top of this page is a 4 by 4 field of one small bit, with some stamps rotated so the bar does not point the same way in every position.

The bit, opened once

The second picture is that bit alone, large enough to read, with the grid put away.

Open this drawing and you are looking at the only outline those stamps share. The bar is the shape whose direction shows rotation. The contact is the shape that has to land on a strap. There is one of each. If this drawing is wrong, every stamp that still points at it is wrong in the same way. If this drawing is right, you do not redraw it at the other fifteen sites.

An instance is one stamp: which cell, where it sits, and how it is turned. An array is a regular grid of those stamps. In a stream file the grid is often one record, an array reference. The record names the child, the corner where the grid starts, the number of columns, the number of rows, and the step from one column to the next and from one row to the next. Older file notes abbreviate that record AREF. The name means a reference to the cell, repeated as an array, not a pile of copied polygons.

A single array reference carries one orientation for every stamp in its grid. The top picture shows some stamps rotated, which one array reference will not do, because one record has one turn. Those rotated bits are still the same child. They sit as their own instances on the same pitch, beside an array reference that holds the upright ones, or the whole 4 by 4 is ordinary instances snapped to a regular step. The screen can look like one array either way. Open the properties on a stamp before you assume one record owns all sixteen.

Step, count, and the last column

Pick a step you can say out loud. Columns on a 2.0 micrometer pitch, rows on a 2.0 micrometer pitch, four by four. The file stores the pitch and the counts. It does not store sixteen outlines. Change the pitch to 2.1 micrometers and the whole grid loosens, including the stamps you were not looking at. That is the point of step and repeat, and it is also how a one-digit typo walks across the chip. When the pitch and the counts should be inputs rather than fixed values, a parameterized square-array cell takes them as knobs and draws a new grid for each set.

The last column is where a bad step shows. Suppose each bit must land its contact on a strap drawn at 2.0 micrometer centers. A step of 1.9 micrometers is only a tenth short, and the first column still looks seated. By the fourth column the contact has walked 0.3 micrometers off the strap. The array is still a perfect grid. It is perfectly misplaced. Measure the step, then measure from the first origin to the last, and do not trust the first neighbor alone.

Rotation belongs in the same check. If three bits must turn to meet a folded strap and thirteen must stay upright, do not put all sixteen in one array reference and hope a mixed turn will stick. One turn applies to that whole record. Place the turned bits as instances. Keep the regular ones in the array. Editing the child still updates both, as long as both still reference the child. Flattening the turned ones so you can rotate their polygons is a different choice, and those flattened bits will miss the next edit to the child.

When one bit in the grid is not one bit

The failure is editing the child to fix a single site. The bit in the corner overlaps a neighbor after a routing change. You open what looks like that bit, move the bar, and all sixteen bars move. Fifteen sites that were healthy now overlap their neighbors or fall off their straps. You wanted one repair. The array gave you sixteen, because there was only one drawing.

The matching failure is exploding the array so you can patch one bit, then forgetting you did. After the explode you have raw polygons. A later correction to the contact in the child updates any stamp that is still an instance and leaves the exploded bit behind. On a memory, one stale bit is a dead row. Keep the array record until a stamp truly must differ. When it must, flatten that stamp only, and leave the placement name honest so the next person can find the exception.

Select one stamp in the top picture and read the property line. It should name the bit cell and show a row and column, or a position on the pitch. It should not list a private set of polygons. Then open the second picture and confirm you are editing the only outline those stamps share. If the bar on a rotated stamp is a different length from the bar in the child, that stamp has already left the array. Put it back, or accept it as a deliberate exception, before the grid ships.