pol_cdc

LedaClock Domain Crossing Rules GuideVersion J-2014.12December 2014

Comments?E-mail your comments about this manual to [email protected].

Copyright Notice and Proprietary InformationCopyright 2014 Synopsys, Inc. All rights reserved. This software and documentation contain confidential and proprietary information that is the property of Synopsys, Inc. The software and documentation are furnished under a license agreement and may be used or copied only in accordance with the terms of the license agreement. No part of the software and documentation may be reproduced, transmitted, or translated, in any form or by any means, electronic, mechanical, manual, optical, or otherwise, without prior written permission of Synopsys, Inc., or as expressly provided by the license agreement.

Destination Control StatementAll technical data contained in this publication is subject to the export control laws of the United States of America. Disclosure to nationals of other countries contrary to United States law is prohibited. It is the readers responsibility to determine the applicable regulations and to comply with them.

DisclaimerSYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

Registered Trademarks ()Synopsys, AMPS, Arcadia, C Level Design, C2HDL, C2V, C2VHDL, Cadabra, Calaveras Algorithm, CATS, CSim, Design Compiler, DesignPower, DesignWare, EPIC, Formality, HSPICE, Hypermodel, iN-Phase, in-Sync, Leda, MAST, Meta, Meta-Software, ModelAccess, ModelTools, NanoSim, OpenVera, PathMill, Photolynx, Physical Compiler, PowerMill, PrimeTime, RailMill, Raphael, RapidScript, Saber, SiVL, SNUG, SolvNet, Stream Driven Simulator, Superlog, System Compiler, Testify, TetraMAX, TimeMill, TMA, VCS, Vera, and Virtual Stepper are registered trademarks of Synopsys, Inc.

Trademarks ()abraCAD, abraMAP, Active Parasitics, AFGen, Apollo, Apollo II, Apollo-DPII, Apollo-GA, ApolloGAII, Astro, Astro-Rail, Astro-Xtalk, Aurora, AvanTestchip, AvanWaves, BCView, Behavioral Compiler, BOA, BRT, Cedar, ChipPlanner, Circuit Analysis, Columbia, Columbia-CE, Comet 3D, Cosmos, CosmosEnterprise, CosmosLE, CosmosScope, CosmosSE, Cyclelink, Davinci, DC Expert, DC Expert Plus, DC Professional, DC Ultra, DC Ultra Plus, Design Advisor, Design Analyzer, Design Vision, DesignerHDL, DesignTime, DFM-Workbench, DFT Compiler, Direct RTL, Direct Silicon Access, Discovery, DW8051, DWPCI, Dynamic-Macromodeling, Dynamic Model Switcher, ECL Compiler, ECO Compiler, EDAnavigator, Encore, Encore PQ, Evaccess, ExpressModel, Floorplan Manager, Formal Model Checker, FoundryModel, FPGA Compiler II, FPGA Express, Frame Compiler, Galaxy, Gatran, HDL Advisor, HDL Compiler, Hercules, Hercules-Explorer, Hercules-II, Hierarchical Optimization Technology, High Performance Option, HotPlace, HSPICE-Link, iN-Tandem, Integrator, Interactive Waveform Viewer, i-Virtual Stepper, Jupiter, Jupiter-DP, JupiterXT, JupiterXT-ASIC, JVXtreme, Liberty, Libra-Passport, Library Compiler, Libra-Visa, Magellan, Mars, Mars-Rail, Mars-Xtalk, Medici, Metacapture, Metacircuit, Metamanager, Metamixsim, Milkyway, ModelSource, Module Compiler, MS-3200, MS-3400, Nova Product Family, Nova-ExploreRTL, Nova-Trans, Nova-VeriLint, Nova-VHDLlint, Optimum Silicon, Orion_ec, Parasitic View, Passport, Planet, Planet-PL, Planet-RTL, Polaris, Polaris-CBS, Polaris-MT, Power Compiler, PowerCODE, PowerGate, ProFPGA, ProGen, Prospector, Protocol Compiler, PSMGen, Raphael-NES, RoadRunner, RTL Analyzer, Saturn, ScanBand, Schematic Compiler, Scirocco, Scirocco-i, Shadow Debugger, Silicon Blueprint, Silicon Early Access, SinglePass-SoC, Smart Extraction, SmartLicense, SmartModel Library, Softwire, Source-Level Design, Star, Star-DC, Star-MS, Star-MTB, Star-Power, Star-Rail, Star-RC, Star-RCXT, Star-Sim, Star-SimXT, Star-Time, Star-XP, SWIFT, Taurus, Taurus-Device, Taurus-Layout, Taurus-Lithography, Taurus-Process, Taurus-Topography, Taurus-Visual, Taurus-Workbench, TimeSlice, TimeTracker, Timing Annotator, TopoPlace, TopoRoute, Trace-On-Demand, True-Hspice, TSUPREM-4, TymeWare, VCS Express, VCSi, Venus, Verification Portal, VFormal, VHDL Compiler, VHDL System Simulator, and VMC are trademarks of Synopsys, Inc.

Service Marks (SM)MAP-in, SVP Caf, and TAP-in are service marks of Synopsys, Inc.

SystemC is a trademark of the Open SystemC Initiative and is used under license.ARM and AMBA are registered trademarks of ARM Limited.All other product or company names may be trademarks of their respective owners.

3Contents

Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7About this Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

How Rules are Organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Manual Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Typographical and Symbol Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Getting Leda Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9The Synopsys Web Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Chapter 1Clock Domain Crossing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Clock domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Meta-stability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Guidelines for Effective CDC Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Clock Inference with Clock Gating Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Synchronization Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Synchronization of Control Signals with 2-FF Synchronizers . . . . . . . . . . . . . 18

Input Data Stability to Avoid Data LossGray Encoding to Avoid Data Incoherence (For Vector CDC Control Signals)

Synchronization of CDC Data Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Passing Data through MUX Synchronizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Handshaking Data between Clock Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Passing Data by FIFO between Clock Domains . . . . . . . . . . . . . . . . . . . . . . . . 22User-defined Synchronizers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

CDC Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Structural Analysis to Identify CDC Signals and appropriate Synchronizers . . 24Structural Analysis to Identify Structural Defects before and after Synchronization

24Convergence in the Crossover PathDivergence in the Crossover PathDivergence of Meta-stable SignalRe-convergence of Synchronized SignalsDetermination and Validation of appropriate Properties for every Synchronizer

Leda - CDC Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Automatically Generated CDC Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4Contents

Synchronizers Identified by Leda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Flip-flop Synchronizers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

DescriptionImplementation

MUX Synchronizers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33DescriptionImplementation

Handshake Synchronizers (Push) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34DescriptionImplementation

Dual Clock FIFO Synchronizers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37DescriptionImplementation

Complex Synchronizers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Quasi Static Signal for Identifying Double FF Synchronizer . . . . . . . . . . . . . . . . . 42

ExampleGray Code Encoding for Vector Control Signals . . . . . . . . . . . . . . . . . . . . . . . . . . 43

DescriptionImplementation

CDC AEP Rule Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Naming Convention for Automatically Generated CDC AEP Files . . . . . . . . . . . . 47

Binding the Assertion Definitions to the Design . . . . . . . . . . . . . . . . . . . . . . . . 47Using Generated Assertions in VCS and Magellan . . . . . . . . . . . . . . . . . . . . . . 48Failure Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Configuring Latches in CDC Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49CDC Tcl Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

set_cdc_ignored_path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Support of Wildcard in set_cdc_ignored_path Command

set_cdc_synchronizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52set_cdc_input_delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53extract_cdc_info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53report_cdc_info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54clear_cdc_info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54set_cdc_parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Chapter 2Clock Domain Crossing Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57CDC Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58CDC Ruleset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5Contents

NTL_CDC00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59NTL_CDC01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Message: No synchronization scheme found for signalscrossing clock domains

NTL_CDC01_0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Message: Flip-flop Synchronizer detected

NTL_CDC01_1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Message: Logic Synchronizer detected

NTL_CDC01_3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Message: Complex Synchronizer detected

NTL_CDC01_4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Message: User-Defined Synchronizer detected

NTL_CDC01_5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Message: Fifo Synchronizer detected

NTL_CDC01_6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Message: Handshake Synchronizer detected

NTL_CDC02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Message: Convergence found in clock domain crossing path

NTL_CDC03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Message: Divergence found in clock domain crossing path

NTL_CDC04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Message: Divergence of meta-stable signal detected

NTL_CDC05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Message: Convergence between signals coming from different synchronizers

NTL_CDC06 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Message: CDC control signal must be stable enough (property generated)

NTL_CDC07 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Message: Reconverging control path detectedDetailed Explanations for Rules NTL_CDC05 and NTL_CDC07

