Over the past few years, as FPGA devices have increased in density, speed, and started embedding dedicated memory, multiplier blocks, high performance intellectual property (IP), PLLs, and high-speed SERDES, they have become a viable alternative to implement complex designs and applications that traditionally targeted ASIC or ASSP-based designs . This trend however is stressing the limits of traditional FPGA static timing analysis tools and designer productivity is affected.
To meet market requirements and achieve target performance, FPGA design engineers are adopting new design styles and complex clocking schemes (i.e. clock multiplexing in 10M, 100M, 1G Ethernet applications), in addition to embedding in their designs source-synchronous clock interfaces (i.e. DDR and DDR2) that are difficult to analyze using traditional FPGA timing analysis.
Following is an overview of new FPGA design software requirements necessary to perform efficient timing analysis and assist timing closure, including the use of the industry-standard Synopsys Design Constraints (SDC) format and the productivity advantage gained from using SDC.
Why A Standard Static Timing Analysis Terminology?
Static timing analysis is a method of analyzing, debugging, and validating the timing performance of a design. It is used in conjunction with functional verification (typically simulation or prototyping) to verify the correct design operation.
After the synthesis step or place-and-route step (which can include physical synthesis) is performed, engineers perform timing analysis and check for timing violations that may result from the compilation of the design. These violations need to be corrected through changes in the design’s logic or in the synthesis and place-and-route settings.
Traditional FPGA timing analysis isolated the timing analysis of a device from that of the board, using proprietary constraints such as Tsu, Tco, and Tpd requirements to constrain I/Os. To reduce cost and provide faster development time, more ASIC-like applications are implemented using FPGAs. As FPGA-based designs are becoming an integral part of complex and faster systems, the timing analysis becomes more system-centric. By specifying external board delays as input/output delays and clock latencies, the FPGA is analyzed as part of a complete system. Furthermore, input/output delays and clock latencies remain unchanged when clock constraints change, unlike proprietary Tsu, Tco, and Tpd requirements.
With the increasing importance of high-speed I/O for fast chip-to-chip data transfers, I/O timing is becoming more and more critical. Techniques such as a source synchronous design (used for DDR interfaces) have been adopted to help ensure robust timing and performance at higher speed. While these techniques make it easier to meet timing at higher clock frequencies, the timing analysis of such circuits is more complex. SDC constraints make it easier to analyze these types of circuits, a task that is difficult to impossible in existing FPGA timing analyzers.
The use of the Synopsys Design Constraints (SDC) format enables a powerful timing constraints methodology. While the SDC format efficiently captures the “design intent” and the surrounding constraints for synthesis, clocking, timing, power, test and environmental and operating conditions, this article focuses on the timing constraints portion of the SDC format.
The use of standard reporting terminology also aids interoperability, providing a familiar reporting language across multiple tools. Specifically, the use of arrival and required times simplifies the reporting of paths, and provides a consistent usage for both core and I/O paths.
Figure 1 and the caption describe the timing terminology used today to describe timing paths between registers.
 |
| Figure 1. An on-chip, register-to-register application using standard timing terminology. This terminology is important because most modern timing analysis tools report the timing analysis results in this format. |
- Arrival Time: the latest time that a signal arrives at the destination register. For hold checks, the earliest time is used.
- Required Time: the latest time that a signal can arrive and be correctly stored in the destination register. For hold checks, the earliest time that a signal can arrive at the destination register, such that data from the previous clock edge is properly latched.
- Setup Slack: the difference between required time and arrival time. A positive slack means the circuit performs at the desired frequency. A negative slack means the path to the destination register is too slow and the design does not operate at the desired speed.
- Critical path: the path among register pairs with the smallest setup slack.
- Hold Slack: the difference between arrival time and required time. For the design to function properly each register pair must have a positive hold slack.
The primary difference between standard terminology and the traditional FPGA timing analysis terminology is the use of “Arrival” and “Required” timings, instead of proprietary “point-to-point” (or register-to-register) timing definitions.
One benefit of adopting this terminology is that it eases the analysis of both the FPGA device and board timing. Figure 2 shows the use of “Arrival” and “Required” times and how they apply at the register-to-register level, as well as the overall system.
 |
|
Figure 2. A system view consistent with the SDC timing terminology
|
Traditionally FPGA vendors introduced different static timing analysis methodologies based on proprietary technologies and timing constraint formats. In the past the overall clock frequency (Fmax) was the most important parameter to consider in FPGA-based designs, therefore these formats were mainly designed to model register-to-register timing constraints.
As designs became more complex, FPGA vendors continued adding “ad-hoc” constructs aimed at solving the additional design complexity. However, adding these additional constructs increased the overall complexity of the constraints language, thus defeating the original purpose of creating a comprehensive language to solve complex design problems. Because of the proprietary nature of these languages, the reuse of constraints was limited. Designers need to re-use constraints when working on design derivatives. The only way to re-use design constraints was to continue using the same FPGA design software and, most importantly, the same FPGA vendor.
Another (and possibly more important) re-use issue is that as more ASIC-type applications are being migrated to FPGAs in order to reduce cost and provide faster development time, it is becoming difficult to transfer existing timing constraints from ASICs to FPGAs. Even if such transfer is feasible, it results in a time-consuming and error-prone translation between proprietary constraint languages.
Additionally, an important software requirement for a timing analysis tool is the integration of the static timing analysis with the synthesis and place-and-route engines. This integration ensures that the same timing constraints can be effectively used to drive the synthesis and the place-and-route algorithms to achieve better Quality of Results (QoR).
If the synthesis and the timing engines are not integrated, debugging and fixing critical paths within the design is difficult. This occurs when node names are mismatched between the original netlist and the netlist generated by the synthesis engine. Such mismatches are often the result of changes in the node names database that typically occur after place-and-route and physical synthesis. When this happens, some of the internal nodes become less “observable” and difficult to map back to the original timing constraints.
Solution
In addition to industry-standard usability features, design engineers point to two primary technology requirements that next-generation FPGA timing analysis tools must satisfy:
- Native support for industry-standard SDC timing constraints, and finer timing analysis control
- Integration
Native SDC Support
The SDC timing format has been broadly adopted by ASIC engineers and enables a fast, reliable ASIC design cycle. For these design engineers SDC support is becoming much more important since FPGAs are often used to implement fast prototyping of ASIC designs. Because of its expressiveness, the SDC format support allows FPGA and structured ASIC designers more control in constraining timing paths.
Complex timing constraints for multi-frequency designs and designs containing source-synchronous interfaces, such as DDR and DDR2, are conveniently expressed with SDC. SDC timing constructs have proven sufficient, consistent, and effective in constraining the latest high-performance designs.
Design interfaces such as source-synchronous interfaces are becoming more common in high-end FPGA designs. Source-synchronous interfaces are characterized by having both the data and clock signals “sourced” by the same host device, exposing both signals to the same physical effects to reach the on-board destination device, resulting in greater interface speed.
Constraining A Source-Synchronous Interface
 |
|
Figure 3. A simplified DDR controller design
|
One of the typical requirements of a source-synchronous interface is that the data and the (sourced) clock leave the FPGA at about the same time. If the clock period of the system is 5ns and the maximum allowable skew is +/-500ps, the SDC commands to constrain the design are as follows:
To calculate the delay parameters used in the SDC set_output_delay commands above, refer to “A SDC Primer: Calculation of Delay Parameters” below.
This example highlights how SDC is used to generate a clock at the output pin of the device. SDC support frees the user from specifying complex timing relationships among signals and, in this case, transfers the responsibility of understanding the delay between CLK_IN and CLK_OUT (which could vary between compilations, making it difficult to achieve timing closure) to the timing analysis tool.
Timing analysis tools that provide native support for the SDC constraints format provide a general solution that neither requires an ad-hoc methodology nor learning proprietary timing constraints languages. Native SDC support provides all the sophisticated constraints controls engineers require when performing timing analysis of high-performance FGPA-based designs.
As more commercial applications move from the ASIC to the FPGA domain, ASIC design engineers are developing new devices and/or derivatives using FPGA design software and technologies. These engineers are familiar with the SDC-based timing analysis methodologies. SDC constraints are available for many of the blocks being re-designed that target FPGA devices. Re-using timing constraints represents a clear productivity advantage. More time is saved by avoiding human error associated with the manual or automated translation process from SDC to the constraints format supported by the target FPGA design software timing tool.
Another key aspect of SDC-based timing analysis is the possibility of using SDC constraints in conjunction with the Tcl scripting. SDC-based timing analysis promotes scripting and empowers users to automate timing related design tasks.
Realizing these benefits, some FPGA designers are comparing the increased productivity experienced with the shift from traditional FPGA to SDC-based timing analysis with the transition from proprietary Hardware Description Languages (HDL) and even schematic entry, to standard languages such as Verilog and VHDL.
Integration
When a timing engine is integrated with the synthesis tool it performs a timing-driven synthesis (as well as physical synthesis) that guides the place-and-route algorithm. This integration has a positive impact on the QoR. Timing-driven synthesis and placement provide better results because the constraints used in the analysis phase are used to optimize the logic synthesis and placement in the device to meet the timing specifications. Ultimately this integration reduces the number of cycles necessary to close timing.
There are several important productivity benefits resulting from integration of the synthesis and timing engine. Since the same timing constraints drive synthesis, place-and-route, and timing analysis, the user describes the timing constraints only once, using the SDC format and there is no need to reconcile names across different design netlists.
In addition the user has the ability to perform these tasks using the same tool, and thus the same tool’s interface. This holds true whether the user adopts a GUI or a script-based approach.
Integration has possibly the biggest positive impact in debugging timing analysis violations. The synthesis engine, the fitter, and the timing analysis engine use the same data representation, thus all netlist nodes are observable without any need for re-mapping node names.
Lastly, the integration of the timing closure floorplan with the RTL viewer (or “technology viewer”) enables “cross-probing”, which is the ability to select design elements from one tool and locate them in another tool. Cross-probing ultimately provides a better understanding of the design’s timing critical paths and assists in debugging timing violations.
 |
| Figure 4. With native support for the SDC timing constraints format, TimeQuest enables users to create, manage, and analyze complex timing constraints, and to quickly perform advanced timing verification. Integrated in Quartus II software version 6.0 Subscription Edition, TimeQuest is used in conjunction with the Quartus Integrated Synthesis engine to meet the desired area and timing requirements in less iteration, thus enhancing user’s productivity. |
Summary
Advances in process technologies have enabled the adoption of FPGAs into a wide range of applications that typically belonged in the ASIC domain. The increased number of designs embedding clock multiplexing clocking schemes and source-synchronous clock interfaces suggest that, to keep up with productivity requirements, a new approach for performing timing analysis in FPGA design is needed.
From a methodology perspective, user productivity is tied to the industry-standard SDC format to specify design constraints. From a technology standpoint, the timing analysis engine must be integrated with synthesis and place-and-route to ensure faster and reliable timing closure.
A SDC Primer: Calculation of Delay Parameters
The requirement for the example in Figure 3 states that the arrival time of DATA_OUT should be within +/- 0.500 of CLK_OUT.
Using the definitions introduced in Figure 1, the above requirement is expressed as:
Arrival(CLK_OUT) – 0.500 < Arrival(DATA_OUT) < Arrival(CLK_OUT) + 0.500
Use a “setup check” to constrain the right hand side relationship and a “hold check” to constrain the left-hand side relationship.
For the setup check:
Arrival(DATA_OUT) < Required(DATA_OUT)
Arrival(DATA_OUT) < Period + Arrival(CLK_OUT) – OutputDelay(DATA_OUT)
Arrival(DATA_OUT) < Arrival(CLK_OUT) + Period – OutputDelay(DATA_OUT)
Solving for:
Arrival(DATA_OUT) < Arrival(CLK_OUT) + 0.500
The following is obtained:
0.500 = Period – OutputDelay(DATA_OUT)
The output delay for the setup relationship is: OutputDelay(DATA_OUT) = Period – 0.500
For the hold check:
Required(DATA_OUT) < Arrival(DATA_OUT)
0 + Arrival(CLK_OUT) – OutputDelay(DATA_OUT) < Arrival(DATA_OUT)
Arrival(CLK_OUT) – OutputDelay(DATA_OUT) < Arrival(DATA_OUT)
Solving for:
Arrival(CLK_OUT) – 0.500 < Arrival(DATA_OUT)
We obtain the output delay for the hold relationship: OutputDelay(DATA_OUT) = 0.500
The values calculated above are used in the SDC set_output_delay commands to constrain the setup (-max) and the hold (-min) relationships.
In the event of a setup/hold check violation, the timing analysis tool will report by how much – and in which direction – the design is violating the skew requirement.
|
About the Author |
|
 |
Alessandro Fasan has over 14 years of engineering, field and marketing experience. |
