Integrating PCB and FPGA Constraints

A product’s success is in large part a direct result of how well, relative to the target market, the product is constrained. Manufacturing costs, ergonomics, reliability, retail price, usability, power requirements – all of these factors (among a host of others) are in one way or another a constraint on the finished product. From an electrical engineering perspective, additional, more specific constraints have to be dealt with: bus latency, bandwidth, data processing needs, component costs and availability, power consumption, etc.

In their attempts to create a product that meets the needs of the market, engineers must make hundreds of tradeoffs before committing to a final architecture. When FPGAs (or ASICs, but for the purpose of this article, FPGAs) figure into that architecture, one of the initial design-level issues that must be dealt with is how to properly constrain both the FPGA and the PCB. Board-level demands (constraints) must consider the capabilities of the FPGA; conversely, the FPGA must be carefully selected in order to meet the needs of the overall system. Tying these together requires a system-wide view of constraints.

Types of Constraints

An FPGA-based board design has many types of constraints, from the paths internal to the FPGA to the routing constraints on the PCB. But although they may affect different areas of the design, these constraints are almost never mutually exclusive. They are usually tied together and interdependent in ways that are not always obvious. For example, increasing the speed of a clock may solve a timing problem but may also introduce SI or EMI problems.

The FPGA is constrained by the timing requirements of the design (timing constraints), the capacity and architecture of the device (routing constraints) and the I/O standards applied to the I/O buffers (I/O constraints). Each of these constraints influences the choice and sizing of the FPGA buffers that connect the FPGA to the rest of the system.

The PCB (system) requirements and characteristics also influence the optimum FPGA I/O buffer choice. The loading capacitance, PCB stackup, routing length, trace width, number of vias in the signal path, and speed of the signal all directly affect the sizing of the I/O buffer. Many of the constraints needed to define the internal timing of the FPGA can be derived from – and are directly affected by – the external components connected to it. These devices are often other FPGAs which, due to the programmable nature of the I/O buffers, compound the problem by adding more variables to the equation.

Figure 1 shows a typical board-level FPGA-FPGA register-register timing path. Though not obvious in this simplified diagram, the total signal path is from output register to output buffer, to bond wire, to pad (ball), to PCB trace, to pad, to bond wire, to input buffer and finally the input register. Each section of this path has its own unique constraint. While accurately modeling and capturing constraints at this (the transistor) level is extremely difficult, it is not unheard of, especially in critical applications.

Figure 1 - FPGA Timing as Seen From the Board.

Constraint Ownership

Constraint ownership is shared by many designers and constraints are a key element of every product whether they’re formally recognized as such or not. Some argue that constraints are perhaps the single most important ingredient of intellectual property. Although a project typically originates with the design of the FPGA, requiring an initial subset of constraints, the information necessary to accurately define a complete set of constraints comes from many sources (systems, firmware, software, DSP, power, SI, CPU [possibly embedded in the FPGA], timing analysis, PCB layout, and other groups), all of whom are involved with, or affected by, the performance of the overall system.

Unfortunately, the mechanisms employed to capture and convey this critical information have largely been localized and manual in nature. Constraint entry and management systems delivered with EDA tools generally don’t have strong connections to the FPGA vendor’s tools and databases (for place & route and synthesis) and vice-versa. As a result, converging on a design that satisfies both the board and the FPGA is largely an iterative process. FPGA designers typically, synthesize to a given set of constraints, pass their results to the schematic and PCB designers who then request changes to the FPGA, and so on, until both the FPGA and the board work as a system.

This technique may have worked well for many years, but with higher pin counts and more FPGAs per board, what is clearly needed is a project and team-wide method of defining and communicating constraints across multiple tools from multiple vendors.

An Integrated View of Constraints

Effectively resolving this issue won’t be easy. While a close collaboration between the EDA and FPGA vendors would certainly accelerate a solution, a proven communication link between the board and FPGA tools has already been established through existing synthesis and P&R files, which can be easily read and modified by both the EDA and FPGA vendor’s tools. What is missing is a means of defining the FPGA’s I/O constraints while simultaneously considering the performance constraints of the PCB.

In order to be useful, a constraint management tool needs to be able to span the entire spectrum of system constraints: physical, electrical, and mechanical (other constraints also come into play but these are the ones most directly affecting the board). And it needs to provide a means of allowing the system designer to influence the choice of I/O buffers on the FPGA. In this kind of approach, the system designer, via constraints, can help size the buffers by capturing the performance characteristics of the rest of the board and making that data available to the FPGA synthesis tools.

Once this information is captured in a single location, changes to the FPGA’s pin out now become much less troublesome. For example, seeing that there are routing problems which could potentially be fixed by altering pins locations on the FPGA, a PCB designer could feed that change request to the FPGA designer electronically. Since moving a pin does not change the overall system constraints, the data needed to re-synthesize the FPGA remains intact. The synthesis and P&R constraints files can be automatically updated and a ‘what if’ pass through the FPGA tools attempted.

Moving in this direction, Mentor Graphics® latest release of their I/O Designer™ application supports the import, export, entry, and modification of the set of constraints that most directly affect the choice of the FPGA’s I/O buffers. Linked with its long-standing ability to read and write the FPGA synthesis and P&R files, this combination significantly improves FPGA and board-level constraints communication. Shown below in figure 2 is a screenshot of I/O Designer with an exploded view of the ‘Timings’ window. In this GUI, the user can see each signal name, the required timing of the signal, actual values reported from the PCB, slack time, associated clock name, relative clock edge, and data arrival time (before or after). This window supports the display and modification of clock, pad-to-setup, clock-to-pad, and pad-to-pad constraints. Values displayed in this window come from the Mentor constraints database as well as, from the FPGA vendor’s synthesis constraints file.

Figure 2 - I/O Designer with Expanded View of Constraints GUI.

Conclusion

Expanding on the ideas in this article, an EDA tool or environment that can ‘see’ across multiple FPGAs at once would open up the possibility of automatically sizing the FPGA I/O buffers so that the resulting inter-FPGA connections would be electrically compatible. It should eventually even be possible, using real-time inter-tool communication, to converge on an optimal solution for both the FPGA (buffer sizing and pin location) and the PCB (routing), with minimal user interaction. But neither of these can be accomplished without the marriage of FPGA and PCB constraints in a common, consistent database.

August 22, 2006

[back to top]

Comments on this article? Send them to comments@fpgajournal.com