Dominating FPGA clock domains and CDCs

Multiple clock domains in FPGAs have simplified some aspects of designs, allowing effective partitioning of logic. As FPGA architectures get more flexible in how clock domains, regions, or networks are available, the probability of signals crossing clock domains has gone way up.

We know one result: metastability, where a signal crossing two domains with differing clock sources in an unknown relationship results in an indeterminate state. And, we know one way to fix that, at least generally: a couple layers of registering or flip-flops.

But finding a metastable signal manifested in hardware can be a real beast; by the time the problem is observed, it has spread out of control. The task is not much easier in simulators, with the X propagation phenomenon – applying the wrong assumption can unleash artificial issues, or mask a real problem.

If there is only one signal involved, it’s a good day, but that is also increasingly unlikely as domains increase and designs get larger and more complex. Signal re-convergence, where signals arrive from multiple disparate domains with differing characteristics, gets even more difficult. Fixes such as clock oversampling may take care of some of the inbound signals, but not others in the mix.

So, what are designers to do? It’s kind of the old Henny Youngman joke, where the patient goes to the doctor complaining of pain when contorting a limb in a certain manner: “Doctor, it hurts when I do this!” The doctor responds, in deadpan: “Then don’t do that.” (Bit of trivia: that joke was actually stolen from an old Vaudeville act, Smith & Dale, and their “Dr. Kronkheit” sketch – it was made famous in the TV age by Youngman and his trusty violin.)

In other words, the best solution is to find clock-domain crossing (CDC) problems before they start.

Preventing CDCs for FPGA-based designs of any complexity is extremely difficult, but using design rule checking tools, they can be found and categorized for closer review. This can save a ton of time in both debug and remediation.

Ajay Pradhan, product manager at Aldec has been discussing CDC issues in FPGAs, and how design rule checking works to spot them. He has two recent blog posts on the subject:Averting Clock-Domain Crossing issues in FPGA Design
Averting CDC Roadblocks in FPGA Design

He suggests that working backwards to find root cause of CDC problems could end up taking as much or more time than the design itself. By pre-cleaning designs and locating CDC issues early, decisions can be made to either fix the signals or change the partitioning so signals don’t cross domains, or at least do so less contentiously.

Pradhan has just completed a webinar exploring the topic further, archived for your convenience:Static Design Rule Checks in FPGA Design

The linting process in Aldec ALINT starts with automatic design constraint creation, then moves into structural analysis looking for rule violations. ALINT can then be used in conjunction with Aldec Riviera-PRO to provide dynamic simulation and verification, using the constraints.

Design rule checking has many other uses, and is completely extensible by users with rules developed from internal experience and coding standards. It is an important tool that should be in every FPGA designer’s bag to dominate CDCs.

Related articles:

• Because X doesn’t always mark the exact spot
• The never-ending quest to kill metastability