In most FPGA-based boards, the PCB designer is on his own -- with little help from any tool -- to unravel what is often a routing nightmare. This can be caused by FPGA and/or schematic designs that have given little thought to the actual routing, inclucing layer stackup, crossovers, differential pair length matching, and high-speed signal integrity requirements.
To be fair, this is not completely the fault of the upstream designers, since they also have no tools to provide PCB guidance when they make their pin assignment choices. So, they do what they can and then work with the PCB designer later -- in a painful, endless series of negotiations -- to untangle the signal spaghetti, as this DDR3 example (using actual FPGA-tool-defined pin assignments) illustrates:
Figure 1 - Typical DDR3 pin assignments received by a PCB designer
The result is that system design processes continue to suffer from a lack of the right knowledge at the right point in the process.
For example, consider a simple, two component design -- two FPGAs connected through a 32-bit data bus. Suppose that the FPGA designer has used the FPGA design tool to pick pin assignments with the assumption that the two FPGAs will be placed side by side. Lacking intrinsic information about the PCB, the FPGA designer can't, at least natively within his tools, use component proximity to help guide him in his pin assignment effort. Also, since he can edit only one FPGA at a time, he has to have separate projects for each FPGA (although the tools would at least give him the ability to spread the 32 data bits across the appropriate side of each FPGA).
While a straightforward, side-by-side topology like this example is easy for an FPGA designer to envision, an FPGA is usually interconnected to several components and in some cases there are multiple FPGAs interfaced to multiple components and other FPGAs. Then, PCB placement becomes almost impossible to visualize because the FPGA tools simply do not account for the spatial qualities of the board.
Another way to create the initial FPGA pin assignments is to use a board-aware FPGA I/O planning and pin assignment tool like Cadence's Allegro/OrCAD FPGA System Planner. Since Allegro/OrCAD FPGA System Planner understands component placement, it uses this information, along with FPGA pin assignment rules, to automatically assign FPGA pins to signals that are optimized for both domains -- FPGA and PCB.
Allegro/OrCAD FPGA System Planner (FSP) can be used in multiple ways. The user can derive the pin assignments in Allegro / OrCAD FSP and pass those to the FPGA designer for FPGA simulation/verification, or the FPGA designer can pass the FPGA tool's pin locations into Allegro/OrCAD FPGA System Planner, which can then by optimized for routing on the PCB. This allows the Allegro/OrCAD FPGA System Planner user and FPGA designer to converge on an agreeable first-pass set of assignments up front, at the beginning of the process.
Figure 2 - Allegro/OrCAD FPGA System Planner
Regardless of how the pin assignments are created, either with the FPGA tools or with a tool like Allegro/OrCAD FPGA System Planner, or both, numerous FPGA and design constraints have to be managed:
o What about the FPGA power and voltage reference pins and how do those change as the pin assignments change?
o Most I/O pins are multi-use pins but many are not -- which ones are which?
o How do the configuration and JTAG pins need to be connected?
o Are there high-speed buses, whose signals should be kept together, like a byte lane of a DDR interface?
o Do some signals have to connect to dedicated FPGA pins, like clock-capable or multi-gigabit serial I/O pins?
o Are there constraints on some signals such that they all must route to the same clock region or to the same bank of the FPGA?
o What about strobes for memories? They have a specific relationship to the data bits.
o What signals are already connected to a particular bank? That affects how other signals can be connected to that same bank.
The value of using a tool like Allegro/OrCAD FPGA System Planner is that it can automatically deal with all of the issues listed above and it can also be used within the Allegro PCB design tools as an "engine" to guide/assist the PCB designer (which is the topic of Part 2 of this blog series).
In the simple example above, if the FPGA on the right has its pin assignments on the left and vice-versa, it's conceivable that the 32 interconnects should be easy to route on the PCB. But what would happen to the routing if the FPGA placement changes or if PCB restrictions demand that the signals have to be flowed around the FPGA's? The PCB designer is then either going to have to figure out how to route the board with the original pin assignments or he is going to have to work with the FPGA designer to change the pin assignments to better meet the PCB routing needs. Or, if he or the PCB tool understood the FPGA well enough to make informed pin swap decisions (see the list of items above that have to be considered in this effort), he could do this immediately, eliminating countless hours of haggling with the FPGA designer.
Several customers have used this approach of planning their FPGA pin assignments while simultaneously assessing the affects of those assignments on the PCB layout -- and vice-versa. Many of them reported shortening their time to integrate FPGAs with their PCBs anywhere from 40% to 75-80% depending on the number of FPGAs used on the PCB. Three customers, IN2P3 in France, JDSU in Ottawa, and Verisilicon in China, have shared their experiences using this technique. You can read more about this at http://www.cadence.com/rl/Resources/success_stories/IN2P3_cs.pdf, http://www.cadence.com/rl/Resources/success_stories/jdsu_cs.pdf, and http://www.cadence.com/rl/Resources/success_stories/verisilicon_cs.pdf.
In an upcoming blog I'll take this two-FPGA design into the PCB tool and explore what happens as the PCB designer attempts to route the connections with these pin assignments.