NTL_CDC08 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Message: Multiple CDC control signals must be gray coded, property generatedDifference between rules NTL_CDC07 and NTL_CDC08 :

NTL_CDC09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Message: CDC control signal must not be part of a BUS

NTL_CDC10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Message: Different clock polarity FFs in the simple synchronizer

NTL_CDC11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Message: One of the FFs in a 2-FF simple synchronizer has a gated clock (single-bit CDC signal)

NTL_CDC12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Message: A vector is synchronized by a set of 2-FF simple synchronizers where one of the 2-FF synchronizers has a gated clock FF

NTL_CDC13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Message: There exists an unscented control path driven by a CDC asynchronous reset signal

6Contents

NTL_CDC14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Message: Control and Data Signals of a MUX (Logic) Synchronizer must be Stable Enough (Property Generated)

NTL_CDC15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Message: A Handshake Synchronizer Must Implement The Handshake Protocol and Data Stability Correctly (Property Generated)

NTL_CDC16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Message: A FIFO Synchronizer Must Implement the FIFO Protocol and Data Stability Correctly (Property Generated)

7Preface

Preface

About this ManualThis book contains reference information for prepackaged rules that come with the Leda Checker tool. This information mirrors the information available in the HTML-based help files that you access directly from the Leda Checker tools Error Report. The purpose of this book is to provide a reference that you can view online or print out so that you can review available prepackaged rules and decide which ones you want to use before running the Checker tool on your HDL source files. On the other hand, the HTML-based help system is designed to provide random access to this same information from the Checker Error Report, so that you can quickly access more information about a specific rule that was violated, including in some cases, circuit diagrams and valid and invalid examples of Verilog or VHDL code.

This book is intended for use by hardware design and quality assurance engineers who are already familiar with VHDL or Verilog.

How Rules are OrganizedRules are organized into major categories called policies, which have multiple rulesets. Each ruleset can contain multiple rules. You use the prepackaged rules to check your VHDL or Verilog source code for compliance with various standards and compatibility with downstream tools in the design and verification flow. Some rules apply just to Verilog or VHDL and some apply to both HDLs. The documentation for each rule, both in the HTML-based help system and in this manual clearly labels which languages each rule applies to.

NoteThere is a separate book for each policy (set of prepackaged rules) that Leda supports.

8Preface

Related DocumentsThis manual is part of the Leda document set. To see a complete listing or to navigate to another online document in the set, refer to the Leda Document Navigator.

Manual OverviewThis manual contains the following chapters:

Typographical and Symbol ConventionsThe following conventions are used throughout this document:

Preface Describes the manual and lists the typographical conventions and symbols used in it; explains how to get technical assistance.

Chapter 1Clock Domain Crossing

Detailed information of Clock Domain Crossing.

Chapter 2Clock Domain Crossing Rules

Detailed information about CDC rules.

Table 1: Documentation Conventions

Convention Description and Example

% Represents the UNIX prompt.

Bold User input (text entered by the user).% cd $LMC_HOME/hdl

Monospace System-generated text (prompts, messages, files, reports).No Mismatches: 66 Vectors processed: 66 Possible"

Italic or Italic Variables for which you supply a specific value. As a command line example:% setenv LMC_HOME prod_dir

In body text:In the previous example, prod_dir is the directory where your product must be installed.

| (Vertical rule) Choice among alternatives, as in the following syntax example:-effort_level low | medium | high

9Preface

Getting Leda HelpFor help with Leda, send a detailed explanation of the problem, including contact information, to [email protected].

The Synopsys Web SiteGeneral information about Synopsys and its products is available at this URL:

http://www.synopsys.com

[ ] (Square brackets) Enclose optional parameters:pin1 [pin2 ... pinN]

In this example, you must enter at least one pin name (pin1), but others are optional ([pin2 pinN]).

TopMenu > SubMenu Pulldown menu paths, such as:File > Save As

Table 1: Documentation Conventions (Continued)

Convention Description and Example

10

Preface

. 11

Chapter 1: Clock Domain Crossing

1Clock Domain Crossing

OverviewAs modern System-on-Chip (SoC) designs continue to face increasing size and complexity challenges, multiple asynchronous clock domains have been employed for different I/O interfaces. A CDC-based (Clock Domain Crossing) design is a design that has one clock asynchronous to, or has a variable phase relation with, another clock. A CDC signal is a signal latched by a flip-flop (FF) in one clock domain and sampled in another asynchronous clock domain. Transferring signals between asynchronous clock domains may lead to setup or hold timing violations of flip-flops. These violations may cause signals to be meta-stable. Even if synchronizers could eliminate the meta-stability, incorrect use, such as convergence of synchronized signals or improper synchronization protocols, may also result in functional CDC errors. Functional validation of such SoC designs is one of the most complex and expensive tasks. Simulation on register transfer level (RTL) is still the most widely used method. However, standard RTL simulation can not model the effect of meta-stability.

Within one clock domain, proper static timing analysis (STA) can guarantee that data does not change within clock setup and hold times. When signals pass from one clock domain to another asynchronous domain, there is no way to avoid meta-stability since data can change at any time.

As the CDC errors are not addressed and verified early in the design cycles, many designs exhibit functional errors only late in their design cycles or during post-silicon verification. Several coverage metrics are proposed to measure the validation's adequacy and progress, such as code based coverage, finite state machine coverage, and functional coverage. Nevertheless, these coverage metrics do not have direct relations with CDC issues.

To address clock domain problems due to meta-stability and data sampling issues, designers typically employ several types of synchronizers. The most commonly used synchronizer is based on the well-known two-flip-flop circuit. Other types of

12


synchronizers are based on handshaking protocols or FIFOs. In a limited number of cases it may be useful to employ dual-clock FIFO buffers or other mechanisms optimized for domains with similar clock frequencies.

To accurately verify clock domain crossings, both structural and functional CDC analysis should be carried out. Structural clock domain analysis looks for issues like insufficient synchronization, or combinational logic driving flip-flop based synchronizers. Functional clock domain analysis uses assertion-based verification to check the correct usage of synchronizers. Assertions may be used to find problems such as data stability violations when going from a fast clock domain to a slower one. Assertions generated in PSL or other assertion languages such as OpenVera or SystemVerilog, can then be used in formal model checking or simulation.

This chapter is organized in the following sections:

Background - Prepares the background required for further discussions.

Synchronization Techniques - Discusses the synchronization techniques.

CDC Analysis - Discusses the various steps of CDC analysis.

Leda-CDC Flow - Provides information on the basic Leda-CDC tool flow.

Automatically Generated CDC Assertions - Provides a detailed specification of the Leda supported assertions.

Synchronizers Identified by Leda - Describes the types of synchronizers identified by Leda.

CDC AEP Rule Usage & Naming Conventions for Automatically Generated CDC AEP Files - Provides further detail of assertion related topics.

CDC Tcl Interface - Provides information about CDC Tcl Interface.

. 13


Background

Clock domainA clock domain is a part of a design that has a clock that operates asynchronous to, or has a variable phase relationship with, another clock in the design. For example, a clock and its derived clock (via a clock divider) are in the same clock domain because they have a constant phase relationship. But, 50MHz and 37MHz clocks (whose phase relationship changes over time) define two separate clock domains. Figure 1 illustrates three different clocks in a design, but synchronous to each other. CLK, its inversion and D1 (derived from CLK) are synchronous to each other.

Figure 1: Synchronous Clock

A clock domain crossing signal is a signal from one clock domain that is sampled by a register in another clock domain. More details of the clock origin/domain inference engine are given in [1].

14


Meta-stabilityEvery flip-flop (FF) that is used in any design has a specified setup and hold time, or the time in which the data input is not legally permitted to change before and after a sampling clock edge. This time window is specified as a design parameter precisely to keep a data signal from changing too close to another synchronizing signal that could cause the output to go meta-stable.

Figure 2: Setup and hold time of a Flip-flop

However, if some input (say d in Figure 2) violates the setup and hold time of a FF, the output of the FF (q in Figure 2) keeps oscillating for an indefinite amount of time. This unstable value may or may not non-deterministically converge to a stable value (either 0 or 1) before the next sampling clock edge arrives.

Example - Consider the 1-bit CDC signal adat, which is sampled by register bdat1 in Figure 3. Since adat comes from a different clock domain (aclk), its value can change at any time with respect to bdat1's clock (bclk). If the value of adat changes during bdat1's setup and hold time, the register bdat1 might/might not assume a state between 0 and 1.

clk

d

q

setup hold

metastable

. 15


In this state, the register is said to be meta-stable. A meta-stable register may/may not (unpredictably) settle to either 0 or 1, causing illegal signal values to be propagated throughout the rest of the design.

