Building Scan Chains: v1999.10 Scan Synthesis Reference Manual

v1999.
10 Scan Synthesis Reference Manual
8
Building Scan Chains 8
The insert_scan command builds scan chains and connects test
signals. The hierarchical scan insertion capability allows you to
specify scan chain designs and to implement a top-down, bottom-up,
or middle-out hierarchical scan insertion flow.
The following sections in this chapter explain how to build scan chains:
• Hierarchical Scan Insertion

• Generating a Default Scan Design
• Specifying a Scan Design
• Previewing a Scan Design
• Building Scan Chains in a Design
• Displaying Test Information on the Current Design
• Using Partial Scan
HOME CONTENTS INDEX / 8-1

v1999.10 Scan Synthesis Reference Manual
• Design Considerations for Scan Designs
Hierarchical Scan Insertion
With the DC Expert Plus hierarchical scan insertion capability, you

can
• Implement automatically balanced scan chains

• Specify complete scan chains
• Generate scan chains that enter and exit a design module multiple
times
• Reuse existing modules that already contain scan chains
• Control the routing order of scan chains in hierarchy
• Perform scan insertion from the top or from the bottom of the
design
• Implement automatically enabling or disabling logic for
bidirectional ports and internal three-state logic
• Implement automatically multiplexed and enabling or disabling
logic to shared function ports as test data ports
With hierarchical scan insertion, you can design scan chains using a
specify-preview-synthesize process, which consists of multiple
specification and preview iterations to define an acceptable scan
design. After the scan design is acceptable, you can invoke the
synthesis process to insert scan chains. Figure 8-1 shows this
specify-preview-synthesize process.

Figure 8-1 The Hierarchical Scan Insertion Design Process
Scan Chain Design
Specification Synthesis
Reporting Preview
User dc_shell script Modified Scan Chain Design
"what-is" report
"what-shall be"
report
TC-generated
dc_shell script
Example 8-1 is a basic hierarchical scan script.
Example 8-1 Basic Hierarchical Scan Script

dc_shell> current_design Top
dc_shell> check_test
dc_shell> set_scan_configuration -chain_count 1
dc_shell> preview_scan
dc_shell> insert_scan
dc_shell> report_test -scan_path
dc_shell> report_constraints -all_violators

In this example, set_scan_configuration -chain_count 1 is the

specification command. It specifies a single scan chain in the design.
The preview_scan command is the preview command. It builds the
scan chain and produces a range of reports on the proposed scan
architecture. The insert_scan command is the synthesis command.
It implements the proposed scan architecture. The following sections
describe these steps in the hierarchical design process.
Specification Process
During the specification phase, you use the scan specification

commands to describe how the insert_scan command should
configure the scan chains. You can apply the commands interactively
from the dc_shell or use them within design scripts. The specification
commands annotate the database but do not otherwise change the
design. They do not cause any logic to be created or any scan routing
to be inserted.
Using the scan specification commands, you can specify as little or

as much scan detail as you want. If you choose not to specify any
scan detail, the insert_scan command implements the default full-
scan methodology. If you choose to completely specify the scan
design that you require, you explicitly assign every scan element to
a specific position in a specific scan chain. You can also explicitly
define the pins to use as scan control and data pins.
Alternatively, you can create a partial specification, where you define

some elements but do not issue a complete specification. If you issue
a partial specification, the preview_scan command creates a
complete specification during the preview process.

The scan specification commands are
• set_scan_configuration
• set_scan_path
• set_scan_signal
• set_scan_element
• set_scan_segment
• set_scan_link
• remove_scan_specification
These commands are described in detail later in this chapter.
The scan specification commands apply only to the current design

(as determined by the current_design command) and to lower-level
subdesigns within the current design. If you want to do hierarchical
scan insertion using a bottom-up approach, use the following general
procedure:
1. Set the current design to a lower-level subdesign (current_design

command).
2. Set the scan specifications for the subdesign (set_scan_path,
set_scan_element, and so on).
3. Insert the scan cells and scan chains into the subdesign
(check_test, preview_scan, and insert_scan).
4. Repeat steps 1, 2, and 3 for each subdesign, at each level of
hierarchy, until you finish scan insertion for the whole design.

By default, the insert_scan command recognizes and keeps scan

chains already inserted into subdesigns at lower levels. Thus, you
can use different sets of scan specifications for different parts or levels
of the design, by using insert_scan separately on each part or level.
Note that each time you use the current_design command, any
previous scan specifications no longer apply. This means that you
need to enter new scan specifications for each newly selected design.
Preview Process
The preview_scan command produces a scan chain design that

satisfies scan specifications on the current design and displays the
scan chain design for you to preview. If you do not like the proposed
implementation, you can iteratively adjust the specification and rerun
preview until you are satisfied with the proposed design.
The preview process (preview_scan command) performs two tasks:
• It checks the specification for consistency. For example, you

cannot assign the same scan element to two different chains.
• It creates a complete specification if you have specified only a
partial specification.
Using preview_scan, you can create a dc_shell script that completely
specifies the proposed implementation. You can edit this script and
use the edited script as an alternative means of iterating to a scan
design that meets your requirements.

The preview_scan command does not annotate the database. If you

want to annotate the database with the completed specification, use
the -script option to create a specification dc_shell script, then run
this script. The specification commands in this script add attributes
to the database.
The preview_scan command is described later in this chapter.
Synthesis Process
You invoke the synthesis process using the insert_scan command,

which implements the scan design determined by the preview
process. If you issue this command without explicitly invoking the
preview process, the insert_scan command transparently runs
preview_scan.
Execute the check_test command at least once before executing

insert_scan. Executing check_test provides information on testability
that is necessary before inserting scan into your design.
The insert_scan command is described later in this chapter.
Generating a Default Scan Design
If you do not specify any scan detail, the insert_scan command

implements a default scan design using the full-scan methodology.
This section describes the ground rules that the preview_scan and
insert_scan commands apply to generate a default scan design.

The insert_scan command performs the following tasks as it

implements a default full-scan design:
• Unscans scan-replaced elements from compile -scan or a

previous scan insertion if test design rule violations prevent their
inclusion in a scan chain.
• Scan-replaces sequential elements if you did not previously
perform a scan replacement on sequential elements.
• Allocates scan elements to scan chains.
- Allocates scan elements to produce the minimum number of
scan chains consistent with clock domain requirements. By
default, the insert_scan command generates a scan design
with the number of scan chains equal to the number of clock
domains. The resulting design contains one scan chain for each
set of sequential elements clocked by the same edge of the
same test clock.
- Automatically infers existing scan chains both in the current
design and in subdesigns. This is only true if the design has the
proper attributes.
- Does not reroute existing scan chains built by the insert_scan
command or subdesign scan chains built by the insert_scan
command, even if the existing routing does not conform to
default behavior.
- Orders scan elements in scan chains alphanumerically. By
default, the insert_scan command alphanumerically orders
scan elements within scan chains across the full hierarchical
path specification of the scan element name.
• Automatically inserts and routes global test signals to support the
specified scan style. These test signals include clocks and enable
signals.

• Allocates ports to carry test signals. Where possible, the

insert_scan command uses mission (normal function) ports to
carry scan out ports and inserts multiplexing logic, if required. The
insert_scan command performs limited checking for existing
multiplexing logic to prevent redundant insertion.
• Inserts three-state and bidirectional disabling logic during default
scan synthesis. The insert_scan command checks for existing
disabling logic to prevent redundant insertion.
If the current design includes pad cells, the insert_scan command
identifies the pad cells and correctly inserts test structures next to
them by
• Ensuring correct core-side hookup to all pad cells and three-state

drivers
• Inserting required logic to force bidirectional pads carrying scan-
out signals into output mode during scan shift
• Inserting required logic to force bidirectional pads carrying scan-
in, control, and clock signals into input mode during scan shift
• Determining requirements and, if necessary, inserting required
logic to force all other nondegenerated bidirectional ports into
input mode during scan shift
• Inserting required logic to enable three-state output pads
associated with scan-out ports during scan shift
By default, the insert_scan command uses constraint-optimized scan
insertion to reduce scan-related performance and area impact by
minimizing constraint violations and eliminating compile design-rule
errors. For consistency with Design Compiler, insert_scan uses the
clock waveforms described by create_clock to determine whether a
logic path meets performance constraints. The insert_scan command

does not use the timing values described using create_test_clock for
constraint optimization. The insert_scan command also selects scan-
out signal connections (Q or QN) to minimize constraint violations.
For information about constraint-optimized scan insertion, see

“Building Scan Chains in a Design” later in this chapter. That section
includes details on default behavior and describes how you can
control the fixing of compile design rules and performance constraint
violations using the insert_scan options -map_effort and
-ignore_compile_design_rules.
Scan chain synthesis is primarily concerned with the scan shift

operation. Problems associated with scan capture are identified by
check_test and might require user resolution of problems caused by
functional clock waveforms.
Scan chains synthesized by the insert_scan command are functional

under zero-delay assumptions. The insert_scan command
synthesizes scan chains that can be operated using default test
protocols generated by check_test. Such default protocols assume
zero skew and propagation delay. Before scan synthesis, you can
specify test clocks using create_test_clock. All test clocks have the
same period.
Specifying a Scan Design
The previous section described how the insert_scan command

implements a default scan design using the full-scan methodology if
you did not specify any scan detail. To alter this default scan design,
you must specify changes to the scan configuration. You can make
specifications at any point before scan synthesis.

This section describes the specification commands you can use. It

also includes information on how the preview_scan and insert_scan
commands resolve conflicts when your specifications are not
consistent and how the insert_scan command handles existing scan
chains.
DC Expert Plus and Test Compiler do not yet support the creation of
complex test and maintenance architectures where individual scan
cells are members of more than one chain.
Specification Commands
This section describes the scan specification commands.
Specifying a Scan Chain Design

Use the set_scan_configuration command to specify the scan chain
design. This command constrains almost all aspects of how the
insert_scan command makes designs scannable. The exceptions are
specific to particular scan chains and are included in set_scan_path
command options.
The syntax is
set_scan_configuration
[-add_lockup true | false]
[-bidi_mode input | output]
[-chain_count integer | default]
[-clock_gating entire_design | leaf_cell | superbuffer]
[-clock_mixing no_mix | mix_edges | mix_clocks
| mix_clocks_not_edges]
[-create_test_clocks_by_system_clock_domain true
| false]
[-dedicated_scan_ports true | false]
[-disable true | false]
[-existing_scan true | false]

[-hierarchical_isolation true | false]

[-internal_clocks true | false]
[-methodology full_scan | partial_scan | none]
[-multibit_segments true | false]
[-physical true | false]
[-replace true | false]
[-route true | false]
[-route_signals all | global | serial | clock
| scan_enable]
[-rebalance true | false]
[-style multiplexed_flip_flop | clocked_scan
| lssd |aux_clock_lssd | combinational | none]
-add_lockup true | false

Instructs insert_scan to insert lock-up latches between clock
domain boundaries on scan chains. The insert_scan command
inserts lock-up latches by default, so set this argument to false to
disable lock-up latch insertion. The insert_scan command ignores
the argument if the scan specification does not mix clocks on
chains.
-bidi_mode input | output

Specifies whether insert_scan configures bidirectional ports in a
design as inputs or outputs during scan shift. By default,
insert_scan turns bidirectional ports inward during scan shift to
eliminate any possibility of board-level contention. Set this
argument to output to turn bidirectional ports outward. The
insert_scan command ignores the argument if there are no
bidirectional ports or you set -disable to false.

