#

## property

Attach a "property" (string key and value pair) to the edit cell

### Usage:

> property [key [value]]

> > where key and value are any text strings.

### Summary:

> The property command implements a general-purpose method of attaching information to a cell definition. Except for a few properties known to the lef, extract, and gds commands (q.v.), properties have no inherent meaning to magic but may be used with other programs or scripts to add additional information about a cell definition.

> With no arguments, all properties of the current edit cell are listed. With only the key argument, the value associated with the key is returned. With both arguments, the string value is associated with the string key as a property of the cell. If key is an existing key, then its original value will be overwritten.

> Property names reserved by and used by magic:
> GDS_FILE
>   The value is the name of a GDS file which contains the mask data for the cell. The cell is then effectively an abstract view, because its contents are in the GDS file and do not necessarily match what is displayed (although they might).
> GDS_START
>   If a GDS_FILE is defined, then this value indicates the byte position of the start of mask data for this cell definition in the file. If set to value 0, then the file will be searched for the data bounds.
> GDS_END
>   If a GDS_FILE is defined, then this value indicates the byte position of the end of mask data for this cell definition in the file. If GDS_START is set to 0, then this property may be omitted.
> LEFview
>   If set to TRUE, this cell is an abstract view such as that obtained from a LEF macro, and should not be used for extraction or for writing mask data (unless GDS_FILE is defined).
> LEFproperties
>   If the file was read from a LEF macro, then this property corresponds to the LEF PROPERTY block values. All values from the block are contatenated into the single property string.
> LEFsymmetry
>   If the file was read from a LEF macro, then this property corresponds to the macro's SYMMETRY value.
> LEFclass
>   If the file was read from a LEF macro, then this property corresponds to the macro's CLASS value.
> LEFsite
>   If the file was read from a LEF macro, then this property corresponds to the macro's SITE value.
> CIFhier
>   If defined, then this cell will be written to CIF or GDS output with hierachical processing regardless of the settings of the command options "cif *hier write disable" and "cif *array write disable". That allows those commands to be used to avoid time-consuming and unnecessary hierarchical processing of a top-level chip assembly with mostly correct-by-design components (such as a digital standard cell layout) while preserving necessary hierarchical processing on blocks (such as analog circuits) that need them.
> FIXED_BBOX
>   This property value is a space-separated list of four integer values corresponding to the abutment box of the cell, in magic's internal units. The abutment box is automatically read from LEF files, but may be defined for any file and can be used for placement alignment.
> OBS_BBOX
>   This property value is a space-sparated list of four integer values corresponding to a bounding box to be used when generating a LEF file abstract view of a cell. The area inside the bounding box will be entirely covered in obstruction layers (unless cut-outs are required to accommodate pins). Any set-back applied by the "lef write -hide <value>" option will be applied to this obstruction box.
> device
>   This property declares that the cell is a device or contains a single device that is not a known extractable device defined in the technology file. In the first case, the device to be extracted is a subcircuit and the name of the device is the same as the name of the cell. In this case, the property value should begin with "primitive". This may be followed by any parameters associated with the device that need to be output in the netlist; e.g., "primitive nf=4. When the cell is recast as a primitive device, it is necessary for the port order in the cell to match the port order of the device as it must appear in the output netlist. In the second case, the device to be extracted is either a low-level component type (not a subcircuit), or is a subcircuit with a different name than the cell. In that case, the value string should be the text of the line as it should appear in a "device" line in the output `.ext` file when the cell is extracted. That includes the names of all ports and any parameters to be output. As the output device is defined inside the subcircuit of the cell in which it is defined, the ports may be reordered between the subcircuit and the instantiation of the device. The use of either form of the device property precludes the generation of parasitics associated with the cell. All parasitics are assumed to be included in the device model.
> parameter
>   If, when an instance of the cell's subcircuit is generated in the output netlist, the instance should be passed one or more parameters, then those parameter key=value pairs (as a single, space-separated string) should be defined as the value to the parameter property.
> MASKHINTS_type
>   The value is a string of consecutive sets of four integer values, each set representing the bounding box of a rectangle defining the area of CIF type type, in magic's internal units. This indicates that magic will always generate mask layer type in the specified rectangle area when writing GDS or CIF output. type may be a templayer, such that type could be defined as the absence of a mask layer, for example.

### Implementation Notes:

> property is implemented as a built-in command in magic. The property structure itself is implemented as a hash table in the cell definition structure.

Return to command index

Last updated: March 7, 2020 at 1:06pm