Figure 3: Meta-stability scenario

In a multi-clock design, meta-stability is inevitable, but there are certain design techniques that help to avoid the chance of getting meta-stable.

Guidelines for Effective CDC VerificationProper CDC (Clock Domain Crossing) verification needs careful building of verification environment. One of the primary requirements of CDC verification is to have proper clock domain extraction. If the clock domain extraction is wrong, CDC verification would lead to false results. To ensure that clock domains have been extracted correctly from a complex design, follow these steps:

Proper set_case_analysis values and clock gating cell settings - In general, most of the logic in clock path includes MUXs and clock gating cells. By providing appropriate information, you can reduce the number of clock origins that Leda infers for a clock path having complex logic. The following paragraphs describes how to handle these two combinational logics in Leda:

MUX

A MUX is used to select one of the multiple clocks in its fan-in cone. In a single CDC checking, this selection needs to be static. If you do not provide any selection value during the checks, Leda infers a new clock origin at the output of the MUX.

aclk

bclk

adat

bdat1

adat changing

Clocked signal is initially Metastable and is still metastable on the next active clock edge

16


Therefore, if you intent to pass only one clock origin at the output of the MUX, you need to provide the exact value of the 'MUX select signal' to using 'set_case_analysis'. An example of set_case_analysis value setting is given below.

set_case_analysis 0 top.mod1.mux_sel (full hierarchical name of the MUX select signal)

In this case, you can choose to pass clock at input 0 of the MUX to MUX output.

For more information about set_case_analysis, see the Leda User Guide. For information about clock gating cell, see the next section.

Proper BBOX settings - In complex designs, multiple memory blocks, analog blocks, third party IPs are commonly used. There form portions of the design that may not need CDC analysis. You should properly set these modules as Black-boxes in Leda for proper CDC checks. For more information about setting black-boxes in Leda, see the Leda User Guide.

Grouping of Leda extracted clock origins - Leda, as a static checker, uses an algorithm while detecting clock sources (or clock origins) in the design. Therefore, Leda might detect larger number of clock origins. These extra clock origins are usually output of combinational blocks in the clock path of various design clock sources. You need to group these extra origins to appropriate clock sources to extract proper clock domain crossing paths.

Clk1

Clk2

Clk3

mux_sel

. 17


ExampleSuppose in a design, four clock origins - top.clk1, top.internal1, top.internal2, top.clk2 have been extracted. However, you intent to generate only two clocks top.clk1 and top.clk2. In this case, you need to provide the following clock grouping to Leda.

set_clock_groups -name CLK1 -asynchronous -group {\top.clk1 \top.internal1 \}set_clock_groups -name CLK2 -asynchronous -group {\top.clk2 \top.internal2 \}

Clock Inference with Clock Gating CellsLeda treats clock gating cell as special cells that you can use in a clock path to control the operation of some sub parts of the design. A clock gating cell can have multiple inputs. One of these inputs is marked as a clock pin (clock_gating_clock_pin). The other pins include 'enable pin', etc.

If a clock gating cell is present in the clock path of a FF, then the output of that cell is not considered as a clock origin (specifically a 'gated clock origin'). Instead, the signal that is connected to the 'clock' pin of the cell is treated as the clock origin of this FF clock pin.

The following figure gives an example scenario of this:

FF2

FF1

clk out1clock_gating_cell

18


In this example, for standard clock gating cell, Leda infers signal clk as clock origin and not the signal out1. Even if FF1 is not there, Leda would still infer signal clk as clock origin.

Synchronization TechniquesThe main responsibility of a synchronizer is to allow sufficient time such that any meta-sable output can settle down to a stable value in the destination clock domain. The most common synchronizer used by designers is two-flip-flop (2-FF) synchronizers as shown in Figure 4. Usually the control signals in a design are synchronized by 2-FF synchronizers.

Figure 4: A 2-FF synchronizer

Synchronization of Control Signals with 2-FF Synchronizers

In a 2-FF synchronizer, the first flip-flop samples the asynchronous input signal into the destination clock domain and waits for a full destination clock cycle to permit any meta-stability on the stage-1 output signal to decay, then the stage-1 signal is sampled by the same clock into a second stage flip-flop, with the intended goal that the stage-2 signal is now a stable and valid signal synchronized into the destination clock domain. It is theoretically possible for the stage-1 signal to still be sufficiently meta-stable by the time the signal is clocked into the second stage to cause the stage-2 signal to also go meta-stable.

However, note that the meta-stability is a probabilistic phenomenon. The meta-stable output converges to a stable value with time. Therefore, even if the input to the stage-2 FF still remains meta-stable, the probability that the output of the stage-2 FF will remain meta-stable for a full destination clock cycle is asymptotically close to zero. This calculation of the probability of the time between synchronization failures (MTBF) is a

dat bdat2bdat1adat

aclkbclk

. 19


function of multiple variables including the clock frequencies used to generate the input signal and to clock the synchronizing flip-flops. For most synchronization applications, a 2-FF synchronizer is sufficient to remove all likely meta-stability.

Even if a 2-FF synchronizer helps to prevent propagation of meta-stable values, for the correct operation of the design, some other issues needs to be tackled. These issues are explained in the following sections.

Input Data Stability to Avoid Data LossA synchronizer circuit ensures avoiding propagation of meta-stability into the destination clock domain, but it can't ensure propagation of correct value as the meta-stable signal non-deterministically converges to any stable value (1 or 0). However, for correct operation of the design, every transition on the input signal needs to be correctly propagated to the destination domain. To ensure preventing data loss (losing input transitions), the input signal needs to hold its value a minimum amount of time such that there is at least a single destination sampling clock edge, which samples the input value correctly (No setup/hold violation; Figure 5 gives such an example). This stability condition on the input signal is usually checked by putting assertions. For more information, see the section Flip-flop Synchronizers.

Figure 5: Stability of input signal value

Gray Encoding to Avoid Data Incoherence (For Vector CDC Control Signals)Similar to the case of syncing a single bit control signal, the natural way to transfer a vector control signal is to model each bit of the vector to be separately synchronized by a FF synchronizer. You have already seen that even if you use FF synchronizers, it usually takes more than one cycle to propagate correct input values to the destination domain. Now consider a case where every bit of the vector takes a transition very close to the destination clock edge. Also assume that, by virtue of meta-stability, only some of

adat

bdat1

bclk

Keep values stable

Correct value propagated

20


these transitions are correctly captured by the destination domain in the first cycle. Now, if the bit values of the vector decide the state of the destination domain, after the first cycle, the destination domain may move into an invalid state.

Figure 6: Scenario indicating Data Incoherence

Example - Suppose a vector control signal Sig [2:0] crosses from Domain 1 to Domain 2. Signal Sig also decides the state of Domain 2 and you assume that the value "100" of Sig [2:0] indicates an invalid state for Domain 2. Now, think of a situation, where the signal Sig wants to change its value from "000" to "101" (both indicate valid states). This requires the two bits Sig [0] and Sig [2] to transit simultaneously. Both these transition occurs very close to the destination sampling clock edge (see Fig 6). By virtue of meta-stability, transition on Sig [2] gets captured correctly and the transition on Sig [0] is missed. In this way, in the first cycle of the destination clock, the system moves to state "100" which is invalid.

This case would not have happened, if changing the states of the design requires changing only a single bit of the vector (Sig in this case). In case of a single bit transition, either that transition would be captured in the destination domain or not. This way the design either stays in the previous state or move to a valid state. Therefore, for vector control signals (multi-bit signals, such as address buses), the usual solution is to use a Gray code when crossing a clock domain boundary. A Gray code ensures that only a single bit changes as the bus counts up or down. The presence of gray coding on vector control signal can be checked by using assertions. For more information, see the section Gray Code Encoding for Vector Control Signals.

Invalid state

Sig [2]

dSig [2]

dclk

Sig [0]

Sig [1]

dSig [1]

dSig [0]

. 21


Synchronization of CDC Data SignalsOne of the challenges in designing a multi-clock based system is to enable correct transfer of data buses from one clock domain to another. The difficulty arises, as individual bits of a data bus can change randomly while changing clock boundaries. Using synchronizers/gray code to handle the passing of data bus is generally unacceptable.

Three common methods for synchronizing data between clock domains are:

Using MUX based synchronizers.

Using Handshake signals.

Using FIFOs (First In First Out memories) to store data with one clock domain and to retrieve data with another clock domain.

Passing Data through MUX SynchronizerAs shown in the following figure (Figure 7), in a MUX synchronizer, the control path is usually FF-synchronized while the synced-in control signal is used to synchronize the data paths.

Figure 7: A MUX synchronizer

