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

需积分: 9 157 浏览量更新于2024-07-28 收藏 194KB PDF 举报

"《多时钟异步系统设计和描述技巧》由Clifford E. Cummings撰写，书中探讨了在ASIC设计中常见的多时钟异步系统设计问题，包括硬件设计、定时分析、综合和仿真策略。这本书是针对实际工程中的多时钟设计需求而编写的，旨在分享作者的经验教训，但不追求全面覆盖所有相关知识。" 在现代数字系统设计中，尤其是在ASIC（应用特定集成电路）领域，多时钟异步系统设计已经成为常态。传统的教育通常侧重于单一时钟同步逻辑的设计方法，但在实际工程实践中，由于各种功能和性能需求，多数设计都涉及到多个异步时钟域。这本书的核心内容主要分为以下几个方面： 1.1 引言作者指出，虽然学术课程中大多教授单一时钟同步逻辑设计，但现实情况是，多数ASIC设计都需要处理多时钟异步问题。本篇论文将介绍一些应对这些问题的具体方法，包括设计、定时分析、综合和仿真等方面的实践策略。 2.0 存 metastability 问题 metastability 是异步系统设计中的关键挑战之一，它指的是在两个不同时钟域之间传输数据时可能出现的不稳定状态。Dally等人的著作中对此有深入讨论， metastability 可能导致数据错误，因此在设计中必须采取措施确保数据在时钟域间的正确转换，如使用同步器（FIFO、寄存器对等）来稳定信号。 3.x 设计技巧书中详细介绍了如何在硬件层面处理多时钟问题，包括时钟门控、时钟树合成、时钟域交叉（CDC，Clock Domain Crossing）设计以及相关的同步电路设计。这些技巧对于减少 metastability 的风险至关重要。 4.x 定时分析在多时钟环境中，定时分析变得复杂，因为不同的时钟域可能导致路径延迟的不同计算。书中会讨论如何进行精确的时序分析，以确保满足设计的时序约束。 5.x 综合策略综合工具在处理异步设计时需要特殊处理，以避免引入不必要的 metastability。作者可能介绍了如何利用脚本语言定制综合过程，以优化时钟域之间的数据流和减少潜在的不稳定点。 6.x 仿真与验证多时钟系统验证是一项艰巨的任务，需要考虑各种时序边界条件。书中可能涵盖如何使用模拟工具和脚本进行有效的异步设计验证，以确保设计的正确性和可靠性。《多时钟异步系统设计和描述技巧》提供了宝贵的实战经验，帮助读者理解并解决实际工程中遇到的多时钟设计挑战。虽然不是一本详尽无遗的指南，但作者的经验分享对任何从事异步系统设计的工程师来说都是极其宝贵的资源。

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页未读，继续阅读

海盗@船长

粉丝: 1
资源: 2

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

设计异步多时钟系统的综合以及描述技巧

异步多时钟FIFOverilog代码

基于多时钟域的异步FIFO设计

多时区时钟的设计实现

PLD设计技巧——多时钟系统设计

EDA大作业--含异步清零和同步时钟的模可变计数器设计（VHDL）

同步的 和 异步的 环型FIFO的VHDL描述

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

FIFO异步设计，包括原理说明和代码分析

FPGA多时钟设计合成与脚本技巧

最新资源

同步的和异步的环型FIFO的VHDL描述