异步多时钟设计综合与实践技巧

需积分: 10 41 浏览量更新于2024-07-30 收藏 220KB PDF 举报

在设计异步多时钟系统中，理解并有效运用多时钟架构变得至关重要。本文由Clifford E. Cummings撰写，他在Sunburst Design, Inc.工作，针对的是那些在实际应用中广泛存在的多时钟系统设计问题。大多数ASIC设计都依赖于多个异步时钟，这导致了复杂性，因为必须处理数据、控制信号以及确保设计稳定性和正确性的验证。设计纯单时钟同步系统通常被视为奢侈，但在实际的集成电路设计领域，这种情况并不常见。本文首先探讨了为何异步时钟设计如此普遍，因为它们能够适应不同模块间的时间不一致性，提高系统的灵活性和性能。在设计过程中，遇到的主要挑战之一是处理时序相关性和metastability（暂稳态）问题。Metastability指的是电路在不同时钟边缘切换期间可能会出现的不确定状态，这对信号完整性和可靠性构成威胁。为了克服这些挑战，作者分享了他们在硬件设计、时序分析、综合（synthesis）和模拟方法上的实践经验。设计异步多时钟系统时，需要使用特定的技术和脚本语言来协调不同时钟域之间的数据流，例如使用锁存器（FIFOs，First-In-First-Out）来缓冲数据，以避免竞态条件和保持数据一致性。此外，高效的逻辑综合工具需要考虑时钟树优化，包括时钟相移（clock skew）、扇出（fan-out）限制以及有效的逻辑资源分配。文中提到的SNUG-2001会议上的最佳论文评选，反映了该主题在业界的重要性和认可度。这篇论文作为第3名获奖作品，展示了在实际设计流程中如何通过综合技术和脚本编写来简化复杂的设计过程，并提供了一种从经验中学到的方法论，有助于工程师们在面对多时钟系统挑战时，更好地进行设计、实现和验证。总结来说，本文的关键知识点包括异步多时钟系统的设计原则，时序分析中的挑战，如metastability的管理，以及如何通过硬件设计策略、工具和技术（如FIFOs和脚本编程）来确保多时钟系统的设计质量与稳定性。阅读本文，设计师可以了解到如何在现代ASIC设计中有效地应对多时钟环境下的设计和验证问题。

SNUG San Jose 2001 Synthesis and Scripting Techniques for

Rev 1.1 Designing Multi-Asynchronous Clock Designs

4.0

Static Timing Analysis

Performing static timing analysis is the process of verifying that every signal path in a design

meets required clock-cycle timing, whether or not all of the signal paths are even possible. Static

timing analysis is not used to verify the functionality of the design, only that the design meets

timing goals. In theory, timing verification could be accomplished by running exhaustive gate-

level simulations with SDF backannotation of actual timing values after a design is placed and

routed. This is often referred to as dynamic timing verification.

Static timing analysis has three principal advantages over dynamic timing verification: (1) static

timing analysis tools verify every single path between any two sequential elements, (2) static

timing analysis does not require the generation of any test vectors, and (3) static timing analysis

tools are orders of magnitude faster than trying to do timing verification running exhaustive gate-

level simulations[4].

Timing analysis using Synopsys tools on a completely synchronous design is relatively easy to

perform using either DesignTime within the Synopsys Design Compiler or Design Analyzer

environments, or by using PrimeTime.

Timing analysis on modules with two or more asynchronous clocks is error prone, more difficult

and can be time consuming. Static timing analysis on signals generated from one clock domain

and latched into sequential elements within a second, asynchronous clock domain is inaccurate

and for the most part worthless. The timing information for a signal latched by a clock that is

asynchronous to the latched signal is inaccurate because the phase relationship between the

signal and the asynchronous clock is always changing; therefore, the static timing analysis tool

would have to check an infinite number of phase relationships between the signal and

asynchronous clock. The fact is, one must assume that signals that pass from one clock domain to

another at some point will violate either setup or hold times on the destination sequential

element.

There is no good reason to perform timing analysis on signals that are generated in one clock

domain and registered in another asynchronous clock domain. It is a given that these signals DO

violate setup and hold times on the destination register. This is why synchronizers (see section

3.0) are needed, to alleviate the problems that can occur when a signal is passed from one clock

domain to another.

For RTL modules that have two or more asynchronous clocks as inputs, a designer will be

required to indicate to the static timing analysis tool which signal paths should be ignored. This

is accomplished by "setting false paths" on signals that cross from one clock domain to another.

This can be a tedious and error prone job unless the guidelines in the next two sections are

followed.

SNUG San Jose 2001 Synthesis and Scripting Techniques for

Rev 1.1 Designing Multi-Asynchronous Clock Designs

5.0

Clock Naming Conventions

Guideline:

Use a clock naming convention to identify the clock source of every signal in a

design.

Reason:

A naming convention helps all team members to identify the clock domain for every

signal in a design and also makes grouping of signals for timing analysis easier to do using

regular expression "wild-carding" from within a synthesis script.

A number of useful clock naming conventions have been used by various design teams. One that

was used by design engineers in 1995 while designing video ASICs for In Focus projectors

required that a leading prefix character be used to identify the various asynchronous clock

domains. Examples included: uClk for the microprocessor clock, vClk for the video clock and

dClk for the display clock.

Each signal was synchronized to one of the clock domains in the design and each signal-name

had to include a prefix character identifying the clock domain for that signal. Any signal that was

clocked by the uClk would have a u-prefix in the signal name, such as uaddr, udata, uwrite, etc.

Any signal that was clocked by the vClk would similarly have a v-prefix in the signal name, such

as vdata, vhsync, vframe, etc. The same signal naming convention was used for all signals

generated by any of the other clocks in the design.

Using this technique, any engineer on the ASIC design team could easily identify the clock-

domain source of any signal in the design and either use the signals directly or pass the signals

through a synchronizer so that they could be used within a new clock domain.

The naming convention alone contributed significantly to the productivity of the design team.

How do we know there was a productivity gain? One of the design engineers started his part of

the ASIC design using his own naming convention, ignoring the convention in use by the other

design team members. After much confusion about the signals entering and leaving his design

partition, a team meeting was called and the non-compliant designer was "strongly encouraged"

to rename the signals in his part of the design to conform to the team naming convention. After

the signal names were changed, it became easier to interface to the partition in question. Fewer

questions and less confusions occurred after the change.

6.0

Design Partitioning

Guideline:

Only allow one clock per module.

Reason:

Static timing analysis and creating synthesis scripts is more easily accomplished on

single-clock modules or groups of single-clock modules.

Guideline:

Create a synchronizer module for each set of signals that pass from just one clock

domain into another clock domain.

Reason:

It is given that any signal passing from one clock domain to another clock domain is

going to have setup and hold time problems. No worst-case (max time) timing analysis is

required for synchronizer modules. Only best case (min time) timing analysis is required between

剩余25页未读，继续阅读

mfkiass

粉丝: 1
资源: 32

异步多时钟设计综合与实践技巧

多时钟异步系统设计和描述技巧

多时钟异步系统设计实战与脚本技巧

Verilog设计小技巧-综合文档

基于FPGA异步FIFO设计完整报告

基于FPGA的异步FIFO设计与实现.pdf

FPGA硬件最小系统设计-综合文档

VHDL设计技巧：实现单时钟分频器

FPGA设计高级实践：状态机、时钟域与优化技巧

FPGA设计：同步与异步设计中的毛刺消除策略

FPGA可靠与高速设计关键：时钟纯净与单一

最新资源