clk1

22


Handshaking Data between Clock DomainsData can be passed between clock domains using a set of handshake control signals, depending on the application and the paranoia of the design engineer. When it comes to handshaking, the more control signals that are used, the longer the latency to pass data from one clock domain to another. The biggest disadvantage in using handshaking is the latency required to pass and recognize all of the handshaking signals for each data word that is transferred. Figure 8 shows a typical handshake synchronizer.

Figure 8: A Handshake Synchronizer

For many open-ended data-passing applications, a simple two-line handshaking sequence is sufficient. The sender places data onto a data bus and then synchronizes a "req" signal (request) to the receiving clock domain. When the "req" signal is recognized in the destination clock domain, the receiver clocks the data into a register (the data should have been stable for at least two/three sampling clock edges in the destination clock domain) and then passes an "ack" signal (acknowledgement) through a synchronizer to the sender. When the sender recognizes the synchronized "ack" signal, the sender can change the value being driven onto the data bus.

Passing Data by FIFO between Clock DomainsOne of the most popular methods of passing data between clock domains is to use a FIFO. A dual port memory is used for the FIFO storage. One port is controlled by the sender, which puts data into the memory as fast as one data word (or one data bit for serial applications) per write clock. The other port is controlled by the receiver, which pulls data out of memory; one data word per read clock. Two control signals are used to indicate if the FIFO is empty, full, or partially full. Two additional control signals are frequently used to indicate if the FIFO is almost full or almost empty. In theory, placing

. 23


data into a shared memory with one clock and removing the data from the shared memory with another clock seems like an easy and ideal solution to passing data between clock domains. For the most part it is, but generating accurate full and empty flags can be challenging.

Figure 9: A dual-clock FIFO Synchronizer

User-defined SynchronizersSometimes, you may specify some cells to be synchronizers. If this cell is found on the path between the FF, the path has to be considered as synchronized. Note that the cell itself may have other inputs than the source flip-flop as shown in the following illustration. The way of specifying a synchronizer is explained in chapter 2, section Using Tcl Command 'set_cdc_synchronizer'.

Figure 10: User-defined Synchronizer

24


CDC AnalysisFollowing are the basic steps for CDC analysis and checking (irrespective of toolset implementation):

Structural Analysis to Identify CDC Signals and appropriate Synchronizers

The most important task of any CDC structural analyzer is to find out all the signals (CDC) that cross clock boundaries. In Leda, rule NTL_CDC01 (For more information, see the section CDC Ruleset in chapter 2.) reports all the un-synchronized CDC paths. However a CDC path may be synchronized in the destination clock domain. Thus, identification of synchronization schemes is very important to avoid reporting false CDC reports. Automatic detection of synchronizers is very tough and may depend on the underlying design principle. Therefore, sometime, the designer needs to provide additional information for the underlying synchronization schemes.

Once extraction of information for all the CDC paths (synchronized and un-synchronized) is over, you need to see whether there are structural defects before and after the synchronizers.

Structural Analysis to Identify Structural Defects before and after Synchronization

Many design teams choose a few synchronizer styles, apply them to all signals crossing clock domains and enforce their usage by design style rules and design reviews. Although proper synchronizers are essential for multi-clock designs, they are insufficient to avoid all possible problems regarding signals crossing clock domains. Considerable extra care must be taken in the design process to avoid these problems. Some of the structural problems that may cause functional errors in multi-clock based systems are as follows.

Convergence in the Crossover PathUsing combinational elements in a CDC path before synchronization can lead to functional problems. For example, it is important that glitches in the driving clock domain not be propagated into the receiving clock domain. Since the flip-flops in the receiving clock domain can sample the signals from the driving clock domain at any point, there is no way through static timing analysis to ensure that the glitch will not be

. 25


propagated. Figure 11 shows an example of combinational logic (convergence) that could cause a glitch to pass from one clock domain to another. Rule NTL_CDC02 detects this issue.

Figure 11: Glitch propagation due to convergence in CDC Path

NoteOne of the possible ways to avoid this problem is to register the output of the AND gate which is clocked by (source domain) CLK1. It is better to have the n-FF CDC synchronizer where FF driven from CLK1 domain need to be directly connected to the 2-FF synchronizer clocked by CLK2.

a a

b b

out out1

a

out

CLK1

b

b

a

CLK2

out1

26


Divergence in the Crossover PathDesign styles which allow divergent logic on a CDC signal to multiple synchronization paths, may cause functional errors. As Figure 12 illustrates, a single control signal (Trans_en) from the source clock domain (clk1) is used to activate both the "addr" and "data" transfer unit in the destination clock domain (clk2). The purpose is to enable both the logics at the same time. To model this, fan-outs of Trans_en has been used before the synchronization takes place. However, due to the propagation delay and different meta-stable settling times, the two fan-outs ('addr_en' and 'data_en') could reach the Address and Data transfer logics at different times. Therefore these two logics may start at different time causing functional errors. This type of structure should be avoided by fanning out a single FF synchronized 'common enable' signal to the two transfer logics. Rule NTL_CDC03 detects this issue.

Figure 12: Divergence in the crossover path

FF0

FF1 FF2

FF3 FF4

Address Transfer Logic

Data Transfer Logic

adr_en_sync

data_en_sync

Trans_en

clk2

clk1

. 27


Divergence of Meta-stable SignalUsing a meta-stable signal in a design can be erroneous. Therefore multiple fan-out of the output of the first FF of a FF synchronizer can cause functional errors. Rule NTL_CDC04 detects this issue.

Figure 13: Divergence of meta-stable signal

FF0 FF1 FF2

Other Logic

clk2clk1

28


Re-convergence of Synchronized SignalsSynchronization and glitch elimination alone are not enough to ensure reliable transfer of data across clock domains. When a signal goes meta-stable, a synchronizer settles it down, but cannot guarantee the precise number of cycles before the valid signal is available in the receiving clock domain. Therefore, if (1) two independent signals or (2) bits of a multi-bit signal are independently synchronized (using same type of synchronizers or different types of synchronizers), the bits may arrive in the receiving clock domain skewed with respect to one another. A very simple form of re-convergence is shown in Figure 14. Rule NTL_CDC05 and NTL_CDC07 detect this issue.

Figure 14: The simplest form of re-convergence

Therefore, even when meta-stability does not occur, any pair of bits can get out of synchronization if routing differences and electrical effects cause the two bits to have different delays before reaching their respective synchronizers. It is possible for one synchronizer to sample its input and capture a signal change before the other synchronizer captures the change, at which point the two copies of the signal will be skewed by a cycle and no longer correlated.

NoteOne of the possible ways to avoid this problem is to have the distinction between control and data logic synchronization mechanism or to use the gray encoding circuit at the time of convergence (after the synchronization).

CLKA

CLKA

ASig1 SSig1

CLKB

CLKB

ASig2 SSig2

L

O

G

I

C

. 29


Leda has six rules that check all the above structural checks for CDC signals. The purpose of these rules is to provide the following information. Detailed description of all the Leda structural checks is provided in chapter 2.

a. NTL_CDC01 - Reports all the unsynchronized CDC paths in the design.

b. NTL_CDC02 - Reports all convergence in the crossover paths in the design.

c. NTL_CDC03 - Reports all divergence in the crossover paths in the design.

d. NTL_CDC04 - Reports divergence of any meta-stable signal in the design.

e. NTL_CDC05/07/08 - Reports all kinds of re-convergence of synchronized signals in the design. There is a subtle difference between rule NTL_CDC05, NTL_CDC07, and NTL_CDC08. For more information about the difference, see the section CDC Ruleset in chapter 2.

Determination and Validation of appropriate Properties for every SynchronizerJust having a synchronization circuit connected is only part of the solution; the associated logic must interact correctly with the synchronization circuit to ensure valid operation. To ensure this, assertions need to be specified that check correct functionality of the synchronization circuits and validates correct use of the synchronizers by the environment in which they are instantiated. You automatically specify these properties once for every synchronizer and automatically attach them to all instances of the corresponding synchronization building blocks. The supported property checks for CDC synchronization circuit elements are given as follows. For more information about these property specifications, see the section Automatically Generated CDC Assertions.

Flip-flop Synchronizer Control signal stability assertions

MUX Synchronizer Control signal stability assertions

Data signal stability assertions

Handshake Synchronizer Control signal stability assertions

Data signal stability assertions

Handshake protocol check assertions

30


FIFO Synchronizer Control signal stability assertions

Gray coded assertions for read and write pointers

FIFO protocol (full/empty check) assertions

Data integrity checks

A more complete description of the CDC AEP (automatically extracted properties) usage is given in the section CDC AEP Rule Usage.

