In this column, we introduce "FPGA technical information that is surprisingly little known but makes a difference if you know it.
The contents are useful for a wide range of people from FPGA beginners to experienced users, so please stay with us to the end.
Part 4: FPGA Defects Compared to ASICs - Asynchronous Clock
Asynchronous clocking is one of the most common problems in FPGAs compared to ASICs.
As a device, FPGAs are no more vulnerable to asynchronous than ASICs, and the reason is that few people do asynchronous verification in FPGA development.
It does not matter because we are verifying on actual devices! If you are thinking, "I verify on actual devices, so it doesn't matter! Asynchronous verification is not possible in actual device verification!
Incidentally, asynchronous clock verification is a common practice in ASIC development.
What is an asynchronous clock error?
An asynchronous clock error is a defect caused by lasing or metastable when data is exchanged between different clocks.
They occur once every few hours, days, weeks, or even decades in actual devices, and cannot be reproduced by timing simulation or actual device verification.
Figure 1: Asynchronous clock circuit example
Figure 2: Metastable of the back-end register
As shown in Figure 1, when data is exchanged between clocks with different frequencies, the timing difference between the clocks and the data may cause data from the previous cycle to be captured at one time and data from the next cycle at another time.
If this is a bus, only some bits will be the previous cycle's data and other bits will be the next cycle's data. By the way, if it's the same clock, it doesn't matter because it verifies the setup and hold timing.
And if the clock comes in during the setup or hold time of a later register, it can become a metastable. Metastable is a very serious problem because it is an indeterminate state (an intermediate potential that is neither "L" nor "H") for several cycles. It is not reproducible on actual equipment.
There is a method to verify by shifting the clock and data back and forth (Clock: Min condition, Data: Max condition / Clock: Max condition, Data: Min condition), but this method is also troublesome because the metastable cannot be verified.
See below for details on metastables.
Why asynchronous clock errors are troublesome
Cannot be verified by "logic simulation!
Cannot be verified by "timing verification!
Cannot be verified by "timing verification"! But, it cannot be reproduced!
To analyze asynchronous clock errors, it is necessary to follow the circuit diagram or use a dedicated tool (CDC: Clock Domain Crossing).
Soft errors" are easily mistaken for asynchronous clock errors.
Some people mistake an asynchronous clock error for a soft error because they cannot figure out the cause of the asynchronous clock error.
If it is a soft error, the error can be "reproduced" if the FPGA is not reconfigured (reconfigured again).
A soft error changes the logic of the circuit, while a metastable does not. If you suspect a soft error, run the same test bench to see if the error can be reproduced.
Selecting a CDC (Clock Domain Crossing) tool
To verify asynchronous clocks, it is recommended to use a CDC tool.
Although the CDC tool itself is easy to use, "checking for pseudo-errors" and "considering countermeasures" can be very difficult, so please note the following points when selecting a CDC tool.
-
Verification must be possible at RTL in the upstream of design!
Verification after logic synthesis takes a lot of man-hours, so it must be able to be verified at RTL. -
The report should be easy to understand! (Because many pseudo-errors are generated.)
When pseudo-errors are generated in tens of thousands of places, important errors are overlooked.
Pseudo-errors require manual verification of the circuit, so easy-to-understand reports are a must.
-
There should be a function to determine if a circuit requires countermeasures!
If an error occurs but does not affect logic, there is no problem.
It is useful to have a function to verify that there is no problem by formal verification or logic simulation.
CDC (Clock Domain Crossing) CDC Free Evaluation Campaign
Ultima is currently conducting a "free" evaluation campaign of your design using CDC.
We will not make any pushy sales pitch, so if you are interested in CDC, please feel free to contact us.
Know the difference! FPGA "Just the Facts" series
Power Consumption
- Part 1: Three Tips for Low Power Consumption
- Part 2: Is Clock Gating (Gated Clock) Effective?
- Part 3: Is this leakage power? No, it is DC power.
- Part 4: Why Precision Power Simulators Were Never Used
- Part 5: Is this the ultimate low-power method?
- Part 6: How to Reduce Load Capacitance (C)
- Part 7: How to Reduce Signal Amplitude (Vs) and Supply Voltage (VCC)
- Part 8: How to reduce the operating frequency (F) and toggle ratio (N).
- Part 9: How to Reduce Short-Circuit Power
- Part 10: How to reduce DC power and leakage power
Verification
- Part 1: What is the first thing to ask designers who are concerned about design quality?
- Part 2: Verification methods not recommended for designs that have already been commercialized.
- Part 3: Verification is a combination of various methods.
- Part 4: FPGAs have more defects than ASICs - Asynchronous clocks.
- Part 5: What is formal verification?