Device is still used to point to a VHDL model. Some of the other "Attribute" properties are used by other downstream products which Mentor has not re-written and less to the point, some thrid party products.
DxDesigner is used to frontend other layout tools that do not use the iCDB interface. So even thought PADS/DxDesigner is now an iCDB interface we may well see legacy attributes for quite a while.
Well, that's OK if it is consistent (no mixing of "attributes" and "properties" in the same file) but I've seen that sometimes if I change type of the symbol pin it adds pin property "Pin Type" (with new value) and keeps the old attribute "PINTYPE" (with old value). But perhaps it was just a bug.
Maybe Mentor guys could shed some light on if it's intended to finally switch to properties in symbols?
If backward compatibility is an issue (and it actually is) then I guess symbols will stay in text format with "attributes" for a long time (which is fine).
The problem with "PINTYPE" and "Pin Type" appearing in symbol file was that in NSE I edited a standalone symbol, outside of Central Library.
I'd suggest Mentor include a table with "property" to "attribute" mapping in their documentation. For people coming from DxDesigner 2005 and earlier this should not be an issue but for those new to the flow it could.
The symbol editor was designed to create symbols that can be backward compatible, used for several PCB flows such as PADS and Expedition, or consistent only for the current PCB layout flow. This versatility results in the behavior you are noting when editing new and old symbols.
Properties in a symbol, can be either new style EE properties or old netlist style attributes. When a symbol is brought into DxDesigner for EE, the old netlist attributes are mapped to the new EE flow properties by the map.cfg file. (mapnl.cfg is used for the netlist flows, which are generally the same as Dx2005 properties)
map.cfg maps the "DEVICE" symbol attribute to the EE Flow "Part Number" and "REFDES" to "Ref Designator". This operation now occurs in reverse when the symbol is saved from NSE to save the symbol in the most compatible format.
Properties are also controlled by the assigned centlib.prp file or netlist.prp properties definition file. This allows for the simple dropdown property selection and reduces typos in the Property window pane or the Symbol Editor.
The Precision drop down in the Symbol Editor changes the version number in the symbol file header, and changes the unit of measurement in the symbol file to a much higher precision. Precision does not add a property to the symbol.
Properties assigned by DxDatabook are controlled by the dxdatabook .dbc configuration file and are not adjusted by map.cfg or the assigned .prp file. If the properties added by DxDatabook are to be edited by the user, they need to be added to appropriate .prp file.
Properties assigned by scripting are not adjusted by map.cfg or the assigned .prp file. If the properties added by scripting are to be edited by the user, they need to be added to appropriate .prp file.
In summary, although I am not aware of a published "TABLE"; you can see the property mapping (and change it for your application) by viewing the map.cfg file. This file is located in the SDD_HOME\standard directory. As shipped, the properties are saved in the most compatible format for the combination of flows supported. Opening NSE in different flows or standalone may result in differences in the properties presented and saved in a symbol based on the different files used to determine how a symbol should be created. Note that in we tune the .prp files and map.cfg file on many releases and we recommend that you compare the new and old version when upgrading.
Many thanks for an extensive answer, Gary!
Indeed map.cfg is what I'm talking about - a one-to-one relation between "attributes" and "properties". So I guess my Python scripts for ASCII symbol parsing will not get outdated in the foreseeable future