CoralEDA standard: crl001: schematics-pcb attributes

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


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 an 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:

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).


Copyright (C) 2019 Tibor 'Igor2' Palinkas.

The documentation is licensed under the Creative Commons "CC BY" license ( deed | legal code ).

Attribution: please use a reference to the project page (

Note: the license of this document does not affect the license of 3rd party code written using the information published in this document. In other words: your implementation is not affected by the above license in any way, only copies of these files are affected.

To keep these standards help interoperability: