feature article
Subscribe Now

Complex ASIC Timing Verification Converges with FPGA-Based Designs

The importance of a SDC-based timing analysis methodology for FPGAs

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.
He joined Altera in November 2005. He leads the technical marketing team for Altera’s Quartus II design software.
Prior to joining Altera Alessandro worked at Synopsys as product marketing manager for the Magellan product, technical marketing manager for Synopsys’s flagship VCS simulator, and field engineer supporting VCS and Vera.  Other experience includes 7 years as an IC design and verification engineer with ST Microelectronics working on MPEG2, microprocessor (x86), and memory controller designs.
Alessandro holds a Laurea in Ingegneria Elettronica (MSEE) from the University of Padova, Italy. He is an MBA candidate at San Jose State University and holds two US patents.

Leave a Reply

featured blogs
Oct 3, 2024
Someone with too much time on his hands managed to get Linux to boot on an Intel 4004 in only 4.76 days...

featured paper

A game-changer for IP designers: design-stage verification

Sponsored by Siemens Digital Industries Software

In this new technical paper, youā€™ll gain valuable insights into how, by moving physical verification earlier in the IP design flow, you can locate and correct design errors sooner, reducing costs and getting complex designs to market faster. Dive into the challenges of hard, soft and custom IP creation, and learn how to run targeted, real-time or on-demand physical verification with precision, earlier in the layout process.

Read more

featured chalk talk

Accelerating Tapeouts with Synopsys Cloud and AI
Sponsored by Synopsys
In this episode of Chalk Talk, Amelia Dalton and Vikram Bhatia from Synopsys explore how you can accelerate your next tapeout with Synopsys Cloud and AI. They also discuss new enhancements and customer use cases that leverage AI with hybrid cloud deployment scenarios, and how this platform can help CAD managers and engineers reduce licensing overheads and seamlessly run complex EDA design flows through Synopsys Cloud.
Jul 8, 2024
20,873 views