In this era of high-performance electronics, timing continues to be a top priority and designers are spending increased amounts of effort addressing FPGA performance. With the migration of mainstream designers to 0.35 micron (350 nanometer) technology, FPGA design sizes have rapidly increased to more than half-a-million gates and early 0.25 micron (250 nanometer) technology designs have shown working silicon containing more than a million gates. With the advent of 0.18 micron (180 nanometer) technology, designs are reaching gate counts of over five million. In the next three years, communications, multimedia and embedded microcontroller systems will be operating together on single chips designed in less than a year. Such high levels of integration and time-to-market pressures will make design reuse an indispensable task for system designers. These market trends are forcing design activities towards mega sized systems on a chip (SoC). Complexity, speed and deep-submicron effects are making timing closure for a SoC design more critical than ever. For DSM designs, interconnect delay values are increasing, and post place and route and accurate timing analysis are becoming key success factors for accurate timing. Timing verification of multimillion-gate designs is a must for accurate timing closure. Conventional timing verification methodologies are falling short in capacity and performance for SoC designs. As a result, We are turning to newer design methodologies and tools, such as advanced static-timing analysis, for timing closure.  our solution will Featuring very low Power consumption designs and the industry's highest design security, Power XLogic offer our customers a reliable, solution to your FPGA  , ASIC needs. providing an efficient, flexible i/o architecture we have ideal design expertise for integrating your legacy logic requirements into a single low cost device .we know how to manage high volume platform that enables solutions without compromising on cost and time .our designs can match the speed and performance of high end ASIC and be used to generate system wide saving by integrating multiple functions into a low cost chip solution.

Figure 1: Logic Design Methodology Using Simulation

Verification Bottleneck: Full-Chip Timing Analysis Using Simulation

Traditionally, a dynamic simulator has been used to verify the functionality and timing of an entire design or blocks within the design, as shown in Figure 1. Dynamic timing simulation requires simulation vectors specifically designed to exercise timing critical paths in the design, a Logic simulator and timing information. With this methodology, input vectors are used to exercise functional paths based on dynamic timing behaviors for the chip or block. Dynamic simulation based methodologies can verify functionality as well as timing of the design without placing much restriction on design styles being verified or on testbenches. This is the most popularly used and widely understood timing verification strategy.

Today, designers are spending 50 percent of overall design time performing functional and timing verification of their design. Designers have to create separate timing and functional vectors for verification. It is extremely difficult to create timing vectors that will exercise each path in the design exhaustively. The vector generation problem explodes as the size and complexity of designs increase and overall design schedules shrink due to time-to-market pressures. Existing simulation tools do not have the performance and capacity to meet the demands of the full-timing simulation of multimillion-gate designs.

The advent of larger designs and mammoth vector sets make dynamic simulation a serious bottleneck in design flows. Dynamic simulation is becoming more problematic because of the difficulty in creating comprehensive vectors with high levels of coverage. Time-to-market pressure, chip complexity, limitations in the speed and capacity of traditional simulators -- all are motivating factors for migration towards static-timing techniques.

Static-Timing Analysis (STA)

STA is an exhaustive method of analyzing, debugging and validating the timing performance of a design. This is achieved by breaking down the entire design into sets of paths. The delay of each path in the design is calculated and checked against the timing assertions for any possible violation. Different types of checks performed by a static-timing analysis tool are described later in the section titled "Typical Static-Timing Analysis Checks." STA is exhaustive in that every path in the design is checked for timing violations. This is a key benefit over dynamic simulators, which would require an impossible number of vectors in order to provide the same level of timing coverage. STA has been available for many years and is an integral part of the Logic synthesis process, so Our designers are familiar with the STA techniques. High-end digital custom IC designers (e.g., microprocessor designers) have also been using STA-based timing verification methods for years because of the complexity of their designs. Since STA is not based on functional vectors, it is typically very fast and can accommodate very large designs. This is not to say that STA will completely replace dynamic simulation; static tools will coexist with dynamic verification tools. One primary reason is that STA does not verify the functionality of a design. Also, certain design styles are not well suited for a static approach. For instance, dynamic simulation may be required for asynchronous parts of a design and certainly for any mixed-signal portions. However, STA can significantly off-load tasks formerly handled by dynamic simulation and the usage of dynamic verification tools will decrease significantly. STA offers the runtime, capacity and complete analysis required by designers implementing large, SoC designs. Static-based timing verification means decreased time-to-market, increased productivity and exhaustiveness of verification. Figure 2 shows an Logic methodology for a typical synchronous design.

Figure 2: Logic Design Methodology Using STA

Benefits of Using STA

