DFT Compiler RTL Test Design Rule Checking User Guide [PDF]

Zitiervorschau

DFT Compiler RTL Test Design Rule Checking User Guide Version W-2004.12, January 2005

Copyright Notice and Proprietary Information Copyright  2005 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.

Right to Copy Documentation The license agreement with Synopsys permits licensee to make copies of the documentation for its internal use only. Each copy shall include all copyrights, trademarks, service marks, and proprietary rights notices, if any. Licensee must assign sequential numbers to all copies. These copies shall contain the following legend on the cover page: “This document is duplicated with the permission of Synopsys, Inc., for the exclusive use of __________________________________________ and its employees. This is copy number __________.”

Destination Control Statement All 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 reader’s responsibility to determine the applicable regulations and to comply with them.

Disclaimer SYNOPSYS, 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, I, 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, VirSim, 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. Printed in the U.S.A. DFT Compiler RTL Test Design Rule Checking User Guide, W-2004.12

ii

Contents

1.

2.

Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

v

Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

v

Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

vi

Customer Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

vii

Preparing your RTL Design for Design Rule Checking Reading the HDL Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

Setting the Scan Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

Defining the Test Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

Test Protocol Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

Reading an Initialization Protocol in STIL Format . . . . . . . . . . . . . . . . . .

3

Design Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Test Protocol Example 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Test Protocol Example 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7 7 9

Checking for Violations in RTL Designs Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

Violations That Prevent Scan Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

Uncontrollable Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

Latches Enabled at Beginning of Clock Cycle . . . . . . . . . . . . . . . . . . . .

15

Asynchronous Control Pins in Active State . . . . . . . . . . . . . . . . . . . . . . .

15

iii

Violations That Prevent Data Capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clock Used As Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

Black Box Feeds Into Clock or Asynchronous Control . . . . . . . . . . . . . . .

17

Source Register Launch Before Destination Register Capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Latches as the Source and Destination Register . . . . . . . . . . . . . . .

17 17

Registered Clock-Gating Circuitry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

Three-State Contention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

Clock Feeding Multiple Register Inputs . . . . . . . . . . . . . . . . . . . . . . . . . .

19

Violations That Reduce Fault Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

Combinational Feedback Loops. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

Clocks That Interact With Register Input . . . . . . . . . . . . . . . . . . . . . . . . .

21

Multiple Clocks That Feed Into Latches and Flip-Flops . . . . . . . . . . . . . . Latch Requires Multiple Clocks to Capture Data . . . . . . . . . . . . . . . Latches Are Not Transparent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22 22 23

Black Boxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

Index

iv

15

About This Manual The DFT Compiler RTL Test Design Rule Checking User Guide describes design rule checking at the RTL level when using DFT Compiler.

Audience This manual is intended for ASIC deisgn engineers who have some exposure to testability concepts and strategies. It is also useful for test and design-for-test engineers who want to understand how basic test automation concepts and practices relate to DFT Compiler.

Related Publications For additional information about DFT Compiler, see: •

Documentation on the Web, which provides HTML and PDF documents and is available through SolvNet at: http://solvnet.synopsys.com

•

The documentation installed with the DFT Compiler software and available through the DFT Compiler Help menu

•

Synopsys Online Documentation (SOLD), which is included with the software for CD users or is available to download through the Synopsys Electronic Software Transfer (EST) system

v

About This Manual Conventions

You might also want to refer to the documentation for the following related Synopsys products: •

Design Compiler

•

BSD Compiler

•

TetraMAX

Conventions The following conventions are used in Synopsys documentation. Convention

Description

Courier

Indicates command syntax.

Courier italic

Indicates a user-defined value in Synopsys syntax, such as object_name.

Regular italic

A user-defined value that is not Synopsys syntax, such as a user-defined value in a Verilog statement.

Courier bold

Indicates user input—text you type verbatim—in Synopsys syntax and examples.

Regular bold

User input that is not Synopsys syntax, such as a user name or password you enter in a GUI.

[]

Denotes optional parameters, such as pin1 [pin2 ... pinN]

...

Indicates that a parameter can be repeated as many times as necessary

|

Indicates a choice among alternatives, such as low | medium | high

(This example indicates that you can enter one of three possible values for an option: low, medium, or high.) _

vi

Connects terms that are read as a single term by the system, such as set_annotated_delay