-chain_count integer | default

Instructs insert_scan to build a specified number of scan chains
or to revert to its default behavior. By default, insert_scan builds
the minimum number of scan chains consistent with clock mixing
constraints. By specifying a positive integer, you tell insert_scan
to build exactly that number of chains.
-clock_gating entire_design | leaf_cell | superbuffer

Applies only when you are using a partial-scan methodology.
Instructs the insert_scan command about the kind of clock gating
logic to insert. Clock gating can be at the leaf cell or entire design
level. When you ask for super-buffer clock gating, the insert_scan
command infers a super-buffer in the scan clock tree, inserts clock
gating logic before the super-buffer, and inserts an additional
super-buffer at the root of the gated clock tree. By default, the
insert_scan command uses entire_design clock gating.
-clock_mixing no_mix | mix_edges | mix_clocks |

mix_clocks_not_edges]
Specifies whether the insert_scan command can include cells
from different clock edges or clock domains in the same scan
chain. For the default value no_mix, each scan chain can only
contain cells clocked by the same clock edge. For mix_edges,
each scan chain can contain cells clocked by different edges of
the same clock. For mix_clocks, each scan chain can contain cells
clocked by different clocks and clock edges. For
mix_clocks_not_edges, each scan chain can contain cells
clocked by different clocks, but only on the same edge type (either
rising or falling).

-create_test_clocks_by_system_clock_domain true | false

Associates dedicated test clocks with distinct clock domains. By
default, the insert_scan command does not use dedicated test
clocks. Instead, it creates and uses global test clocks.
-dedicated_scan_ports true | false

By default, the insert_scan command does not implement
dedicated scan-out signal ports on the current design. It uses
mission-mode ports as scan-out ports whenever possible. Set the
option to true to implement dedicated scan-out signal ports.
-disable true | false

By default, the insert_scan command inserts disabling logic. The
option ensures that, during scan shift, three-state buses have
exactly one active driver and that bidirectional port modes are
controlled. Set the option to false if you do not want to insert
disabling logic.
-existing_scan true | false

The insert_scan command assumes that designs it has not
processed do not have scan chains. Set the option to true if you
are using the check_test or insert_scan commands to process an
imported design that does have scan chains.
-hierarchical_isolation true | false

Instructs the insert_scan command to build hierarchical isolation
logic when you set the option to true. This means that dedicated
subdesign scan-out signals are gated by the design scan enable
signal. By default, the insert_scan command does not build
hierarchical isolation logic.

-internal_clocks true | false

Instructs the insert_scan command to treat an internal clock
driven by a multiple-input gate as a separate clock for the
purposes of building scan chains. By default, the insert_scan
command does not treat such clocks as separate.
-multibit_segments true | false

Determines how the insert_scan command treats multibit
registers. Set the option to true if you want the insert_scan
command to treat multibit registers as synthesizable segments.
Set the option to false if you want the insert_scan command to
treat each bit of all sequential multibit components individually
when building scan chains. By default, the insert_scan command
implicitly treats multibit registers as synthesizable segments.
-physical true | false

Determines whether the insert_scan command considers
physical clustering information and scan cell physical locations
when ordering or reordering scan cells in scan chains. Set the
option to true if you want physical information to be considered.
In that case, the information must be provided in Physical Design
Exchange Format (PDEF), version 2.0. Set the option to false (the
default setting) if you do not want physical information to be
considered. For details, see the chapter called “Assembling Scan
Structures” in the Scan Synthesis User Guide.
-methodology full_scan | partial_scan | none

Selects the test methodology. The insert_scan command makes
all sequential cells that do not violate scan design rules scannable
in full_scan methodologies. A partial_scan methodology trades
off the area and timing penalties of full scan at the expense of
testability and test pattern generation time by leaving valid

nonscan cells off scan chains. A methodology of none means that

no scan methodology has been selected for the design. By default,
the insert_scan command uses full_scan methodologies.
-replace true | false

By default, the insert_scan command replaces sequential cells
that are not violated by scan design rule checking with scan cells.
Set the option to false if you do not want scan replacement.
-route true | false

By default, insert_scan routes scan signals you specify in the
-route_signals option. If you do not use the -route_signals option,
insert_scan routes all scan signals. Set the option to false if you
do not want scan signal routing.
-route_signals all | global | serial | clock | scan_enable

By default, routes all scan signals (scan clocks, scan enables, and
serial signals such as scan_in and scan_out). Select global to
route scan clocks and scan enables only.
-rebalance true | false

By default, insert_scan respects existing scan chains, including
those in subdesigns, when building scan chains. Set the option
to true if you want insert_scan to split up existing scan chains to
produce scan architectures with more balanced scan chains.
-style multiplexed_flip_flop | clocked_scan | lssd | aux_clock_lssd |

combinational | none
Identifies the scan style. Select none if you have not selected a
scan style for the design. By default, insert_scan uses the scan
style value specified by environment variable
test_default_scan_style in your .synopsys_dc.setup file.

Specifying a Scan Chain for the Current Design

Use the set_scan_path command to specify a scan chain for the
current design. The set_scan_path command allocates scan cells,
subdesign scan chains, and scan links to scan chains and specifies
scan chain ordering.
Scan chain elements cannot belong to more than one chain. Where
set_scan_path commands conflict, the preview_scan and
insert_scan commands execute the most recent command.
The syntax is
set_scan_path
scan_chain_name
[ordered_list]
[-dedicated_scan_out true | false]
[-complete true | false]
scan_chain_name
This arbitrary text string gives the scan chain a name.
ordered_list
Defines scan chain elements. This ordered list can include
sequential cells, multibit components, design instances,
subdesign scan chains, and scan links. You can use wildcards
and dc_shell command expressions like all_registers(), filter(),
and find() to identify design objects.
It is possible for different objects to have the same name, such as

a multibit component and a sequential cell. If the ordered list
specifies such a name, the path definition might not work as you
expect. To prevent this problem, always define a new object such
as a multibit component using a unique name, different from the
name of any existing object.

-dedicated_scan_out true | false

The last scan cell in a chain can drive a port in mission mode. By
default, insert_scan uses this port as a scan-out port. Set the
option to true if you want insert_scan to always build a dedicated
scan-out port for the chain.
-complete true | false

The insert_scan command might add components to a specified
scan chain. Set the option to true to indicate to the preview_scan
and insert_scan commands that the chain specification is
complete and additional components must not be added.
Specifying Scan Signals for the Current Design

Use the set_scan_signal command to specify one or more scan
signals for the current design.
The syntax is
set_scan_signal
test_signal_type
[-port port_list]
[-hookup pin_name [-sense inverted | non_inverted]]
[-chain scan_chain_list]
test_signal_type
Describes the type of the signal. Valid types include test_clock,
test_scan_clock, test_scan_clock_a, test_scan_clock_b,
test_scan_enable, test_scan_enable_inverted, test_scan_in,
and test_scan_out (see Table 8-1). Validation ensures that
specified types are consistent with the design scan style.

-port port_list
Identifies design ports that insert_scan can use to transmit signals
of the specified type. Validation ensures that the port direction is
consistent with the signal type.
-hookup pin_name
By default, insert_scan command connects wires to the core side
of identified signal ports, jumping pads, and buffers as needed.
The -hookup option overrides this behavior and instructs
insert_scan to connect wires to a specific pin, which you specify
by name. The insert_scan command does the hookup without
checking its validity. After you run insert_scan, use check_test to
check the validity of the hookup. Validation ensures that the pin
direction is consistent with the signal type. You can associate a
specific access pin with only one design port.
-sense inverted | non_inverted

Describes the sense between a port and a hookup pin. Valid
values for sense are noninverted and inverted. The default value
is non_inverted. The -sense option is used only when a hookup
pin is specified. After you run insert_scan, use check_test to
check the validity of the hookup.

-chain scan_chain_list
By default, insert_scan assigns scan signals to scan chains. This
argument lets you make the assignment.
Table 8-1 Attribute Value Assignments for Test Signals

Valid on
three-state
Valid Valid output
Test I/O on on Valid on
port signal Attribute value input output bidirectional
Scan-in test_scan_in yes no no yes
Scan-out test_scan_out no yes yes yes
Test-clock test_clock yes no no no
A scan-clock test_scan_clock_a yes no no no
B scan-clock test_scan_clock_b yes no no no
Scan-enable test_scan_enable or yes no no *

test_scan_enable_inverted
Test-scan-clock test_scan_clock yes no no no
Bidirectional test_bidir_control or yes no no *

enables test_bidir_control_inverted
Asynchronous test_asynch or yes no no *

control ports test_asynch_inverted
*Not recommended: complex methodologies required.
The following is an example of the set_scan_signal command

specifying a scan-in port. If you enter
dc_shell> set_scan_signal test_scan_in -port scan_in
DC Expert Plus responds with

Performing set_scan_signal on port 'scan_in'.
where scan_in is the name of the scan-in port that the insert_scan
command will use.
When the insert_scan command creates additional ports for scan test
signals, it assigns a name to each new port. You can control the
naming convention by using the port naming style variables shown
in Table 8-2.
Table 8-2 Port Naming Style Variables

Name Default value
test_clock_port_naming_style test_c%s
test_scan_in_port_naming_style test_si%s%s
test_scan_out_port_naming_style test_so%s%s
test_scan_enable_port_naming_style test_se%s
test_scan_enable_inverted_port_naming_style test_sei%s
test_scan_clock_port_naming_style test_sc%s
test_scan_clock_a_port_naming_style test_sca%s
test_scan_clock_b_port_naming_style test_scb%s
Using the set_scan_signal Command Versus the

set_signal_type Command
It is important to know when to use the set_scan_signal command
and when to use the set_signal_type command.

Use the set_scan_signal command only for scan insertion and not
for design rule checking. The set_scan_signal command indicates
existing I/O ports that are to be used as scan ports. After the
insert_scan command connects these ports, it places the necessary
signal_type attributes on the ports for design rule checking.
Use the set_signal_type command if you read in an ASCII netlist and

you need to perform design rule checking. Before you use the
set_signal_type command, the ASCII netlist does not contain the
signal_type attributes annotated by scan insertion. Without these
attributes, check_test does not know which ports are scan ports and
reports that the design is untestable.
Note:
Before you use the insert_scan command on an existing scan
design that was not created by the insert_scan command, you
must identify all test ports in your design with the set_signal_type
command.
Suppressing Replacement of Sequential Cells

Use the set_scan_element command to determine whether specific
sequential cells are to be replaced by scan cells and become part of
the scan path during insert_scan.
For full-scan designs, insert_scan replaces all non-violated

sequential cells with equivalent scan cells by default. Therefore, you
do not need to set the scan_element attribute unless you want to
suppress replacement of sequential cells with scan cells. To prevent
such replacement for certain cells, set the scan_element attribute to
false for those cells.

Note:
If you want to specify which scan cells are to be used for scan
replacement, use the set_scan_register_type command. For
details, see “Specifying Scan Cells” on page 5-6.
The syntax of the set_scan_element command is
set_scan_element
true | false
[cell_design_ref_list]
[-multibit multibit_component_list]
true | false
A Boolean value that determines whether the specified cells are
to be replaced by scan cells in the design. Use false to prevent
replacement or true to allow replacement. The default setting is
true. This value is not case-sensitive.
cell_design_ref_list
A list of design objects for scan replacement. Objects can be any
of the following sequential types: cells (such as flip-flops and
latches, which can be mapped or unmapped), hierarchical cells
(containing flip-flops or latches), references, library cells, and
designs.
-multibit multibit_component_list
Use this option if one or more of the cells you are specifying are
multibit components. You can use a separate set_scan_element
command to specify multibit cells, or you can combine regular and
multibit cells in the same command as in the following example:
set_scan_element false cell_a -multibit mcell_b

Note:
You should not use the set_scan_element true command if you
use the compile -scan command to replace elements.
Identifying a Scan Segment

Use the set_scan_segment command to identify existing logic within
a current design as a scan segment.
Scan segments implement scan in a particular scan style. The

insert_scan command can include scan segments in scan chains by
connecting their access pins. The insert_scan command does not
scan-replace scan segment members unless the scan segment is a
multibit segment. The scan style determines how multibit segments
are scan-replaced and routed.
The syntax is
set_scan_segment
scan_segment_name
[-access signal_type_pin_pairs_list]
[-contains member_list]
[-synthesizable true | false | default]
[-reverse_order true | false]
scan_segment_name
Gives the scan segment a name. To prevent possible future
conflicts, choose a name that is different from the names of
existing objects. If the scan segment name is the name of a multibit
segment, the insert_scan command interprets the
set_scan_segment command as an explicit specification of a
synthesizable segment.

-access signal_type_pin_pairs_list
Instructs insert_scan how to access the segment. Consists of a
list of ordered pairs, each consisting of a scan signal type and a
design pin. Valid signal types include test_clock, test_scan_clock,
test_scan_clock_a, test_scan_clock_b, test_scan_enable,
test_scan_enable_inverted, test_scan_in, and test_scan_out.
Validation ensures that specified signal types are consistent with
the design scan style.
-contains member_list
Defines scan segment components. This ordered list can include
sequential cells, multibit components, and design instances. You
can use wildcards and dc_shell command expressions like
all_registers(), filter(), and find() to identify design objects.
It is possible for a multibit component to have the same name as

an existing object. If the member list contains such a name, the
segment definition might not work as you expect. To prevent this
problem, always define a new multibit component using a unique
name, different from the name of any existing object.
-synthesizable true | false | default
Indicates if the insert_scan command treats the multibit
component as a synthesizable segment. When set true, the
insert_scan command treats the multibit component as a unit
when building scan chains. When set false, it treats each single-
bit cell individually. When set to the default, the insert_scan
command treats multibit components according to their
specification in the scan configuration.
-reverse_order true | false

Instructs the insert_scan command to route a synthesizable
segment in the reverse order of its definition.

Declaring a Scan Link

Use the set_scan_link command to declare a scan link for the current
design. Scan links connect scan cells, subdesign scan chains, and
scan ports within scan chains. The insert_scan command supports
scan links that are implemented as wires and scan-out lock-up
latches.
The syntax is
set_scan_link
scan_link_name
wire | scan_out_lockup
scan_link_name
Indicates the name of the scan link.
wire | scan_out_lockup
Specifies the scan link type. This can be a wire or a lock-up latch
design that retimes scan cell scan-out signals.
Removing Scan Specifications

Use the remove_scan_specification command to remove scan
specifications from the current design. This command deletes
specifications made using the set_scan_configuration,
set_scan_link, set_scan_path, set_scan_segment, and
set_scan_signal commands. You can use the -all option to delete all
such specifications and other command options to delete specific
specifications.
Note that remove_scan_specification does not change your design.

It merely deletes specifications you have made.

You can use the remove_scan_specification command to remove

explicit specifications of synthesizable segments. When you remove
an explicit specification, the multibit component inherits the current
implicit specification.
Note:
The remove_scan_specification does not affect the settings made
with the set_scan_register_type command. These settings can
be removed by using the remove_scan_register_type command.
For details, see “Specifying Scan Cells” on page 5-6.
The syntax of the remove_scan_specification command is
remove_scan_specification
[-all]
[-chain chain_name_list]
[-configuration]
[-link link_name_list]
[-segment segment_name_list]
[-signal port_name_list]
-all
Removes all set_scan_path, set_scan_configuration,
set_scan_link, set_scan_segment, and set_scan_signal
command specifications from the design.
-chain chain_name_list
Removes all specifications that reference scan chains in
chain_name_list. Removes associated set_scan_path command
specifications from the design and updates set_scan_signal
command specifications.
-configuration
Restores set_scan_configuration command options to
default values.

-link link_name_list
Removes all specifications that reference scan links in
link_name_list. Removes associated set_scan_link command
specifications from the design and updates set_scan_path
command specifications.
-segment segment_name_list
Removes all specifications that reference scan segments in
segment_name_list. Scan segments in segment_name_list can
be synthesizable segment names. Removes associated
set_scan_segment command specifications from the design and
updates set_scan_path command specifications.
-signal port_name_list
Removes all specifications that reference scan signals associated
with design ports in port_name_list. Removes associated
set_scan_signal command specifications from the design.
Keeping Specifications Consistent

The set of user specifications contributing to the definition of the scan
design must be consistent. User-supplied specification commands
forming part of a consistent specification have the following
characteristics:
• Each specification command is self-consistent. It cannot contain

mutually exclusive requirements. For example, a command
specifying the routing order of a scan chain cannot specify the
same element in more than one place in the chain.

• All specification commands are mutually consistent. Two

specification commands must not impose mutually exclusive
conditions on the scan design. For example, two specification
commands that place the same element in two different scan
chains are mutually incompatible.
• All specification commands yield a functional scan design. You
cannot impose a specification that leads to a nonfunctional scan
design. For example, a specification that mandates fewer scan
chains than the number of incompatible clock domains is
not permitted.
The number of clock domains in your design, together with your clock
mixing specification, determines the minimum number of scan chains
in your design. If you specify an exact number of scan chains smaller
than this minimum, the insert_scan command issues a warning
message and implements the minimum number of scan chains.
Existing Scan Chains

The insert_scan command identifies and respects existing scan
chains in lower-level modules where you either have inserted these
scan chains using insert_scan or have imported them and run
check_test to identify them as valid scan chains. By default, the
insert_scan command does not reroute existing scan structures. In
default mode, invoking preview_scan at the top level results in the
definition of a scan design with existing scan chains that appear as
inviolate.
If you want the insert_scan command to reroute existing chains to

produce balanced designs, use set_scan_configuration -rebalance
true. This command explicitly instructs the insert_scan command to
modify existing scan chains to produce balanced designs as needed.

Outmoded Specification Commands

DC Expert Plus and Test Compiler support certain outmoded
commands that are scheduled to become obsolete in the next
release. Preferred commands that were introduced in Test Compiler
v3.4b offer superior function and should be used instead.
Table 8-3 lists the preferred hierarchical specification commands and

the outmoded commands that they supersede. If you need more
information on the outmoded commands listed in the table, see the
man pages.
Table 8-3 Scan Specification Commands

Task Preferred command Outmoded command
Specify scan style set_scan_configuration -style set_scan_style
Specify full or partial scan set_scan_configuration set_test_methodology

-methodology
Specify that a design contains set_scan_configuration set_test_methodology

scan chains -existing_scan -existing_scan
Specify the membership of set_scan_path set_scan_chain

scan chains
Specify scan chain routing order set_scan_path set_test_routing_order
Specify desired test ports set_scan_signal set_signal_type*
Include or exclude an element set_scan_element set_scan true|false

from a scan path
Specify scan a transparent latch set_scan_transparent - set_scan -transparent

existing
*The set_signal_type command is only outmoded as a way to specify a pin you want insert_scan
to use as a test pin (a desired test port for scan insertion). Use the set_scan_signal command
for this purpose instead. Continue to use the set_signal_type command to specify a pin that is
already used as a test pin (an existing test port for design rule checking).

You should use preferred commands in new scripts. Existing scripts

that use outmoded commands should be updated to use the new
commands because the outmoded commands will no longer be
supported in the next release (2000.04).
Previewing a Scan Design
Use the preview_scan command to preview a scan design. The

command generates a scan chain design that satisfies scan
specifications on the current design and displays the scan chain
design. This allows you to preview your scan chain designs without
synthesizing them, and change your specifications to explore the
design space as necessary. Example 8-2 is an example of the display
generated by the preview_scan command.
The preview_scan and insert_scan commands use the same

algorithms to design scan chains. For more information, see
“Designing Scan Chains,” earlier in this chapter.
Example 8-2 Display Generated by the preview_scan Command

****************************************
Preview scan report
Design: P
Version: 1998.02
Date: Wed Apr 21 11:25:53 1999
****************************************
Number of chains: 1
Test methodology: full scan
Scan style: multiplexed_flip_flop
Clock domain: no_mix
Scan chain '1' (test_so) contains 4 cells

Using preview_scan Versus report_test
Use the preview_scan command when you want to preview scan

chain designs without synthesizing, and change specifications to
explore the design space as necessary. The preview_scan command
presents a view of what you are going to get.
Use report_test to display test-related information about the current

design. The report_test command presents a view of what you
currently have.
Using check_test Versus preview_scan
To understand the difference between the check_test and

preview_scan commands, consider the following sequence of
commands applied to a design with no scan chains yet implemented.
The first check_test command acts as a preprocessor to scan

insertion; it flags valid sequential cells for scan replacement. The
check_test command performs test design rule checking. This
includes checks to determine that sequential cells are able to reliably
capture data during the parallel capture cycle of the scan test
sequence. If check_test finds problems, it reports these problems.
For more information about check_test, see Chapter 6, “Checking
Test Design Rules.”

The preview_scan command uses the results of check_test (the list

of valid scan cells for scan replacement) and your scan specification.
It checks that the specification and design are consistent. For
example, it verifies that you have not included a sequential cell on a
scan chain where check_test has determined that the sequential cell
is not valid for scan replacement.
The preview_scan command then proposes a scan architecture,

including the number of scan chains, the design ports to be used as
scan ports, and the ordering of sequential cells in scan chains. The
command creates a scan architecture that can shift data through the
scan chains successfully using nonviolated scan cells. It does not
annotate the database.
You can iterate around the specification and preview processes until
you are satisfied with the proposed architecture. After you are
satisfied with the proposed architecture, use the insert_scan
command to implement the scan chains.
After you have inserted the scan chains, run check_test again. The
check_test command now checks that the scan chains are valid (can
successfully shift data in and out) and performs more checks to
determine that the scan cells can reliably capture data during the
parallel capture cycle of the scan test sequence.
If there is a problem with capture of data, this problem is independent

of the scan architecture proposed by the preview_scan command and
implemented by the insert_scan command.

Preview Command
The syntax for the preview_scan command is
preview_scan
[-command insert_scan | reoptimize_design]
[-script]
[-show cells | scan | scan_clocks | scan_signals
| segments | all]
-command insert_scan | reoptimize_design

Specifies the context for the preview_scan command. If you set
the -command option with the reoptimize_design value, the
preview_scan command takes the physical design information
into account to reorder scan chains. If you set the -command
option with the insert_scan value, the default, the preview_scan
command takes only logical domain information into account to
reorder scan chains. For more information, see the Scan
Synthesis User Guide.
-script
Instructs preview_scan to produce a dc_shell script that specifies
the defined scan design. The script is written to standard output.
-show cells | scan | scan_clocks | scan_signals | segments | all

Instructs preview_scan to report information of various types, in
addition to the summary report it produces by default. The option
takes a list of case-insensitive arguments in cells, scan, segments,
scan_clocks, and scan_signals, or the keyword all.

Building Scan Chains in a Design
Use the insert_scan command to build scan chains in the current

design. New scan circuitry is chosen from the technology library
specified in the target_library variable. You must define a target library
before you issue the insert_scan command.
The target library must contain cells that have been defined to operate
as scan cells. The insert_scan command uses these scan cells to
replace nonscan sequential logic used in the design. The library
describes each scan cell’s test characteristics, the test input/output
signal characteristics, and multibit characteristics (if any).
For information on the scan cells in the technology library you are
using, see your ASIC vendor. For information on creating technology
library elements in general, see the Library Compiler Reference
Manual, Volume 1. For information on modeling scan cells in
particular, see the chapter called “Defining Test Cells” in the Library
Compiler User Guide, Volume 1.
The insert_scan command supports top-down, bottom-up, and

middle-out scan insertion methodologies. In the process of adding
test circuitry, insert_scan creates testable versions of the subdesigns
and top-level design. Write all these new designs to disk using the
write command. For subdesigns that are made testable, insert_scan
creates new designs in the database that are distinct from the original
subdesigns. The insert_scan command names the new subdesigns
according to the value of the insert_test_design_naming_style
variable. The name of the current design is not changed during
insert_scan.

Preparing for Scan Insertion
Prior to running insert_scan, you need to set design constraints,

define any test modes, specify test ports, and identify and mark any
cells that you do not want to have scanned.
Setting Design Constraints

You should set constraints prior to running insert_scan because it
minimizes constraint violations. Use Design Compiler commands to
set area and timing constraints on your design. If you have already
compiled your design, you do not need to reset your constraints. For
more information about setting area and timing constraints on your
design, see the Design Compiler Reference Manual: Constraints and
Timing.
Defining a Test Mode

If your design requires a static test mode to satisfy design rules or to
enable circuit paths, you need to use the set_test_hold command.
For more information, see Chapter 6, “Checking Test Design Rules.”
Specifying Test Ports

The insert_scan command adds scan signals that use existing ports
identified using set_scan_signal commands. If no such ports are
found, new ports are added to the design. The insert_scan command
names the new ports according to the following variables:
• test_clock_port_naming_style
• test_scan_clock_a_port_naming_style

• test_scan_clock_b_port_naming_style
• test_scan_clock_port_naming_style
• test_scan_enable_inverted_port_naming_style
• test_scan_enable_port_naming_style
• test_clock_in_port_naming_style
• test_clock_out_port_naming_style
For more information on specifying test ports, see the earlier section
“Specifying Scan Signals for the Current Design.”
Scan Insertion Command
The syntax for the insert_scan command is
insert_scan
[-map_effort low | medium | high]
[-ignore_compile_design_rules]
-map_effort low | medium | high

Optional argument specifying the relative amount of CPU time
spent during the mapping phase of insert_scan. The default is
medium. A low -map_effort executes critical path optimization on
logic that insert_scan adds to the design. A medium -map_effort
executes the same optimizations as -map_effort low. If constraints
are violated, it executes critical path optimizations on the entire
design. A high -map_effort executes the same optimizations as -
map_effort medium. If constraints are violated, it applies
sequential mapping to nonscan cells on critical paths. It also tries
to reduce design area by eliminating inverters and downsizing
cells off critical paths.

To instruct the insert_scan command to ignore optimization

constraints, set the environment variable
test_dont_fix_constraint_violations to true.
-ignore_compile_design_rules
Indicates that insert_scan is to exit before correcting compile
design rule violations. This option allows you to check the results
in a constraint report before correcting the violations. By default,
insert_scan corrects compile design rule violations (for example,
max_transition, max_fanout, max_capacitance, and min_path)
and performs mapping optimization before exiting.
For example, to add test circuitry to the design WC66, enter the
following:
dc_shell> current_design WC66

The insert_scan command produces the following
Loading design ’WC66’

Checking test design rules
Architecting Scan Chains
Inserting Scan Cells
Routing Scan Chains
Routing Global Signals
Mapping New Logic
Beginning Mapping Optimizations
OPTIMIZATIONDESIGN RULE
TRIALS AREA DELTA DELAY COST COST
-------- ------ ----------- ------ ------
108 506.00.93 544.0 0.0
186 499.00.90 538.4 0.0
91 483.0 0.87 521.7 0.0
. . .
209 446.0 0.00 505.0 0.0
------
2684

Transferring design ’MOORE’ to database ’MOORE.db’

Transferring (new) design ’CHARLTONS_test_1’ to database
’CHARLTONS.db’
Transferring (new) design ’STILES_test_1’ to database
’STILES.db’
Transferring (new) design ’HURST_test_1’ to database
’HURST.db’
Transferring design ’WC66’ to database ’WC66.db’
The insert_scan Process
The following sections describe the tasks that the insert_scan

command performs as it adds scan circuitry to a design.
Checking Test Design Rules

If check_test information is out-of-date, the insert_scan command
invokes test design rule checking for the specified test methodology
and scan style. Design rule checking infers a design test protocol,
which includes clock information that scan insertion retrieves. Design
rule checking also violates cells that cannot belong to scan chains.
When the insert_scan command invokes test design rule checking,

test design rule checking runs without issuing any warning or error
messages. If the test design rule checking finds violations, it issues
the message
Warning: Violations occurred during test design rule

checking. (TEST-124)
It is very important that you check and then fix, or at least understand
and accept, any violations that test design rule checking finds.

Note that it is a much better practice to use the check_test command

explicitly and to read the violation reports before you use the
insert_scan command. The insert_scan command only runs the
check_test command if you did not explicitly use the check_test
command before the insert_scan command. Therefore, you do not
save time if you omit the check_test command.
For more information on design rule checking, refer to Chapter 6,

“Checking Test Design Rules.”
Designing Scan Chains

Next, the insert_scan command constructs a scan chain design. You
can use the preview_scan command to view the proposed
architecture without synthesizing it. By default, the insert_scan
command constructs as many scan chains as there are clocks and
edges. You can instruct the insert_scan command to create fewer
chains by setting the set_scan_configuration argument -clock_mixing
to mix_edges, mix_clocks, or mix_clocks_not_edges. You can
instruct the insert_scan command to build more scan chains by
setting the set_scan_configuration argument -chain_count. You can
instruct the insert_scan command to treat internal clocks driven by
multiplexers or other multiple input gates as a separate clock when
building scan chains by setting the set_scan_configuration argument
-internal_clocks.The insert_scan command also constructs multiple
scan chains to reflect the assignment of scan cells to scan chains
with the set_scan_path command.
When the insert_scan command constructs multiple scan chains,

scan cells are allocated to scan chains based on the following:
1. set_scan_path commands
2. Clock signals in the design

3. Names of individual scan cells or segments

Scan cells are ordered on scan chains, creating good scan chains
while minimizing clock domain crossings based on
1. set_scan_path command position

2. Scan clock trigger times
3. Port connectivity (output port of current_design directly driven by
a scan cell)
4. Clock domains
5. Scan cell names
The insert_scan command overrides set_scan_path command
positions if you specify an illegal ordering.
Internal Clocks
For the purpose of building scan chains, the insert_scan command,
by default, treats all internal clock signals driven by the same top-level
port as the same clock signal.
For example, the insert_scan command treats the internal clocks

CLK1 and CLK2 in Figure 8-2 as the same top-level clock, CLK.

Figure 8-2 Circuit With Same Top-Level Clock Driving Internal Clock Signals
D1
reg1
CLK1
CLK
OP1
D2
reg2
CLK2
PLL
test mode
By default, the insert_scan command creates a single scan chain, as

shown in Figure 8-3.
Figure 8-3 Default Scan Chain
test_si
reg1
test_so
reg2
Note: The rest of the circuit is unchanged.

Note that the multiplexer on CLK2 delays the arrival of the clock at
reg2. This can cause a hold-time violation, unless you enable hold-
time violation fixing using the set_fix_hold command. If you enable
hold-time violation fixing (set_fix_hold CLK) before building scan
chains, the insert_scan command adds buffers to the scan
connection between reg1/Q and reg2/TI.
You can avoid creating the hold-time violation by assigning the two
flip-flops to separate scan chains. To do this, use the following
command:
dc_shell> set_scan_configuration -internal_clocks true
This command instructs the insert_scan command to treat internal

clocks driven by multiplexers or other multiple input gates as separate
clocks.
If you use the default setting of no mixed clocks

(set_scan_configuration -clock_mixing no_mix) or use a setting of
mixed edges (set_scan_configuration -clock_mixing mixed_edges),
the insert_scan command places reg1 and reg2 on separate scan
chains as shown in Figure 8-4.
Figure 8-4 Default Scan Chain With set_scan_configuration

-internal_clocks true
test_si1 test_so1
reg1
test_si2 test_so2
reg2

If you use mixed clocks (set_scan_configuration -clock_mixing

mix_clocks or mix_clocks_not_edges), the insert_scan command
creates a single scan chain with a lockup latch between reg1 and
reg2, as shown in Figure 8-5.
Figure 8-5 Scan Chain With set_scan_configuration -clock_mixing

mix_clocks -internal_clocks true
reg1
lockup
reg2
Note: The rest of the circuit is unchanged.
You can enable the same behavior on just one clock line by using the
-internal_clocks option of the create_test_clock command. Using the
circuit shown in Figure 8-2, the following command tells the
insert_scan command to treat only internal clocks driven by the CLK
clock line as separate clocks:
dc_shell> create_test_clock CLK -wave {45 55} -internal_clocks

true
If you set opposing values using the set_scan_configuration

command and the create_test_clock command, then the value from
the create_test_clock command takes precedence. For example,
assume you set the following opposing values on the circuit in Figure
8-2 using these two commands:
dc_shell> set_scan_configuration -internal_clocks false

dc_shell> create_test_clock CLK -wave {45 55} -internal_clocks
true

Because the value set by the create_test_clock command takes

precedence, signals driven by CLK via multiplexers or other multiple-
input gates are treated as separate clocks. All other clocks in the
design are treated according to the default configuration. Therefore,
CLK and CLK2, shown in Figure 8-2, are treated as different clocks.
Note:
The -internal_clocks option only affects scan chain building for the
multiplexed flip-flop scan style.
Scan Replacement
The insert_scan command does not perform scan replacement on a
design in two cases. The first case is when you specify no scan
replacement. You do this by using the set_scan_configuration
-replace false command.
The second case is when you previously used the compile -scan
command to synthesize and optimize your design. The compile -scan
command implements all of the flip-flops in the design with scan flip-
flops. The insert_scan command identifies the flip-flops as scan flip-
flops, skips scan replacement, and issues a warning message that it
did not perform scan replacement.
If the set_scan_configuration command has not been invoked with a

-replace false argument, the insert_scan command replaces
sequential cells with their scan equivalents. The insert_scan
command does not replace cells that are violated, scan or
scan_element false, or dont_touch. The form of scan cells and signals
that insert_scan uses depends on the scan style previously defined
with the -style option to the set_scan_configuration command or
test_default_scan_style variable.

The insert_scan command applies a scan equivalence process to all