It can be seen from Figure 2 that use of STA can save as much as twenty percent of overall design cycle, thereby improving the timing coverage of the design. The primary benefits of using STA are:

• Exhaustive path coverage
• Does not require vectors
• Up to 100x faster than vector generation and simulation cycle
• Functional and timing verification efforts can be done in parallel
• Comprehensive reports for timing violations
• Sophisticated analysis features not available using simulation e.g., min/max analysis, combinational loop detection, automatic false path detection and elimination

Static-Timing Analysis Based Sign-Off

The sign-off process involves transferring the design data (netlist, timing assertions, etc.) to the silicon vendor for completion of remaining design steps (e.g., design layout using vendor specific tools) and manufacturing of the design. The our designer(s) perform all the necessary steps (e.g., pre-layout timing closure) prior to handing-off the design data to the silicon vendor. The silicon vendor then performs all the necessary verification steps (e.g., post-layout timing closure) prior to manufacturing. Currently dynamic simulation is the most prevalent tool of silicon vendors for timing verification related to the FPGA sign-off process. This is changing rapidly as the silicon vendors are moving towards static-timing analysis, (due to dynamic simulation limitations outlined in the section titled "Verification Bottleneck: Full-Chip Timing Analysis Using Simulation"), as the preferred choice of tool for pre- and post-layout timing sign-off of the design. This will require our designers to transfer the static-timing constraints and timing reports to LOGIC vendors, rather than the timing vectors, testbench and simulator output. The challenge for Logic vendors is to develop a detailed static-timing sign-off procedure that will give them the same (or even higher) degree of confidence in the static-timing sign-off flow as they have had in existing dynamic simulation based sign-off flow. This means that the Logic vendor can assure that the silicon will be free of timing problems. The following section describes some of the common requirements for FPGA sign-off and features of a typical static-timing analysis tool that helps our designers and vendors increase their confidence in static-timing sign-off.

Typical Static-Timing Analysis Checks

Comprehensive Timing Checks

Performing static-timing analysis on an FPGA requires many different kinds of violation checks. For example, negative setup and hold times are very common due to built-in multiplexers of flip-flop macros. Support for negative constraint values is essential for an STA tool. Following are the possible timing violation checks.

Setup and Hold
Setup is defined as the minimum length of time that a data input pin must be stable before the active clock transition. Hold time is defined as the minimum length of time that a data input pin must be stable after the active clock transition. Setup and hold should be handled with respect to different edges, if necessary (e.g., setup with respect to clock rising, hold with respect to clock falling).

Figure 3: Setup and Hold

Recovery and Removal
Recovery is defined as the minimum length of time that an asynchronous control input pin (e.g., preset or clear) must be stable before the clock active-edge transition. Removal is defined as the minimum length of time that an asynchronous control input pin (e.g., preset or clear) must be stable after the clock active-edge transition. These checks are analogous to setup and hold checks.

Figure 4: Recovery and Removal

Min Pulse Width
This is defined as the minimum width of a clock pulse (high or low) measured at the clock pin of a register. The register may not latch data correctly if clocked with a smaller pulse.

Figure 5: Minimum Pulse Width for a Positive Edge Triggered FF

The Figure 6 below shows the minimum pulse width for a positive edge triggered FF.

Zero-Cycle Paths (Hold Time Violation)
Zero-cycle paths are race conditions between two state devices. A zero-cycle path which is too short should be flagged as a hold violation unless designated as an intentional zero-cycle path. The data from the first state device is transferred to the second state device on the same clock cycle. This is illustrated in the following example:

Figure 6: Zero-Cycle Paths

It is important to notice that zero-cycle paths can be intentional or unintentional. The designer may have intentionally designed its Logic to be zero cycle, in this case, this is actually a multicycle constraint where the multicycle value is "0." On the other hand, the zero cycle can be unintentional and be the result of a large clock skew between two registers as shown in the example above. Such zero cycles are really hold-time violations and should be reported to the user.

Clock-Gating Checks
Static-timing analysis assumes that clock signals are correctly propagated through the entire clock network. Clock-gating Logic can cause glitches or shaved pulses of the clock waveform. The gating Logic should be checked specially for setup and hold to ensure that the active clock pulse is not corrupted.

Figure 7: Clock Gating Checks

Analysis Types

The tool should support simultaneous minimum and maximum analysis (min/max mode), or consider possible on-chip variation of delays due to process, temperature and voltage differences.

Multiclock and Multifrequency Support

The timing analyzer should accommodate designs which contain multiple clocks with multiple frequencies, phases and waveforms. Static-timing analysis imposes the restriction that all defined clocks must be harmonically related -- a known and fixed phase relationship must exist between the waveforms of all the clocks. Paths between clock domains which are not harmonically related must be verified using full-timing simulation.