About This Manual Customer Support

Convention

Description

Control-c

Indicates a keyboard combination, such as holding down the Control key and pressing c.

\

Indicates a continuation of a command line.

/

Indicates levels of directory structure.

Edit > Copy

Indicates a path to a menu command, such as opening the Edit menu and choosing Copy.

Customer Support Customer support is available through SolvNet online customer support and through contacting the Synopsys Technical Support Center.

Accessing SolvNet SolvNet includes an electronic knowledge base of technical articles and answers to frequently asked questions about Synopsys tools. SolvNet also gives you access to a wide range of Synopsys online services including software downloads, documentation on the Web, and “Enter a Call to the Support Center.” To access SolvNet, 1. Go to the SolvNet Web page at http://solvnet.synopsys.com. 2. If prompted, enter your user name and password. (If you do not have a Synopsys user name and password, follow the instructions to register with SolvNet.) If you need help using SolvNet, click SolvNet Help in the Support Resources section.

vii

About This Manual Customer Support

Contacting the Synopsys Technical Support Center If you have problems, questions, or suggestions, you can contact the Synopsys Technical Support Center in the following ways: •

Open a call to your local support center from the Web by going to http://solvnet.synopsys.com (Synopsys user name and password required), then clicking “Enter a Call to the Support Center.”

•

Send an e-mail message to your local support center.

•

viii

-

E-mail [email protected] from within North America.

-

Find other local support center e-mail addresses at http://www.synopsys.com/support/support_ctr.

Telephone your local support center. -

Call (800) 245-8005 from within the continental United States.

-

Call (650) 584-4200 from Canada.

-

Find other local support center telephone numbers at http://www.synopsys.com/support/support_ctr.

1 Preparing your RTL Design for Design Rule Checking1 This chapter describes how to prepare your design for RTL design rule checking, including reading in the HDL source files, setting the scan style and defining the test protocol.

Reading the HDL Source Files Input the HDL source files using the read command or the analyze and elaborate commands. For example, to read a Verilog design file, enter one of the following command sequences: dc_shell-t> set hdlin_enable_rtldrc_info true dc_shell-t> read_verilog my_design.v

or dc_shell-t> set hdlin_enable_rtldrc_info true dc_shell-t> analyze -format verilog my_design.v dc_shell-t> elaborate my_design

Important: You must set the hdlin_enable_rtldrc_info variable to true before you read in your HDL source. Then TestDRC can report file names and line numbers associated with any testability violations, which makes it easier to edit the source code and fix the violations.

1

Preparing your RTL Design for Design Rule Checking Setting the Scan Style

To save execution time in subsequent dc_shell sessions, you can save the design in .db format using the following command: dc_shell-t> write -format db -hierarchy -output my_design.db

Read the .db file using the following command. dc_shell-t> read_db my_design.db

For more information about these commands, see the Design Compiler documentation.

Setting the Scan Style The scan style setting affects messages generated by test design rule checking, because some design rules only apply to specific scan styles. To set the scan style, enter dc_shell-t> set_scan_configuration -style scan_style

The scan_style argument may be multiplexed_flip_flop, clocked_scan, lssd, aux_clock_lssd, combinational, or none. Alternatively, you can set the test_default_scan_style variable instead of using the set_scan_configuration command. If you do not set the scan style before performing test design rule checking, multiplexed flip-flop is used as the default scan stye.

Defining the Test Protocol You must define a test protocol prior to running test design rule checking. Note: You cannot use the -infer_clock and -infer_asynch options of the create_test_protocol command to infer a protocol if your design is at the RTL stage.

2

Preparing your RTL Design for Design Rule Checking Defining the Test Protocol

Test Protocol Requirements You must define the test protocol before you perform test design rule checking. To define the test protocol, you need to: •

Identify all test clock signals. Use the create_test_clock command to identify all test clocks. Identify a clock signal as a clock and not as any other signal type, even if it has more than one attribute. Test design rule checking generates an error message if you identify a clock signal with any other attribute.

•

Identify all nonclock control signals, such as asynchronous presets and clears or scan enable signals. Use the set_signal_type command to identify the following nonclock control signals.

•

-

test_asynch

-

test_asynch_inverted

-

test_scan_enable

-

test_scan_enable_inverted

Define constant logic value requirements. If a signal must be set to a fixed constant value, use the set_test_hold command.

