Graham is VP of Marketing at Real Intent. He has over 20 years experience in the design automation industry. He has founded startups, brought Nassda to an IPO and previously was Sales and Marketing Director at Internet Business Systems, a web portal company. Graham has a Bachelor of Computer … More »
Fundamentals of Clock Domain Crossing Verification: Part Three
July 24th, 2014 by Graham Bell
Last time we looked at design principles and the design of CDC interfaces. In this posting, we will look at practical considerations for designing CDC interfaces.
Verifying CDC interfaces
A typical SOC is made up of a large number of CDC interfaces. From the discussion above, CDC verification can be accomplished by executing the following steps in order:
All verification processes are iterative and achieve design quality by iteratively identifying design errors, debugging and fixing errors and re-running verification until no more errors are detected.
Practical considerations for CDC verification
Effective deployment of CDC tools in the design flow requires due consideration of multiple factors. We have discovered that first-generation CDC tools were not being used effectively in design flows. Based upon feedback from users, we have identified the following factors as the most important considerations for CDC deployment:
There is consistent feedback from the users that the minimization of engineering cost for high-quality verification is critical for effective deployment of the CDC tools.
Coverage of error sources
CDC errors can creep into a design from multiple sources. The first is inadvertent clock-domain crossing where there is an assumption mismatch or oversight at block interfaces. The second is faulty block-level design. The designers, because of oversight or because of the pressure to design correct and high-performance interfaces, can make a design error. As an example, consider the protocol in Figure 12. Here, tapping Feedback Signal from an earlier flop stage can reduce the latency across the interface. But correct operation of this interface requires that the transmitting clock frequency be lower than the receiving clock frequency. Otherwise, it is possible to signal New Data before Load Data is completed.
These two error sources are properly covered by RTL analysis. They can also be covered by netlist analysis. But not all CDC error sources are covered by RTL analysis. This is because CDC errors are dependent upon glitches and hazards. It is a well-known phenomenon that synthesis transformations can introduce hazards in the design. Hazards in CDC logic lead to CDC failures. Figure 13 shows an example of a design failure caused by synthesis. Here, the multiplexor implementation created a logic hazard that violated the multi-cycle path requirement on the data bus. We are aware of multiple design failures because of this phenomenon.
With the increasing complexity of SOCs and the increasing number of CDC interfaces on the chip, the contribution of this risk factor is increasing. As a result, CDC verification must be run on both RTL and netlist views of the design.
Design setup cost
Design setup starts with importing the design. With the increasing complexity of SOCs, designs include RTL and netlist blocks in a Verilog and VHDL mixed-language environment. In addition, functional setup is required for good quality of verification. A typical SOC has multiple modes of operation characterized by clocking schemes, reset sequences and mode controls. Functional setup requires the design to be set up in functionally valid modes for verification, by proper identification of clocks, resets and mode select pins. Bad setup can lead to poor quality of verification results.
Given the management complexity for the multitude of design tasks, it is highly desirable that there be a large overlap between setup requirements for different flows. For example, design compilation can be accomplished by processing the existing simulation scripts. Also, there is a large overlap between the functional setup requirements for CDC and that for static timing analysis. Hence, STA setup, based upon Synopsys Design Constraints (SDCs), can be leveraged for cost-effective functional setup.
Design constraints are usually either requirements or properties in your design. You use constraints to ensure that your design meets its performance goals and pin assignment requirements. Traditionally these are timing constraints but can include power, synthesis, and clocking.
Timing constraints represent the performance goals for your designs. Designer software uses timing constraints to guide the timing-driven optimization tools (synthesis) in order to meet these goals. You can set timing constraints either globally or to a specific set of paths in your design. You can apply timing constraints to:
Correct functional setup of large designs may require setup of a very large number of signals. This cumbersome and time-consuming drudgery can be avoided with automatic setup generation. Also, setup has the first-order effect on the quality of verification. Hence, early feedback on setup quality can lead to easy and effective setup refinement for high quality of verification.
In the next posting we will discuss the costs associated with debugging and sign-off verification .