The tool should automatically constrain paths for single-cycle timing based on the clocks of the startpoint and endpoint registers.

Multicycle Path Support

Multicycle paths are paths which intentionally require more than one clock cycle to propagate. This information cannot possibly be inferred by the timing analyzer, so it must be specified by the designer so the analyzer can mark the path and correctly compute the timing. A start point, end point and/or "through" point is specified, along with the number of allowed clock cycles. The command syntax should allow specification of clocks, ports or pins as the startpoint and endpoints, and a list of through pins.

Transparent Latch Support

The timing analysis tool should support time borrowing (also known as cycle stealing) in level-sensitive latch-based designs. This capability accurately analyzes the case where the data arrives within the enable pulse width of the latch. The tool should handle arbitrary levels of borrowing in latches, and should support loops of latches.

Back-Annotation Support

The timing analyzer should support full back-annotated timing information from layout using SDF (standard delay format) files. A report should be generated by the analyzer for data which has not been back-annotated. SDF support should include cell delays, interconnect delays, and timing checks.

Net capacitance is needed to check design rule violations such as maximum transition time and maximum capacitance.

Detailed or reduced parasitics (from SPEF, RSPF or DSPF) should also be supported for accurate delay calculation. The tool should be able to compute "Ceffective" and pin-to-pin net delays given detailed parasitics.

False Path Detection and Elimination

False paths are Logic paths which can not be sensitized because they are functionally blocked, or because of delays in reconvergent Logic. The tool should allow manual specification of false paths and consider them to be unconstrained. In addition, the tool should be able to automatically determine whether paths are able to be sensitized due to static or dynamic behavior.

Mode Analysis

Many large designs contain embedded complex Logic blocks. These can include:

·         Microprocessors/micro-controllers

·         Single and multiport RAMs

·         Single and multiport latch arrays

These blocks cannot be modeled as simple library elements because they can operate in different modes with separate timing arcs and timing characteristics for each mode. The mode can be determined by internal state in the block and/or a value or combination of values on its pins. The static-timing analyzer should support the different modes, and be able to perform the required checks and analysis under any mode selected by the user, and for all modes during sign-off.

State-Dependent Timing

State-dependent timing (conditional delays) is the ability to select a delay value based on a Boolean expression. Such a Boolean expression often uses the internal state and cell pin values as its parameters. At the cell level, such dependency can lead to a different delay value, a different unateness or the presence or absence of the arc. Since static-timing analysis is independent of the values of input signals and the internal state of the design, it is impossible to support the full state-dependent timing as in the simulation world. A static-timing analyzer can only use state-dependency information during case analysis, when the Logic function is considered.

Case Analysis

Case analysis is a means of restricting the paths and transitions considered in static timing by specifying constant values or rise/fall transition at certain ports or pins.

Case Analysis: Constant Declaration
Sometimes a designer will need to specify that an LOGIC pin is to be tied to a constant Logic value (high or low). Some reasons for doing this are:

• The pin is used as a "mode" pin when the LOGIC has different operating modes, or is "sliced"

• The pin is unused in a particular instantiation of the LOGIC

• The pin is only used for LOGIC chip test, and is not functional in a board

• The pin is functional only in a maintenance mode, and is not switched at speed

The user should be able to specify that this pin is held to a constant value, and the timing analyzer should intelligently exclude it from timing analysis. This implies that all corresponding propagated timing arcs are also eliminated from the analysis. All paths through which the constant is propagated have their timing arcs deleted from the analysis. Given the following example design illustrated in Figure 8:

Figure 8: Constant Declaration

In the example above, the user will run several analysis of the design: one in system mode, and one in scan test mode. In system mode, the scan paths should be ignored; this can be done by specifying port scan_mode as a constant. This has the effect of disabling all scan-chain paths because the constant value is propagated through out the design. Constant declaration really breaks paths as the constant value is propagated through out the design. It is also important to notice that constant is propagated only forward. Multiple constants on different signals should be supported.

Case Analysis: Specifying Transitions
A condition could be specified as a list of Logic constants or Logic transitions (rising and falling) on ports or pins.

A case analysis to a transition (rising or falling) is usually performed to specify a false path in the design by providing information which is not available in the design for false path detection. This is illustrated in Figure 9.

Figure 9: Specifying Transitions

This design has the specific behavior that all inputs A, B, C and D are always mutually exclusive; only one of these four inputs can be at Logic one at a given time. Without specifying this behavior, the longest path of this design may be one in which more than one input is rising, which should actually be considered as a false path. Using case analysis on the possible transitions of the primary inputs on this design will eliminate these false paths.