other cells. The scan equivalence process first selects scan
equivalents based on library function identifiers. If the insert_scan
command does not find a scan equivalent for a storage element, it
uses sequential mapping techniques. These techniques consider the
logic function implemented by each flip-flop instance to be scan-
replaced, along with immediately surrounding logic. This
consideration generates a set of possible alternatives, and the
insert_scan command selects the best replacement based on scan
style, design area, and design rule considerations such as connection
classes and maximum fanout.
If insert_scan selects a replacement cell that is not the one you

expect, it could be due to the lower implementation cost of the
selected cell. Another possibility is a technology library with incorrect
or missing information. If you suspect the latter, contact the ASIC
vector for more information.
You can disable sequential mapping based scan equivalence by

setting the insert_test_map_effort_enabled variable to false. By
default, sequential mapping based scan equivalence is enabled.
You might want to specify which flip-flop scan cells in the target library
are to be used for replacing nonscan cells in the design. In that case,
use the set_scan_register_type command. This command restricts
the choices of scan cells available for scan replacement. You can
apply this restriction to the current design, to particular designs, or to
particular cell instances in the design. For details, see “Specifying
Scan Cells” on page 5-6.

Unscanning Elements
Unscanning an element takes place when the insert_scan command
remaps a scannable sequential cell that causes a design rule violation
to a nonscan cell. The insert_scan command unscans sequential
elements in the following cases:
• If you performed a compile -scan operation and there are design

rule violations in the design, the insert_scan command unscans
sequential elements.
By default, the compile -scan command performs scan
replacement on all sequential cells in your design. If there are
design rule violations in your design, the insert_scan command
might be unable to place all scan cells on chains because doing
so would create a nonfunctional scan chain.
For example, Figure 8-6 shows a simple compile -scan design

with a serious design rule violation. The insert_scan command
cannot place FF2 on a scan chain because its asynchronous reset
is not controllable during scan shift.
Figure 8-6 Design With Scan Flip-Flops
D2
OUT1
D1
FF1 FF2
CLK
Figure 8-7 shows the effects of running the insert_scan command

on the design shown in Figure 8-6.

Figure 8-7 Design After the Unscanning Process
D2
test_so
test_si OUT1
D1
test_se
FF1 FF2
CLK
• If you performed a bottom-up scan insertion and there are serious

design rule violations that would prevent the successful operation
of the chain, the insert_scan command unscans sequential
elements that violate design rules. For example, the insert_scan
command unscans sequential elements that violate design rules
if there are asynchronous set/reset inputs to a module that are
drivers from another module.
Disabling Three-State Buses

The insert_scan command ensures that three-state buses and
bidirectional ports are properly configured during scan shift. This step
is skipped if the set_scan_configuration command is executed with
a false -disable option.
The insert_scan command avoids adding redundant logic by ignoring

buses and bidirectional ports that are configured properly.

Having identified candidate buses, insert_scan determines the

configuration logic needed. The insert_scan command iterates
through all three-state bus drivers and computes the logic values that
must be applied to input pins to configure the bus. The insert_scan
command cannot compute the logic values if
• A bus driver belongs to a design that has a dont_touch attribute

• The insert_scan command could not disable any of the three-state
drivers
• Conflicting logic values are necessary to disable three-state
drivers
• Disabling values conflict with those of previous buses
When the insert_scan command does not encounter any of these
conditions, it adds generic configuration logic, where needed. The
insert_scan command finds all pins that do not hold the values
needed during scan shift, and gates them.
The insert_scan command issues the following warning messages

when it does not disable a three-state bus:
Warning: There exists a cell %s on the bus which is not

controllable. So the tristate disabling logic on this bus
is not synthesized. (TEST-591)
Warning: There is a contention while controlling cell %s on

the bus. So the tristate disabling logic on this bus is not
synthesized. (TEST-592)
Configuring Bidirectional Ports

The insert_scan command configures all bidirectional ports by adding
gates to force bidirectional ports into input mode or output mode, as
appropriate, when the scan-enable signal is asserted. The

insert_scan command only configures bidirectional ports that have

exactly one three-state driver (unless that driver belongs to a
dont_touch design). It does not configure the following:
• Ports used to apply scan-enable signals to the design

• Bidirectional ports that are configured as inputs or outputs by
constant logic values
The insert_scan command establishes the configuration direction for
other ports during scan shift. The command turns scan outputs
outwards, and turns other scan signals inwards. By default, the
command turns all other bidirectional ports inwards. To turn them
outwards, use the -bidi_mode argument to the
set_scan_configuration command.
Again, the insert_scan command computes the logic values that must
be applied to driver input pins to configure each port. The insert_scan
command cannot apply the logic values if the required logic values
conflict with previous logic values. If this does occur, insert_scan adds
generic configuration logic where needed. Then insert_scan finds all
pins that do not hold the values needed during scan shift, and it gates
them.
Routing Scan Chains

The insert_scan command routes scan chains if the
set_scan_configuration command
• Has been invoked with a -route_signals all | global | serial

argument
• Has not been invoked with a -route false argument

For each chain, insert_scan determines the scan-in pin. The

insert_scan command looks first for test_scan_in signals specified
using set_scan_signal commands. The insert_scan command then
looks for design ports with test_scan_in signal_type attributes. If
insert_scan finds no such ports, it creates a dedicated scan-in port
for the chain.
The insert_scan command jumps over connected pads and through

input buffers. Starting at the load pin, it jumps over single-fanout
inverters and buffers to find a better hookup pin. Scan sense is toggled
if the jump causes inversions.
Given the best hookup pin, scan insertion builds the rest of the chain.
The insert_scan command uses the preferred routing order specified
with the set_scan_path command to route between serial signals and
scan cells. If no preferred order is specified, insert_scan uses a
default ordering scheme.
If set_scan_configuration has not been invoked with a false

-add_lockup argument, insert_scan inserts lockup latches at clock
domain boundaries. This compensates for clock skew and ensures
a glitch-free scan shift. You can also specify where to add lockup
latches using set_scan_link to define a scan-out lockup latch and
set_scan_path to include it in the scan chain.
You can override insert_scan using set_scan_link to define a wire

and include it in the scan chain using set_scan_path.
The insert_scan command multiplexes a test_scan_in access pin into

functionally connected scan segments. The insert_scan command
does not recognize a pin as functionally connected if the pin
• Is not connected to a net

• Is connected to a net that is held at a constant logic value

• Was created using the insert_scan command

• Is a driver and does not have a load, or is connected to a subdesign
output port created using the insert_scan command
• Is a load and does not have a driver, or is connected to a subdesign
input port created using the insert_scan command
The insert_scan command does not touch optional methodology
signal pins that are functionally connected. It reconnects mandatory
methodology signal pins that are functionally connected, and
generates a warning.
The insert_scan command selects the scan-out driver for each cell
using the following criteria:
• The insert_scan command identifies the scan-out signal by

looking at signal_type attributes. If pins with both test_scan_out
and test_scan_out_inverted attributes are present, insert_scan
picks the noninverted pin.
• The insert_scan command considers all the inverting and
noninverting drivers that fan out from the scan-out signal and
chooses the driver with the most slack. If there is a tie, it chooses
the driver with greatest drive strength.
You can disable this behavior by setting environment variable
test_disable_find_best_scan_out to true. In that case, insert_scan
does not attempt to find the optimum driver. Instead, it chooses the
driver based on availability, and chooses the dedicated scan-out
driver if any is defined in the library. Note that the chosen driver can
still be inverting or noninverting.
To finish building scan chains, insert_scan determines the scan-out

port for the chain. If you did not specify a scan-out port, insert_scan
creates a new one. Otherwise, insert_scan avoids inserting

redundant multiplexing logic. The insert_scan command first

establishes whether there is already a signal path between the last
scan-out pin and the scan-out port by considering the effects of two
conditions: scan_enable asserted and set_test_hold asserted.
By default, the insert_scan command uses existing ports that are

directly driven by flip-flops as scan-out ports. This is done to minimize
the number of test pins required in your design. You can force the
creation of dedicated scan-out ports on a particular scan chain by
using the set_scan_path command, or on all scan chains by using
the set_scan_configuration command.
dc_shell> set_scan_path scan_chain_name -dedicated_scan_out

true
dc_shell> set_scan_configuration -dedicated_scan_ports true
These commands only affect the creation of dedicated scan-out ports

for the top level of the current design, not for subdesigns within the
current design. By default, dedicated scan-out ports are created for
all subdesigns. To change this behavior, set the
test_dedicated_subdesign_scan_outs variable to false. (This
variable is set true by default.)
Leaving the test_dedicated_subdesign_scan_outs variable at its

default setting (true) enables Design Compiler or Floorplan Manager
to buffer the scan signals independently from the functional signals
at the module level, thereby reducing the impact of scan loading on
the functional signal path. It also enables better placement of scan-
out lockup latches by insert_scan during bottom-up scan insertion.
However, the addition of scan-out buffers between hierarchical levels

can cause an increase in the gate count, and the creation of dedicated
scan-out ports on subdesigns can cause more uniquification of

subdesigns. When these effects outweigh the benefits of having

dedicated scan-out ports, set the variable called
test_dedicated_subdesign_scan_outs to false.
Dedicated Test Clocks for Each Clock Domain

The insert_scan command creates clocks that are used only for test
purposes when it routes scan chains using the following scan styles:
• Clocked-scan
• Level-Sensitive Scan Design (LSSD)
• Clocked LSSD
• Auxiliary clocked LSSD
The test clocks are dedicated test clocks for each system clock
domain. This makes clock trees and clock signal routing easier. The
insert_scan command uses the following guidelines to determine how
test clocks are added:
• For sequential cells with one clock, the insert_scan command

adds different test clocks to cells that are clocked by different
system clocks. This applies only to designs that use the clocked-
scan scan style.
• For sequential cells with multiple test clocks, the insert_scan
command adds a test clock for each unique set of the system
clocks. For example, in Figure 8-8, cell U1 is clocked by C1
(master) and B1 (slave), cell U2 is clocked by C2 and B1, cell U3
is clocked by C1 and B2, and cell U4 is clocked by C2 and B2.
The insert_scan command adds four test clocks, one for each
unique set.

Figure 8-8 Adding Test Clocks for Sequential Cells With Multiple Test Clocks
C1 c U1 C2 c U2
port_1 port_2
a a
B1 b b
c U3 c U4
port_3 port_4
a a
B2 b b
For cells that are clocked by the same system clock, the insert_scan
command adds the same test clock to these cells even though they
are clocked by different clock senses (rising edge, falling edge, active
low, and active high). When a clock is distributed to pins with mixed
clock senses, the insert_scan command inserts inverters to ensure
design functionality.
Controlling LSSD Slave Clock Routing

For designs using LSSD scan style, clocked LSSD scan style, and
auxiliary clocked LSSD scan style, all single-latch and flip-flop
elements have an unconnected slave clock pin after scan
replacement.
If possible, the insert_scan command uses the slave clocks

distributed to double-latch elements and does either of the following:
• Creates, at most, one new port per design when you want to use
only the slave clocks distributed to the double-latch elements
• Creates one or more ports when you want test clocks created
according to different system clocks

The insert_scan command uses the following guidelines when

connecting slave clock pins of single-latch and flip-flop elements after
scan replacement:
• Connect the unconnected slave clock pin of LSSD scan style

single-latch or flip-flop elements to the slave clock pin of the
double-latch that is clocked by the same system clock. See Figure
8-9.
Figure 8-9 Single-Latch and Double-Latch Clocked by the Same System
Clock
c U1 c U1
SL DL
b
C1 c U2 C1 c U2
DL DL
B1 b B1 b
c U3 c U3
FF FF
b
Before Scan Replacement After Scan Replacement
Note:
For clarity, the A clock is omitted in Figure 8-9 through Figure
8-14 after scan replacement.
• Connect to a new slave clock, creating a new one if necessary, if
a system clock drives multiple cells with different slave clocks. See
Figure 8-10.

Figure 8-10 Single-Latch and Double-Latches Clocked by the Same System

Clock
c U1 c U1
SL new port DL
b
C1 c U2 C1 c U2
DL DL
B1 b B1 b
c U3 c U3
DL DL
B2 b B2 b
• Connect to a new slave clock port, creating one if necessary, if

double-latches are driven by different clocks. See Figure 8-11.
Figure 8-11 Single-Latch and Double-Latch Clocked by Separate System
Clocks
C2 c U1 C2 c U1
SL new port DL
b
C1 c U2 C1 c U2
DL DL
B1 b B1 b
• Connect to a new slave clock, creating a new port if necessary, if

there are no double-latches. See Figure 8-12.

Figure 8-12 Connecting Slave Clock Pin: No Double-Latches
C2 c U1 C2 c U1
SL new port DL
b
C1 c U2 C1 c U2
SL DL
b
You can determine how the insert_scan command connects slave

clock ports using the -create_test_clocks_by_system_clock_domain
option to the set_scan_configuration command or using the
test_use_dual_latch_slave_clock variable. If you set the
-create_test_clocks_by_system_clock_domain option to true, you
might create more than one slave clock port when cells are clocked
by different system clocks, as shown in Figure 8-13.

Figure 8-13 The -create_test_clocks_by_system_clock_domain Option Set

to True
C1 c U1 C1 c U1
SL new port 1 a DL
b
C2 c U2 C2 c U2
SL a DL
new port 2
b
C3 c U3 C3 c U3
DL DL
B3 b B3 b
If you set the test_use_dual_latch_slave_clock variable to true and

do not use the -create_test_clocks_by_system_clock_domain option
in the set_scan_configuration command (or if you set the option to
false), the insert_scan command will use any existing slave clock
signal for dual-latches to connect to single-latches. See Figure 8-14
for an example in which the test_use_dual_latch_slave_clock
variable is set true and the -
create_test_clocks_by_system_clock_domain option of the
set_scan_configuration command is false.

Figure 8-14 The test_use_dual_latch_slave_clock Variable Set to True

C1 c U1 C1 c U1
SL a DL
b
C2 c U2 C2 c U2
SL a DL
b
C3 c U3 C3 c U3
DL DL
B3 b B3 b
Note that setting the test_use_dual_latch_slave_clock variable to true

and setting the -create_test_clocks_by_system_clock_domain
option of the set_scan_configuration command to true accomplish
the same task; they both use the slave clocks distributed to double-
latch elements for connecting slave clock pins. The difference
between the two is that you might create more than one slave clock
port using the -create_test_clocks_by_system_clock_domain option.
The default is to not use the slave clocks distributed to double-latch

elements for connecting slave clock pins (setting the
-create_test_clocks_by_system_clock_domain option to false).

Mapping Optimization
The insert_scan command optimizes the current design if it has
performance constraint violations. The optimization level depends on
the -map_effort argument setting.
Low optimization
For -map_effort low, the insert_scan command resizes only the
logic it has added to the design.
Medium optimization
For -map_effort medium, the insert_scan command first resizes
logic it has added. If constraints remain violated, the insert_scan
command applies a set of heuristic optimization algorithms to all
critical paths in the design.
High optimization
For map_effort high, the insert_scan command first resizes logic
it has added. Again, if constraints remain violated, the insert_scan
command performs critical path optimization on the entire design.
If constraints are still violated, the insert_scan command applies
sequential mapping to sequential elements on critical paths. The
command then tries to reduce design area, downsizing cells that
are not on a critical path, and eliminating extra inverters. Next, the
insert_scan command attempts to eliminate any remaining
constraint violations using normal critical path optimization.
The medium optimization level uses the following heuristic
optimization algorithms:
• Sizing one or more drivers or loads for appropriate drive strength

• Replacing the driver with one that has the opposite phase

• Inserting buffers or inverter pairs; and transforming inverter pairs

to buffers, buffers to inverter pairs, or buffer inverters
• Downsizing and swapping out loads
• Isolating noncritical loads using inverter pairs or buffers
• Offloading noncritical loads to other driver outputs, using a driver
output with a greater drive strength, using drivers with more
outputs, or moving loads to nets with earlier arrival times
• Balancing by redistributing loads among drivers, balancing
buffers, or by balancing loads across driver outputs
• Splitting duplicate drivers, distributing loads, or dedicating one
driver to the critical path
If you do not want to fix performance constraints, set the
test_dont_fix_constraint_violations variable to true, as follows:
test_dont_fix_constraint_violations = true
By default, the insert_scan command does not fix hold-time

violations. To fix hold-time violations, use the set_fix_hold command.
If the insert_scan command creates test input ports, it creates input

ports with a delay of zero and an infinite driving strength. For more
accurate results, do either of the following:
• Create input ports and set all necessary timing attributes on them
and declare them to the insert_scan command using the
set_scan_signal command before using the insert_scan
command.
• Use a two-pass insert_scan flow with timing attributes set after
the first pass.

Fixing Compile Design Rule Violations

By default, the insert_scan command fixes all compile design rule
violations in the design, regardless of whether the violations occur in
the test logic. If you do not want to fix compile design rule violations,
use the -ignore_compile_design_rules option of the insert_scan
command.
Saving the Design

The insert_scan command saves designs back into db data
structures after creating scan chains and running constraint violation
fixing routines. Where subdesigns changed, because of scan chain
insertion for example, DC Expert Plus saves the subdesign as a new
subdesign with a different name. For example, the insert_scan
command might save subdesign A as A_test_1.
The insert_scan command “uniquifies” an instance of a common

subdesign if that instance differs from other instances of the
subdesign. For example, the insert_scan command might save
subdesign A as A_test_1 and A_test_2. It does this only in the
following cases:
• If you specify a different scan ordering in each instance of the

same reference design.
For example, if you route and rebalance a design so that two
instances of the subdesign have different scan chain ordering, the
insert_scan command uniquifies the design.
• If the insert_scan command determines that there are different

solutions during constraint optimization and design rule fixing.

Constraint optimization and design rule fixing are features of the

insert_scan command. If you want to eliminate unnecessary
uniquification, turn off these features by entering the following
commands:
dc_shell> test_dont_fix_constraint_violations = true

dc_shell> insert_scan -ignore_compile_design_rules
Displaying Test Information on the Current Design
Use the report_test command to display test-related information

about the current design.
To select the type of information to be printed, specify one or more

report_test sections. Some of the sections have options to further
control the report content. You can select as many different reports
as desired, but you cannot select the same one more than once. You
must specify a current_design before you use report_test.
Note:
To show changes caused by using the insert_scan command, you
must run the check_test command before the report_test
command. Running an incremental compile or other command
that changes the database causes the check_test results to be
discarded. In that case, you need to run check_test again before
you use report_test.
Example 8-3 shows the type of information displayed by the

report_test -scan_path command.

Example 8-3 Test-Related Information Displayed by the report_test

Command
Report from report_test -scan_path
****************************************
Report: test
-scan_path
Design: P
****************************************
Complete scan chain (test_si --> test_so) contains 4 cells:
test_si->
instA/dff1->
instA/dff2->
instB/dff1->
instB/dff2->
test_so
The report shows the scan cells in the order that they are connected
in the scan chain. Cells in the list are sometimes annotated with a
single character to provide more information about the scan data or
the cell at that point in the chain:
• c indicates a cell that is scan controllable only (not observable)

• o indicates a cell that is scan observable only (not controllable)
• x indicates a cell that cannot capture data
• * indicates a change of polarity in the scan data
The notations “c” and “o” are scan-shift violations, and notation “x” is
a capture violation. For information on these types of violations, see
“Sequential Cells With Violations” on page 6-65.
The notation “ * ” (asterisk) indicates a change of polarity in the scan

data from the marked cell to the next cell in the list. The most common
reason for this is that the negative (Q-bar) output of a sequential

element is used for connection to the next cell in the scan chain.
However, any type of signal inversion between the two cells can
cause this notation to appear. Here are some more examples:
• An inverter gate between the current cell and the next cell
• A negative (bubble) D input to the sequential input of the next cell
• An inverter gate at the D input of the next cell, internal to that cell
Therefore, the cause of the signal inversion is not always obvious.
The syntax of the report_test command is
report_test
[-configuration]
[-state]
[-constraints]
[-port]
[-clock]
[-scan_path]
[-nosplit]
-configuration
Selects the Configuration Report for display. This report contains
a list of scan configuration settings for the current design, as
specified by the set_scan_configuration command. The scan
configuration for the design includes, among other things,
information about the test methodology, the scan style for the
design, number of scan chains desired, and type of clock mixing.

-state
Selects the State Report for display. This report contains the
current scan status description for the current design. Possible
values are unknown, scan cells replaced, scan cells replaced with
loops, scan cells replaced and scan routed, and existing scan
circuitry.
-constraints
Selects the Constraints Report for display. This report contains a
list of test constraints for the current design, as specified by the
set_min_fault_coverage command, and it gives the status of
whether the constraints have been met by the insert_scan
command.
-port
Selects the Port Report for display. This report contains details of
test ports for the current design, and it displays (if applicable) the
signal type, scan chain index, and clock attributes.
-clock
Selects the Clock Report for display. The report contains details
of clock sources and associated derived clocks, if any.
-scan_path
Selects the Scan Path Report for display. This report contains a
list of every scan cell on the scan path for the current design. If
you get an error message saying that no scan path is defined, try
running check_test again, followed immediately by the report_test
-scan_path command.

-nosplit
Most design information is listed in fixed-width columns. If the
information for a given field exceeds its column’s width, the next
field begins on a new line, starting in the correct column. This
option prevents line splitting and facilitates writing software to
extract information from the report output.
For other options to the report_test command, see the man pages.
Multibit Support
A multibit component is a sequence of cells with identical functionality.

The multibit component can consist of single-bit cells or the set of
multibit cells supported by Design Compiler. Cells can have identical
functionality even if they have different bit widths. Multibit synthesis
ensures regularity and predictability of layout.
HDL Compiler infers multibit components through HDL directives.

See HDL Compiler for Verilog Reference Manual for more information
about multibit inference. You can specify multibit components using
the Design Compiler create_multibit command and remove_multibit
command. You control multibit synthesis using the
set_multibit_options command. See Design Compiler Reference
Manual: Optimization for details.
When you create a new multibit component with the create_multibit

command, choose a name that is different from the name of any
existing object in your design. This will prevent possible conflicts later
when you use the set_scan_path and set_scan_segment commands.

Structured logic synthesis is a special case of multibit synthesis in

which the individual bits of a multibit component are implemented as
distinct elements. Use the set_multibit_options -mode structured
command to enable structured logic synthesis.
Multibit components have the following properties:
• All the synthesis and optimization that DC Expert Plus performs

