Migrating Design Data Between EDA Platforms

Changing an EDA platform is a project rather than an installation. The copper transfers more easily than anything else; what costs the time is the data around the copper, the footprint attributes, the net names, the rules and the libraries that accumulated over years of use on the old tool.

This article describes what survives a conversion between platforms, what has to be rebuilt, and how to run the change so that the first board produced on the new tool is a working one.

Why Teams Change Platforms

The reasons are rarely technical in the narrow sense. A company may be required to use the same tool as a customer, may need a capability the old tool does not have, may find that support for an old version has ended, or may simply be following the engineers who already know the new environment.

Whatever the reason, the cost is concentrated in the existing body of design data. A new project can be started on a new platform with no conversion at all; it is the library and the legacy designs that make a migration expensive, and they are the part that is easiest to underestimate.

What Actually Transfers

Geometry transfers well. Layer data, pad shapes, track widths and board outlines move between tools with little loss, because they describe shapes rather than intent. What does not transfer is everything that depends on how the original tool stored information.

Component attributes are the first casualty. A conversion will often produce parts whose footprint attribute is empty, because the original tool kept the association in a place the translator did not read. Rules, differential pair definitions, classes and constraint sets are the second: they are expressed differently in every tool, and most conversions drop them entirely.

Converting the Schematic

A schematic translation is usually the point at which the original tool exports a netlist and the new tool imports it. Hidden pins and pin numbers are frequently lost in that step, because they are not drawn on the sheet, and they have to be restored in the library before the design will compile cleanly.

Footprint attributes are the largest manual task. Every component has to be given the footprint name that the new platform expects, and the name has to match a part that exists in the new library. Where the old tool allowed a footprint name that the new one does not, the part is renamed as part of the work rather than patched afterwards.

Hierarchical Designs and Bus Naming

A flat design converts with fewer surprises than a hierarchical one. Where the original used sheet symbols and repeated blocks, the buses that connect the sheets have to be named explicitly in the new environment, because the new tool may not infer the connection that the old one did.

Parts that are split across several units are another case. Multiple-part components have reference designators that have to be reassigned consistently, and a conversion that changes the numbering without updating every instance leaves a design that looks correct and connects the wrong pins. Checking these is part of the workflow that runs from rules to DRC and it belongs before the layout starts.

Footprint Library Migration

The library is the asset that took the longest to build. A shop that has used one platform for a decade has a collection of footprints that have been proven in production, and losing them means re-validating parts that were never in doubt.

There is a route that preserves most of them. The old footprints are placed on an empty board in the original tool, that board is exported in a neutral ASCII format, and a conversion utility is used to import it into the new environment as a library rather than as a board. The result still needs a review to confirm pad sizes and origins, but the geometry survives and the naming can be normalised in one pass. The quality of a board depends on libraries of this kind, so the effort is not administrative.

Net Names, Rules and Constraints

Net names carry meaning that the tool does not generate itself. A net called a supply rail, a clock or a differential pair is treated by rules that reference its name, so a conversion that renames nets silently disables the rules that were written around them.

The same applies to classes. Differential pairs, matched groups and impedance-controlled nets are defined as classes in the new tool, and each class has to be rebuilt and attached to the nets it belongs to. Reading the rules from the old tool and rewriting them in the new one is a deliberate exercise, and it is the step most often skipped under schedule pressure.

Verifying the Converted Design

A converted design should be verified against the original rather than trusted. The schematic is recompiled with all checks enabled, the netlist is compared with the one exported from the old tool, and the layout is checked for the nets that changed name or disappeared.

A design rule check on the converted layout is the next step, and it should be run with the new rule set rather than the old one, because the rules are part of what was converted. Where the conversion produced a difference that cannot be explained, the original file is the reference. The rules that keep a layout efficient are easier to re-apply to a verified design than to repair one that was migrated without checking.

Planning the Cut-Over

Migrations work best when they are run alongside production rather than instead of it. A pilot project is converted first, on a schedule that allows the remaining work to be finished in the old tool if the conversion needs more time than expected.

The last part of the plan is documentation. Whoever maintains the library next needs to know how it was converted, which parts were renamed and which rules were rewritten. That record also satisfies the design rules that the fabricator expects to see stated rather than assumed.

Keeping the Old Environment Available

The old installation should stay usable for the duration of the migration and for a period afterwards. Legacy designs will be opened for reference, questions will arise about how a rule was written, and a conversion that has gone wrong is easier to diagnose when the original can still be loaded.

Licences are usually the constraint, because a company that has moved to a new platform does not keep the old one running indefinitely. The practical compromise is to export the reference material that matters, the netlists, the libraries and the rule documentation, before the last seat is given up.

FAQ

Can a full design be converted without manual work? No. Geometry converts automatically, but attributes, rules and classes generally do not. The manual work is what makes the converted design equivalent to the original.

Is it better to convert old designs or to re-draw them? Convert the ones that will be maintained, and leave the rest in the archive. A design that is never touched again does not need to be migrated.

What is the most common cause of a failed migration? Footprint attributes that were lost in the schematic conversion, which then appear as parts that cannot be placed once the layout begins.