A case analysis to a transition does not break any timing arcs of the design; it just tells the tools that some transitions should not be considered in the current timing analysis. Case analysis applied on pins will not be propagated backward, only forward propagation is performed.

Methodology and Synchronous Design Checking

The timing analyzer should be able to check for and detect any violations to a synchronous design methodology. An alternative methodology such as dynamic timing simulation may be required to verify timing of asynchronous regions for sign-off.

Checking of Design and Constraints
The tool should examine the design for possible topoLogical problems and errors in the user-specified attributes/constraints:

• Registers clock pins with no clock fanning in

• Unconstrained endpoints

• Combinational feedback loops

• Problems in generated clock networks

• Level-sensitive latches which fanout to themselves

Asynchronous Domain Support and Combinational Feedback Loops
Static-timing analysis works on synchronous Logic. Some netlists will contain regions of asynchronous Logic, and the tool should provide a means to analyze the synchronous portions of such designs.

• Set false path between unrelated clocks. If there are paths between registers of two clocks which aren't harmonically related, the tool should allow manual exclusion of such paths. The tool should provide reporting facilities to identify interacting clock domains.

•  Dynamic breaking of combinational feedback loops.

•  Tool should be able to detect and break asynchronous feedback loops in such a manner that other critical paths of the design are not pruned from the analysis. The tool should be able to break bus loops and also be able to handle bidirectional buffers and bus contentions.

On-Chip Variation

The tool should be capable of handling on-chip PVT variation for deep-submicron designs. This also is referred to as "uncorrelated min/max analysis," i.e., hold margin analysis using maximum clock delay with respect to minimum data delay, so that no real time violation could go unnoticed. On-chip variation allows analysis when small variations of operating conditions exist on the chip. In this mode, it is necessary to consider in the same timing report cell and net delays at different operating conditions. The variation on the chip of the operating condition can be specified in terms of a percentage around a given operating condition (for example, from 95 percent to 100 percent of the delays in worst case (WC) conditions). It can also be specified by two separate operating conditions (for example, WC and WC_scaled operating conditions). The timing analyzer should be able to report on-chip variation using back-annotated delays.

Clock Reconvergence
For the parts common to both clock and data path for any constraint, the tool should have the capability to reconverge the delays for those parts. Reconvergence will determine that a common path pessimism exists between a clock and data path even if they share a common path in the clock tree while utilizing different edges.

Tester-Specific Environment

Part of the sign-off process is to check that in the specific tester environment, no timing violation will occur. Because the functional testers have a lot of limitations, the environment of the chip during post fab functional test is very different from the system environment of the chip. Some of the tester limitations include:

•  Very limited freedom in terms of clock signal generation. The tester may only allow a unique clock signal and a very small number of divided clock signals.

• Very limited number of different possible input delay times

• Very limited number of strobe times.

In terms of tester environment specification, the following figure explains how all times and delays need to be specified. In the specific tester environment, the tester period should be the reference for all timing specification, rather than the generated clock signal.

Special consideration may be needed for multicycle paths in the design. If the tester clock frequency is lower than the system clock of the chip, multicycle paths should not be specified when running timing analysis at tester speed.

The timing analysis should account for possible input delay variations (dithering) on input ports due to tester skew. Input delay specification should support min and max values to model the possible tester skews. Similarly, the output delay specification should support max and min to account for the variations in strobe times (scaling) on the tester.

Figure 10: Tester-Specific Environment

Timing Models for Non-Synthesized Blocks

Blocks which have not been synthesized from library elements (and thus do not naturally contain timing arcs) should be modeled so that paths to, from, and through them can be timed. These blocks may include, RAM, microcontrollers, microprocessors, etc. These blocks are generally too complex to be described as normal primitives in the library, and must be modeled separately. An STA tool should support timing models of such blocks.

Tool Interface Requirements

The timing analyzer must be able to read a variety of netlist formats (e.g., Verilog, EDIF, VHDL) and run in batch mode and, hierarchical timing analysis must be possible. The timing analyzer should be able to build a model for a design block so that it can later be used when the design block is instanced in a top-level design. The tool should also generate synthesis constraints for lower-level blocks.

Summary

Power Xlogic by using  Static-timing analysis provides a complete timing verification solution that addresses the needs of Logic designers and vendors. A static timing sign-off based methodology reduces the overall design cycle time, meaning shorter time-to-market. The comprehensiveness of STA methodology translates to a higher percentage of working silicon. This further reduces time-to-market and time-to-volume along with the reduction in cost associated with silicon iterations.