Understanding the fclk and tck Clock Domains in ARM SoCs
In ARM-based System-on-Chip (SoC) designs, clock domain crossing (CDC) between functional clocks (fclk) and test clocks (tck) is a critical aspect of timing closure and functional correctness. The fclk domain typically operates at the system’s functional frequency, while the tck domain is used for test and debug purposes, often running at a different frequency or being completely asynchronous. The interaction between these domains can lead to metastability issues, data corruption, or timing violations if not properly constrained.
The fclk domain is responsible for the normal operation of the SoC, including processor execution, memory access, and peripheral communication. On the other hand, the tck domain is used during manufacturing testing, debug, and post-silicon validation. The tck domain often interfaces with test access ports (TAPs), scan chains, and other test infrastructure. The relationship between these domains is crucial because test logic must be able to observe and control the functional logic without disrupting its operation.
When signals traverse between the fclk and tck domains, they must be synchronized to prevent metastability. Metastability occurs when a signal is sampled near the clock edge, causing the output to settle to an indeterminate state. This can propagate through the design, leading to functional failures. Additionally, the timing paths between these domains must be constrained to ensure that setup and hold times are met, even when the clocks are asynchronous or have different frequencies.
Challenges in Constraining fclk-to-tck Paths: False Paths vs. Max-Delay
The primary challenge in constraining paths between fclk and tck lies in determining whether to treat these paths as false paths or to apply maximum delay constraints. A false path is a timing path that does not require timing analysis because the signals are never expected to meet setup and hold requirements. This is often the case for asynchronous clock domains where the clocks are not related and the data transfer is controlled by handshake signals or FIFOs.
However, in some cases, applying a maximum delay constraint is more appropriate. This is particularly true when there is a known relationship between the clocks, or when the design includes synchronizers that ensure proper data transfer across the clock domains. The decision between false paths and max-delay constraints depends on the specific design requirements and the nature of the clock domain crossing.
False paths are typically used when the clocks are completely asynchronous and there is no functional requirement for the signals to meet timing. This approach simplifies timing analysis by excluding these paths from consideration. However, it is essential to ensure that the design includes proper synchronization mechanisms to handle metastability.
On the other hand, max-delay constraints are used when there is a known relationship between the clocks, or when the design requires that signals meet specific timing requirements. For example, if the tck domain is derived from the fclk domain through a clock divider, the relationship between the clocks can be used to apply max-delay constraints. This ensures that the timing paths are analyzed and that the design meets the required timing margins.
Implementing SDC Constraints for fclk-to-tck Paths
To properly constrain the paths between fclk and tck, it is essential to understand the clock relationships and the design requirements. The following steps outline the process of implementing SDC (Synopsys Design Constraints) for these paths:
First, identify the clock domains and their relationships. Determine whether the clocks are synchronous, asynchronous, or have a known phase relationship. This information is crucial for deciding whether to apply false paths or max-delay constraints.
Next, analyze the design to identify all paths that cross between the fclk and tck domains. This includes both data paths and control signals. For each path, determine whether it requires synchronization and whether it should be treated as a false path or constrained with a max-delay.
For paths that are determined to be false paths, use the set_false_path command in the SDC file to exclude them from timing analysis. This command tells the timing analyzer to ignore these paths, simplifying the analysis and reducing the risk of false timing violations. For example:
set_false_path -from [get_clocks fclk] -to [get_clocks tck]
set_false_path -from [get_clocks tck] -to [get_clocks fclk]
For paths that require max-delay constraints, use the set_max_delay command to specify the maximum allowable delay for these paths. This ensures that the timing analyzer considers these paths and that they meet the required timing margins. For example:
set_max_delay -from [get_clocks fclk] -to [get_clocks tck] 2.0
set_max_delay -from [get_clocks tck] -to [get_clocks fclk] 2.0
In addition to these constraints, it is essential to include synchronization elements in the design to handle metastability. This typically involves adding synchronizer flip-flops or FIFOs to ensure that signals are properly synchronized when crossing clock domains. The synchronizers should be placed as close as possible to the destination clock domain to minimize the risk of metastability.
Finally, verify the constraints and the design using static timing analysis (STA) and simulation. STA ensures that the timing constraints are met and that there are no setup or hold violations. Simulation, particularly with corner cases and different clock frequencies, helps to validate the design’s functionality and robustness.
By following these steps, designers can effectively constrain the paths between fclk and tck domains, ensuring that the design meets timing requirements and operates correctly across different clock domains. Proper constraint management and synchronization are key to achieving a robust and reliable ARM-based SoC design.
