Schematic Conversion Between Design Tools: What Breaks

Designs change hands. A product line is acquired, a customer supplies an older board for a derivative, an engineering team consolidates onto one tool, or a design is taken over from an external developer who used something else. In each case a schematic has to move between tools, and the move is treated as a small housekeeping task until the reversed connector or the missing net appears on the first prototype.

Two Ways to Move a Design

The first route is a direct schematic conversion by the receiving tool, which reads the source database and rebuilds it. The advantage is that the graphical information usually survives, so the schematic still looks like a schematic. The disadvantage is that the translation is a best effort: it maps what it recognises and reports what it does not, and the report is often long enough that nobody reads all of it.

The second route is a neutral exchange format. The source design exports its connectivity and its component list into a text structure, and the destination imports that. The advantage is that the connectivity transfers exactly, because connectivity is what the format carries. The disadvantage is that the drawing does not come with it: the result is a database with the right nets and the right parts and no readable schematic, which is fine for a layout and useless for maintenance.

The practical choice is often both: a direct conversion for the documentation, and a netlist comparison to prove that the converted version is electrically identical to the original.

What Transfers and What Does Not

Connectivity transfers. If two pins are on the same net in the source, they will be on the same net after the conversion, provided the net survived at all.

Designators transfer by name. Every part keeps its reference, which is what makes the conversion usable, because the same designator now appears in the layout, the bill of materials and the assembly data.

Symbol graphics transfer partially. A symbol whose shape is drawn from a library entry will come across with whatever geometry the translator can express, which is often close but rarely identical, and any custom drawing conventions are lost.

The symbol library does not transfer. The destination tool has its own libraries, and the converted design has to be re-linked to parts that exist there. This is the largest single piece of work in most conversions, and it is the source of most of the errors, because the mapping from the old library entry to the new one is made by a person under time pressure.

Footprint names transfer as text, which is to say they arrive as strings that may refer to nothing. Footprint mapping is the second half of the library work: every component has to be pointed at a footprint that exists in the new tool and that matches the physical part.

The Traps Worth Knowing

Several failures appear repeatedly in converted designs, and each has a cheap check.

The first is the hidden power pin. Many older symbols treat the supply pins of a logic device as implicit connections rather than as drawn pins, so the net exists only as a property of the symbol. A tool that models this differently will produce a design where the supply pins are either unconnected or connected to a net with a different name, and the error is invisible in the drawing. Comparing the net list before and after the conversion is what finds it.

The second is pin naming. Some tools identify a pin by its number and others by its name, and a symbol can carry both. Where a part has pins whose names differ from their numbers, a conversion that mixes the two produces a design with the right number of connections on the wrong pins. This is the classic cause of a prototype that fails immediately and works perfectly after a firmware change that nobody wanted to make.

The third is the multi-part component. A package that contains two amplifiers, four gates or several supply sections is represented as several symbols that share one designator. If the conversion flattens them into separate components, the pins are still connected but the bill of materials counts the part more than once, and the assembly data places more parts than the board has positions.

The fourth is the no-connect flag. A pin that was deliberately marked as unused becomes a floating pin if the marking is lost, and a floating input on a CMOS device may draw current, oscillate, or simply behave unpredictably. Restoring the flags is a manual pass, and it should be part of the acceptance of the conversion rather than a later clean-up.

The fifth is the global net. Older designs sometimes used net names to connect circuits that were never drawn together, so the connectivity exists only in the name. A translator that renames duplicated nets to make them unique breaks those connections silently.

Proving the Conversion

The netlist comparison is the acceptance test, and it is worth doing properly rather than by spot checks.

Export the netlist from the source design and from the converted design, reduce both to a canonical form of component, pin and net name, and compare them as sets. What the comparison should prove is that every connection in the original exists in the conversion, and that no connection exists in the conversion that was not in the original. Differences are then classified: a renamed net is acceptable if the mapping is understood, a missing connection is not, and an added connection is a short waiting to be found.

Two supporting counts are worth printing alongside the comparison. The number of components should match the original, and the number of pins that have a connection should match as well. A conversion that loses a net usually loses it in a way that changes the pin count.

The rest of the acceptance is a design rule check on the converted database and a review of the bill of materials, because the conversion is also the moment when a component list can silently change. Where a part in the original library no longer exists, the substitution belongs in a procurement record rather than in the design, and our component procurement process handles approved alternatives that way so the design intent stays documented.

When the Converted Design Goes to Production

A converted design is a new database, and the fabrication and assembly data generated from it is new data. Even when the electrical result is identical, the artwork may differ, because the conversion can change pad geometry, silkscreen positions or the copper on an unused area. On a dense board that difference is enough to change the yield.

The safe sequence is to treat the conversion as a design revision. Check the converted layout against the fabrication data of the released version, confirm the differences are understood, and release it with its own revision identity. Our design and layout team supports that comparison, and the released package and the conversion record are kept together in our quality management flow, which is what makes a legacy board reproducible five years later.

FAQ

Can a converted design be trusted without checking? No. The connectivity usually survives, but the library mapping, the no-connect flags and the footprint assignments are all made by hand and each of them can change the electrical result.

Why does a converted design show the wrong part count? Usually because a multi-part component was flattened into separate symbols, or because a duplicated designator was renamed during the import.

What is the single check that finds the most errors? A canonical netlist comparison between the original and the converted design, done as a set comparison rather than by eye.