are as prescribed by the multibit mode in effect.
• Scan chain allocation and routing result in a layout that is as
regular as possible.
To achieve these goals, DC Expert Plus assimilates sequential
multibit components into synthesizable segments.
A synthesizable segment is an extension of the user segment

concept. A synthesizable segment has the following properties:
• Its implementation is not fixed at the time of specification.

• It consists of a name and a sequence of cells that implicitly
determine an internal routing order.
• It lacks access pins and possibly internal routing.
• It need not be scan-replaced.
• Test synthesis controls the implementation.
A synthesizable segment that cannot be synthesized into a valid user
segment is invalid. Only multibit synthesizable segments are
supported.

You control multibit test synthesis through the specification of the scan
configuration. You do this using the following commands:
• set_scan_configuration
• set_scan_transparent
• remove_scan_specification
• set_scan_segment
• set_scan_path
• set_scan_element
Commands that accept segment arguments also accept multibit
components. You can refer by instance name to multibit components
from the top-level design through the design hierarchy. Commands
that accept sets of cells also accept multibit components. When you
specify a multibit component as being a part of a larger segment, the
multibit component is included in the larger user-defined segment
without modification.
Multibit Component Scan Replacement
Use the compile -scan command or the insert_scan command to

perform multibit component scan replacement. These commands
perform a homogeneous scan replacement. Bits of a multibit
component are either all scan-replaced or all not scan-replaced.
Then, bits are assembled into multibit cells as specified by the
set_multibit_options command. See Design Compiler Reference
Manual: Optimization for details about the set_multibit_options
command.

The number of cells after scan replacement can change. For example,
a 4-bit cell can be scan-replaced by two 2-bit cells. If this occurs, the
two 2-bit cells get new names. If the cell is scan-replaced with a cell
of equal width, a 4-bit cell replaced by a 4-bit cell for example, then
the name of the cell remains the same.
You control the scan replacement of multibit components using the

set_scan_element command. See “Suppressing Replacement of
Sequential Cells,” earlier in this chapter for more information about
the set_scan_element command.
You control the transparency of level-sensitive multibit components

using the set_scan_transparent command. See Chapter 6, “Checking
Test Design Rules,” for more information about the
set_scan_transparent command.
When specifying individual cells using either of these commands, do

not specify an incomplete multibit component unless you previously
disabled multibit optimization.
You can disable structured logic and multibit component support by

doing one of the following:
• Remove some or all of the multibit components using the

remove_multibit command.
• Turn off scan synthesis using the set_scan_configuration -
multibit_segments false command.
• Turn off scan synthesis on a specific scan segment using the
set_scan_segment -synthesizable false command.

Multibit Components and Scan Chains
You can specify whether multibit components are implicitly treated as

synthesizable segments using the set_scan_configuration
-multibit segments command. This command applies globally to the
current design and overrides any specification on subdesigns. By
default, multibit components are implicitly treated as synthesizable
segments. For example, the command
set_scan_configuration -multibit_segments false
ensures that each bit of all sequential multibit components is treated

individually when the insert_scan command builds scan chains. Scan
replacement is still performed homogeneously for each multibit
component.
See “Specifying a Scan Chain Design” earlier in this chapter for

information about the set_scan_configuration command.
Implicit synthesizable specifications cannot be removed; they can

only be overridden. To override the implicit specification of individual
multibit instances, use the set_scan_segment -synthesizable
command. See “Identifying a Scan Segment” earlier in this chapter
for more information about the set_scan_segment command.
You can use either the remove_scan_specification -segment

command or the set_scan_segment -synthesizable default command
to remove explicit specifications of synthesizable segments. See
“Removing Scan Specifications” earlier in this chapter for more
information about the remove_scan_specification command.

You can use the set_scan_path command to specify a scan chain

that has multibit and synthesizable segments. See “Specifying a Scan
Chain for the Current Design” earlier in this chapter for more
information about the set_scan_path command.
The preview_scan command reports on synthesizable segments
when you specify the -show segments option.
Example 8-4 shows a sample script that creates a multibit component.
This script makes two assumptions:
1. Design B has sequential cells r[0] through r[3].
2. Design B is instantiated twice in design A as B1 and B2.
Example 8-4 Multibit Cell Sample Script
current_design = B
/* create multibit reg in design B */
create_multibit -name reg {r*}
current_design = A
/*Override implicit segment specification for multibit
in B1 */
set_scan_segment B1/reg -synthesizable FALSE
/* Specify scan chain */
set_scan_path chain1 {B1/r[0] B1/r[1] B2/reg B1/r[2] B1/
r[3]}
Example 8-5 shows the resulting scan chain.
Example 8-5 Resulting Scan Chain for Sample Script

test_si ->
b1/r[0] ->
b1/r[1] ->
b2/r[3] ->
b2/r[2] ->
b2/r[1] ->
b2/r[0] ->
b1/r[2] ->
b1/r[3] ->
test_so

Using Partial Scan
If you select the partial-scan test methodology, some of the sequential

cells in your design are replaced with their scannable equivalents.
Test Compiler Plus uses a set of heuristics that automatically selects
the best set of sequential cells to scan according to your performance,
area, and testability constraints. The selection of sequential cells to
scan is based on structural analysis only and is not influenced by
existing fault coverage. In most cases, sequential cells that are not
scanned can still propagate faults, because Test Compiler Plus uses
sequential ATPG algorithms to generate test patterns. However,
design rule violations might cause Test Compiler Plus to treat a cell
as a black box, which might lower fault coverage.
In the partial-scan test methodology, the state of all nonscan

sequential cells must be maintained during the scan shift operation.
Otherwise, each scan test sequence will reinitialize these sequential
elements, resulting in very large vector sets.
If the scan style you select has a dedicated test clock, the state of the
nonscan cells is easy for Test Compiler Plus to maintain during scan
shift because the test clock does not affect the nonscan cells.
For the multiplexed flip-flop scan style, which uses the same clock for
both normal operation and scan shift, this requirement means that
the clock must be gated to prevent clocking of nonscan cells during
scan shift.
Test Compiler Plus offers a method for clock gating in multiplexed flip-
flop partial-scan designs. Clock gating is performed once, at the top
level of the design, making it much easier to balance the scan and
nonscan clock trees.

Scan Cell Selection in Partial-Scan Designs
In a partial-scan design, you can influence which registers are

scanned according to the constraints you set for area, performance,
and fault coverage. You set these constraints using the following
commands:
dc_shell> max_area n
dc_shell> max_delay n
dc_shell> set_min_fault_coverage lower_bound \
-timing_critical -area_critical
Setting Constraints
The set_min_fault_coverage command is covered in detail in this
section. The other two constraints are explained briefly; for a detailed
discussion, see the Design Compiler reference manuals.
set_min_fault_coverage Command
You can define a lower bound of acceptable fault coverage for your
partial-scan design with the set_min_fault_coverage command. This
command has no effect on full-scan designs. The command syntax is
set_min_fault_coverage lower_bound [-area_critical]

[-timing_critical]
lower_bound
Is an integer in the range of 80 to 100. Test Compiler Plus maps
the lower bound you select into a discrete fault coverage range.
The ranges are 80 percent to 100 percent, 90 percent to 100
percent, 95 percent to 100 percent, and 98 percent to 100 percent.
Test Compiler Plus reports the range when you issue the
command, as shown in the following example:

dc_shell> set_min_fault_coverage 92
Setting fault coverage target range 90-100% on
'design'.
-area_critical
Indicates that meeting the area constraint takes priority over
meeting the lower bound on fault coverage. Insertion of scan test
circuitry does not increase the area of the design beyond the value
specified by the max_area variable.
-timing_critical
Indicates that timing constraints are more important than the lower
bound on fault coverage. When you use this option, Test Compiler
Plus guarantees that the scan circuitry it inserts will not lengthen
the critical path beyond the value defined by the timing constraints
you set. If the timing constraint limits the number of cells scanned,
Test Compiler Plus reports the cells that would violate the
constraint if they were scanned.
If you do not define a minimum fault coverage, Test Compiler Plus

uses the value of the environment variable called
test_default_min_fault_coverage. You can define this variable in the
.synopsys_dc.setup file, or you can use the default value of 95. To
reset the minimum fault coverage, reissue the
set_min_fault_coverage command.
When you run insert_scan, Test Compiler Plus reports how many
cells are replaced by scan cells.
When you run create_test_patterns, you can examine the fault

coverage report. If the coverage is too low because not enough cells
are scanned, consider relaxing your area or performance constraints,
or removing the -area_critical or -timing_critical options.

Determining Possible Fault Coverage

The fault coverage target you set applies to the testable faults in your
design. For example, if you set a fault coverage target of 95 percent
and your design has 80 percent testable faults, with 20 percent
untestable faults resulting from design rule violations, the maximum
possible fault coverage for your design (with full scan) is 95 percent
of 80 percent.
Note:
Scan design rule violations have a significant effect on fault
coverage. If your design violates scan design rules, the overall
fault coverage of your design will be lower than the target fault
coverage you set.
Remember that a higher fault coverage target, such as 98 percent,

means that more registers are made scannable, which affects the
area of your design. The actual number of registers scanned is
determined by the testability of your design and the area and
performance constraints you set. The fault coverage target also
affects ATPG runtime, because partial-scan designs use a sequential
ATPG algorithm, and sequential ATPG runs faster with a higher
percentage of scan registers in the design.
For a summary of actual fault coverage compared to target fault

coverage, use the report_test -constraints command.
Effect of Constraints on Scan Cell Selection

In general, the higher you set the minimum fault coverage constraint,
the more registers Test Compiler Plus makes scannable. The actual
number of registers scanned is determined by the testability of your
design, whether you indicate the -area_critical or -timing_critical

options, and the area and performance constraints you set. Typically,
the percentage of registers scanned falls between 25 percent and 75
percent.
You can override the automatic scan selection process with the
set_scan_element command, explained earlier in this chapter. You
can force individual registers that pass design rule checking to be
scanned or not scanned.
The following examples show two applications of the partial scan

feature.
Critical Area Constraint Example

In this example, a design with 47,000 gates is close to the 50,000-
gate limit. The target fault coverage for the design is 95 percent.
Suppose a full-scan approach requires a 10 percent increase in area,
which means that the next larger (and more expensive) package size
must be used. The following commands define an area constraint that
determines which registers are scanned:
dc_shell> set_scan_configuration -methodology partial_scan

dc_shell> max_area 50000
dc_shell> set_min_fault_coverage 95 -area_critical
These commands instruct Test Compiler Plus to keep the total design
area under 50,000 gates, even if the fault coverage goal might not be
met.

Critical Timing Constraint Example

In the following example, CPU prototype must run at 50 MHz to be
competitive. The design uses a cell-based technology, so area is not
a concern. Fault coverage is not a concern at the prototype stage.
The following commands set the appropriate constraints for this
example:
dc_shell> set_scan_configuration -methodology \

partial_scan -scan_style lssd
dc_shell> create_clock -period 20 -waveform {10,15} CLOCK
dc_shell> set_min_fault_coverage 80 -timing_critical
The create_clock command sets the period (in nanoseconds) on the

pin or port name you define. In this case the clock speed is 50 MHz,
which corresponds to a period of 20 ns. The -timing_critical option
ensures that critical paths are not lengthened beyond 20 ns.
Assume you are ready for the final volume production version of the
chip in the previous example. At this stage, the fault coverage target
has been raised to 95 percent, and the speed constraint remains at
50 MHz (a 20-ns period). The following example shows the
commands you enter:
dc_shell> set_scan_configuration -methodology partial_scan