Leda - CDC FlowThe complete Leda CDC flow is given in Figure 15. The main CDC related modules have been colored. The CDC verification engine takes help of the Magellan/VCS for checking the Leda CDC assertions (statically/dynamically).

Figure 15: The complete Leda CDC flow

RTL

Hardware Inference

Netlist Generation

Clock origin/domain Inference

CDC information Extraction

Verify CDC Magellan/VCS

Error Fix

. 31


Automatically Generated CDC AssertionsStructural analysis primarily checks whether there exists a synchronizer in the CDC paths. Having a synchronizer connected only solves the verification problem partially. You additionally need to check the following two features.

1. The environment (associated logic) must interact properly with the synchronizer.

2. The synchronizer itself behaves correctly.

These two checks are mandatory to ensure valid operation in real life. The AEP (automatically extracted properties) engine of Leda generates and binds assertions that check correct functionality of the synchronizers and validates correct use of the synchronizers by its environment. To identify the synchronizers, the AEP engine uses the Leda structural analyzer. In the following paragraphs, you will categorically enumerate the synchronizer related checks for ABV (assertion based verification).

Synchronizers Identified by LedaLeda identifies the following synchronizers:

Flip-flop Synchronizers

DescriptionThe FF synchronizers (shown in Fig 16) form the basic building block for most of the existing synchronization circuits. A simple FF synchronizer consists of m (> 1) FF modeled as a shift register running on the 'destination clock'. Once the presence of a FF synchronizer having m stages is detected, the following property is generated to ensure that the device functions correctly in presence of this synchronizer.

If no assumptions are made about the relationship between the 'source' and 'destination' clock domains, then the following property ensures that all input signal values can be reliably transported to the synchronizer output.

32


Input data values must be stable for m+1 destination clock edges.

Figure 16: Flip-flop Synchronizers

ImplementationExample SVA codes for the above properties are given as follows. This assertion verifies the stability of din as observed in the destination clock domain. Signal rst is the reset signal (if any, with the appropriate polarity) extracted from the synchronizer FF, din is the single bit input to the first FF of the synchronizer.

property p_stability; disable iff (rst)@( dclk) !$stable (din) |=> $stable (din)[*m] );endproperty A_p_stability: assert property (p_stability);

To configure the detection of FF synchronizers according to the design usage, see set_cdc_synchronizer on page 52.

m flip-flops

dins

rst

R R RD Q D Q D Q

clk clk clk

sclk dclk

dout

. 33


MUX Synchronizers

DescriptionDesigns typically have both control and data paths. As shown in the following figure (Fig 17), the control paths are usually flop-synchronized while the synced-in control signals are used to synchronize the data paths. Here, these data paths use a controlled synchronizer MUX for crossing clock domains. These control MUXs are sometimes called D-MUX, MUX synchronizer, or sync MUX.

Figure 17: MUX synchronizers

din

ready_in

sclkdclk

m flip-flop sync.

data

dready

MUX

sready

1

0sDR

dDRdout

34


The MUX synchronizer has the following functional requirements to ensure correct results.

sready must be stable for m+1 number of destination clock cycles (modeled by property p_stability as explained in the section Flip-flop Synchronizers).

data should remain stable in the destination clock domain during the data transfer phase (indicated by the time dready is asserted in dclk domain and until dready deasserted in dclk domain).

ImplementationStability of Data

property p_data_stable; disable iff (drst) @( dclk) ((dready) |=> ($stable (data) || (!dready)); endpropertyA_p_data_stable: assert property (p_data_stable);

Handshake Synchronizers (Push)

DescriptionThere are different types of handshake synchronizers in practice, but most come down to the fundamental working principle of synchronizing a single-bit request into the destination clock domain and waiting for a synchronized version of the acknowledge to come back. The differences in the architecture of the handshake synchronizers take place because of the higher level protocols for the associated interfaces, data management, etc.

The handshake synchronizers use two m-flip-flop synchronizers to generate request and acknowledge signals. The associated properties are given as follows.

Input Data Stability for the m-flip-flop Synchronizers - Input data values must be stable for m+1 destination clock edges (Re-use of the assertion in 6.a)

Protocol check - The sender and the receiver should follow the handshake protocol correctly.

. 35


Data Stability - The data must be present when request is asserted on the destination and remain stable until the acknowledgment is generated.

Figure 18: Handshake synchronizers

ImplementationThe following assertions cover the proper use of the m-flip-flop synchronizers, the handshake protocol, and the corresponding data stability.

1. Input Data Stability for the m-flip-flop synchronizers

Request signal (sreq) of the sender and Acknowledgement signal (dack) must be stable for m+1 'dclk' and 'sclk' cycles respectively as implemented in the section Flip-flop Synchronizers.

2. Protocol check

a. The sender should continue to assert the sreq signal until sack is asserted at the source clock (sclk) domain.

b. The sender should not assert a new request (sreq) until the acknowledgement for the previous transfer is de-asserted in the source clock (sclk) domain.

Src

sclk dclk

m flip-flop sync.

data

dreqsreq Dest

m flip-flop sync.dacksack

sDR dDR

sLdCtrl

36


A SVA property that covers the above two checks is given as follows.property src_conformance (clk, rst, ssig, dsig); disable iff (rst) @( clk) ssig && !dsig |=>ssig; endpropertyA_src_conformance_req: assert property (src_conformance (sclk, srst, sreq, sack));A_src_conformance_new_req:

assert property (src_conformance (sclk, srst, !sreq, !sack));

Similar properties for the destination clock domain (dclk) are given as follows.

- The receiver should continue to assert the dack signal till dreq is asserted at the destination clock (dclk) domain.

- The receiver should not assert a new acknowledgement (dack), until a new request is received in the destination clock (dclk) domain.

A SVA property that covers the above two checks is given as follows.property dest_conformance (clk, rst, ssig, dsig); disable iff (rst) @( clk) ssig |=>dsig; endpropertyA_dest_conformance_req: assert property (dest_conformance (dclk, drst, dreq, dack)); A_dest_conformance_new_req:

assert property (dest_conformance (dclk, drst, !dreq, !dack));3. Data stability

- The receiver should continue to receive stable data till it asserts the acknowledgment.

The following SVA property implements the above two scenarios.property data_stability (clk, rst, dreq, dack, data); disable iff (rst)

@( clk) (dreq && !dack) => $stable (data);endpropertyA_data_stability_dest:

assert property (dest_stability (dclk, drst, dreq, dack, data));The checks for Pull synchronizers are similar.

. 37


Dual Clock FIFO Synchronizers

DescriptionAnother common CDC synchronization circuit, which is used when the high latency of the handshake protocols cannot be tolerated, is the dual-clock asynchronous FIFO as shown in Fig 19. Although many implementation variations exist, the basic operation is the same; data is written into a dual-port RAM block from the source clock domain and the RAM is read in the destination clock domain. Gray-coded read and write pointers are passed into the alternate clock domain (using two m-flip-flop synchronizers) to generate full and empty status flags. The following properties are generated for the dual-clock asynchronous FIFO:

The producer never writes when the FIFO is full.

The consumer never reads when the FIFO is empty.

Read and Write pointers must be gray-coded at source.

Checks for data integrity (FIFO preserves Order and Data Value).

Figure 19: FIFO Based Synchronizer

38


ImplementationThe following SVA code provides a possible implementation of these checks. The p_data_integrity assertion starts a new thread with a unique cnt value whenever wdata is written to the FIFO and checks the rdata value against the local data variable whenever the corresponding read occurs. The first_match is required in p_data_integrity to ensure the property checks rdata on the first occurrence of a read with the corresponding cnt, otherwise it waits for ever for a rdata match at the rcnt value. You should create a module M, which contains the assertions. It is then bound to the nearest top-level module instance containing the FIFO code.

No Load on Full & No Read on Emptyproperty p_bad_access(clk, inc, flag);@( clk) inc |-> !flag;endproperty : p_bad_access//-- Property for bad write accessA_p_bad_access_write: assert property (p_bad_access (wclk,winc,wfull));//-- Property for bad read accessA_p_bad_access_read: assert property (p_bad_access (rclk,rinc,rempty));

. 39


Order and Data Preservation//- The following code mimics the gray coded read and write pointers. If you have//- those pointers automatically identified from the design, this is not requiredbit [$bit (waddr)-1:0] rcnt=0, wcnt=0;always @(posedge wclk or negedge wrst_n) begin if (wrst_n) wcnt

(rdata == data));endproperty : p_data_integrity

A_p_data_integrity: assert property (p_data_integrity);

Complex SynchronizersAny synchronizer identified by Leda's CDC manager, which does not fall in the category of Single FF-Synchronizer, MUX Synchronizer, Handshake Synchronizer, User-given Synchronizer, and FIFO Synchronizer is called a Complex Synchronizer.

