Pin and part swapping has long been one of the many techniques that electronics designers exploit to decrease PCB routing complexity and remain competitive. But the accelerated adoption of FPGAs due to their increased affordability and ever improving performance has placed new pressures on traditional PCB design flows.

Yesterday's task of exchanging a few gates within an IC package or the connections to a couple of resistor arrays is quite different from today's task of managing several hundred pin swaps across one or more FPGA devices, and then synchronizing those changes with the FPGA design. As the design progresses through multiple iterations, the task of synchronizing the data and pins across the PCB and FPGA domains has become a full-time job in itself and the blessing of pin swapping has become a curse.

So, designers need to overcome this increasing synchronization complexity so that they can continue to exploit the benefits of programmable hardware.

Through examining traditional design processes and their efficiency at dealing with FPGA-based designs, this paper explores the ways in which board level designers can harness the benefits of FPGAs without being overwhelmed by their complexity. Of particular interest is the management of pin swapping data across schematic, PCB and FPGA design domains.

I'll examine the various synchronization techniques that are typically used by board level designers to synchronize their schematic and PCB design data, and how those techniques need to change to deal with the complexities introduced by increasingly more powerful FPGAs. I'll propose an improved data synchronization model along with some key considerations that need to be kept in mind when purchasing a design tool.

The old and the new: design synchronization the old way
The design of custom board-level products has typically consisted of two primary phases; schematic capture and PCB layout. Schematics are created first as a logical representation of the circuit. They use the language of symbols and circuit topologies to communicate both design intent and the connectivity model. The PCB layout process takes this connectivity model and seeks to create a physical representation of the design that can be manufactured reliably and economically.

One of the challenges of working between the schematic and PCB environments is that whilst the schematic document is responsible for specifying the logical connections between components, it is not until the design is migrated into the PCB layout tool that physical optimization opportunities become apparent. For example, where multiple components exist within a single package such as in a resistor array, the schematic developer may have wired up the resistors indiscriminately but the PCB layout specialist may wish to reorder the connections to improve track placement.

As the design evolves and the connection model is updated, any change made in either the schematic or PCB domain needs to be propagated through to the other domain to ensure project level synchronization. There are two ways that this is typically done. Older design packages (or design packages caught in an old paradigm of design) only support the forward propagation of design information from the schematic to the PCB. In this instance the only reliable way to make changes to PCB connections is to modify the schematic documents and then propagate those changes through. For simple designs this is little more than a small inconvenience but for larger designs, or more complex designs, or for designs requiring the in-built flexibility and advantages of FPGAs, the inconvenience can become large.

The limitations of forward-only data synchronization quickly become apparent when trying to perform pin or part swapping at the PCB level. This is often an iterative process since changes made to one device or set of connections will often reveal, and lead to, further optimization opportunities. If forward propagation is the only means for design synchronization, designers may find themselves going round the 'modify schematic, update PCB' cycle many times over. Each time through the design loop consumes time, which over several iterations can be substantial.

Ideally, the process of improving track routing should be a less arduous task driven from the PCB layout tool. This makes a lot more sense given that it is the layout expert who is directing the changes. But for this to be possible, the design system must support the propagation of design information from the layout tool back to the schematic tool. This can be accomplished through an Engineering Change Order (ECO) process or a 'was/is' file. After performing various updates to the PCB document, an ECO file is created and passed to the schematic tool for incorporation into the schematic sheets. This file is sometimes called a "was/is file" because of the way the updates are ordered within it; i.e. pin 1 was connected to pin 2; pin 1 is now connected to pin 3.

The use of ECO files is an intuitive process but it relies on the user following strict design processes. If more than one ECO file is generated through the life of the project, extreme caution needs to be exercised to ensure it is applied to the schematic in the exact order it was created. If manual edits are applied to the schematic before the ECO files have been incorporated, then synchronization can be totally defeated and the design edits lost. Recovering from such a situation can mean many hours of mind-numbing tedium.

Designing without adequate synchronization tools is painful
The ECO method is the most common means of design synchronization in schematic and PCB design systems. But unfortunately, most tool vendors treat the FPGA design process as being separate from the board level design process. So the ECO process that is integral to the synchronization of schematic and PCB documents does not extend to FPGA design data.

Overcoming this data disconnect can be a particularly painful experience when resorting to manual means. Whilst it may be feasible to manually synchronize PCB, schematic and FPGA design data for very small FPGA devices, the thought of having to do this across an FPGA device with 1000+ pins can be totally demoralizing. As an example, consider a 1000 pin device that is iteratively pin swapped 10 times in an effort to improve the routing complexity and PCB layout options. This relates to a total of 10,000 pins requiring manual check and synchronization.