dc_shell> set_min_fault_coverage 95
For this example, Test Compiler Plus determines that fault coverage
of 95 percent or better is more important than limiting critical paths
to 20 ns or less, because the -timing_critical option is not used. The

critical paths might exceed 20 ns, but fault coverage is at least 95

percent for a testable design. Note that a higher percentage of
registers is scanned to target 95 percent fault coverage.
Overriding Automatic Scan Cell Selection

You can also override the automatic selection of scan cells for your
partial-scan design. In a partial-scan design, a set_scan_element
false cell without design rule violations is treated as a valid nonscan
cell and it retains its value during scan operations. If your design has
latches, you can choose to test them in transparent mode without
replacing them with scannable equivalents. For a partial-scan design,
Test Compiler Plus takes user-scannable cells into account during
the constraint-driven scan selection process.
Clock Gating
If the test methodology is partial_scan and the scan style is
multiplexed_flip_flop, insert_scan adds clock gating logic. Clock
gating prevents state changes in nonscan storage elements while
scan elements are changing in scan mode. Any nonscan storage
element that shares an active clock with a scan element will have the
function of the signal on its clock input changed. The new clock
function for the nonscan element is to hold it inactive in scan mode.
Clock gating may be done in three different ways. If

set_scan_configuration is invoked with a -clock_gating leaf_cell
option, the behavior is that found in Test Compiler Plus releases prior
to v3.2. Gating is done on each design that contains a nonscan
element on the same clock net with a scan element.

With the -clock_gating entire_design option, insert_scan considers

as a common clock any clock that has at least one scan and one
nonscan element somewhere in the design hierarchy. Further,
insert_scan creates from the common clock a derivative clock,
equivalent to the common clock when not in scan mode, but set to
the inactive level in scan mode. This nonscan clock is used to clock
all nonscan elements that were on the common clock.
Also, under the -clock_gating entire_design option, insert_scan

creates two nonscan clocks for a single clock signal that drives scan
and nonscan elements on both rising and falling edges. Two nonscan
clocks are required because different edge elements must be held to
different inactive levels; that is, the behavior required in scan mode
is different. In addition, insert_scan creates two clocks for any clock
used in both inverted and noninverted states by same edge elements.
Although the inactive level for all of the same edge storage elements
is the same, the clock signal is different, so different nonscan clocks
(clock and clock-bar) must be created. In this case, the behavior in
scan mode for all elements is the same, but the functional mode
behavior is different. You can name ports that are created for nonscan
clocks using the variable test_non_scan_port_naming_style.
The -clock_gating entire_design option does not modify a clock net

that has a dont_touch attribute on it. However, successful
implementation of partial scan may require that such a clock net be
modified. To prevent an incorrect design from being generated, a
preprocess is run that detects dont_touch nets that clock gating would
modify. If any are found, the user is notified of their location and clock
gating insertion on these nets stops with no modifications.

Note:
The insert_scan command continues to run, it just does not modify
dont_touch nets.
If the -clock_gating option is set to superbuffer (the command is

set_scan_configuration -clock_gating superbuffer), the insert_scan
command jumps back over one level of buffering to find the gating
point, duplicates the buffer (unless it belongs to a dont_touch design),
and takes the gated clock from the duplicated buffer output. The
option reverts to entire_design clock gating if there is a problem.
You can override the default of entire_design clock gating using the
-clock_gating option to the set_scan_configuration command.
Design Considerations for Scan Designs
When you specify the design constraints involving control of clocks,

using the default settings reduces risk of encountering problems. If
you override the defaults, you might need to consider the following
issues.
Clock Requirements in Edge-Sensitive Scan Shift Styles
Scan chain clocking issues are different for edge-sensitive scan shift
and LSSD scan styles. Edge-sensitive scan shift scan styles include
multiplexed flip-flop and clocked-scan.
To avoid timing-related problems in edge-sensitive scan shift styles,

the clocks to all flip-flops in each chain must be aligned. The safest
way to align the clocks is to make all flip-flops share a common clock
with the same phase and no skew. Under these conditions, if the path

from the clock-to-Q to the test input of the next stage is longer than
the hold time of that stage, the shift occurs reliably on the active edge
of the clock. The clock must have a controlled path from an external
primary input so the shift function can be performed on demand in
any state.
Skew Issues
Skew can arise from clock tree buffers, but a more serious source of
skew is gating and multiplexing logic that is inserted on clock lines to
obtain supposedly congruent clocks for the scan chain. Gating logic
is not necessarily discouraged, but its introduction can cause hold-
time problems that must be addressed. Fortunately, the Synopsys
environment includes timing analysis that detects hold-time
problems.
Construct scan chains to reduce the risk of skew outside of tolerable

limits. Skew can result in hold-time violations if it delays downstream
flip-flop clocks longer than it delays upstream flip-flop clocks. This
condition is illustrated in Figure 8-15. If the skew is bad enough, two
flip-flops can share a single state, causing data to fall through and
resulting in incorrect scan operation.
Use set_scan_configuration -internal_clocks true or create_clock

-internal_clocks commands to avoid problems when placing gating
logic on the clock lines. Alternatively, you can enable hold-time
violation fixing using the set_fix_hold command before running the
insert_scan command.
Skew can also cause setup violations, but it is unlikely.

Figure 8-15 Hold-Time Violation Caused by Delayed Downstream Clock

Upstream Downstream
D Q D Q
TI TI
C C
Delay
Mixed Phases
If clocking on the scan chain is both inverted and noninverted, a
problem similar to excessive skew can occur. For example, if the
upstream flip-flop is rising-edge triggered and the downstream flip-
flop is falling-edge triggered, a positive clock pulse first clocks a value
into the upstream flip-flop. Then, on the same pulse’s falling edge, it
clocks the same value into the downstream flip-flop. Figure 8-16
illustrates this condition.
If you must mix phases, there can be only one point in the chain where
the clock phase reverses and clocks upstream flip-flops on the trailing
edge of the clock. You must clock downstream flip-flops on the leading
edge. For a positive pulse, the negative edge-triggered flip-flop must
be clocked first; for a negative pulse, the positive edge-triggered flip-
flop must be clocked first.
If you specify an illegal arrangement, preview_scan will reject the

specification.

Figure 8-16 Mixing Edges in a Scan Chain

Upstream Downstream
D Q D Q
TI TI
C C
Good
Clock second Clock first
Bad
Multiple Clocks
If clocks originate from different sources, you must consider whether
these clocks can be constrained to the same timing, given real-world
tester constraints. The timing is determined from the waveforms
defined with the create_test_clock command. If optimistic
assumptions are made in the defined waveforms, the circuit might not
test properly. Consequently, using multiple clocks results in greater
risk and lower predictability than using a single clock for all cells on
a scan chain.
The insert_scan command reduces risks by
• allowing only one clock per scan chain (default)

• minimizing clock domain crossing
• inserting lockup latches between clock domains (default)
If you change the defaults, you must pay attention to these risks.

Clock Requirements in LSSD Scan Styles
The same clocking requirements apply to all of the LSSD scan styles:
single-latch LSSD, double-latch LSSD, clocked LSSD, and auxiliary-
clock LSSD.
LSSD implements the shift function by using separate scan clocks on

the master latch and the slave latch. Each master-slave latch pair is
called a shift-register latch (SRL). Test data transferred from a
preceding SRL is stored in the master latch of the SRL when the
“A Scan Clock” is active. The master test clock then changes to the
inactive state, causing all latches to retain their stored values. The
slave test clock then changes to the active state, permitting the slave
latch to take on the state held in the master latch.
Scan mode does not require a scan mode control. Scan control is
performed by using a clock different from the one used in functional
mode.
Master Scan Clock and Slave Clock

To make an LSSD circuit scan-controllable, the scan chain must be
complete from the scan input to the last flip-flop in the chain. The
master scan clock and slave clock must be controllable from primary
inputs.
Synchronized Clocks
You must synchronize the clocks for the various scan cells in the chain.
Master latches must be enabled by the same clock pulse; slave
latches must be enabled by a different, nonoverlapping clock pulse.
If there is overlap, all latches are simultaneously transparent, causing
incorrect operation.

If you specify an illegal arrangement, preview_scan will reject the

specification.
Skew Control
Unlike edge-sensitive scan shift scan styles, LSSD scan styles do not
require skew control because there is no race between clock and
data. Correct low-frequency operation of the circuit for scan is
ensured with LSSD.


Building Scan Chains: v1999.10 Scan Synthesis Reference Manual

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Building Scan Chains: v1999.10 Scan Synthesis Reference Manual

Uploaded by

Copyright:

Available Formats

v1999.

10 Scan Synthesis Reference Manual

• Hierarchical Scan Insertion

HOME CONTENTS INDEX / 8-1

• Design Considerations for Scan Designs

Hierarchical Scan Insertion

With the DC Expert Plus hierarchical scan insertion capability, you

• Implement automatically balanced scan chains

HOME CONTENTS INDEX / 8-2

Figure 8-1 The Hierarchical Scan Insertion Design Process

Scan Chain Design

User dc_shell script Modified Scan Chain Design

Example 8-1 is a basic hierarchical scan script.

Example 8-1 Basic Hierarchical Scan Script

HOME CONTENTS INDEX / 8-3

In this example, set_scan_configuration -chain_count 1 is the

During the specification phase, you use the scan specification

Using the scan specification commands, you can specify as little or

Alternatively, you can create a partial specification, where you define

HOME CONTENTS INDEX / 8-4

The scan specification commands are

The scan specification commands apply only to the current design

1. Set the current design to a lower-level subdesign (current_design

HOME CONTENTS INDEX / 8-5

By default, the insert_scan command recognizes and keeps scan

The preview_scan command produces a scan chain design that

The preview process (preview_scan command) performs two tasks:

• It checks the specification for consistency. For example, you

HOME CONTENTS INDEX / 8-6

The preview_scan command does not annotate the database. If you

The preview_scan command is described later in this chapter.

You invoke the synthesis process using the insert_scan command,

Execute the check_test command at least once before executing

The insert_scan command is described later in this chapter.

Generating a Default Scan Design

If you do not specify any scan detail, the insert_scan command

HOME CONTENTS INDEX / 8-7

The insert_scan command performs the following tasks as it

• Unscans scan-replaced elements from compile -scan or a

HOME CONTENTS INDEX / 8-8

• Allocates ports to carry test signals. Where possible, the

• Ensuring correct core-side hookup to all pad cells and three-state

HOME CONTENTS INDEX / 8-9

For information about constraint-optimized scan insertion, see

Scan chain synthesis is primarily concerned with the scan shift

Scan chains synthesized by the insert_scan command are functional

Specifying a Scan Design

The previous section described how the insert_scan command

HOME CONTENTS INDEX / 8-10

This section describes the specification commands you can use. It

This section describes the scan specification commands.

Specifying a Scan Chain Design

HOME CONTENTS INDEX / 8-11

[-hierarchical_isolation true | false]

-add_lockup true | false

-bidi_mode input | output

HOME CONTENTS INDEX / 8-12

-chain_count integer | default

-clock_gating entire_design | leaf_cell | superbuffer

-clock_mixing no_mix | mix_edges | mix_clocks |

HOME CONTENTS INDEX / 8-13

-create_test_clocks_by_system_clock_domain true | false