There are software tools to migrate the existing designs to new FPGAs--simply program and pop in the new part. But can migration tools be trusted?
Several of our circuit card products use an FPGA that had recently been obsoleted by the manufacturer. Fortunately, they had a replacement FPGA with the same pinout, the major difference being that the silicon was smaller and faster. And there was a software tool to migrate the existing designs to the new device, allowing us to simply program and pop in the new part. Unfortunately, this simple migration did not go quite as planned.
As a second-party owner and manufacturer of the product line, we did not have all of the original FPGA design documentation, only the final load files. This was sufficient for the migration tool to re-create the loads for the new device along with basic schematic drawings. The migration worked successfully for all but three of our production cards. The problems with those three cards turned out to be analog related. Funny, when you consider these FPGAs are digital devices.
The first card was very flaky with the new silicon. Probing the clocks and data to the FPGA caused more erratic performance–a typical clue to analog problems. In dismay, I held the PCB up to the light and realised there were no internal ground/power planes–the PCB had only two copper layers. The original designer had gotten away with four widely spread power/ground traces to the FPGA due to the slower speed of the original silicon.
I suspected that the new faster silicon was seeing increased power/ground bounce from the long individual etch runs between its multiple ground and power pins. To prove this, I cut out two squares of single-sided copper-clad PCB stock to fit within the through-hole FPGA socket pins on the rear side of the board. All problems were solve, when the multiple power and ground pins of the new FPGA were soldered together onto these copper-clad squares. A re-spin with added internal power and ground planes provided a permanent solution.
The second card had internal power and ground planes, but one of the FPGA functions was a phase detector for an external phase locked loop (PLL) using a voltage-controlled crystal oscillator (VCXO). When the FPGA was cooled to slightly below room temperature, the PLL took off with wild frequency fluctuations. It turned out the original designer had not included sufficient damping in the loop filter and the extra noise on the power rails from the faster FPGA transitions was all that was needed to push the PLL over the instability threshold into erratic injection lock behaviour. An increase to the proper 0.7 damping factor resolved the problem nicely.
The third card was a real bear. All external circuits were strictly digital and the PCB was well designed with internal power/ground planes. Unlike the first two problem FPGAs, which at least had some activity, this FPGA refused to show any life at all. We printed the schematics from the code before the final compile and immediately spotted something unusual: The original designer had used cascaded buffers as analog delay lines in several places and in one place these cascaded buffers were used to create a ring oscillator for a watchdog timer.
Tools without reason
This ring oscillator was not oscillating, thus holding the device in permanent reset. The migration tool for the new silicon had deleted these extra buffers as extraneous to the circuit in its attempt to minimise excess delay. The tool did not realise the delays were intentionally placed there for a good reason. Re-compiling the design with an override to prevent deletion of the cascaded buffers restored the device to proper operation.
What migration miseries have you had to deal with?
First published by EDN.