CoralEDA standard: crl001: schematics-pcb attributes

Status:	active
Type:	strongly recommended
Affects:	schematics editors (partly PCB editors)

Attributes

Attributes, sometimes called tags, properties, fields, are key-value pairs. Key is sometimes a free form text string entered by the user or selected from a list, or for some attributes it is a hardwired named field with dedicated input widget in the software. Value is a free form text string, typically entered by the user but sometimes selected from lists or filled in by the software. Nevertheless, for this document, and for communication between software, every such data is just a key-value attribute.

Recommendations when an attribute is used to communicate with other EDA software: keys should contain only alphanumeric characters, dashes, dots, colons and underscores. Value should contain 7 bit ASCII characters not lower than character code 32. Within a list of attributes for a given object (e.g. component or net), keys are unique.

In this document attributes are written as key=value. The actual syntax in software-to-software communication may be different, and is always specified by the format used in the communication.

Schematics attributes

It is assumed that the schematics editor can attach attributes to at least symbols (components, parts) and networks.

PCB attributes

It is assumed that the PCB editor can attach attributes to at least footprints (components, parts, subcircuits) and networks.

Attribute flow: forward annotation

It is strongly recommended that symbol and network attributes from the schematics are filtered and transferred to the PCB editor. The interpretation of the attributes are implementation specific. For interoperability, it is recommended to follow these principles on the schematics editor side:

• 1. Software or format scope prefix: if an attribute starts with the name of the target PCB software or netlist format name, followed by a colon: truncate the software/format prefix with the colon and emit the attribute. For example a symbol attribute pcb-rnd:footprint=sot23 should always export attribute footprint=sot23, without filtering for keys or values. A typical format prefix would be "tedax:".
• 2. Domain scope prefix: if an attribute starts with "pcb:", the "pcb:" prefix should be truncated and the resulting attribute exported if the result does not override attributes exported above. For example pcb:footprint=sot-23 should export attribute footprint=sot-23, without filtering for keys or values, unless footprint was already exported because of a software or format scope attribute.
• 3. Whitelist: the schematics editor should have a list (preferably user configured, optionally different per netlist format or target software) of attributes to export. For example "footprint" as a symbol attribute should be normally exported. If a symbol has a footprint=SOT_23 attribute, it should be exported as footprint=SOT_23, unless a footprint attribute was already exported for this object in the above 2 steps.
• 4. blacklist: the truncated key attribute should be matched against an export format specific list of no-export attributes. If the key is found on the list, the attribute should not be exported. For example if the export format has a set of hardwired fields and then custom attributes, and there is already a hardwired field for footprint, a redundant footprint attribute should not be exported in the custom attributes section for that object.

Note: if the schematics editor software does not accept colon in the attribute syntax, it can be replaced with another separator.

Attributes expected to export from schematics:

Object type	key	type
component	footprint	strongly recommended
component	value	strongly recommended
network	type	recommended

Attribute flow: back annotation

The user may change any attribute in the PCB editor software and then back annotate the change. If the schematics editor supports back annotation, it should find the best fit (tightest scope) existing attribute for the modification, executing the same logics specified for forward annotation, in the same order.

Back annotation of attribute deletion should remove enough prefixed or unprefixed attributes that a new forward annotation wouldn't export the deleted attribute.

If a new attribute (newly created key) is back annotated, the schematics editor is free to decide which scope prefix it uses (or it can decide not to use a prefix).

Copying