•

Define test mode initialization requirements. Your design might require initialization to function in test mode. Use the read_init_protocol command to read in a custom initialization sequence. You can define a custom initialization sequence by modifying the protocol created by the create_test_protocol command.

Reading an Initialization Protocol in STIL Format You can read in a custom initialization sequence by using the read_init_protocol command. The read_init_protocol command overwrites any existing initialization protocol or custom test protocol that might exist in memory. If you enter any specifications after using the read_init_protocol command, the initialization protocol is not changed.

3

Preparing your RTL Design for Design Rule Checking Defining the Test Protocol

To read in an initialization protocol in STIL format, use the command: read_init_protocol -format stil filename.spf

Example 1 shows a complete STIL protocol file, including an initialization sequence. The initialization sequence is found in the test_setup section of the MacroDefs block. Example 1 Complete Protocol File (init.spf) STIL 1.0 { Design P2000.9; } Header { Title "DFT Compiler 2000.11 STIL output"; Date "Wed Jan 3 17:36:04 2001"; History { } } Signals { "ALARM" In; "BSD_TDI" In; "BSD_TEST_CLK" In; "BSD_TMS" In; "BSD_TRST" In; "CLK" In; "HRS" In; "MINS" In; "RESETN" In; "SET_TIME" In; "TEST_MODE" In; "TEST_SE" In; "TEST_SI" In; "TOGGLE_SWITCH" In; "AM_PM_OUT" Out; "BSD_TDO" Out; "HR_DISPLAY[0]" Out; "HR_DISPLAY[1]" Out; "HR_DISPLAY[2]" Out; "HR_DISPLAY[3]" Out; "HR_DISPLAY[4]" Out; "HR_DISPLAY[5]" Out; "HR_DISPLAY[6]" Out; "HR_DISPLAY[7]" Out; "HR_DISPLAY[8]" Out; "HR_DISPLAY[9]" Out; "HR_DISPLAY[10]" Out; "HR_DISPLAY[11]" Out; "HR_DISPLAY[12]" Out; "HR_DISPLAY[13]" Out; "MIN_DISPLAY[0]" Out; "MIN_DISPLAY[1]" Out; "MIN_DISPLAY[2]" Out; "MIN_DISPLAY[3]" Out; "MIN_DISPLAY[4]" Out; "MIN_DISPLAY[5]" Out; "MIN_DISPLAY[6]" Out; "MIN_DISPLAY[7]" Out; "MIN_DISPLAY[8]" Out; "MIN_DISPLAY[9]" Out; "MIN_DISPLAY[10]" Out; "MIN_DISPLAY[11]" Out; "MIN_DISPLAY[12]" Out; "MIN_DISPLAY[13]" Out; "SPEAKER_OUT" Out; } SignalGroups { "all_inputs" ’"ALARM" + "BSD_TDI" + "BSD_TEST_CLK" + "BSD_TMS" + "BSD_TRST" + "CLK" + "HRS" + "MINS" + "RESETN" + "SET_TIME" + "TEST_MODE" + "TEST_SE" + "TEST_SI" + "TOGGLE_SWITCH"’; // #signals=14 "all_outputs" ’"AM_PM_OUT" + "BSD_TDO" + "HR_DISPLAY[0]" +

4

Preparing your RTL Design for Design Rule Checking Defining the Test Protocol

"HR_DISPLAY[1]" + "HR_DISPLAY[2]" + "HR_DISPLAY[3]" + "HR_DISPLAY[4]" + "HR_DISPLAY[5]" + "HR_DISPLAY[6]" + "HR_DISPLAY[7]" + "HR_DISPLAY[8]" + "HR_DISPLAY[9]" + "HR_DISPLAY[10]" + "HR_DISPLAY[11]" + "HR_DISPLAY[12]" + "HR_DISPLAY[13]" + "MIN_DISPLAY[0]" + "MIN_DISPLAY[1]" + "MIN_DISPLAY[2]" + "MIN_DISPLAY[3]" + "MIN_DISPLAY[4]" + "MIN_DISPLAY[5]" + "MIN_DISPLAY[6]" + "MIN_DISPLAY[7]" + "MIN_DISPLAY[8]" + "MIN_DISPLAY[9]" + "MIN_DISPLAY[10]" + "MIN_DISPLAY[11]" + "MIN_DISPLAY[12]" + "MIN_DISPLAY[13]" + "SPEAKER_OUT"’; // #signals=31 "all_ports" ’"all_inputs" + "all_outputs"’; // #signals=45 "_pi" ’"all_inputs"’; // #signals=14 "_po" ’"all_outputs"’; // #signals=31 } ScanStructures { ScanChain "c0" { ScanLength 40; ScanIn "TEST_SI"; ScanOut "SPEAKER_OUT"; } } Timing { WaveformTable "_default_WFT_" { Period ’100ns’; Waveforms { "all_inputs" { 0 { ’5ns’ D; } } "all_inputs" { 1 { ’5ns’ U; } } "all_inputs" { Z { ’5ns’ Z; } } "all_outputs" { X { ’0ns’ X; } } "all_outputs" { H { ’0ns’ X; ’95ns’ H; } } "all_outputs" { T { ’0ns’ X; ’95ns’ T; } } "all_outputs" { L { ’0ns’ X; ’95ns’ L; } } "CLK" { P { ’0ns’ D; ’45ns’ U; ’55ns’ D; } } "BSD_TEST_CLK" { P { ’0ns’ D; ’45ns’ U; ’55ns’ D; } } "RESETN" { P { ’0ns’ U; ’45ns’ D; ’55ns’ U; } } } } } PatternBurst "__burst__" { "__pattern__" { } } PatternExec { Timing ""; PatternBurst "__burst__"; }

5

Preparing your RTL Design for Design Rule Checking Defining the Test Protocol

Procedures { "load_unload" { W "_default_WFT_"; V { "BSD_TEST_CLK"=0; "BSD_TRST"=0; "CLK"=0; "RESETN"=1; "TEST_MODE"=1; "TEST_SE"=1; "_so"=#; } Shift { W "_default_WFT_"; V { "BSD_TEST_CLK"=P; "BSD_TRST"=0; "CLK"=P; "RESETN"=1; "TEST_MODE"=1; "TEST_SE"=1; "_so"=#; "_si"=#; } } } "capture" { W "_default_WFT_"; F { "BSD_TRST"=0; "TEST_MODE"=1; } V { "_pi"=\r14 #; "_po"=\r31 #; } } "capture_CLK" { W "_default_WFT_"; F { "BSD_TRST"=0; "TEST_MODE"=1; } "forcePI": V { "_pi"=\r14 #; } "measurePO": V { "_po"=\r31 #; } "pulse": V { "CLK"=P; } } "capture_BSD_TEST_CLK" { W "_default_WFT_"; F { "BSD_TRST"=0; "TEST_MODE"=1; } "forcePI": V { "_pi"=\r14 #; } "measurePO": V { "_po"=\r31 #; } "pulse": V { "BSD_TEST_CLK"=P; } } "capture_RESETN" { W "_default_WFT_"; F { "BSD_TRST"=0; "TEST_MODE"=1; } "forcePI": V { "_pi"=\r14 #; } "measurePO": V { "_po"=\r31 #; } "pulse": V { "RESETN"=P; } } } MacroDefs { "test_setup" { W "_default_WFT_"; V { "BSD_TEST_CLK"=0; "CLK"=0; } V { "BSD_TEST_CLK"=0; "BSD_TRST"=0; "CLK"=0; "RESETN"=1; "TEST_MODE"=1; } } }

6

Preparing your RTL Design for Design Rule Checking Defining the Test Protocol

Note: The read_init_protocol command only imports the test_setup section of the protocol file and ignores the remaining sections.

Design Examples This section contains two simple design examples that illustrate how to generate test protocols. The first example shows how to use the set_signal_type command to control the clock signal, the scan-enable signal, and the asynchronous reset. The second example decribes a two-pass process for defining an initialization sequence in a test protocol.

Test Protocol Example 1 Figure 1 shows a schematic and the Verilog code for a simple RTL design that needs a test protocol. Figure 1 RTL Design that Needs a Simple Protocol

out1 in2 in3 in1 clk

out2

U2 U1

cdn

module tcrm (in1, in2, in3, clk, cdn, out1, out2); input in1, in2, in3, clk, cdn; output out1, out2; reg U1, U2; wire gated_clk; always @(posedge clk or negedge cdn) begin if (!cdn) U1