Following are the examples of Complex Synchronizer:

A vector signal when FF-Synchronized constitutes a Complex Synchronizer. A group of FF-Synchronizers when do not synchronize any CDC data path can create a Complex Synchronizer.

In many cases, Leda might identify part of a real synchronizer and mark it as a complex one. Therefore a Complex Synchronizer might need your intervention for proper categorization.

40


For example,

- If CDC manager identifies part of FIFO synchronizer, then it might be identified as a Complex Synchronizer.

- If CDC manager adds one or two more signals to a MUX/Handshake Synchronizer, it would be a Complex Synchronizer.

Following is a case of Complex Synchronizer identification by Leda:

In the following test case, Leda identifies that a vector signal has been FF-Synchronized and is used in the destination domain (converges to some combo logic). It therefore group all these bits and try to find out whether they are giving rise to another known synchronizer. In this case, it will not be inferred as a Complex Synchronizer.

module test (in1, in2, clk1, clk2, out2, sel);input clk1, clk2, sel;input [2:0] in1, in2;output out2;

reg [2:0] out1, first, src;reg out2;wire temp;

always @(posedge clk1) src

. 41


config.tcl:rule_deselect -allrule_select -rule NTL_CDC01rule_select -rule NTL_CDC01_0rule_select -rule NTL_CDC01_3

Violation 12: out1 [WARNING] NTL_CDC01_0: Flip-flop Synchronizer Detected test.out1(0) --- Source Clock: test.clk1 (file: test.v, line: 2) --- Target Clock: test.clk2 (file: test.v, line: 2) --- Source Register: test.src(0) (file: test.v, line: 9) --- Target Register: test.out1(0) (file: test.v, line: 5)

12: out1 [WARNING] NTL_CDC01_0: Flip-flop Synchronizer Detected test.out1(1) --- Source Clock: test.clk1 (file: test.v, line: 2) --- Target Clock: test.clk2 (file: test.v, line: 2) --- Source Register: test.src(1) (file: test.v, line: 9) --- Target Register: test.out1(1) (file: test.v, line: 5)

12: out1 [WARNING] NTL_CDC01_0: Flip-flop Synchronizer Detected test.out1(2) --- Source Clock: test.clk1 (file: test.v, line: 2) --- Target Clock: test.clk2 (file: test.v, line: 2) --- Source Register: test.src(2) (file: test.v, line: 9) --- Target Register: test.out1(2) (file: test.v, line: 5)

1: module test (in1, in2, clk1, clk2, out2, sel); ^

test.v:1: CDC> [WARNING] NTL_CDC01_3: Complex Synchronizer Detected test --- Source Clock: test.clk1 (file: test.v, line: 2) --- Target Clock: test.clk2 (file: test.v, line: 2) --- Source Register: test.src(0) (file: test.v, line: 9) --- Target Register: test.out1(0) (file: test.v, line: 5) --- Source Register: test.src(1) (file: test.v, line: 9) --- Target Register: test.out1(1) (file: test.v, line: 5) --- Source Register: test.src(2) (file: test.v, line: 9) --- Target Register: test.out1(2) (file: test.v, line: 5)

42


Quasi Static Signal for Identifying Double FF Synchronizer

Proper identification of a double FF (flip-flop) synchronization often needs specification of 'quasi static inputs'. Typically, Leda does not allow any combinational logic between the synchronizing FFs of a double FF synchronizer. Given some parameter, Leda allows only inverter and buffer. However, in some cases, a 'quasi static signal' is often connected to MUX select pins that enable functionality of a double FF synchronizer. In these scenarios, a MUX is placed between the FFs of the double FF synchronizer, whose select pin is driven by the quasi static signal. A typical schematic of such synchronization schemes is given in following figure:

The dashed box is source FF in source clock domain (CLK1) and sold lined boxes are synchronizing FFs in destination clock domain (CLK2).

By default, Leda will not treat the circuit having a MUX between a double FF synchronizer as a 2-FF synchronizer. However, if you specify the MUX select pin as a quasi static signal using the below Tcl command, then Leda takes this information and recognizes the circuit as a double FF synchronizer.

set_quasi_static_signals -signal_list {top.mod1.mux_sel, signal2, signal3, }

NoteYou need to mention the signal with hierarchical information.

You can apply this Tcl command directly in Leda and use the -clock_file option in batch mode.

. 43


ExampleThe following Verilog module works as a double FF synchronizer only if the following command is set.

set_quasi_static_signals -signal_list {top.sel}

module top (in1, clk1, clk2, out1, sel);input clk1, clk2, in1, sel;output out1;

reg out1, first, src;

always @(posedge clk1) //- CDC src register src

44


synchronizers. In this way, when there is a change from one state of the multi-bit signal to another, only one bit changes at a time. It ensures that the destination side will not sample inconsistent state values due to different skews and meta-stability delays on each bit. The Gray code may be decoded on the destination side, after the individual synchronizers.

Figure 20: Multi-bit Data Transfer

Once such multi-bit signals are identified, the purpose of the function checks is to verify that state changes on the source side before entering the bit synchronizers follow the Gray code.

ImplementationEach individual m-flip-flop synchronizer must satisfy the signal stability properties indicated in 1.1.2. In addition, the Gray code assertion verifies that whenever there is a change of value on data_in the next value differs from the preceding one only in one bit. The vector data_in is formed by concatenating all the variables that are part of the multi-bit signal.

