sch-rnd-aux knowledge pool

 

How get custom attributes exported

attr_export_name by Tibor 'Igor2' Palinkas on 2023-07-04	Tags: howto, attribute, export, whitelist, pcb, spice, target_pcb, target_spice, tedax
node source

 

Abstract: n/a

  Some of the abstract attributes are exported, depending on the export file format. There are two types of attribute exporting:

• when a hardwired field in the file format is deduced from an attribute value; this is done by the export_* plugin. For example the tEDAx netlist format has a dedicated footprint field and export_tedax generates the value of that fields by looking at abstract component attributes
• user selected extra attributes that are not hardwired fields of the outpout file format. This happens when the file format allows exporting arbitrary key=value pairs. The target_* plugin marks some of the abstract attributes setting their export names and the export_* plugin exports them using those export names. For example the target_pcb plugin marks attribute pcb:foo to be exported as foo and the tEDAx netlist format allows adding comptag lines to components so export_tedax will export the attribute as comptag called foo .

This document describes how to use the second mechanism.

Following the CoralEDA recommendations , the standard mechanism implemented by most target_* plugins offer 4 ways to control the export name of attributes, as documented in the user manual.

The recommended way is to use whitelist. For example suppose a project has a custom attribute called foobar and that should always be exported in the PCB workflow. This means the target plugin is target_pcb, and that plugin has an attr_export/whitelist config node. Get a project file saved (e.g. set something on the project role in the preferences dialog), then add the following subtree within the li:sch-rnd-conf-v1 block of the project file (project.lht), after the overwrite {} block:

ha:append {
	ha:plugins {
		ha:target_pcb {
			ha:attr_export {
				li:whitelist={foobar}
			}
		}
	}
}

This will append foobar to the existing whitelist coming from the stock config. Set the attribute "foobar" to "something" on one of the symbols (e.g. R5) then do a tedax export. It should contain the following line:

comptag R5 foobar something

After importing this tEDAx file in pcb-rnd, or importing the schematics in pcb-rnd, the subcircuit R5 will also have the attribute foobar=something.

The usual lihata syntax for building the list is:

li:whitelist={foobar;baz;blobb}

If the export name is not specified the attribute is exported using its original name. To make a rename for the export, specify the export name with an arrow:

li:whitelist={foobar->my_fb;baz;blobb}

This will export attribute foobar as my_fb, so the comptag line in the tEDAx netlist would be:

comptag R5 my_fb something

Note: do not use whitespace around the arrow.

Different views (e.g. pcb, spice_raw, etc., selectable top right in the main window) will use different target plugins which in turn will have different attribute export whitelisting config.

The advantage of using whitelists is that it makes it easy to create generic attributes that then can be "routed" in different target_* plugin configurations. For example if you have an unusual attribute for humidity limit, you can introduce a new symbol attribute like humidity=80 and set up your project file to export it under whatever attribute name in the pcb workflow, and under some other attribute name in the spice workflow^1. The disadvantage is the need for the extra configuration.

Note: the best place for such configuration is the project file. It could go anywhere, but the sheet file is too narrow (you typically want this to work the same for all sheets in a multisheet project). The user config ("I need these exported in all my projects anyway") looks like a good idea first, but if you ever need to share or distribute your project, it will break, because the user config is not distributed with projects. The configuration distributed with projects is the project file, that's why project.lht is the best place for this.

An alternative approach is to use the target plugin's flow_prefix. In case of target_pcb, the default config has "pcb", so any attribute with a key prefixed with "pcb:" will get exported without whitelisting. For example add attribute "pcb:foobar" with value "something" to a component while using the pcb view, export to tEDAx and the attribute will show up there in a comptag under the name foobar. The advantage is that no configuration is needed. The disadvantage is that it is not possible to do renames and if you need the same attribute exported in multiple different targets, you will need to have multiple copies of that attribute. With the above humidity example, doing that using flow prefixes you'd need to have both pcb:humidity=80 and spice:humidity=80 to get it exported in both workflows, and you would need to manually keep them in sync.

---

footnotes:

• 1. target_spice doesn't really export custom attributes because the spice file format doesn't have support for that; this example assumes using a more modern file format and a simulator that can process this info. So the example is rather hypotethical.