Useful Skew - Using Clock Skew as a Tool to Achieve Optimal Timing

What is Useful Skew anyway?
Some nonzero skews can become useful by creating safety margins to guard against delay variations (Moving the skews toward the center of the permissible ranges, creating safety margins against potential timing violations).

When we look for optimal design solutions, we need to look at the bigger picture:
What is the problem we're trying to solve in the first place? Is minimizing clock skew the primary goal of our design?
No, the primary goal of any design is to meet the chip's timing requirements. Since logic path delays also determine the timing of a chip, minimizing skew is just one approach to meeting the timing specifications. If we consider skew in the context of chip timing, we would find a larger, multidimensional space in which to search for solutions. Designers can consider skew--much like logic functions, gate sizes, and supply voltages--as a design variable. In that sense, what we're really trying to achieve is not just a good clock design, but rather a closure of timing or a more robust timing of the chip.

More detailed explanation @ (EE Times)

All about Clock skew & Short path

Clock Skew:
Differences in clock signal arrival times across the chip are called clock skew. It is a fundamental design principle that timing must satisfy register setup and hold time requirements. Both data propagation delay and clock skew are parts of these calculations. Clocking sequentially-adjacent registers on the same edge of a high-skew clock can potentially cause timing violations or even functional failures.

Short Path:
The problem of short data paths in the presence of clock skew is very similar to hold-time violations in flipflops. The problem arises when the data propagation delay between two adjacent flip-flops is less than the clock skew.

How to Measure Clock Skew:
The first step in coping with clock skew problems is to measure the clock skew. Users should perform a static timing analysis of the design after place-and-route to determine the amount of clock skew. Timing report gives a better pciture.

The timing report is only valid if the user has specified one or more clock constraints. If the design clocks are not constrained, the report will be empty. The timing report has four sections as follows depending on the type of tool and vendor:
• Header: This section contains software version, design name, operating condition, device type, speed grade and Timer preferences.
• Clock Constraint Violation: This section reports the critical paths limiting any clock frequency constraint set in the General tab window.
• Max Delay Constraint Violation: This section reports the critical paths that are limiting any Max Delay constraint set in the Timer Path tab window.
• Min Delay Constraint Violation: In this section, short data paths that are susceptible to hold-time violations are listed.

In the timing report, the skew of the clock network is taken into account in calculating the slack. The report is sorted by slack for each section; a negative slack indicates a violation. The timing report is created based on the operating conditions set in the timer preferences.
Therefore, to examine the long data paths versus any clock or Max Delay Constraint, the user should export the report while the timer preferences are set to worst case/long paths. On the other hand, to identify all the possible hold-time violations, the report should be created while the timer preferences are set to best case/short paths. Users should note that after each change in the operating conditions in the Timer window, the "calculate delays" option should be selected before exporting the timing violation report.

Minimizing the Clock Skew:
The short-path problem is created by the existence of unacceptably large clock skew. Therefore, minimizing (i.e., nearly removing) the clock skew is the best approach to reduce the risk of short-path problems. Many FPGA devices offer global routing resources, which reduce skew.
If there are any free global resources available on the device, users should assign their clock signals to these resources. Maintaining the clock skew at a value less than the smallest register-to-register delay in the design by using low-skew global resources will improve the robustness of the design against any shortpath
problems.

Comments are most invited.