property p_gray_coded (clk, rst,data); disable iff (rst) @( clk) !$stable (data) |-> ($onehot (data ^ $past (data)); endpropertyA_p_gray_coded: assert property (p_gray_coded (dclk, rst, din));

In the following section, you will read how Leda generates these assertions and how to use these assertions for verification.

din

sclk dclk

Gray codeassertion

m flip-flop sync.

m flip-flop sync.Source domain

logic

Destination domain

logicdata_outn bits

. 45


CDC AEP Rule UsageClock Domain Crossing is a global problem and Leda currently has an effective solution for CDC verification. In this section, the CDC rules that generate assertions for verifying functionality of each of the CDC synchronizer recognized in the design (NTL_CDC06, and NTL_CDC14 - NTL_CDC16) are elaborated. In addition, there is a rule NTL_CDC08, which checks for the correct implementation of gray coding for each vector CDC control signal detected in the design.

The purpose of adding these five rules is to provide the following information:

NTL_CDC06 - Indicates that FF synchronizers have been used in the design. For each of these FF synchronizers, Leda generates assertion for checking the signal stability property of the associated CDC control signal.

NTL_CDC08 - The purpose of NTL_CDC08 is two fold. First to report 're-convergence scenario' for a set of individually synchronized signals. The second purpose is to generate gray code assertions for "re-converging" vector signals. For each of such vector CDC control (synchronized) signal, Leda generates assertion for checking whether the associated vector has been gray coded. Note that NTL_CDC08 does not generate gray code property for re-converging non-vector signals.

NTL_CDC14 - Indicates that MUX synchronizers have been used in the design. For each of such MUX synchronizers, Leda generates assertions for checking signal stability of the associated control and data signals.

NTL_CDC15 - Indicates that Handshake (Push/Pull) synchronizers have been used in the design. For each of such Handshake synchronizers, Leda generates assertions for checking signal stability of the associated control and data signals. In addition, it generates assertions for checking the correctness of the associated handshake protocol.

NTL_CDC16 - Indicates that FIFO synchronizers have been used in the design. For each of such FIFO synchronizers, Leda generates assertions for checking empty/full criterion of the associated FIFO. In addition, it generates assertions for checking the (a) data signal integrity of the FIFO, and (b) gray coding of the FIFO read/write pointers.

Furthermore, the detailed structural analysis statistics for the CDC synchronizers (such as the numbers, locations etc.) can be accessed in the following ways:

While using Tcl mode (switch leda +tcl_shell), there is a command called 'report_cdc_info', which displays all types of detected CDC structures.

46


There are 7 rules (NTL_CDC01, NTL_CDC01_0, NTL_CDC01_1, , NTL_CDC01_6) which when selected displays all types of CDC structures (synchronized, unsynchronized) detected in a design by Leda.

The section CDC Tcl Interface provides details of the current CDC Tcl interface. Additionally, each of the CDC assertion specific rules NTL_CDC14 - NTL_CDC16 also provides signal specific information about the CDC synchronizers. An example is provided in the section CDC Analysis.

. 47


Naming Convention for Automatically Generated CDC AEP Files

For each of the rules specified in previous section, Leda generates a separate assertion file. This file contains the template/definition for the associated assertion. The naming convention of the assertion files (also definitions) follows the specific issue for which the assertion has been generated. For example, 'aep_signal_stability.v' file contains assertion definition for checking the control signal stability. The generated file names along with their purposes are given as follows:

aep_signal_stability.v - Checks control signal stability.

aep_mux_data_signal_stability.v - Checks data signal stability of a MUX synchronizer.

aep_handshake_data_signal_stability.v - Checks data signal stability of a Handshake synchronizer.

aep_handshake_protocol_check.v - Checks handshake protocol checks for a Handshake synchronizer.

aep_fifo_validate_assertions.v - Checks fifo properties (full/empty, data integrity) for a FIFO synchronizer.

Each of these assertion definition files are generated only once. As every complex synchronizer (MUX, FIFO, and Handshake) uses FF synchronizers for synchronizing the control signals, aep_signal_satbility.v is also re-used for each of them.

Binding the Assertion Definitions to the DesignThe generated assertion definitions are attached to the design signals using a set of 'bind' statements. These bind statements are generated in a separate file named 'leda_top_properties.v'. As there can be multiple instances of a specific synchronizer, for each of these instances, a separate bind statement is generated. The instance name of the assertion definitions (used in the bind statements) is numbered.

The general idea for generating properties is to use prepackage modules containing assertions and bind them to the verified design. The bind should try to bind the lowest possible module in the design hierarchy in order to allow reduction of the design size for the formal tool. The bind command will have the general following syntax:

bind #( ) ( );where, is of the form:

i__

48


For example if there are three FF synchronizers detected in a design, there would be one control signal stability assertion definition and three separate bind statements generated with three unique assertion instances namely - i_NTL_CDC06_1, i_NTL_CDC06_2, and i_NTL_CDC06_3.

Sometimes, if you want to avoid explosion of the simulation time or Magellan running time, you can also bound the number of properties that are generated. The set_max_properties command placed in the design configuration file allows controlling this number. This command is not specific to the CDC Manager; it is part of the property generation manager.

set_aep_max_properties -value max_value

Using Generated Assertions in VCS and MagellanThe generated assertions can be verified on the design using (1) VCS (simulation based verification) or (2) Magellan (formal verification). To simplify building of the assertions, a file (named leda_prop_file.lst) containing the list of automatically generated files is created. As a result, you only need to attach file 'leda_prop_file.lst' to the associated checker tool.

The set of assertion related files are generated in a directory naming 'ForMG'. This directory is located by default in .leda_work or in case .leda_work is missing in the 'run directory.

Moreover, for Magellan, a project file template (named 'LedaMgPrjFile.prj') is also generated. You (sometimes) may need to add additional information like - the clock periods, the reset configurations etc. in this template. You don't need to use any switch for generating the assertions. The assertions and the associated files are created by default.

For Mixed designs (having both VHDL and Verilog models), CDC assertion evaluation needs manual intervention. Moreover, for generating Magellan project file for MX flow, you need to set the following environment variable:

setenv LEDA_MG_MX_FLOW 1

After generating the project file, contact Leda support for further assistance.

Failure DebuggingIn case of any CDC assertion violations for a design, you need to use the debugging aids of the associated checker (VCS/Magellan) for finding the root cause of the failure.

. 49


Configuring Latches in CDC AnalysisA Latch can lead to the following scenarios during CDC analysis:

Latch as an endpoint - If you want to use Latch as a source or destination point of a clock domain crossing path, then use the following command.set_cdc_parameter -name "STOP_AT_LATCH" -value 1

Latch as a combinational logic (transparent element) - This is the default behavior of Leda. In many designs, Latches are used as a pass through combinational logic during CDC analysis. In this case, Leda does not treat the Latch as a CDC path endpoint.set_cdc_parameter -name "STOP_AT_LATCH" -value 0

CDC Tcl InterfaceThe following is the command reference information for built-in Tcl commands that you can use to manage the CDC rules:

set_cdc_ignored_pathUse the set_cdc_ignored_path command to specify a path to be ignored by CDC analysis.

Syntaxset_cdc_ignored_path [-from source_ff_name] \

[-to target_ff_name]

Arguments-from Specify the source flip-flop name.

-to Specify the target flip-flop name.

50


Although -from and -to are optional, at least one of the options must be used. If you dont specify any one of the options, then its value is considered as any. For example:

module cdc01_4 (in1, in2, clk1, clk2, out2, sel); input clk1, clk2, sel; input in1, in2; output out2;

reg out1, first, src;reg out2;wire muxout1, muxout2;wire temp;

always @(posedge clk1) src

. 51


check -config cfg.tclreportclear_cdc_infoelaborate -top cdc01_4set_cdc_ignored_path -from cdc01_4.srccheck -config cfg.tclreport

As mentioned above, user has to clear CDC information using the command clear_ cdc_info before setting the ignored path. Any path starting from the src signal will be ignored by Leda for CDC checks.

Support of Wildcard in set_cdc_ignored_path CommandYou can use wildcard for signals specified with the Tcl command set_cdc_ignored_path. For example:

# sample commandset_cdc_ignored_path -from top.sub1.I1.qout_1set_cdc_ignored_path -from top.sub1.I1.qout_2 set_cdc_ignored_path -from top.sub1.I1.qout_3set_cdc_ignored_path -from top.sub1.I1.qout_4

Now by using wildcard, you can specify the signal as follows:set_cdc_ignored_path -from top.sub1.I1.qout_*

This makes sure that all the signals qout_1, qout_2, qout_3, and qout_4 are applied to the set_cdc_ignored_path command.

If you see $ sign in the hierarchical path, for example, top.sub1.$_U1.I1.qout_1, then you should prefix \, as shown below, to filter the violation message.

set_cdc_ignored_path -from top.sub1.\$_U1.I1.qout_*

52


set_cdc_synchronizerUse the set_cdc_synchronizer command to specify a synchronizer cell.

Syntaxset_cdc_synchronizer -name name \

[-synchro_type type [-synchro_parameters {..} ] ]

Arguments-name Specify the name of the synchronizer cell.

-synchro_type Specify the synchronizer type. It can take one of the

following values:

simple (for flip-flop synchronizers).

logic (for logic synchronizers).

complex (for complex synchronizers).

fifo (for fifo synchronizers).

handshake (for handshake synchronizers).

-synchro_parameters Specify the parameters corresponding to the synchronizer.

For all the specified synchronizers, the parameters are a list of strings that specify some values. The following table lists the parameters that are applicable for various synchronizers.

Table 2: Parameters of different synchronizers

Parameters applicable to all synchronizers

Parameters applicable to FIFO synchronizer

Parameters applicable to handshake synchronizer

-source_clock -source_clock -source_clock

-target_clock -target_clock -target_clock

-write_signal -handshake kind (can be pushhanshake or pullhandshake)

-read_signal -transmit_signal

-fifo_full -receive_signal

-fifo_empty

. 53


set_cdc_input_delayUse the set_cdc_input_delay command to specify a clock that controls the module pins or ports specified with the option -pin_port_list. This helps you to analyze the CDC issue in a given module and focus on debugging in that module.

Syntaxset_cdc_input_delay -clock user_clock_name -delay_value delay_value \

-pin_port_list {PIN_PORT_LIST}

Arguments-clock Specify the clock name.

-delay_value Specify the delay value. Leda actually discards this valueand so you can specify any value.

-pin_port_list Specify the list of pins or ports that the clock controls

For example, if you have a module SYNCHHRONIZER_MODULE that contains the synchronizer as follows:

module SYNCHRONIZER_MODULE (out_data, in_data, clk);

You can instantiate this module in a design and specify a new clock, say clk1 that controls the pin in_data. To avoid debugging the whole design and to just focus on this synchronizer module, you need to specify the set_cdc_input_delay command in the leda_clock_file.tcl as follows:

set_cdc_input_delay -clock clk1 -delay_value 1 -pin_port_list {SYNCHRONIZED_MODULE.in_data}

extract_cdc_infoUse the extract_cdc_info command to run the CDC inference within the Tcl shell mode in order to refine the different parameters for this inference.

Syntax

-write_reset_signal

-write_read_signal

-data_signal

Table 2: Parameters of different synchronizers

Parameters applicable to all synchronizers

Parameters applicable to FIFO synchronizer

Parameters applicable to handshake synchronizer

54


extract_cdc_info

You need to execute this command only after elaboration. You can then use the report_cdc_info command to visualize the inferred CDC elements. You may execute this command many times, but it is important to run the clear_cdc_info command before any call.

report_cdc_infoUse the report_cdc_info command to print the inferred CDC elements on the console or to a file.

Syntaxreport_cdc_info [-file filename]

Arguments-file Specify the file name.

NoteWhen you redirect the output of this command to a file, the console does not display any information.

You can customize and source this file from the tcl_shell or the design_config file to have a clean CDC inference.

clear_cdc_infoUse the clear_cdc_info command to clear all the inferred CDC informations.

Syntaxclear_cdc_info

In the Tcl shell mode, you may be interested to try several parameters until you get the correct CDC inference. In order to do this incrementally, you can call the clear_cdc_info command to reset everything and start the inference with new parameters.

set_cdc_parameterUse the set_cdc_parameter command to specify a value for the parameters for CDC inference.

Syntax

. 55


set_cdc_parameter [-name cdc_parameter_name] [-value cdc_parameter_value]

Arguments-name Specifies the CDC Parameter Name

-value Specifies the CDC Parameter Value

The following parameters shall be used with this command:

NB_FFS_FOR_SYNCHRONIZER - Use this parameter to specify the number of flip-flops to be used for synchronization. The default value is 2.

ALLOW_BUF_INV_IN_SYNC_FFS - This parameter is used to specify if the path between the synchronizing flip-flops contain buffers or inverters. If set to 1, the path between the synchronizing flip-flops may contain buffers or inverters. The default value is 1.

MAX_NB_PATHS - This parameter is used to specify the maximum number of path allowed in a valid CDC Element. Above this number, the CDC element is marked invalid and not taken into account by any CDC checks.

MAX_NB_DISPLAYED_PATHS - This parameter is used to specify the maximum paths to be displayed in a single CDC violation. The default value is 10.

MAX_SYNCHRONIZATION_DEPTH - The CDC Inference algorithm explores the influence of control signals to find the controlled paths. This parameter is used to controls the maximum sequential depth to be explored by Leda. The default value of this parameter is set to 4, to allow Leda to detect all kinds of synchronizers. In a design using logic synchronizers, it is recommended to limit this number to 2 or 1.

STOP_AT_LATCH - This parameter is used when you want to use Latch as a source or destination point of a clock domain crossing path.

56


57

Chapter 2: Clock Domain Crossing Rules

2Clock Domain Crossing Rules

IntroductionThis chapter presents detailed reference information about the rules contained in the CDC ruleset of Design policy. This ruleset specifies rules that covers many aspects of clock domain crossing (CDC).

NoteClock domain crossing rules under CDC ruleset of Design policy is currently a beta feature.

58


CDC Usage ModelTo generate the complete CDC results from Leda, perform the following steps:

1. Do the following setting:% setenv LEDA_MAX_CLOCKS 1

2. In your configuration file, make sure that you have chosen the CDC rules.

You can choose the CDC rules in the config file as follows:rule_select policy DESIGN ruleset CDC

3. Run Leda in batch or Tcl mode.

You will see that Leda will flag a message saying:WARNING: Leda has extracted x clock origins (x clock domains), which is suspicious...WARNING: Therefore no chip-level, netlist or sdc checks have been executedWARNING: Please check the list of clock origins as dumped in leda__clocks.tcl,WARNING: modify this file to group synchronous clocks using set_clock_groups command,WARNING: set $LEDA_CLOCK_FILE or use option -clock_file to point to this file and re-run the checker

The clock grouping file with the name leda__clocks.tcl that is generated by Leda in the pwd, has to be grouped by the user and given back to Leda using the option clock_file.

4. Run Leda specifying the clock grouping file using the option clock_file and the configuration file using the option config.

5. All the CDC violations will be present in the leda.log file.

59


CDC RulesetThe following rules are from the CDC ruleset:

NTL_CDC00

Message: Clock domain crossing detected.

ExampleThis is an example of invalid Verilog code that illustrates the problem:

module NTL_CDC00 (d0, d1, q1, clk0, clk1);

input d0, d1, clk0, clk1;output q1;

reg q0, q1;wire n0;

// clock domain crossing from clk0 to clk1 detected here always @ (posedge clk0) q0

60


ViolationsT11: q0 [NOTE] NTL_CDC00: Clock domain crossing detected NTL_CDC00.q0 --- Source clock: NTL_CDC00.clk0 (file: NTL_CDC00.v, line: 3) --- Target register: NTL_CDC00.q1 (file: NTL_CDC00.v, line: 16) --- Target clock: NTL_CDC00.clk1 (file: NTL_CDC00.v, line: 3)

Schematic

61


NTL_CDC01

Message: No synchronization scheme found for signalscrossing clock domains

Description Leda flags this rule when it finds signals (one or more) crossing from one clock domain (say A) to another clock domain (say B) and no global synchronization scheme is found.This rule fires only one message for all the signals crossing between domains.

You can use the rule_set_parameter Tcl command to configure the following parameters:

SHOW_ALL_PATHS You can configure this parameter to value 0, if you want Leda to show one violation per path. If you set the value to 1, then Leda flags only one violation for the CDC element. For example:

leda> rule_set_parameter -rule NTL_CDC01 -parameter SHOW_ALL_PATHS -value {1}

SHOW_CONTROL_PATHS You can configure this parameter to display the control paths in the track info. For this, you need to set the value of parameter SHOW_CONTROL_PATHS to 1 and the value of parameter SHOW_ALL_PATHS to 1. For example:

leda> rule_set_parameter -rule NTL_CDC01 -parameter SHOW_CONTROL_PATHS -value {1}

REPORT_BUS_ONLY When this parameter is enabled, only unsynchronized CDC Bus signals would be reported with NTL_CDC01 rule.

Therefore, if 'sig' is a bit, with parameter REPORT_BUS_ONLY enabled, there will be no NTL_CDC01 violations.

To set this parameter, modify the configuration file as follows:leda> rule_select -rule NTL_CDC01leda> rule_set_parameter -rule NTL_CDC01 -parameter REPORT_BUS_ONLY -value 1

62


ExampleFollowing is an example of the rule:

module cdc01 (rst, clk1, clk2, clk3, din, dout);input clk1;input clk2;input clk3;input rst;input din;output dout;reg dout;reg d_reg0;always @(posedge clk1 or negedge rst)begin

if (~rst)d_reg0

63


Violations22: dout [FATAL] NTL_CDC01: no synchronization scheme found for signals crossing clock domains cdc01.dout --- Source Clock: cdc01.clk1 (file: NTL_CDC01.v, line: 2) --- Target Clock: cdc01.clk2 (file: NTL_CDC01.v, line: 3) --- Source Register: cdc01.d_reg0 (file: NTL_CDC01.v, line: 15) --- Target Register: cdc01.dout (file: NTL_CDC01.v, line: 22)

Schematic

NoteYou need to have NTL_CDC01 rule selected in the config file to have the below mentioned rules working.NTL_CDC01_0, NTL_CDC01_1, NTL_CDC01_3, NTL_CDC01_4, NTL_CDC01_5, NTL_CDC01_6.

64


NTL_CDC01_0

Message: Flip-flop Synchronizer detected

NoteTo run this rule, you must select the NTL_CDC01 rule in the configuration file.

Description This rule is flagged when Leda detects a flip-flop synchronizer.

Policy DESIGN

Ruleset CDC

Language VHDL/Verilog

Type Hardware

Severity Warning

65


ExampleFollowing is an example of this rule:

module cdc01_0 (rst, clk1, clk2, clk3, din, dout);input clk1;input clk2;input clk3;input rst;input din;output dout;reg dout;reg d_reg0;reg d_reg1;reg d_reg2;

always @(posedge clk1 or negedge rst)begin

if (~rst)d_reg0

66


Violations

27: d_reg2 [WARNING] NTL_CDC01_0: Flip-flop Synchronizer Detected cdc01_0.d_reg2 --- Source Clock: cdc01_0.clk1 (file: NTL_CDC01_0.v, line: 2) --- Target Clock: cdc01_0.clk2 (file: NTL_CDC01_0.v, line: 3) --- Source Register: cdc01_0.d_reg0 (file: NTL_CDC01_0.v, line: 17) --- Target Register: cdc01_0.d_reg2 (file: NTL_CDC01_0.v, line: 11)

67


NTL_CDC01_1

Message: Logic Synchronizer detected

NoteTo run this rule, you must select the NTL_CDC01 rule in the configuration file.

ExampleFollowing is an example of this rule:

In the following figure, a 4-bit data path from clock domain of clk1 is passed through a MUX 'm' to the domain of 'clk2'. The MUX is enabled by a 2-FF synchronized control signal 'rx_dsel'. Clearly this arrangement is a MUX synchronizer.

Description This rule is flagged when Leda detects a logic synchronizer.

Poli

pol_cdc

Documents

design compiler

fpga compiler

hdl compiler

ecl compiler

dft compiler

eco compiler

physical compiler

behavioral compiler