In part 1 of this blog, I discussed a scenario that PCB designers working with FPGA-based boards are often faced with: getting pin assignments from FPGA and/or schematic engineers that can create serious PCB routing problems. In that blog I claimed that the upstream engineers can't accurately assess the impacts of their FPGA pin selections on the PCB partially because the tools they use don't consider the PCB. As a result, the team can sometimes spend weeks trying to reach closure on system-optimal FPGA pin assignments. And I proposed that the solution is to bring the PCB knowledge to the front-end engineers and give the PCB designer the power and knowledge to make valid changes to the FPGA pin assignments.
To demonstrate this scenario, in the first blog I created a simple, two-FPGA design, with an interconnected 32-bit data bus. In part 2 of this blog, I will take this design into the PCB tool and see what happens as the PCB designer attempts to route it.
Figure 1 - The FPGA designer's PCB placement assumption
If the PCB layout matches what the FPGA designer assumed, the PCB designer should have no problems routing the connections. But what happens if the FPGAs can't be placed side by side for some reason - maybe another component needs to occupy the space - and the PCB designer needs to place the FPGAs vertically?
Figure 2 - The PCB designer's placement needs
Or maybe the side-by-side placement is fine but there is a hole in the board between the FPGAs, and the signals have to flow into the top of the FPGA on the left.
Figure 3 - A hole that affects the PCB bundle flow
This could not, or may not, have been anticipated when the pins were first being assigned. Certainly the FPGA designer and schematic engineer wouldn't have planned for it because they are not directly dealing with PCB routing, and neither they nor the tools they use have any in-depth knowledge of the PCB layout.
Now the pin assignments have too many crossovers and don't look so good from a routing perspective. And in a typical flow, the PCB designer is probably going to be forced to go back to the FPGA designer to negotiate pin swaps, which means the schematic engineer is also going to have to get involved (those "finished" schematics are now no longer finished).
But what if the PCB designer had been involved with the FPGA pin planning from the very start? What if he could take the FPGA-related subsystem, with the existing pin assignments, plan the placement and signal flows, and then use this knowledge to propose better pin assignments? What if the PCB designer had the technology, within the PCB tool itself, to use an FPGA-intelligent algorithm that could automatically re-assign the pins based on how the signals enter the FPGA? Not a static swap matrix that only understands that two signals are part of the same swap group and knows nothing about the FPGA itself, but an engine, running under the PCB hood, like a built-in FPGA expert.
Let's see what could be accomplished by using Cadence's Allegro/OrCAD FPGA System Planner (FSP) engine, within Allegro PCB Editor.
Figure 4 - Using the Allegro/OrCAD FPGA System Planner engine to assign new FPGA pins
By selecting the bundle and using Allegro/OrCAD FPGA System Planner's FPGA knowledge and pin swapping algorithm to reassign the signals on the left FPGA, not only have better (with respect to PCB routing) pins been chosen for the FPGA, the signals have been unraveled, which translates into faster routing on fewer layers:
Figure 5 - FPGA pin reassignment on FPGA U1
The same algorithm could be applied to the FPGA on the right:
Figure 6 - FPGA pin reassignment on FPGA U2
Notice how some signals on the right-hand FPGA tend to occupy the top center of the FPGA. This is, in some cases, to be expected - in this case the pins on the top left quadrant of this particular FPGA consist of power, configuration, and differential pins. But since the Allegro/OrCAD FSP engine has full knowledge of the FPGA and the device's pin characteristics, it has automatically picked pins that adhere to the FPGA's capabilities.
There is no way that a static swap mechanism can support this level of FPGA knowledge. Classic pin swapping technology has barely evolved beyond a rudimentary scheme where groups of pins are tagged as being logically and/or electrically equivalent. For fixed-pin parts, this works fine. But for FPGAs, the pin usage rules change as the connectivity to the FPGA changes and a simple swap group approach cannot possibly account for this. Even if it could, to accomplish the degree of re-optimization highlighted above the PCB designer would have had to spend hours manually moving signals one at a time.
Now that the PCB designer has a signal flow and pin assignments that appear to support the actual routing, what does this look like to the FPGA designer, whose tools do not consider the signal flow on the PCB?
Figure 7 - PCB-optimal pin assignments as seen by the FPGA designer
Without knowledge of how the signals would eventually be flowed on the PCB, it is highly unlikely that the FPGA designer would have chosen the pin assignments shown above. To him, they make no sense - there are multiple crossovers, the "traces" appear to be longer than they need to be, and the FPGA pins don't appear to be well-utilized. But that is irrelevant. If the resulting pin assignments work for the FPGA and the PCB designer's needs have been met, the end result will be a more optimal design that will be routable in less time and with fewer layers.
A short video that demonstrates the scenario above can be found here. Also, I will be hosting a webinar on September 12th, 2013, where I will give a demonstration and expand on the concepts I have discussed in parts 1 and 2 of this blog, using a more complex design than the example I've used here. Click here to register for the webinar.