Embed Size (px)
Citation preview
CALIFORNIA STATE UNIVERSITY, NORTHRIDGE
DESIGN FOR TESTABILITY APPLICATION AND ANALYSIS USING
CADENCE DFT TOOL COMPILER
A graduate project submitted in partial fulfillment of the requirements
For the degree of Master of Science in Electrical Engineering
By
Augusto Euler Mannucci
December 2018
ii
The graduate project of Augusto Mannucci is approved:
__________________________________________ __________________
Dr. Deborah K Van Alphen Date
__________________________________________ __________________
Dr. Xiyi Hang Date
__________________________________________ __________________
Dr. Jack Ou, Chair Date
California State University, Northridge
iii
Acknowledgement
I would like to thank Dr. Jack Ou, Dr. Xiyi Hang, and Dr. Deborah K Van Alphen for
being members of my committee, but in particular to Dr. Ou for his genuine interest and
support of this project when others would nagat. I would also like to thank Henry Emil
for supplying me with all the CADENCE tools I needed to complete this project and
Daesung Kim, a friend and mentor, for inspiring me to choose this project and keep
pushing forward.
iv
Table of Contents
Signature Page .................................................................................................................................................ii
Acknowledgement ......................................................................................................................................... iii
List of Figures ...............................................................................................................................................vii
ABSTRACT .................................................................................................................................................... x
Chapter 1 ......................................................................................................................................................... 1
1.1 Introduction ........................................................................................................................................... 1
1.2 Objective ............................................................................................................................................... 2
1.2 Project Outline....................................................................................................................................... 3
Chapter 2 ......................................................................................................................................................... 4
2.1 Why ATPG? .......................................................................................................................................... 5
2.2 Controllability and Observability .......................................................................................................... 5
2.3 DFT Approach....................................................................................................................................... 6
2.3.1 Ad Hoc DFT ................................................................................................................................... 6
2.3.2 DFT Structure-Based ...................................................................................................................... 8
2.4 DFT in the Design Flow ...................................................................................................................... 10
2.5 DFT Scan Cell Design Techniques ..................................................................................................... 10
2.5.1 Muxed Scan Cell .......................................................................................................................... 10
2.5.2 Clocked-Scan Cell ........................................................................................................................ 12
2.5.3 Level-Sensitive Scan Design (LSSD)........................................................................................... 13
2.5.4 Scan Cell Design Advantages/Disadvantages .............................................................................. 15
2.5.5 Cadence Scan Cell Requirements ................................................................................................. 15
2.6 Scan Architectures ............................................................................................................................... 18
2.6.1 Full-Scan Design .......................................................................................................................... 18
2.6.2 Muxed Full-Scan Design .............................................................................................................. 18
2.6.3 Clocked Full-Scan Design ............................................................................................................ 21
2.7 Scan Design Rules ............................................................................................................................... 22
2.7.1 Bidirectional I/O Connection ....................................................................................................... 22
2.7.2 Tristate Buses ............................................................................................................................... 23
2.7.3 Gated Clocks ................................................................................................................................ 24
2.7.4 Derived Clocks ............................................................................................................................. 25
2.7.5 Combinational Feedback Loops ................................................................................................... 26
2.8 Design Flow – Scan ............................................................................................................................. 27
2.8.1 Scan Design Rule Checking ......................................................................................................... 28
2.8.2 Scan Synthesis .............................................................................................................................. 29
2.8.2.1 Configuration - Scan ............................................................................................................. 29
v
2.8.2.2 Scan Replacement ................................................................................................................. 31
2.8.2.3 Reordering - Scan .................................................................................................................. 32
2.8.2.4 Scan Stitching ........................................................................................................................ 32
2.8.3 Scan Extraction ............................................................................................................................ 32
2.8.4 Scan Verification .......................................................................................................................... 33
Chapter 3 ....................................................................................................................................................... 34
3.1 UART (Universal Asynchronous Receiver Transmitter) Design ........................................................ 34
3.1.1 Design Overview .......................................................................................................................... 34
3.1.2 Baud Rate Generator Stage .......................................................................................................... 36
3.1.3 FIFO (First In First Out) Memory Module ................................................................................... 38
3.1.4 Transmitter Stage ......................................................................................................................... 43
3.1.5 Receiver Stage .............................................................................................................................. 46
3.1.6 UART Top Level Testbench ........................................................................................................ 50
Chapter 4 ....................................................................................................................................................... 53
4.1 Genus Synthesis Solution .................................................................................................................... 53
4.2 Key Features ........................................................................................................................................ 53
4.3 Key Benefits ........................................................................................................................................ 54
4.4 Preparing to Run Genus Synthesis Solution ........................................................................................ 54
4.4.1 What is Needed to Synthesize a Design ....................................................................................... 55
4.4.2 Genus Run Scripts ........................................................................................................................ 55
4.5 Invoking Genus ................................................................................................................................... 56
4.5.1 Genus Shell & Navigation ............................................................................................................ 56
4.5.2 Genus Synthesis Templates .......................................................................................................... 57
4.6 Read Target Libraries .......................................................................................................................... 58
4.7 Reading In The Design ........................................................................................................................ 59
4.8 Elaborate the Design ........................................................................................................................... 59
4.9 Constraints Setup - Read SDC ............................................................................................................ 60
4.10 Setup for DFT Rule Checker ............................................................................................................. 61
4.11 Run DFT Rule Checker and Report Registers ................................................................................... 63
4.12 Fix DFT Violations ........................................................................................................................... 65
4.13 Synthesize Design to Generic + Map to Scan ................................................................................... 65
4.14 Configure Scan Chains ...................................................................................................................... 66
4.14.1 Connect Scan Chains .................................................................................................................. 67
4.15 Run Incremental Optimization .......................................................................................................... 68
4.16 Write ATPG – Interface to ATPG Tool ............................................................................................ 70
4.17 Genus Reports ................................................................................................................................... 71
4.18 Modus DFT Test Solution ................................................................................................................. 72
4.19 Modus ATPG Features ...................................................................................................................... 73
4.20 Command Interface ........................................................................................................................... 73
vi
4.21 GUI Interface..................................................................................................................................... 74
4.22 Design Flow Using Cadence Modus ................................................................................................. 77
4.22.1 Requirements for ATPG ............................................................................................................. 77
4.23 Modus ATPG Design Flow ............................................................................................................... 77
4.23.1 Build Model................................................................................................................................ 79
4.23.2 Build Test Mode ......................................................................................................................... 79
4.23.3 Report Test Structures ................................................................................................................ 81
4.23.4 Verify Test Structures ................................................................................................................ 82
4.23.5 Build Fault Model ...................................................................................................................... 82
4.23.6 Create Scan Chain Tests ............................................................................................................. 83
4.23.7 Create Logic Tests ...................................................................................................................... 83
4.23.8 Write Vectors for Verification.................................................................................................... 85
4.24 Incisive Pattern Verification Process ................................................................................................. 86
4.24.1 Pattern Verification Results ........................................................................................................ 87
Chapter 5 ....................................................................................................................................................... 91
CONCLUSION ......................................................................................................................................... 91
References ..................................................................................................................................................... 93
Appendix A: UART Verilog Source Code .................................................................................................... 94
Appendix B: UART Test Bench ................................................................................................................. 105
Appendix C: Genus Complete Run Script................................................................................................... 107
Appendix D: Genus’ DFT Rule Checker .................................................................................................... 113
Appendix E: Genus’ Report Registers Log ................................................................................................. 115
Appendix F: Genus’ DFT Setup TDRC Log ............................................................................................... 121
Appendix G: Genus’ Scan Chain Report Log ............................................................................................. 123
Appendix H: Modus’ Run Script................................................................................................................. 129
Appendix I: Modus Build Model Output Log ............................................................................................. 131
Appendix J: Modus FULLSCAN Build Test Mode Output Log ................................................................ 136
Appendix K: Modus Report Test Structures Output Log ............................................................................ 140
Appendix L: Modus Verify Test Structure Output Log .............................................................................. 158
Appendix M: Modus Build Fault Model Output Log .................................................................................. 164
Appendix N: Modus Create Scan Chain Test Output Log ......................................................................... 168
Appendix O: Modus Create Logic Test Output Log ................................................................................... 172
Appendix P: Modus’ Write Vectors Output Log......................................................................................... 176
Appendix Q: Incisive Irun ATPG Simulation Run Script .......................................................................... 181
Appendix R: Incisive Irun Test Vector Reduced Log ................................................................................. 182
Appendix S: Cadence Sample test_cell Syntax ........................................................................................... 186
Appendix T: Cadence Sample Power Consumption Report........................................................................ 187
vii
List of Figures
Figure 2.1 – IC Design Cycle 5
Figure 2.2 – Low and High Observability Nodes 7
Figure 2.3 - Control Point Insertion 8
Figure 2.4 - Sequential Circuit Internal States 9
Figure 2.5 - DFT in the Design Flow 10
Figure 2.6 - Muxed-D Scan Cell 11
Figure 2.7 - Muxed-D Scan Cell Operation 11
Figure 2.8 - Edge-triggered Muxed-D Scan Cell 12
Figure 2.9 - Clocked-Scan Cell 13
Figure 2.10 - Clocked-Scan Cell Operation 13
Figure 2.11 - Level Sensitive Scan Design (LSSD) Cell 14
Figure 2.12 - LSSD Scan Cell Operation 14
Figure 2.13 - Sequential Circuit without Scan Elements 19
Figure 2.14 - Sequential Circuit after Scan Chain Insertion 19
Figure 2.15 - Timing Diagram 21
Figure 2.16 - Full-Scan Clocked Configuration 21
Figure 2.17 – Bidirectional Connection 22
Figure 2.18 - Bidirectional I/O Port Fix 23
Figure 2.19 - Tristate Buses 23
Figure 2.20 - Tristate Bus Fix 24
Figure 2.21 - Gated Clocks 24
Figure 2.22 - Gated Clock Fix 25
Figure 2.23 - Derived Clock Example 25
Figure 2.24 - Derived Clock Fix 26
Figure 2.25 - Combinational Feedback Loop 26
viii
Figure 2.26 - Scan Design Flow 28
Figure 2.27 – Positive and Negative Edge Scan Elements 30
Figure 2.28 - Lock-up Latch between Two Clock Domains 31
Figure 2.29 - Lock-up Latch Configuration Timing Diagram 31
Figure 3.1 – Two Rx/Tx Interface Diagram 35
Figure 3.2 – Tx to Rx Serial Data Transmission 35
Figure 3.3 - Baud Rate Common Speeds 36
Figure 3.4 – Diagram of Data Processing using a FIFO and LIFO 39
Figure 3.5 - Connections of an Asynchronous FIFO Module 40
Figure 3.6 - FIFO Simulation of Write Ports 42
Figure 3.7 – FIFO Simulation of Read Ports 43
Figure 3.8 - Serial Data Packet Format 43
Figure 3.9 - Bit period of 26us 44
Figure 3.10 - UART Transmitter Stage 45
Figure 3.11 - Transmitter Stage Simulation 46
Figure 3.12 - Data Stream Sampling Locations 47
Figure 3.13 - Receiver Stage Block Diagram 48
Figure 3.14 – Receiver Stage Simulation 49
Figure 3.15 - UART's Receiver Stage 50
Figure 3.16 - UART Top Level I/O Ports 51
Figure 3.17 - UART Top Level Simulation 52
Figure 4.1 - Genus Shell Directory 56
Figure 4.2 - Genus Synthesis Flow 58
Figure 4.3 - Non-Scan Flip-Flop & Multiplexer Scan Flip-Flop 61
Figure 4.4 - Genus' Top Level Post Scan Schematic View 69
Figure 4.5 – UART Power Report 71
Figure 4.6 - Cadence Solution Software Mutual Integration 72
Figure 4.7 - Genus, Modus, and Incisive Integration Flow 73
ix
Figure 4.8 - Modus GUI Interface 75
Figure 4.9 - Modus' GUI Task View 76
Figure 4.10 - Modus Work Directory Structure 76
Figure 4.11 - Modus ATPG Flow 78
Figure 4.12 - ASIC ATPG Flow 87
Figure 4.13 - Test Pattern Verification Process 88
Figure 4.14 - Vector Test Log Results 89
Figure 4.15 - Test Vector Simulation Waveform Viewer 90
x
ABSTRACT
IMPLEMENTATION, VERIFICATION AND SIMULATION OF
BOUNDARY SCAN ARCHITECTURE
By
Augusto Mannucci
Master of Science in Electrical Engineering
As circuits become smaller in size and their complexity increases, testing ICs
becomes more challenging and expensive. Faults within a project are most of the time
unknown until later stages of the design. To address these issues, design engineers can
implement DFT (Design for Testing) techniques at earlier stages of the design. Design
for Testing consists of IC design techniques that add testability to the hardware of the
design. Testing without proper DFT implementation can be very difficult if even
possible. DFT concepts and techniques will be discussed and implemented.
A UART (Universal Asynchronous Receiver Transmitter) system will be
designed in Chapter 3 to be used in the insertion of Scan Chain testability features. The
Scan Chain architecture is explained in Chapter 2.6. The Scan Chain insertion into the
ASIC design will then be performed using CADENCE Genus. After design synthesis
and Scan Chain implementation, ATPG (Automatic Test Pattern Generation) will be
implemented using CADENCE MODUS as well to automatically generate manufacturing
fault test patterns. All the patterns generated by MODUS will be verified via simulation
using CADENCE NCSIM.
1
Chapter 1
INTRODUCTION
1.1 Introduction
Design for Test, sometimes also referred to as Design for Testability or DFT, is the
name given to design methodologies that add testability features to a hardware design. The
main purpose of this addition to the design is to validate that the product under development
will not contain defects that could potentially affect the product’s intended operation. DFT
came to be because of the rapidly shrinking size of components and the inadequacy of
traditional testing. DFT techniques address these issues. These techniques are part of the
design process. In this report, I will be talking about Design for Testability concepts before
applying them to a design. The Scan Cell technique that will be implemented is discussed
in Chapter 2.5.1.
Introducing DFT features to an ASIC design is essential to attain higher reliability. The
rapidly shrinking technology causes circuits to grow not just in size but in their complexity
too. This in turn will cause the controllability and observability of its circuit components
to decrease and thus cause an increase in test times. Fault coverage approximation can
help avoid complex design modifications in the later stages of the design to ensure cost
effective quality manufacturing. Fault coverage is a constant process carried out along the
ASIC development time frame and as such, fault coverage can only be known at later stages
of the design when it approaches tapeout.
2
There are multiple DFT techniques that can be used to increase the testability of
designs. The DFT engineer must decide which techniques to use based on the specific
features of the chip. If this is done properly, the testing cost could be minimized by
selecting the right DFT methodology. The different DFT methodologies will be discussed
in detail in Chapter 2.
SCAN is one of the most widely used DFT techniques available and it will be
implemented in Chapter 4 for the UART (Universal Asynchronous Receiver Transmitter)
system designed in Chapter 3. The ATPG flow and steps to follow to successfully
implement it will be discussed as well.
1.2 Objective
The objective of this project is to apply Design for Testability features to a verilog
design and analyze the results. This project will be a fundamental starting point and
provide an overview of Design for Testability concepts regarding SCAN, ATPG Design
flow and CADENCE DFT Software Solutions. This implementation will verify and
simulate ATPG scan architecture. A UART (Universal Asynchronous Receiver
Transmitter) design will be used and all its memory elements will be used for the scan
synthesis and ATPG implementation. The UART design’s proper functionality will first
be verified prior to DFT implementation.
3
1.2 Project Outline
The project will be divided into five chapters and twenty appendixes. Chapter 2
introduces the different DFT methodologies in the industry, architecture, DFT violation
rules to consider and design flow with an emphasis on Scan Chain implementation.
Chapter three will present the UART (Universal Asynchronous Receiver Transmitter)
design to be used in the DFT implementation. It was chosen to demonstrate how Scan
Architecture can be implemented in the memory logic of a design. A testbench will be
compiled and simulated along with the top level main design prior to the DFT insertion to
confirm the design’s proper operation. CADENCE Incisive Simulator will be used to
perform all the corresponding simulations.
Chapter four will cover CADENCE tools as well as the ATPG Design Flow that will
be followed. It will present the steps to take to synthesize both designs, the designs’ Scan
Chain insertion and their configuration. Modus ATPG (Automatic Test Pattern
Generation) will then be used to generate automatic patterns and CADENCE Incisive will
be used to simulate them. CADENCE Modus will also report the faults in the design and
calculate the overall coverage of the design.
Chapter five will provide the reader with the conclusion of this project. The Verilog
source code and logs from the Synthesis and ATPG implementation of the UART design
are provided in their respective Appendix.
4
Chapter 2
DESIGN FOR TESTABILITY
DFT (Design for Testability) is a broad topic which consists of design techniques to
add testability features to a hardware product design. The main purpose to doing so is to
validate hardware correct functionality after manufacturing. This is important because
during production there is always a possibility for a device to have some sort of
manufacturing defect which would hinder its normal operation in the field. There are
different DFT techniques that could be implemented but this report will discuss the ones
involving Scan testing implementation to ASIC (Application Specific Integrated Circuit)
designs.
To better understand why DFT is needed we can make a contrast to more traditional
testing methodologies. To test any chips or ICs, one must make some sort of physical
contact to it such as using probes. A bed of nails is an example of a traditional test
fixture composed of many pogo pins making contact with nodes in the circuitry of the
PCB. These bed of nails test fixtures are a mechanical assembly which are expensive to
maintain as a result of how complex they are and thus it is no longer a cost-effective
solution. In addition, IC technology shrinks with each year thus testing by means of
physical probes is no longer a liable and it nearly impossible to perform. Gaining access
to internal nodes is a challenge and thus why DFT techniques were developed. It is also
the reason why physical test fixtures are slowly being replaced by DFT techniques.
5
2.1 Why ATPG?
Before implementing ATPG into a device, designers must consider its advantages and
disadvantages. Implementing ATPG will greatly reduce the development cycle since test
vector generation takes up almost forty percent of it.
Figure 2.1 – IC Design Cycle [2]
2.2 Controllability and Observability
Testing involves the combination of controllable and observable properties.
A node is considered controllable if we can drive it to a logic value by setting its primary
inputs. A node is considered observable if we can read the logic value from its primary
output. Both concepts are applicable in testing combinational measures and sequential
measures. Combinational logic is usually easy control and observe. Finite state machines
on the other hand can be more difficult since it could require many cycles to enter the
designated states. A UART (Universal Asynchronous Receiver Transmitter) will be used
to implement the Scan Architecture and ATPG implementation. The UART design will
6
be covered in Chapter 3. Regarding the ATPG implementation that will be performed in
Chapter 4, we need to know whether or not the nodes in the circuit are easily controllable
and observable. After ATPG generates testing patterns, such patterns will be simulated
to check if the logic driven through the inputs is readable and does not miscompare at any
node. Adequate controllability and observability reduces the number of required vectors
for manufacturing test[2].
2.3 DFT Approach
There are two possible approaches when it comes to choosing a DFT method, either
the DFT Ad Hoc method or the Structured DFT method. Both have advantages and
disadvantages which are listed in more detail below.
2.3.1 Ad Hoc DFT
The ad-hoc DFT design approach relies on good design practices. These practices are
learned from experience and it is a strategy meant to enhance the design testability
without modifying the design style. Some of the Ad Hoc techniques are as follows:
• Make all flip-flops initializable: In order to make them initializable, a clear or
reset input signal can be supplied to them. The only requirement is that the
input has to be fed from primary inputs.
• Avoid asynchronous feedback: Oscillation is a possible effect of having
asynchronous logic feedback in the combinatorial logic of the design.
7
Oscillation makes the circuit hard to verify and generate automatic test
patterns.
• Provide test control to difficult signals: Some signals are difficult to control
because they are composed of many clock cycles and thus they’re harder to
generate.
• Avoid large number of fan in signals: Fain-in make the gate inputs difficult to
observe and it also causes their output hard to control.
• Insertion of observation points.
The figure below displays the topology implemented to observe flip-flop. It is typically
used in Ad Hoc techniques. This technique is used for observability and controllability
improvement. This structure is made by placing a multiplexer followed by a flip-flop.
The SE line of the mux is equal to 1 so that the SI (Scan In) signal is selected instead of
the low observability point[2].
Figure 2.2 – Low and High Observability Nodes [2]
8
The figure below shows low controllability nodes. The high controllability node is
achieved by placing a mux with a TM select line. The MUX was placed between the
source and destination inside the logic circuit. The TM line of the mux is set to logic
high so it drives the data of the multiplexor into the DO destination output. The TM
select line will only be logic low during normal operation mode[2].
Figure 2.3 - Control Point Insertion [2]
2.3.2 DFT Structure-Based
These techniques are a systematic and an automatic approach to augment testability.
The structural technique targets manufacturing defects. Some of the methods that use a
structured method are:
• Full Scan: Designs using Scan are the most popular DFT structured method
which involves inserting Scan Chains to the ASIC design. Almost all if not all
of its shift registers will be swapped by scan flops to be used for ATPG with
the purpose of pattern testing as it will be shown in Chapter 4.
• Partial Scan: Storage element subsets are swapped for scan enabled elements.
9
• Built-in Self Test: Mechanism to allow a device to test itself.
• Boundary Scan: Boundary scan adds test cells to pins of the device that can
override the functions of such pin.
Figure 2.4 presents an instance to emphasize how it is difficult it is to test a sequential
circuit. This is due to the fact that it is very difficult to observe and control the internal
states of the device. The sequential circuit shown in Figure 2.4 is composed of
combinational logic and 3 flip-flops (FF1, FF2 and FF3). The main inputs that are
connected to the first two flip flops need to be driven to the values shown in the figure in
order to capture a fault in the FF1 flip-flop. As it can be seen in Figure 2.4 however, it is
difficult to do because FF3 and FF2 are not controllable from any of the system’s primary
inputs. Several operations would have to be done to propagate the value of the faulty
flip-flop to one of the main outputs[2].
Figure 2.4 - Sequential Circuit Internal States [2]
10
2.4 DFT in the Design Flow
Figure 2.5 shows the general DFT design flow.
Figure 2.5 - DFT in the Design Flow [2]
2.5 DFT Scan Cell Design Techniques
Scan cells have 2 inputs. The first input, the functional or data input, drives the
combinatorial elements of as the other input, the test input is used to connect to the next
scan cell. To form a chain. These are formed by configuring the end of one scan flop to
the input of another. The data in them can be controlled by connecting the first scan flop
to a primary input of the device and by connecting the last scan flop to an external
primary output. There are three main scan cell design techniques, the Multiplexed-D
flip-flop Scan Cell technique, the Clocked-Scan Cell technique, and the LSSD Scan Cell
technique. They will be discussed in the following sections[2].
2.5.1 Muxed Scan Cell
This scan cell is formed by a multiplexor followed by a flip-flop. The d flip-flop
transfers data on every rising edge of the clock. It is an edge triggered storage element
unlike its d latch counterpart which is level-triggered. Figure 2.6 displays this type of
scan cell. The multiplexer element in Figure 2.6 employs a scan enable (SE) input signal
11
line to select either the scan input (SI) or the data input (DI) depending on its mode of
operation[2].
Figure 2.6 - Muxed-D Scan Cell [2]
The scan enable signal selects which mode of operation the scan cell is set to.
When the scan enable is set to 0, the scan cell is set to the normal/capture mode. The
data in the DI input will be captured by a rising edge. When the scan enable is set to 1,
the scan cell is set to shift mode. In this mode the SI input is used to shift new data to the
D flip-flop as the current value is shifted out. These modes of operation can be seen in
the waveforms in Figure 2.7[2].
Figure 2.7 - Muxed-D Scan Cell Operation [2]
On each rising edge of the clock, when SE is low, DI present data is captured by
the internal D flip-flop. When the scan enable input is high, the scan input SI is
employed to shift in new data while the current content gets shifted out. The complete
12
Muxed-D scan cell adds a D latch to the multiplexer and a D flip-flop. The only
difference in the final configuration is that the shift operations are edge-triggered. The
capture and standard operations are carried out in a level-sensitive manner as shown in
the figure below[2].
Figure 2.8 - Edge-triggered Muxed-D Scan Cell [2]
2.5.2 Clocked-Scan Cell
A Clocked-Scan cell operation is similar to the Mux-D scan cell operation except
that as its name suggests, the operations are dependent on two independent clocks. The
input selection to the D flip-flop is perform using data clock’s (DCK) rising edge and
shift clock’s SCK rising edge. This configuration can be seen in Figure 2.9[2].
13
Figure 2.9 - Clocked-Scan Cell [2]
The behavior of the Clocked-Scan Cell can also be seen in the waveforms shown
in Figure 2.10. The data input is captured only on DCK’s rising edge while the shift
input is dependent only on SCK’s rising edge. A disadvantage of this configuration is the
additional hardware that has to be used and its higher power consumption in contrast to
the Muxed-Scan Cell[2].
Figure 2.10 - Clocked-Scan Cell Operation [2]
2.5.3 Level-Sensitive Scan Design (LSSD)
Unlike Muxed Scan designs or Clocked Scan designs that are utilized on edge-
triggered designs, the LSSD is used on level-triggered latch based designs. An example
can be seen in the figure below[2].
14
Figure 2.11 - Level Sensitive Scan Design (LSSD) Cell [2]
This LSSD contains two latches labeled L1 and L2. The L1 is the master D latch
while L2 is the slave. The first 3 signals in the figure below are the clocks. They are
used to choose either the D or the I input to drive the last two signals in the plot. Either
one of them can be utilized to control combinatorial logic.
The three existing clocks need to not overlap each other in order to avoid potential
race conditions. As it can be seen in Figure 2.12, Clock A, B and C are not overlapping
and both L1 and L2 can be driven[2].
Figure 2.12 - LSSD Scan Cell Operation [2]
15
2.5.4 Scan Cell Design Advantages/Disadvantages
Table 2.1 displays the advantages and disadvantages of the three main scan cell
styles. These three scan cell styles are supported by the Genus DFT tool that it will be
used in Chapter 4 of this report. The Scan Chain insertion that will be performed in
Chapter 4 will be the Muxed-D Scan Cell style because of its common usage and
compatibility with modern design tools[2].
Table 2.1 – Scan Cell Styles Advantages & Disadvantages
2.5.5 Cadence Scan Cell Requirements
Cadence Genus RTL Compiler has scan cell requirements that must be met in
order to recognize a scan cell within the liberty library files provided by a vendor. The
absence of any of these requirements will cause the scan cell to not be recognized and the
DFT Scan Chain insertion to fail. These requirements are as follows:
• The cell group must contain a test_cell group
• The test_cell group must define the nontest-mode function of a scan cell. This
function can be defined by its ff group declaration, and pin function attributes.
For master-slave scan flip-flops, the ff group must reference both the edge-
16
triggered system clock on the master latch and the edge-triggered clock on the
slave latch.
• Clocked LSSD scan flip-flops and master-slave scan flip-flops must have
statetable group that describes both the system and test operation. For clocked
LSSD scan flip-flops, a statetable group is also used to identify the off-sate of
the system clock during scan-shift operation, and the off-state of the scan clocks
during system-mode operation.
• Each pin defined in the cell group must have a corresponding pin with the same
name defined in the test_cell group.
• The pin groups inside the test_cell group
o Cannot contain timing, capacitance, fanout, or load information
o Can only have direction, function, test_output_only, and signal_type
attributes. The function attributes can only reflect the nontest-mode
behavior of the scan cell. The signal_type attributes must identify the
type of the test pin.
The table below identifies the Cadence signal_type attributes that need to be
defined in the Scan Cell definition within the liberty library. The Scan implementation in
Chapter 4 uses the Muxed-D Scan cell thus one can see which signal type will be
applicable[3].
17
Table 2.2 - Cadence Required Scan Cell Attributes
Table 2.3 below identifies the Cadence pin type attributes that need to be defined
in the Scan Cell definition within the liberty library. The Scan implementation in
Chapter 4 users the Muxed-D Scan style so only the input, output and enable scan pins
will be applicable in Chapter 4[3].
Table 2.3 - Cadence Pin Type Attributes
An example of a scan cell test_cell group description with its respective signal
types and input types in a liberty file can be seen in Appendix S. Note how only the
nontest-mode functions are described[3].
18
2.6 Scan Architectures
There are two main types of scan architectures. These architectures are Full-Scan
design where all storage elements are turned into scan cells while ATPG is used to
generate test vectors; Partial-Scan design where just a subset of the storage elements are
turned into scan cells with ATPG testing too. All the scan architectures are described in
more detail below:
2.6.1 Full-Scan Design
These implementations use every memory element in the design and replaces
them with scan enabled shift registers. These scan shift registers are better known as scan
chains. The results of this replacement is that the primary inputs including those directly
connected to scan cells can be controlled. At the same time the primary outputs including
those directly connected to scan cells can be observed. When Full-Scan is implemented
it converts all the memory cells into scan cells; when only a small percentage of storage
cells are replaced it’s called almost full-scan design. Almost full-scan is done for
performance reasons. Another variation of the Full-Scan design is the Partial Scan which
only targets subsets of the design. Full-Scan design can be implemented with either
Muxed, Clocked or LSSD scan styles[2].
2.6.2 Muxed Full-Scan Design
Using Muxed Full-Scan, the D flip-flops in a sequential circuit will be replaced
with scan cells. An example of a design prior to Scan Chain insertion can be seen in
Figure 2.13. Figure 2.13 is a design that has as its primary inputs X1, X2, and X3
feeding a combinatorial logic block with memory elements. There are three D flip-flops,
19
FF1, FF2, and FF3 which serve as the memory elements. For the scan chain to be
successfully formed[2].
Figure 2.13 - Sequential Circuit without Scan Elements [2]
Figure 2.14 shows how the design changes after Scan Chain insertion. The scan
chain is formed by connecting the output Q of one scan flop in this case SFF1 to the scan
input of the next scan flop , in this case SFF2 , and so forth. All the scan enables input
signals are connected to each other on their respective scan chains thus they operate as a
single mechanism when the SE scan enable signal is set to 1 and shift mode is enabled.
When SE is set low then scan cells capture the response coming from the combinatorial
logic[2].
Figure 2.14 - Sequential Circuit after Scan Chain Insertion [2]
20
The timing diagram in Figure 2.15 shows their operation. Table 2.4 shows the
full-scan operation modes performed on Figure 2.15.
Table 2.4 - Full Scan Operation Modes
The timing diagram in Figure 2.15 shows two test vectors, V1:PI and V2:PI. In
both of this time frames the scan enable signal is logic 1 when the shifting operation
occurs, this is designated by the letter S in the timing diagram. The PPI bits encircled
will then be applied to the combinatorial logic. When the shifting operation has
completed, a hold cycle will take effect before it proceeds to execute a capture operation.
The hold cycle is executed when the scan enable signal goes to logic 0, this is done so the
scan mode can be switched to capture mode. The purpose of the hold operation is to
provide enough time to the scan enable the high to low transition. A vector is then used
in its inputs so that the output produced can be contrasted. After capture is done on the
rising edge of the clock, a second hold operation is added to change the scan enable to
one in order to read the data[2].
21
Figure 2.15 - Timing Diagram [2]
2.6.3 Clocked Full-Scan Design
These type of technique is implemented using capture and shift operations just
like the Muxed-Scan circuit design. The main difference between the Muxed Full-Scan
is that it uses two different clocks, DCK clock for the data in and SCK clock for the scan
in. Both of these clocks are independent of each other and there is no scan enable input
signal in this configuration. The two independent clocks, DCK and SCK, have to
properly be applied during capture and shift mode respectively[2].
Figure 2.16 - Full-Scan Clocked Configuration [2]
22
2.7 Scan Design Rules
The following has to be considered in order to add scan capabilities to a design.
Table 2.5 - Scan Design Rules
2.7.1 Bidirectional I/O Connection
These components are used to transfer data in and out of the circuit. Whether the port
is an input or output is usually specified by another input signal. Conflicts may happen
during shifting mode under this configuration. Figure 2.17 shows an example where the
direction of the I/O port is determined by Q[2].
Figure 2.17 – Bidirectional Connection [2]
23
This could cause opposite logic to be driven. The figure below shows a topology
that can be used to prevent this violation[2].
Figure 2.18 - Bidirectional I/O Port Fix [2]
2.7.2 Tristate Buses
Tristate buses happen when opposing data is driven to a tristate bus. When a tristate
contention occurs it could end up damaging the chip involved. Just like with
bidirectional I/Os, during shifting operation it is not certain that only one bus driver will
control a bus. There are modifications that can be implemented in order to avoid tristate
buses. Figure 2.19 shows a tristate contention with three bus drivers, D1, D2 and D3[2].
Figure 2.19 - Tristate Buses [2]
Figure 2.20 shows a fix to a tristate contention that could be implemented in the
previous figure. In Figure 2.20 there is an EN signal for each of the busses which is set
24
to 1 to enable its specific bus while at the same time disabling the others. To drive the
first bus, EN1 needs to be set to 1 while EN2 and EN3 have to be set to 0. Not fixing
tristate contention can cause fault coverage loss, just like not having a bus keeper or a bus
with no pull-up or pull-down[2].
Figure 2.20 - Tristate Bus Fix [2]
2.7.3 Gated Clocks
Clock gating design methods are used in synchronous circuits in order to reduce
dynamic power dissipation. This is carried out by adding additional logic to reduce the
clock tree which will disable portions of the design so flip-flops don’t have a need to
switch states and thus consume more power[2].
Figure 2.21 - Gated Clocks [2]
25
The clock gating capabilities in the circuit should be disabled during shift operations.
Figure 2.22 shows an example in which clock gating is disabled. This is done by adding
an OR gate to change the LAT and CEN data to 1 utilizing either the SE scan enable
signal or the TM test mode signal. Using the test mode signal will cause the CEN to be
held at 1 during scan and capture operation [2].
Figure 2.22 - Gated Clock Fix [2]
2.7.4 Derived Clocks
Derived clocks are internal clocks generated internally by a clock generator. An
example of a derived clock is a phase-locked loop (PLL) or a frequency divider. The
issue that arises from internal clocks is that they can’t be directly controlled from primary
inputs. Figure 2.23 shows an example where an internal clock ICK drives DFF1 and
DFF2[2].
Figure 2.23 - Derived Clock Example [2]
26
Figure 2.24 shows a fix to the internal clock issue. A mux is placed as an input to
DFF1 and DFF2. The TM select line will determine whether to choose the primary input
clock CK or the internally generated clock ICK. In this case, TM is 1 which will drive
DFF1 and DFF2[2].
Figure 2.24 - Derived Clock Fix [2]
2.7.5 Combinational Feedback Loops
Data stored in combinational feedback loops cannot be controlled and it sometimes
leads to oscillations thus it is considered a bad practice to implement them. Since the
values are not controllable under this configuration it produces design coverage loss and
an increase in test complexity. The best way to fix a combinational feedback loop is to
rewrite the RTL code that generated the feedback loop. If rewriting the RTL code is not
possible then a multiplexor can be employed to disable it [2].
Figure 2.25 - Combinational Feedback Loop [2]
27
2.8 Design Flow – Scan
Scan implementation makes testing easier and careful consideration is needed for
proper scan implementation in an ASIC design. Throughout the ASIC development,
there will be several modifications in the design and the DFT engineer needs to consider
the changes along with the scan implementation rules to avoid disrupting the normal
operation of the circuit. The core of the scan’s proper operation is its shift operation and
its capture operation, if both of these operate properly and there are no design violations
then scan testing can be done successfully. A common flow for scan insertion in a can be
seen in the figure below. Following this flow, the pre-synthesis design has to go through
a scan design rule check. The pre-synthesized RTL design is normally referred to as
netlist. When the RTL has been checked for violations and it has been repaired, the scan
insertion is performed. As a result, the design will be composed of one or more scan
chains to be used for testing. The extraction that follows is used for further verification
of the inserted scan chains and to attain a final scan architecture of the scan design for
ATPG testing. The test generation and scan verification steps that follow are the
implementation of shift and capture operations in the final scan architecture to verify that
expected results predicted by the tool in test generation or fault model simulation match
with the timing behavior of the circuit [2].
28
Figure 2.26 - Scan Design Flow [2]
2.8.1 Scan Design Rule Checking
Before the original design becomes a testable design it has to go through the rule
checking and repair step. This step checks for DFT rule violations and repairs them.
Repairing DFT violations assures the scan design will operate properly and that there will
be higher fault coverage. The violations that it checks for can be seen in detail in the
previous section or in Table. After scan synthesis has finished, the tool will check for
violations again to make sure that no new violations were created. After this step has
successfully passed, the testable design shifting and capturing operations are guaranteed
proper operation. CADENCE Genus will be used to carry out the scan design rule
29
checking in Chapter 4. The complete scan design rule checking output log can be seen in
Appendix D[2].
2.8.2 Scan Synthesis
After the violation-free testable design has been produced, the scan synthesis flow is
started. The scan synthesis section is divided into 4 sub steps, Scan Configuration sub
step, Scan Replacement sub step, Scan Reordering sub step, and a Scan Stitching sub
step. These sub steps take care of the scan chain insertion, optimization and verification.
The scan sub steps will be performed in Chapter 4 and its logs can be found in Appendix
G. These scan sub steps are described in more detail below[2].
2.8.2.1 Configuration - Scan
This is the first step of the scan synthesis. Scan configuration is where the user
specifies the details of the scan insertion. This involve how many scan chains are to be
used and their arrangement [2].
The number of scan chains to be allocated in the design in dependent on the available
input and output pins of the design. The number of inputs and outputs is limited by the
dimensions of the die that is to be used in the design. As a general rule, the more scan
chains in the design, the less time that it takes to perform tests on the chip. Testing time
is important because the more time spent on testing, the more expensive it will be to carry
out those tests.
The scan cells to be used in the scan configuration is determined by the vendor library
used for synthesis. Vendor libraries usually have multiple scan cells that are meant to
30
match the behavior of different storage elements. The scan cell must resemble the
storage element timing and functionality.
Regarding storage elements to be replaced by scan cells, they are omitted when they
lie on critical paths where timing margins are very close to cause adverse timing effects.
Each scan chain is dependent upon a single clock domain. If the scan chain has a very
large number of cells then it is likely to be split into multiple scan chains [2].
Figure 2.27 – Positive and Negative Edge Scan Elements [2]
If there are multiple scan cells using different clocks then a lock-up latch is placed
between them to assure proper operation of the cells regarding of any clock skew
between different clocks. Figure 2.28 shows a lock-up latch between two different clocks
while Figure 2.29 shows its respective timing diagram [2].
31
Figure 2.28 - Lock-up Latch between Two Clock Domains [2]
Figure 2.29 - Lock-up Latch Configuration Timing Diagram [2]
2.8.2.2 Scan Replacement
Scan replacement is the step where all the storage elements in the design are replaced
with their equivalent scan cell counterparts. Such scan cells closely resemble speed,
power, and dimensions similar to the original elements. To avoid floating data during
scan replacement, the inputs of the scan cell are tied to its same cell outputs. These
configuration is later removed during the stitching phase of the scan synthesis[2].
32
2.8.2.3 Reordering - Scan
This is the sub step where chains are reorganized. The reorganization of scan chains
is meant to limit the extent of interconnecting wires implemented in the scan chains.
There are different way in which scan chains can be reordered. It can be done within its
own scan chain or among separate scan chains [2].
2.8.2.4 Scan Stitching
Scan stitching is the final step of the scan synthesis. As its name implies, this is the
step where all the scan cells are put together to create scan chains. In addition to
connecting all the internal scan cells together, the primary input of all the scan chains is
also connected to the first scan cell while the last scan cell in the chain is connected to the
scan chain’s primary output port. This two connections are important since the scan
chain has to be externally controlled. An important rule regarding the input and output
ports of the scan chain is to not use high speed I/Os because the I/O ports loading could
degrade speed of the device. During scan stitching, lock-up latches are also places along
in the scan chain if the scan chain is suing more than one clock domain. A successful
scan stitching step will yield the final scan design netlist[2].
2.8.3 Scan Extraction
In this step the original RTL design has already changed to a scan design. Scan
extraction involves taking out all the scan occurrences from every chain in the design.
The extraction is done in order to carry out testing and it’s used in it to recognize the
entire scan architecture of the design. Scan extraction is the final step that is done by
CADENCE Genus in the implementation that will be done in Chapter 5. The scan netlist
33
generated by Genus will then be used by CADENCE Modus to carry out ATPG tests
using CADENCE Incisive simulator.
2.8.4 Scan Verification
The scan verification verifies the scan architecture after all the physical
implementation of the design is done. If the scan design was not properly stitched then
the scan verification will provide information specifically pointing at errors it detected.
The scan verification will also fail if it found any errors during shift operations, if this is
the case then it is likely to have been caused by timing violations between scan cells. It
usually involves delays from one scan component to the input of another. If the timing
violation between two scan cells was produced by a scan chain with a single time domain
then it is an indication that there was a failure with the clock tree synthesis. If the timing
violation between two scan cells was produced by a scan chain with multiple scan
domains then it is an indication that there was a failure in the lock-up latch insertion [2].
In addition to timing violations between two scan cells there could be scan shift
problems involving incorrect initializations that causes the scan circuit to not be into the
right test mode. This in fact happened during the implementation of the scan design
using CADENCE Modus. There were parameters that controlled the external reset
signals that were not properly initialized and thus it caused the scan verification to fail
simulation. Another reason for failure could be an incomplete rule checking/repair step
where the tool does not fix asynchronous reset/set signals to be disabled during shifting
and capture operations; it could also have been caused if positive edge cells were placed
ahead of negative edge cells[2].
34
Chapter 3
3.1 UART (Universal Asynchronous Receiver Transmitter) Design
A UART system will first be designed to be used in the scan implementation. A
UART will use a serial communication interface to carry out the scan architecture and
ATPG implementation. UART stands for universal asynchronous receiver transmitter; it
is a means to send scalable data with scalable speed. The design will be done in Verilog
and it will include several sequential and combinational modules. The data that is
transferred using the UART will be retrieved by a receiver interface; what makes this
system asynchronous is that both the transmitter and receiver are not using the same
clock domain. A synchronous system works using the same system clock so there is no
loss of data due to metastability issues; in this case both the receiver and transmitter will
have to agree in the same setup for data to be properly sent and received; both the
receiver and transmitter will have to be sampled at the same rate for this design to work.
3.1.1 Design Overview
The design is composed of several modules that will have to be set up correctly to be
able to successfully transfer data. The design is composed of four main modules that will
carry out the data operations. Parallel data will be sent through the transmitter stage. The
data will then be saved in a FIFO (First In First Out) memory module. The system will
rely on flags to transfer the data since the system does not rely on a clock to synchronize
it. Through these flags the transmitter will let the FIFO know when to start sending the
data into it. This memory module saves the data in the same order in which it was
received. It will take 8 bits of parallel data and deliver it to the transmitter when the
controlling flag is asserted. Since the receiver and transmitter will have different clock
35
domains, the design will rely on both modules to be set at the same baud rate. A baud
rate generator module will be designed with equal specifications for both the receiver and
transmitter, so no data is lost during serial transmission. The baud rate generator will
sample at 16 times the designated scalable baud rate. This agreement in sampling will
be met by both the transmitter and receiver. A diagram of two UART’s receiver (Rx) and
transmitter (Tx) can be seen in Figure 3.1.
Figure 3.1 – Two Rx/Tx Interface Diagram [11]
The transmitter will sample and convert each of the parallel bits into serial bits. Each
serial bit will be sampled 16 times as it was set up in the baud rate generator. For every 8
bits of data the transmitter will send out 10 bits. The two additional bits are the start bit
placed at the beginning of the data to point out when the data begins and a stop bit to
mark where the data transmission ends. There is an optional parity bit that could be used
for single bit error detection but there was no need to implement that in this design.
Figure 3.2 below shows the data communication from the transmitter to the receiver after
it has been decoded from parallel to serial data format.
Figure 3.2 – Tx to Rx Serial Data Transmission [11]
36
3.1.2 Baud Rate Generator Stage
The baud rate generator stage will have the same set up in both the transmitter and the
receiver stage; this is done so every bit can be correctly transferred with no data loss
since both the transmitter and the receiver work at different clock domains. In this
application, the baud rate will run at 38400bits/s thus each serial transmitted bit will be
26us per bit. A table of the commonly used baud rates can be seen in Figure 3.3.
Figure 3.3 - Baud Rate Common Speeds
The baud rate generator module is a scalable module so it can be adjusted to work at
different baud rates. The baud rate generator will take an input reset signal, an input
37
clock signal, and an output signal that will be asserted high after a specific number of
clock cycles. The formula below shows the numbers that were used in the design.
𝑆𝑦𝑠𝑡𝑒𝑚𝐶𝑙𝑜𝑐𝑘
16∗𝐵𝑎𝑢𝑑𝑅𝑎𝑡𝑒 (1)
𝐵𝑎𝑢𝑑𝑅𝑎𝑡𝑒 = 38400 (2)
𝑆𝑦𝑠𝑡𝑒𝑚𝐶𝑙𝑜𝑐𝑘 = 100𝑀𝐻𝑧 (3)
100𝑀𝐻𝑧
16∗38400= 163 (4)
Equation 1 shows the general formula that was used to calculate the rate at which the
output was going to be enable. The system clock was set to run at 100MHz as it is shown
in equation (3). The baud rate for this application was picked to be 38400 as shown in
equation (2) but other standard values could have been chosen. The 16 stands for the
number of times each serial bit is to be sampled. It could have been modified to 8 as well
which is usually a standard value too. Equation (4) shows the final value of 163; this
implies that the output will be asserted high once for every 163 times the input clock
signal is asserted high.
The difference between bit rate and baud rate is that bit rate is the number of bits sent
per second while baud rate is the number of times a signal deviates in a serial
transmission. In this case, the baud rate signal will be toggled once every 163 times the
clock input is asserted high. This baud rate generator will be feeding the input sampling
signal of both the receiver and transmitter stage. The Verilog source code for the baud
rate generator can be seen in Appendix A of this report.
38
Below is a snippet of the Baud Rate Generator. It was designed using two
conditional statements and an always Verilog function. The always Verilog function
checks every rising edge of the clock and the reset input thus why both input signals are
found in its sensitibity list.
3.1.3 FIFO (First In First Out) Memory Module
The first in first out module will serve as a memory buffer array that will save the
parallel data coming into the transmitter stage. The FIFO will save the data in the same
order in which it was received; and it will output such data array in that same order as
well since it does not rely on a clock to know when to output its saved data content. The
counterpart to the FIFO is the LIFO which stands for last in first out but that
39
configuration is not suited for the requirements in this design. Figure 3.4 shows a
diagram of data processing using a FIFO and LIFO.
Figure 3.4 – Diagram of Data Processing using a FIFO and LIFO [11]
The FIFO will be used to store the 8 bits of parallel data into memory stacks. The
memory locations for such stacks will be assigned by pointers within the module. The
FIFO module is composed of an output read data signal, and a write data signals. Both of
these data signals are 8 bits in size and both of them are active based on their read and
write enable input signals respectively. The write enable input signal needs to be asserted
high for the FIFO to store data while the read enable input signal needs to be asserted
high for the FIFO to output the following data in the array queue.
In addition to the read and write signals and its enable signals; the FIFO also has a
full flag output signal and an empty flag output signal. Both of these signals serve the
purpose of letting the modules interfacing with the FIFO know if the FIFO memory
stacks are either full or empty. For instance, in the transmitter stage of this design, the
empty flag is connected to the start bit input of the transmitter. When the empty flag is
no longer asserted high it will let the transmitter know that it no longer is empty and that
40
it already has data allocated in its memory stack; the transmitter module will then process
the first 8 bits of data allocated in the queue of the FIFO. Figure 3.5 shows the
connections of an Asynchronous FIFO module.
Figure 3.5 - Connections of an Asynchronous FIFO Module
The FIFO’s full flag will serve as the handshake between the transmitter and the
FIFO; this will mark the start of the data transmission agreement between the two
modules.
There are two main rules that were followed when it came to the usage of this FIFO.
The first rule is that no data can be written to the FIFO when it is full. This is rule is very
logical since writing data to an already full FIFO will cause data overflow problems and
the FIFO will start behaving in a way that it is not intended. The second rule to keep in
mind when it comes to the FIFO is not to read data from the FIFO when it is empty. This
rule also makes sense because it will cause the FIFO to be in an underflow state; this will
also cause the FIFO to behave in an unpredictable manner.
A snippet of the FIFO code can be seen below. It is the section that checks for the
write_enable signal and the full_flag which checks when the FIFO is full.
41
If this section of code was not present, the FIFO will try to write to an already full
FIFO which is not allowed. The next snippet of code checks the read_enable input signal
and the empty_flag signal which checks when the FIFO is empty.
The last snippet of code checks any change in the status of the FIFO. It uses the
counter_full_or_empty signal in its sensitivity list. It determines whether the FIFO is
empty or full. It assigns 8 bits to full_flag and 0 if it is empty. The full Verilog code for
the FIFO can be found in Appendix A.
42
Figure 3.6 - FIFO Simulation of Write Ports
Figure 3.6 shows a simulation of the FIFO I/O ports. The FIFO simulation displays
how the flags works. Data goes in the input of the FIFO but it does not get stored until
the write enable signal is asserted high. After the store operation occurs, the empty flag
toggles from high to low indicating that the FIFO is no longer empty and can begin
transferring data. After data has been transferred and the data is full, the full flag will
toggle from low to high, thus no more data can be sent into the FIFO or it could cause
data overflow.
Figure 3.7 shows the read ports of the FIFO. When the FIFO read enable input
signal is asserted high the data will be read from the data out output port. When the data
is read, the full flag toggles from high to low. The FIFO source code can be seen in
Appendix A.
43
Figure 3.7 – FIFO Simulation of Read Ports
3.1.4 Transmitter Stage
The transmitter stage is one of the main two stages that make up a UART design.
The transmitter stage handles the conversion from parallel data coming from the FIFO
queue array into a serial data stream that will be sent out to a UART receiver.
In order for data to be transferred properly both the transmitter and the receiver need
to be running at the same baud rate. During the serial transmission of data both the
transmitter and the receiver will be functioning with different clock domains so their data
exchange will depend on having them set at the same baud rate. In addition to having the
same baud rate, the receiver and transmitter will have to agree in the number of data bits
transferred; this include the number of bits in the data packet, whether it has an optional
parity bit for error detection and how many stop bits are used.
Figure 3.8 - Serial Data Packet Format [11]
44
The serial data stream used in this implementation has the format depicted in Figure
3.8. As it was mentioned in the baud rate generator section, the baud rate is set up to be
running at 38400 bits per second. This means that the receiver will sample 16 times for
every serial bit coming from the transmitter.
Figure 3.9 - Bit period of 26us [11]
Figure 3.9 shows the time frame of every bit in the seiral transmission from the
transmitter stage. Because the baud rate is 38400 bits per second, each bit will be 26us as
shown in Figure 3.3. In this implementation a packet of 10 bits will be transmitter for
every 8 bits of data. The two additional bits are used at the begging for the start bit, to
indicate when the first bit begins; and a stop bit to indicate when the data ends.
After the stop bit ends, the transmission will remain high to indicate that it is in an
idle state. During the idle state the system will wait for signal to go low (start bit) to
indicate that another 8 bits are being queued up to be transmitted. The full transmitter
stage can be seen in Figure 3.10. It shows the connections between the bad rate generator
and the FIFO module that were previously covered, and the transmitter.
45
Figure 3.10 - UART Transmitter Stage
The FIFO module and the transmitter module communicate with each other through
three signals. The first is the data signal which transmits the parallel data to be turned
into serial data. The second signal is a stop flag signal from the transmitter to the read
enable input of the FIFO; this will let the FIFO know when the transmitter can start
reading the data. The third signal is the empty flag from the FIFO going into the start
input of the transmitter; the empty flag will toggle when the FIFO is no longer empty
enabling the transmitter to begin producing the the start bit. Because the sampling is set
to be 16, the start bit will consist of a low enable signal that will last for 16 high
assertions of the signal coming from the baud rate generator. In a similar manner the
following bits will also last for 16 high assertions of the baud rate reference signal.
As it was mentioned in the previous section, the baud rate was set to 38400 which
will cause each serial bit to be 26us. Because a total of 10 bits are sent, the transmission
will last for approximately 260us. Figure 3.11 shows parallel data coming into the
transmitter stage, in this case 00101001. This parallel data will then be converted into
serial data as it can be seen in the transmit_data_out output signal. The full Verilog Code
for the transmitter can be found in Appendix A.
46
Figure 3.11 - Transmitter Stage Simulation
3.1.5 Receiver Stage
The receiver stage is the second main stage of the UART interface. It takes in a
serial input data to then convert it back to its original parallel data format. The parallel
data will then be transferred into a FIFO which will store that data in the same order it
was received. The data will be queued up in the FIFO to be read once the read enable
signal of the FIFO is asserted high.
As it was mentioned in the transmitter stage, for data to be correctly received both
the receiver stage and the transmitter stage will have the same baud rate and bit number
set up. The agreed number of bits to be received are 10. The first bit received will be the
start bit which will let the receiver know the first bit of the data packet will follow. There
will be no parity bit for this design. The last bit will be the eigth bit. It will then be
followed by the stop bit which will conclude the data transmission. After the data
transmission has concluded it will the receiver will go back to an idle state and wait for
another low start bit to be asserted again.
47
As it was explained in the design overview, the UART does not rely on a clock to
sync the transmitting and receiverng data devices. In this case the receiver will know
when to sample based on the baud rate selected.
In an ideal case, the sampling of the signal should be carried out as far from the
signal edges as possible. This makes sense since the possibility of sampling the wrong
value increases as the sampling point approaches a transition state. Figure 3.12 shows the
dial place for sampling of data to take place.
Figure 3.12 - Data Stream Sampling Locations [11]
Because each bit is transmitted at 26us, the baud rate enable signal is asserted 16
times per serial bit. In order to sample correctly, the sampling is to be carried out half
way through, during the 8th time the baud rate enable signal is asserted high. This will
optimize and reassure that all data bits were properly sampled. A block diagram of the
sampling process can be seen in Figure 3.13. In the block diagram one can see that the
system will remain in the IDLE state until the receiver identifies the Start Bit asserted
low; this is the data_in input signal coming from the transmitter stage as it can be seen in
Figure 3.13.
48
Figure 3.13 - Receiver Stage Block Diagram
The Start Bit state will trigger a 3-bit counter that will count to 8; this marks the mid
point of the start bit since the start bit is made of 16 baud rate enabling signals. Once it
has reached the midpoint of the Start Bit, the state will transition to the Data state and it
will begin another counter that will count to 16. Counting to 16 enable baud rate signals
will place it right in the middle of the first bit. The first data bit is then saved into a new
register which will later be used to reassemble the serial data bit stream into its equal
parallel data format. In addition to saving the first bit of the parallal data, this same
process will be repeated 8 times because of another counter that will keep track of the 8
bits of data that are to be saved in the new register. Once the 8 bits of data have been
successfuly saved into the new parallel 8-bit data, it will transition from the Data State
49
into the Stop Bit state as it can be seen in Figure 3.13. Once in the Stop Bit state it will
count 16 more times before transitioning back in to the IDLE state. While in the IDLE
state, the UART receiver’s state machine will keep on checking for the following low
Start Bit to be asserted low for it to restart the same conversion process all over again.
Figure 3.14 – Receiver Stage Simulation
Figure 3.14 shows the input signal receive_data_in with the input serial data and
right below it one can see the 8-bit parallel data output signal. The final output signal is
00101001. This is the same serial data bit stream shown at the input signal except that
the serial input is read from left to right starting with the Start Bit asserted low and
ending with the Stop Bit asserted high.
There are other signals in Figure 3.14 show how the receiver module functions. The
assemble_reg[7:0] signal is the register that is used to save the sampling and thus
reassemblence of the parallel data format. It can be seen how the 8-bit register’s data is
shifted in from its 8’h80 to 8’h29. In addition the state_reg[2:0] keeps track of the
current state of the receiver’s state machine. As it was depicted in the block diagram
from Figure 3.13, the IDLE state is 0, the Start Bit state is 1, the Data State is 2 and the
50
Stop Bit State is 3. The transition of these three states can clearly be seen in Figure 3.14.
Figure 3.15 shows the block diagram of the receiver stage.
Figure 3.15 - UART's Receiver Stage
The stop_bit_flag signal is the one to handle the handshake between the FIFO
module and the receiver module. When the Stop Bit flag is triggered, it will enable the
write enable signal of the FIFO to store the corresponding 8-bits of data into its memory
array in the order in which it was received. In order for the data to be read the read
enable signal of the FIFO would have to be asserted high. In addition, and unlike the
transmitter stage, the receiver stage FIFO does not rely on neither the full flag nor the
empty flag. The full Verilog Code for the Receiver can be found in Appendix A.
3.1.6 UART Top Level Testbench
A testbench was made to test the complete design. A top level module containing
the two main stages of the design was also made to carry this out. Both the transmitter
stage and the reciver stage were instantiated within it.
51
Figure 3.16 shows the UART’s top level module. The top level design is made of
the instantiation of both the transmitter and receiver modules with their respective FIFO
memory array modules, and both of them functioning using the same 38400 bit baud rate
generator module so sampling can be achieved at the same rate as it was displayed in
previous sections. The additional unused I/O ports shown in the top level of the design
were added to be used during the scan implementation that will be done in Chapter 4.
Figure 3.16 - UART Top Level I/O Ports
To test the proper serial communication of both the receiver and transmitter the
testbench was design in a way that it will connect the transmitter_serial_data output to its
receiver_serial_data input. Figure 3.17 shows the data processing from the time a new
parallel data is sent to the primary input of the UART top level to the time that same data
is able to be read from the primary output of the UART top level. Figure 3.17 uses to
cursors to mark that time. In the top left corner of the Figure 3.17 one can also see the
time difference between these two cursors (Cursor-Baseline) which is about 508.115us.
Because the baud rate for the design was set to 38400, each serial bit is 26us, there is a
total of 10 bits sent per 8-bits of data thus the transmitter stage by itself takes about 260us
52
to send parallel data and to convert that data into serial format. One would assume that
the receiver stage would also take about the same time to process the data back into
parallel format but that is not the case. Because the receiver stage sampled the data half
way through each bit it took slightly less time to process the data into its primary 8-bit
output port. Subtrancting the overall time of 508.115us that it took for the UART top
level to transfer and receive data, by the time of 260.8us that it took the transmitter stage
alone to convert parallel data into a serial data, yields 247.315us which is the time that
the receiver stage takes to process the data from a serial bit stream into its equal parallel
data format. The UART top level testbench design can be seen in Appendix B.
Figure 3.17 - UART Top Level Simulation
53
Chapter 4
CADENCE TOOLS – Genus Synthesis Solution and Modus DFT Solution
4.1 Genus Synthesis Solution
Genus Synthesis Solution is Cadence’s next generation register transfer level
(RTL) synthesis tool. It enables DFT implementation without compromising
performance, power, runtime, area or accuracy.
4.2 Key Features
• Comprehensive RTL level and gate level DFT design rule checking
• Full Integration of all DFT insertion
• Time-driven physically aware scan chain insertion and stitching
• Insertion of advanced testability features, boundary scan, PMBIST, OPCG and
Compression
• Scan Violation automatic fixing
• Tight correlation to place and route
• Multi-bit insertion to group registers for area reduction
• Power optimization
• Massively parallel architecture to improve turnaround time
• Extraction of any subset or partition of a design
54
4.3 Key Benefits
Genus Synthesis Solution allows to run a complete synthesis flow on a design
with specifications and optimize such design for timing, area, and power. It enables
the user to account for testability requirements in the early stages of the design. Its
built-in design rule checking allows the creation of test-ready RTL that can be easily
synthesize within its sandbox environment. The integration of testability features
within its environment ensures scan design implementation and optimization. Genus
also has commands that generate run script templates tailored to the designer’s
specific needs.
• DFT synthesis and optimization
• Delivers DFT insertion within the synthesis flow without compromising
design performance
• Accounts for DFT constraints and rule checking early in the design cycle
at RTL
• Reduction in iterations between block-level and unit-level synthesis
4.4 Preparing to Run Genus Synthesis Solution
Prior to running Genus, we need to discuss Genus’ interface and run scripts as
well as discussing what is needed in order to synthesize a design in Genus. Block
diagrams of this flow will also be presented.
55
4.4.1 What is Needed to Synthesize a Design
In order to synthesize a design, Genus requires several files. These files will also
be discussed along the synthesis flow. A list of the required items will be presented
below along with the optional but recommended files.
• Liberty Format Library (.lib) Files
• Library Exchange Format (.lef) Technology Files
• Verilog or VHDL or SystemVerilog Files
• Synopsys Design Constraints (.sdc) Files
• Genus Run Scripts (.tcl)
• Genus Executable & Genus License
Optional but recommended Files:
• QRC tech file / Capacitance Table File (.captbl)
• Design Exchange Format (.def) Floorplan File
• Switching Activity Files: .saif, .tcf, .vcd
• Power: Power Format (.cpf) File
Supports IEEE 1801 Standard
4.4.2 Genus Run Scripts
Genus is a true .tcl based software tool and thus its run scripts are all tool
command language (tcl) scripts. Tcl is a simple open-source programming
language. Genus run scripts will be composed of several attributes, objects, lists,
directories and commands.
56
4.5 Invoking Genus
Genus can be invoked by using any of the following commands in unix:
• Genus
• Genus –legacy_ui
When the command Genus is used it runs the tool in Common UI while using
Genus –legacy_ui will start Genus with Legacy UI. The scan implementation in this
chapter will be done using Legacy UI.
4.5.1 Genus Shell & Navigation
All activity in Genus occurs within its shell. It is an environment similar to that
of UNIX and it shares many characteristics with the UNIX environment [6].
Genus uses a Design Information Hierarchy to interface with its database [6]. The
top-level of this hierarchy can be seen in Figure 4.1.
Figure 4.1 - Genus Shell Directory
UNIX commands can be used once the user has accessed Genus’ shell. For
instance, the cd command will change the directory to any in Genu’ Design Hierarchy
and not the current UNIX directory from where Genus was originally invoked. The
following lists the contents of the root directory as seen in the Figure above:
• legacy_genus:/> ls
./ flows/ libraries/ mmc_designs_spec/
designs/ hdl_libraries messages/ object_types/
57
4.5.2 Genus Synthesis Templates
Genus can generate tcl synthesis run script templates for running Genus. These
scripts are ideal to use because it ensures that all the attribute and variable settings are
for the latest release as well as the layout of the recommended synthesis flow. The
following command can be used to generate Genus’ DFT template:
• legacy_genus:/> write_template –dft –outfile <file_name.tcl>
The –dft option generates the DFT attributes and commands in the script. The
template script will be generated within the same directory from which Genus was
invoked. The Genus run script template can then be edited to reflect the
characteristics of the design. Inside the template there will be angle brackets <name>
which points at what needs to be provided, such as names and directories were the
files are located. The main sections of the synthesis and scan insertion will be
covered in the following sections. The final edited Genus DFT run script that was
used in this report can be seen in Appendix C.The Genus synthesis flow that will be
followed can be seen in Figure 4.2. The template lays out many of the required
parameters from this flow. The implementation will be carried out in this order as
well for consistency, starting with Read Target Libraries and ending with Run
Incremental Optimization. The UART design directories will be used for the
commands shown in Chapter 4 but they will be done for both designs from Chapter 3.
The logs for both designs will be found in the corresponding referred Appendixes.
58
Figure 4.2 - Genus Synthesis Flow
4.6 Read Target Libraries
This is the initial section of the Genus run script. In this section the paths for the
different directories, Verilog design files, libraries and variables are defined. Setting
the target library is the most important part since without it synthesis can’t be
performed. The library used in this implementation is an open source library meant
to be used for educational purposes. Commercial libraries are not free.
• set_attribute init_lib_search_path ./../library_open_source /
• set_attribute library NangateOpenCellLibrary_typical.lib /
• set_attribute lef_library ./../library_open_source/NangateOpenCellLibrary.lef /
This list of attributes point to the directory where the ASIC vendor libraries can
be found. The first attribute points to the directory where the libraries are located, the
second attribute specifies the exact name of the liberty file (lib) library to be used and
59
the final attribute points to the library exchange format file (lef) to be used during
synthesis.
4.7 Reading In The Design
The design path and files need to be defined after defining the paths for the
libraries. To read in the design the path attribute is first specified followed by a list of
all the Verilog files used in the design. All the files need to be found in that directory
or it will cause execution of the script to error out.
• set_attribute init_hdl_search_path ./rtl_uart /
• read_hdl –sv {baud_generator.v uart_transmitter.v uart_receiver.v
FIFO1.v uart_top.v}
If there are multiple files to be read in then they have to be declared inside curvy
brackets. The –sv option in the second bullet point enables the usage of
systemVerilog. If no SystemVerilog construct is used in the design then its inclusion
is not needed. Note that all the files used in this implementation are the ones from the
UART design, but they were also performed for the Lock System. The logs for both
will be presented to gether in the respective Appendix.
4.8 Elaborate the Design
After the libraries and the Verilog files have been defined and read in, the overall
design needs to be created. This is accomplished by using the elaborate command. If
the tool finds any undefined modules they will be labeled as “unresolved” and thus
treated as blackboxes.
• elaborate $DESIGN
60
4.9 Constraints Setup - Read SDC
A constraint file in Synopsys Design Constraint (SDC) format can be read into
Genus. Genus generates a cost group for each clock defined in the file. SDC is a
format used to state the design’s power, timing and area constraints for a specific
design. SDC files, just like Genus scripts, are tcl based.
After elaboration, an SDC file was used to specify the characteristics of the clock
to be used in the design. Other parameters were used in the implementation to further
show what can be modified in a constraint file. Some of the parameters that can be
set as constraints are rise and fall clock transition, clock uncertainty, max input delay,
etc.
The following command can be used to read in the SDC file named read_sdc.sdc:
• read_sdc read_sdc.sdc
The clock definition and constraints inside this file can be seen below:
• create_clock –name clk –period 10 –waveform {0 5} [get_ports “clk”]
• set_clock_transition –rise 0.1 [get_clocks “clk”]
• set_clock_transition –fall 0.1 [get_clocks “clk”]
• set_clock_uncertainty 0.1 [get_ports “clk”]
• set_input_delay –max 1.0 [get_ports “reset”] –clock [get_clocks “clk”]
The option get_ports and get_clocks within the brackets specify the ports and
clock to be used. The clock in the Dual Lock System design is named clk so after
elaboration it can be invoked; because of this the SDC file cannot be read in prior to
elaborating the design or it will error out.
61
4.10 Setup for DFT Rule Checker
The DFT Rule Checker delivers preliminary warnings of test insertion issues
based on the specified configuration. The setup stage will configure the specific DFT
characteristics required to be present in the design. In addition, this section will also
define the relevant ports used during scan operation.
These signals are of course dependent on the scan style implemented. The scan
style in this implementation will be the Muxed-D Scan cell Style. The Muxed-D
Scan Cell Style characteristics were covered in Chapter 2.5.1 while its Muxed Full-
Scan architecture was covered in Chapter 2.6.2. Figure 4.3 shows the Muxed Full-
Scan architecture applied to a non-scan flip-flop.
Figure 4.3 - Non-Scan Flip-Flop & Multiplexer Scan Flip-Flop
The following attributes were used in the Rule Checker Setup:
• set_attribute dft_scan_style muxed_scan /
• set_attribute dft_identify_top_level_test_clocks true /
• set_attribute dft_identify_test_signals true /
• set_attribute dft_identify_internal_test_clocks false /
• set_attribute use_scan_seqs_for_non_dft false /
• set_attribute dft_scan_map_mode tdrc_pass /
62
• set_attribute dft_connect_shift_enable_during_mapping tie_off /
• set_attribute dft_scan_output_preference auto /
• set_attribute dft_lockup_element_type preferred_level_sensitive /
The dft_scan_style attribute designates the type of scan style to use. Genus only
supports Muxed-D scan style and clocked LSSD scan style.
The top_level_test_clocks attribute automatically identifies the top level test
clock while the test_signals attribute automatically assigns a test mode signal to all
top-level pins. The internal_test_clocks attribute is set to false so the rule checker
identifies separate clocks in the same DFT clock domain. The
use_scan_seqs_for_non_dft set to false prevents mapping of scan flip-flops if they did
not pass the DFT Rule Checker.
The connect_shift_enable_during_mapping set to tie_off will cause its shift-
enable pins to be connected to their offstate, meaning tied to a low for active high and
tie to a high for active low. The scan_output_preference set to auto will enable Genus
to automatically choose the output pin based on the pin load or impact on the timing.
The final attribute in the list requests to insert lockup latches whenever is possible.
In addition to the attributes, the setup DFT Rule Checker needs the user to specify the
pins utilized in the scan style (Muxed-D style). The Muxed-D style uses a shift
enable for the enable signal, a scan test clock signal to be used during shifting mode
and test mode if required. The following two definitions were made to implement a
Muxed Full-Scan design:
63
• define_dft test_clock –name clk /designs/uart_top/ports_in/clk
• define_dft shift_enable –name scan_enable –active high
/designs/uart_top/ports_in/scan_enable
4.11 Run DFT Rule Checker and Report Registers
After the setup has been configured to match the design’s required DFT
specification, the DFT Rule Checker will check for DFT rules and consistency. The
report command will be used as well for the tool to provide more information
regarding the DFT architecture. The DFT Rule checker is executed using the
following commands:
• check_dft_rules [design] > file
The check_dft_rules will evaluate the design for DFT readiness. The flip-flops
that successfully pass the DFT Rule Checker will in later stages of the flow be
mapped to respective scan flip-flops in synthesis and thus be included in scan chains.
The output of Genus’ Rule Checker can be found in Appendix D of this report.
The following are some of Genus’ supported rule checks:
• Uncontrollable clock nets
➢ Internally generated clocks
➢ Gated clocks
➢ Tied clock nets
➢ Undriven clock nets
64
• Uncontrollable asynchronous reset/set nets
➢ Internally generated asynchronous reset/set signals
➢ Gated asynchronous reset/set nets
➢ Tied active asynchronous reset/set pins
➢ Undriven asynchronous reset/set pins
• Conflicting asynchronous reset/set net and clock
• Shift Register Rules
➢ Reset/Set are controlled OFF during scan shift
➢ Shift register pins proper connections to transfer data
➢ Clocks are turned on
• Abstract Segment Rules
The following are Genus’ advanced DFT rule checks:
• Tristate contention for external and internal nets
• Asynchronous reset or set race conditions
• Data race conditions and clock
• Floating net violation
• X-source violation
The report dft_registers command will output the DFT scannable status of all flip-
flop instances after running the DFT Rule Checker in the design while dft_setup will
provide setup information. These commands are to be used after check_dft_rules.
• report dft_registers > file
• report dft_setup > file
65
The full log output of the report dft_registers command can be found in Appendix
E of this report. The full log output of the report dft_setup command can be found in
Appendix F.
4.12 Fix DFT Violations
Genus has a command to automatically fix the DFT violations that have been
identified by the Rule Checker. Only the specified types are fixed. The violations
should be listed in the Rule Checker log. The following command is used to fix
identified DFT violations from the Rule Checker for the specified async_set type:
• fix_dft_violations –violations {object name} –async_set
Any DFT violation can be selectively fixed by specifying its violation identifier
which can be found in the log from the check_dft_rules log. It has the following
form: vid_<n>_[asynch|clock|abs], where n is an integer.
DFT violations can be reviewed prior to running the fix_dft_violations with the
following command:
• report dft_violations
There were no dft_violations identified by the Rule Checker in the Dual Lock
System design thus there was no need to fix any violations.
4.13 Synthesize Design to Generic + Map to Scan
In this stage of the flow the design will be synthesized to generic gates. It takes
the top-level Verilog designs and it synthesizes the RTL to generic gates. The
following command is used to synthesize to generic:
66
• syn_generic <design>
It does this using the constraints from the SDC file that was read in earlier in the
flow. The next step in the flow is to map the design to the cells described by the
supplied technology ASIC library and perform logic optimization. The following is
the command to perform mapping:
• syn_map <design>
Note that the effort during optimization is handled by the syn_map_effort root
attribute. In this implementation the syn_map_effort attribute was set to high as it
can be seen in the Genus run script.
4.14 Configure Scan Chains
By default the tool scan configuration is set to insert one scan chain per each test
clock domain. This can be configured differently as it will be shown in this section.
By default, there is also no limitation for the scan chain length. It is up to the user to
specify the maximum length of the scan chains in the design. The attributes to
modify the scan chain length are as follows:
• Set_attribute dft_min_number_of_scan_chains <integer> /designs/uart_top
• Set_attribute dft_max_length_of_scan_chains <integer> /designs/uart_top
In addition to attributes the scan chains can be configured by defining them.
Each separate scan chain definition can be given its own name and it can also
specify which port to use as a primary inout for both ends of the scan chain. The
following four scan chain definitions were used in the implementation:
67
• define_dft scan_chain –name chain1 –sdi /designs/uart_top/ports_in/scan_in_1 –
sdo /designs/uart_top/ports_out/scan_out_1
• define_dft scan_chain –name chain2 –sdi /designs/uart_top/ports_in/scan_in_2 –
sdo/designs/uart_top/ports_out/scan_out_2
• define_dft scan_chain -name chain3 -sdi /designs/uart_top/ports_in/scan_in_3 -
sdo /designs/uart_top/ports_out/scan_out_3
• define_dft scan_chain -name chain4 -sdi /designs/uart_top/ports_in/scan_in_4 -
sdo /designs/uart_top/ports_out/scan_out_4
The –name option designates a name to the scan chain definition. In this case
four scan chains were defined, chain1 , chain2, chain3 and chain4. The –sdi option
stands for scan data input and it is used to point to the specific port to be used for scan
data in. The –sdo option stand for scan data output and it is used to point to the
specific port to be used for scan data out. These ports were created in the Dual Lock
System design’s top level module for the sole purpose of scan chain insertion. The
design’s scan port declarations can be seen in the lock_top module file in Appendix
A. The scan chains must be declared as inout ports. The technology libraries used in
this design have no PADs so their usage had to be omitted in the design.
4.14.1 Connect Scan Chains
After the scan chains have been defined and configured, the scan flip-flops can
now be connected together to form the two scan chains previously defined. The
following command is used:
• connect_scan_chains <design>
68
The command has additional options that can be used. The –auto_create_chains
option could be added to allow the tool to add new chains that are not defined.
Without this option the tool could report an error if it needs additional scan chains in
the design. The scan chain setup and configuration can now be checked with the
following command:
• report dft_chains
This command will report the scan chain configuration. The scan chain report can
be seen in Appendix G.
4.15 Run Incremental Optimization
Optimizing the netlist is the last step to follow after scan chain insertion. This is
carried out using the following command:
• Syn_opt
The effort during the incremental optimization is controlled by the syn_opt_effort
root attribute. In this implementation the syn_opt_effort attribute was set to high.
This can be checked in the run script in Appendix C. The top level module of the
Dual Lock System after Scan Chain insertion can be seen in Figure 4.4 using the
command gui_show in Genus’ tcl environment.
69
Figure 4.4 - Genus' Top Level Post Scan Schematic View
70
4.16 Write ATPG – Interface to ATPG Tool
Once the Genus RTL top-down DFT flow has successfully finished without any
violations, the static ATPG relevant files can be generated. This is done using the
following command:
• write_et_atpg –library“./../library_open_source/NangateOpenCellLibrary_typical.lib”
–directory ./et_atpg_output $DESIGN
–ncsim_library “./../library_open_source/NangateOpenCellLibrary.v”
The –library option specifies the Verilog structural library files required that are
required to run Modus ATPG. The –ncsim_library specifies the library for the
Incisive simulation of the generated vectors.
The files generated are necessary to run ATPG with Modus. It also generates the
template run scripts to run ATPG using Modus Software. The following list is what
this command generates:
1. uart_top.test_netlist.v
2. uart_top.FULLSCAN.pinasssign
3. run_fullscan_sim & run_fullscan_sim_sdf
4. runmodus.atpg.tcl
The first file generated is the final optimized scan-ready netlist to be used to run
Modus’ ATPG. The second file is used to apply the necessary stimuli when the scan
test mode is built. The third file is a template to be edited accordingly to run and
verify the scan ATPG patterns using Cadence NCSim simulator. The final file is the
template to be edited accordingly to be run by Modus. Modus’ verification flow will
be covered in detail in the following sections of this chapter.
71
4.17 Genus Reports
Genus is able to output the logs of every step in the synthesis flow just completed.
The list of possible reports can be displayed in the Genus Shell by typing the following:
• legacy_genus:/> report
After typing this command Genus will generate a list of the possible arguments
for the command report and it will then prompt the user to choose one of the arguments
available. For example, the command “power” can be used to generate and print the
power consumption report. The command and output report can be seen Figure 4.5 and
in Appendix T:
• legacy_genus:/> report power
Figure 4.5 – UART Power Report
72
4.18 Modus DFT Test Solution
Cadence Modus is a new design-for-test (DFT) solution that reduces test time for
digital logic with no impact on chip size or yield [7]. In addition it includes
comprehensive support for all other industry-standard DFT structures, such as
fullscan, XOR, PMBIST, logic BIST and JTAG [7]. It is a high-speed automatic test
pattern generator (ATPG) tool. It enables the user to generate test patterns to
maximize coverage while at the same time minimizing the number vectors and run
time for a variety of DFT design types and flows. Modus DFT solution is natively
integrated within Genus. Its ATPG component also shares a common tcl scripting
language with Genus Synthesis Solution, Innovus Implementation Solution, and
Tempus Timing Signoff Solution. [8] Figure 4.6 shows the mutual integration
between each CADENCE tool.
Figure 4.6 - Cadence Solution Software Mutual Integration
73
4.19 Modus ATPG Features
Cadence Modus has the following ATPG capabilities:
• Modus ATPG tool supports hierarchical tests
• Low power automatic test pattern generation with capture toggle and scan count
limits
• Distributed pattern generation with nearly linear runtime scalability features
• Diagnostics includes multi-die and single-die volume diagnostics with root-cause
analysis and physical defect location callout
• Modus DFT insertion is integrated within Genus Synthesis Solution as in can be seen
in the block diagram flow in Figure 4.7.
Figure 4.7 - Genus, Modus, and Incisive Integration Flow
4.20 Command Interface
Cadence Modus can either be interfaced using a command script or a GUI
interface. The ATPG implementation in this chapter was carried out using the GUI
interface but the command interface will be briefly discussed. The command to start
modus in tcl UI environment is as follows:
74
• modus &
This command will start Modus Test Solution in Tcl UI. Modus’ successful
invocation will case the root to display “modus@root:/>”; Modus commands can
now be used.
The template generated by Genus has all the basic commands to run the
ATPG flow. Once that script is edited, it can be executed simultaneously by
typing the following command prior to accessing the tcl UI :
• modus –file ./runmodus.atpg.tcl
This will execute the list of commands in the runmodus_atpg.tcl script
simultaneously as Modus is invoked. The command exit can be used at any time
to exit out of modus@root.
4.21 GUI Interface
The following command is used to run Cadence Modus in GUI interface:
• modus –legacy_gui &
The –legacy_gui option will cause the GUI interface window to appear. Once in
the GUI interface there are two ways to run the MODUS ATPG flow. It can be
implemented by typing them into the command bar at the bottom of the GUI or
they can be implemented by clicking through the multiple options in the top menu
bar of the GUI.
The approach taken in this implementation is by typing the flow
commands in the command bar. It is a more straightforward and fast approach
75
since the commands can be easily copied and pasted into it. Figure 4.8 shows the
Modus’ GUI interface.
Figure 4.8 - Modus GUI Interface
When a command is used in the command bar it will appear inside the
Task Command Window. This window has the history of commands executed in
the current directory. The GUI interface is very useful in organizing the logs by
their messages. The summary of the messages appear in its log summary
window, it organizes them into error, severe warning, warning and informational
messages.
The Task Command View shows the command that was ran. If the
command had errors it will display an X mark next to it, if it had severe warnings
76
it will display an exclamation mark next to it, if it had warnings it will display an
asterisk symbol next to it and if the command had none of these then it will
simply show a green check mark nest to it. Figure 4.9 shows all these cases along
with its respective symbols.
Figure 4.9 - Modus' GUI Task View
After a command is executed, its log will automatically appear in the
./testresults/logs directory by default; this is the directory where these messages
are read. Figure 4.10 shows the work directory structure created by Modus.
Figure 4.10 - Modus Work Directory Structure
77
4.22 Design Flow Using Cadence Modus
In section 5.16 of this report, several files were generated using the write_et_atpg
Genus command. One of the files was the runmodus.tcl file; this file has all the
commands needed to run Fullscan ATPG in the Modus GUI interface. The
commands have to be modified accordingly to reflect the design’s cell name, the
design’s netlist (generated by Genus) name and directory, the testmode and
experiment name. Each of this commands have dozens of options that are better
detailed in Modus’ User Guide & Command Reference documents. The options for
each command used in this implementation are the standard options because covering
every single option in the flow is not necessary for this application.
4.22.1 Requirements for ATPG
The following files are required to run Modus ATPG:
5. A structural Verilog technology library
6. A file that lists the primary ports and their test functions
(scan input, system test clock, scan enable, and so on).
7. The design’s netlist generated by Cadence Genus
Two of the required files to run Modus were generated by Genus using the
command in section 5.16.
4.23 Modus ATPG Design Flow
Figure 4.11 shows a block diagram of the Modus ATPG flow to be implemented.
Each section is composed of a main command along with applicable options that are
78
preceded by a dash. Each of these steps will generate an output log which can be
found in its respective Appendix.
Figure 4.11 - Modus ATPG Flow
Write Vectors is the final step in the Modus ATPG flow. Write Vectors will
generate test vector files and a test bench file to be used for verification. The
verification process is carried out by Cadence Incisive simulator which will be
covered in section 5.23 of this report.
79
4.23.1 Build Model
In this step the Modus test model is built from the input netlist (generated by
Genus) and library cell description (provided by the ASIC vendor). The following
command and options are required:
• build_model \
source=<filename> \
techlib=<file> \
cell=<topcell>
The full Modus run script used in this implementation can be seen in Appendix H.
It was modified accordingly to reflect the files generated by Genus. The Build Model
output log can be seen in Appendix I.
4.23.2 Build Test Mode
In this step the Modus testmodes are built. The testmodes define the scan
structure and logic for testing. The following command and options are required:
• build_testmode \
assignfile=<filename> \
testmode=<testmode> \
The structures of the design include scan chains, test pins and so on which are
required to generate patterns or to perform diagnostics. The assign file contains the
list of primary ports and their respective test functions. These have to be configured
based on the attributes of the design. The port assignments have the following
format:
• assign pin “<pinname>” test_function = <test function>
80
The <pinname> needs to match its respective port name declared in the design.
Table shows a summary of the possible test functions that can be declared in the
assignfile with their respective value and description.
Table 4.1 - Test Function & Value
The contents of the pinassign file in this implementation can be seen below:
assign pin=reset test_function= -SC; # test_mode
assign pin=scan_enable test_function= +SE; # shift_enable
assign pin=clk test_function= -ES; #System and Scan Clock
assign pin=scan_in_1 test_function= SI0;
assign pin=scan_out_1 test_function= SO0;
assign pin=scan_in_2 test_function= SI1;
assign pin=scan_out_2 test_function= SO1;
After build_testmode is done executing its log can be checked for consistency and
any warnings or errors. The Modus Build Test Mode output log can be seen in
Appendix J. A summary of the overall messages in the report can be found at the
very end of the log. Among these messages one can find the INFO (TTM-357)
message which reports how many scan chains are present in the design and whether
81
they are observable and controllable. The 2 scan chains that were originally defined
in Genus were successfully identified in this step as seen in the log’s message
summary table. If the scan chains would have failed then only 1 or 0 would have
been identified. In this case then the pinassign file test functions would have to be
revised to make sure they were properly assigned in addition to checking any
warnings that were present during the Build Model step.
4.23.3 Report Test Structures
As its name implies, this command will report the test structure information in the
logic modeled as it was configured for the current test mode. Report test structures
uses the following command:
• report_test_structures \
reportscanchain=all \
testmode=<name> \
Adding the reportscanchain=all option will further enable the tool to provide more
details regarding the scan chains in the design. Their length, pin names and exact
hierarchy and order in which they were configured. The complete log of the Report
Test Structures can be seen in Appendix K. If the expected scan chain count does not
much the one reported then the scan chains are broken, meaning that they do not
perform scan operation properly.
82
4.23.4 Verify Test Structures
The Verify Test Structures examines the design for potential problems. Some of
the problems include clocking, contention, and scan chain. Verify Test Structures
uses the following command:
• verify_test_structures \
messagecount= TSV-016=10,TSV-024=10,TSV-315=10,TSV-027=10 \
testmode=<name> \
The log from the Verify Test Structures has to be reviewed to ensure there are no
severe warnings or error messages. The messagecount option simply limits the
printing of the specified message numbers. It has no effect in the application. The
FULLSCAN messages to look out for in this step are TSV-381 which identifies the
scan chains. TSV-093 and TSV-193 are the contention warnings during scan and
capture operation so it is good to verify they do not exist in the log. The complete
ModusVerify Test Structures output log can be seen in Appendix L.
4.23.5 Build Fault Model
As its name implies, in this step the fault model for the design is built. The model
is used for ATPG simulation. Build Fault Model uses the following command:
• build_faultmodel \
Includedynamic=no \
The includedynamic option is set to no because the static faults are the only ones
of interest in this implementation. The Fault Model output log prints out statistics for
83
the faults that were generated. The Fault Model output log can be seen in Appendix
M.
4.23.6 Create Scan Chain Tests
In this step patterns are created to test the scan chains identified by the tool in the
design. The Scan Chain Test uses the following command:
• create_scanchain_tests \
testmode=<testmode> \
experiment=<name> \
The simulation of this patterns are executed and marked as tested. The output log
of this step will provide the testmode statistics listing the coverage based only on
observable faults in the test mode. It is usual for the scan chain coverage to fall
within the 10% to 20% range. The Scan Chain Test output log can be seen in
Appendix N. If the coverage for the scan chain tests do not fall within this range then
verify_test_structures and build_testmode has to be reviewed for any messages
indicating the scan chains are broken. Low scan chain coverage could also be caused
by soft contentions. Soft contention problems, if any, should be display as warnings
or errors in the verify_test_structures step.
4.23.7 Create Logic Tests
In this step test patterns are generated to check for static (stuck-at) faults. The
Create Logic Tests uses the following command:
• create_logic_tests \
testmode=<testmode> \
experiment=<name> \
84
The log will show the Logic Test starting at the coverage percentage where the
Scan Chain Test left off which is 21.11%, in other words it appended to it. There are
two types of test coverage statistics that it reports on, the Tcov(Test Coverage) and
the ATcov(Adjusted Test Coverage). Its fault equations are as follows:
• Tcov = #tested faults / #total faults
• ATcov = #tested faults / (#total faults - #redundant faults)
Note that the log lays out the pattern test generation final statistics into two
sections, the Testmode Statistics and the Global Statistics. It is normal for the
Testmode Statistics to have a higher test coverage since the Global Statistics is
generated from all the faults in the design while the Testmode is based on only the
observable faults which is just a subset of the total. In this implementation both the
Global and the Testmode Coverage are the same. The Create Logic output log can be
seen in Appendix O.
The Global and Testmode coverage of the Dual Lock System design was reported
to be 98.53% with a total of 682 faults detected. Out of the 682 faults detected, 672
faults were tested, 4 were flagged as possibly tested and 6 faults were untested. A
DFT engineer looks to achieve as high coverage as possible in the design. The
resulting coverage from this implementation is a good result but if it was not then the
logs from the Verify Structure run needs to be reviewed in order to fix any violations
or contentions warnings that may be causing a decrease in coverage.
85
In addition to looking at previous logs, the following command can be used to
identify the sections of the circuit that are not being tested:
• report_faults \
experiment=<name> \
testmode=<testmode> \
faultstatus=untested, untestable \
faulttype=static \
The design can be revised as well after identifying the sections that are untested or
untestable.
4.23.8 Write Vectors for Verification
In this step the test vectors are written in the identified language. The following
list shows all compatible languages that can be used for test vector generation:
• Verilog
• STIL (standard test interface)
• WGL (wave generation language)
• TDL (test description language)
The language option can be used to specify the export format. If the language is
not specified then it will default to Verilog language. The Write Vectors step uses the
following command:
• write_vectors \
workdir=<directory> \
testmode=<testmode> \
language=<tdl|Verilog|wgl|stil> \
The workdir option specifies where to export the test vector files. The files that
are generated in this step are the test vector patterns and a test bench file in the
86
language specified. The generated files are meant to be further verified through
simulation by Cadence Incisive. This is covered in section 5.23. The Write Vectors
output log can be seen in Appendix P.
4.24 Incisive Pattern Verification Process
This section will cover the things to consider and steps to follow to perform the
test vector simulation using Cadence Incisive. Incisive is Cadence’s hardware
description language simulator used for the verification of ASICs. Incisive will be
used to simulate the test vectors and test bench that were generated in section 5.22.8.
The following files were generated by Modus’ write_vectors command:
• ATPG test patterns files
➢ VER.FULLSCAN.lock_top_atpg.data.scan.ex1.ts1.verilog
➢ VER.FULLSCAN.lock_top_atpg.data.logic.ex1.ts2.verilog
• ATPG Test Bench file
➢ VER.FULLSCAN.lock_top_atpg.mainsim.v
All of these files will be included in the Incisive simulation run script along with
the netlist that was generated by Genus’ write_et_atpg command in section 5.16 of
this report. The following command is used to invoke Incisive with its graphical
waveform viewer:
• irun –gui
Just like previous commands, the Incisive irun command has a lot of options that
can be included in its run script. The Genus command write_et_atpg generated an
Incisive irun run script template that can be used as a reference. It is recommended to
87
use this template and just edit it accordingly with the correct directory and names of
the files produced by Modus if they differ from the ones in the script.
Incisive can run in batch command mode or GUI mode. The –gui option was
added to the run script to enable the GUI waveform viewer. In addition to the test
vector files, the test bench and the netlist files, the command script must also include
the –v option pointing to the technology library (provided by vendor). The complete
Incisive irun run script can be seen in appendix Q.
4.24.1 Pattern Verification Results
This is the final step in the ATPG flow. Figure 4.12 shows a summary of the
general steps that have been implemented in Chapter 4 and Chapter 5.
Figure 4.12 - ASIC ATPG Flow
88
After simulation is done running, the log has to be reviewed to see whether all the
patterns were successful and that there were no mismatches between the test vectors
and its expected output response. Figure 4.13 shows a block diagram of what Incisive
is simulating using the UART design netlist, test vector files and test bench. In this
case the UART system design netlist represents the circuit under test (CUT) as it is
shown in the picture.
Figure 4.13 - Test Pattern Verification Process
The log contains the list of patterns implemented in the test under the (TVE-202)
code. Note that the log lists the patterns by sequence name, not by content. Those
same sequence names are found inside the test vector files with its respective test
patterns. At the end of the simulation the log will report on the mismatches found in
89
the design. The log also shows the specific time in picoseconds at which they were
implemented.
Figure 4.14 - Vector Test Log Results
The last two messages in the log state how many good comparing vectors were
detected in the simulation as well as its miscomparing vector count. The pattern
verification was successful since it contained no mismatched vectors. There were a
total of 11574 good comparing vectors while there were 0 miscomparing vectors for
the UART design. The UART design had 11574 good comparing vectors and 0
miscompring vectors. The relevant portions of the Incisive test vector log can be seen
in Appendix R since the vector count was too high to include them all. The –gui
option was added to the final Incisive run script so the waveform interface could be
used. The simulation of the Test Vectors generated to test the design can be seen in
Figure 4.15.
90
Figure 4.15 - Test Vector Simulation Waveform Viewer
91
Chapter 5
CONCLUSION
This project covered the concepts of scan chains as a Design for Testing technique, as
well as the steps required to implement it using Cadence Test Solution tools.
Implementing scan into a design will enable ATPG tests to check for faults.
An UART was designed in Chapter 3 to be used in synthesis for scan architecture
insertion along with ATPG implementation. The shift registers within the UART design
were made scan enabled through the synthesis process, and several scan chains were
formed. This means that every flip-flip became a scan-flop and they were all placed.
The UART design was made by writing several Verilog modules that are instantiated
by a top-level module. All the modules in RTL were simulated and tested for proper
functionality using a testbench module to provide stimuli to its inputs. The asynchronous
UART design required the parallel data to be transferred serially through a transmitter
stage to then be received and converted back to parallel format. Cadence Incisive
simulator was used to verify the UART RTL design.
After RTL specifications were met, Cadence Genus was used for synthesis. The flow
for synthesis is comprised of several commands depending on the type of scan
architecture that it is required. The theory of the types of scan architecture were
discussed in Chapter 2 while the Muxed Scan Cell Style architecture was implemented in
synthesis in Chapter 4.
Genus did not find any violations in the design and thus scan synthesis was
successfully implemented. All the possible violations were covered in Chapter 2 and
92
Genus checked for them as it can be seen in the Rule Checker log in Appendix D. Four
scan chains were successfully implemented as it can be seen in the Genus Scan Chain
Report log in Appendix G as well as the Modus Report Test Structures log in Appendix
K.
After scan synthesis is completed, Genus provided Cadence Modus, the ATPG tool,
with the design’s gate level netlist. The new scan netlist was then used by Modus to
generate fault models and calculate the design’s Global Coverage. The Global Coverage
of the UART design was 99.74% as it can be seen in the Logic Test Log in Appendix O.
If a vector set is able to test a design at 100% coverage then it would mean that it can
identify all possible faults in the design. One of the reasons both designs had a relatively
high coverage is that there were no DFT violations identified by neither the synthesis tool
nor the ATPG tool.
The final step in the implementation is to simulate the patterns that were generated by
Modus using Cadence Incisive Simulator. The simulation uses the pattern and testbench
files generated by Modus as well as the post-scan insertion gate level netlist from Genus.
The simulation did not show any mismatches between the patterns generated and the
expected pattern response thus verifying that the patterns can be succesfully applied to
real circuits.
93
References
[1]L. H. Goldstein, “Controllability/Observability Analysis of Digital Circuits”
[2]Wang, Laung-Terng, et al. VLSI Test Principles and Architectures : Design for
Testability, Elsevier Science & Technology, 2006. ProQuest Ebook Central,
https://ebookcentral.proquest.com/lib/csun/detail.action?docID=288757.
[3]Cadence, “Genus Synthesis Solution”, from
https://www.cadence.com/content/dam/cadence-
www/global/en_US/documents/tools/digital-design-signoff/genus-synthesis-solution-
ds.pdf
[4]Cadence, “Design For Test for OSU Standard Cell Library Used at GWU”,
https://search.proquest.com/openview/c5fb2266c13118bd5d9763eaae2b099e/1?pq-
origsite=gscholar&cbl=18750&diss=y
[5]Cadence, “Command Reference for Encounter RTL Compiler”,
https://www.csee.umbc.edu/~tinoosh/cmpe641/tutorials/rc/rc_commandref.pdf
[6]Cadence, “Cadence Modus DFT Software Solution”,
https://www.cadence.com/content/dam/cadence-
www/global/en_US/documents/tools/digital-design-signoff/modus-test-solution-tb.pdf
[7] Bhavna Mahure and Rahul Tanwar, 2012, “UART WITH AUTOMATIC BAUD
RATE GENERATOR AND FREQUENCY DIVIDER”, Vol. 3. (issue no 1), pp – 265-
268.
[8] Implementing a FIFO using Verilog http://electrosofts.com/verilog/fifo.html
[9] Andre castellan Prado, 2014, “Capturing a UART Design in MyHDL & Testing it in
an FPGA”, Designlines Programmable Logic
[10] Minns, P., & Elliott, I. (2008). FSM-based digital design using Verilog HDL.
Chichester, England ; Hoboken, NJ: J. Wiley & Sons.
[11] Back to Basics: The Universal Asynchronous Receiver/Transmitter (UART)”,
https://www.allaboutcircuits.com/technical-articles/back-to-basics-the-universal-
asynchronous-receiver-transmitter-uart/
94
Appendix A: UART Verilog Source Code
//==================Baud Rate Generator ====================//
`timescale 1ns / 1ps
module baud_generator (clk, reset, samp_sig);
input clk,
reset;
output samp_sig;
// signal declaration
reg [7:0] sum_reg;
wire [7:0] register_next;
wire clk,
reset;
always@(posedge clk, posedge reset)
if (reset)
sum_reg <= 0; //resets samp_sig to zero
else
sum_reg <= register_next;
assign samp_sig = (sum_reg==(162))? 1'b1:1'b0; // if 162 samp_sig high else low
// 163 rising edge
assign register_next = (sum_reg == (162))?0:sum_reg+1; // if state reached M-1,
reset next state
//otherwise add 1 to next state
endmodule
95
//=====================UART Transmitter===================//
`timescale 1ns / 1ps
module uart_transmitter (clk, reset, start_flag, samp_sig, transmit_data_in,
transmit_data_out_done, transmit_data_out);
input clk,
reset,
start_flag,
samp_sig;
input wire [7:0] transmit_data_in;
output reg transmit_data_out_done;
output wire transmit_data_out;
reg [2:0] seven_reg, seven_next;
reg [7:0] disassemble_reg, disassemble_next;
reg [1:0] state_reg, state_reg_next;
reg [3:0] onefive_reg, onefive_next;
reg transmit_data_state_out_reg,
transmit_data_state_out_next;
// idle_state, start_state bit, data_state stream, stop_state bit
parameter idle_state = 2'b00,
start_state = 2'b01,
data_state = 2'b10,
stop_state = 2'b11;
assign transmit_data_out = transmit_data_state_out_reg;
always@(posedge clk, posedge reset)
if (reset) // if reset high, reset statements
begin
state_reg <= idle_state;
onefive_reg <= 0;
seven_reg <= 0;
disassemble_reg <= 0;
transmit_data_state_out_reg <= 1'b1; // transmit_data_state_out_reg
idle_state state is high
end // before start_state bit which is
low
else
begin
state_reg <= state_reg_next;
onefive_reg <= onefive_next;
seven_reg <= seven_next;
disassemble_reg <= disassemble_next;
transmit_data_state_out_reg <= transmit_data_state_out_next;
end
always@(*)
96
begin
state_reg_next=state_reg;
transmit_data_out_done = 1'b0;
onefive_next = onefive_reg;
seven_next = seven_reg;
disassemble_next = disassemble_reg;
transmit_data_state_out_next = transmit_data_state_out_reg; //
case(state_reg)
idle_state:
begin
transmit_data_state_out_next = 1'b1; // high before start_state bit
if(start_flag) // external signal from FIFO, '(.empty)
begin
state_reg_next = start_state;
onefive_next = 0;
disassemble_next = transmit_data_in;
end
end
start_state:
begin
transmit_data_state_out_next = 1'b0; // start_state bit is logic low
if (samp_sig) // external signal from Baud Generator
if (onefive_reg==15) // set to 0 at reset, true after 15 samp_sigs
begin
state_reg_next = data_state; // after 15 samp_sigs
onefive_next = 0;
seven_next = 0;
end
else
onefive_next = onefive_reg + 1; // incremental
end
data_state:
begin
transmit_data_state_out_next = disassemble_reg[0]; // [7:0]
disassemble_reg set to 0 at reset
if (samp_sig) // external signal from Baud Generator
if (onefive_reg==15) // set to 0 at reset, true after samp_sigs
begin
onefive_next = 0;
disassemble_next = disassemble_reg >> 1; // [7:0]
disassemble_reg shift right
if (seven_reg==(7)) // seven_reg == 7
state_reg_next = stop_state;
else
seven_next = seven_reg + 1;
97
end
else
onefive_next = onefive_reg + 1;
end
stop_state:
begin
transmit_data_state_out_next = 1'b1;
if (samp_sig)
if (onefive_reg==(15)) // SB_TICK = 16
begin
state_reg_next = idle_state;
transmit_data_out_done = 1'b1;
end
else
onefive_next = onefive_reg + 1;
end
endcase
end
endmodule
98
//====================UART Receiver==================//
`timescale 1ns / 1ps
module uart_receiver (clk, reset, receive_data_in, samp_sig, stop_mid_done,
receive_data_out);
output wire [7:0] receive_data_out;
output reg stop_mid_done;
input clk,
reset,
receive_data_in,
samp_sig;
reg [2:0] seven_reg, seven_next;
reg [7:0] assemble_reg, assemble_next;
reg [1:0] state_reg, state_reg_next;
reg [3:0] onefive_reg, onefive_next;
// idle_state, start_state bit, data_state stream, stop_state bit
parameter idle_state = 2'b00,
start_state = 2'b01,
data_state = 2'b10,
stop_state = 2'b11;
assign receive_data_out = assemble_reg;
always@(posedge clk, posedge reset)
if (reset)
begin
state_reg <= idle_state;
onefive_reg <=0;
seven_reg <=0;
assemble_reg <=0;
end
else
begin
state_reg <= state_reg_next;
onefive_reg <= onefive_next;
seven_reg <= seven_next;
assemble_reg <= assemble_next;
end
always@(*)
begin
state_reg_next = state_reg;
seven_next = seven_reg;
99
assemble_next = assemble_reg;
onefive_next = onefive_reg;
stop_mid_done = 1'b0;
case (state_reg)
idle_state:
if (~receive_data_in)
begin
state_reg_next=start_state;
onefive_next=0;
end
start_state:
if (samp_sig)
if (onefive_reg == 7) // after start_state bit, count to 7
begin
state_reg_next = data_state; // move on to the next state
onefive_next = 0;
seven_next = 0;
end
else
onefive_next = onefive_reg + 1;
data_state:
if (samp_sig)
if (onefive_reg==15) // after mid start_state bit, count 15 to mid 1st bit
begin
onefive_next = 0;
assemble_next = {receive_data_in, assemble_reg[7:1]}; // add bit
to receive_data_out as lsb
if (seven_reg==(7)) // is this the 8th bit aquired? otherwise
increament
state_reg_next = stop_state; // if it is bit 7 then jump to
stop_state state
else
seven_next = seven_reg + 1; // increament up to the 8th bit
end
else
onefive_next = onefive_reg + 1;
stop_state:
if (samp_sig)
if (onefive_reg==(15)) // onefive_reg=0, in mid of last bit
begin
state_reg_next = idle_state; // back to idle_state state after
stop_state bit
stop_mid_done=1'b1;
end
else
100
onefive_next=onefive_reg+1; // increament 16 times to arrive to mid
stop_state bit
endcase
end
endmodule
101
//====================FIFO Module==================//
`timescale 1ns / 1ps
module FIFO1(clk, reset, data_in, data_out, write_enable, read_enable, empty_flag,
full_flag, counter_full_or_empty);
input[7:0] data_in;
output[7:0] data_out;
output[3:0] counter_full_or_empty;
input reset,
clk,
write_enable,
read_enable;
output empty_flag,
full_flag;
reg[7:0] data_out;
reg[7:0] fifo_mem[7:0];
reg[2:0] pointer_read, pointer_write;
reg[3:0] counter_full_or_empty;
reg full_flag,
empty_flag;
always @(posedge clk) // write in content
begin
if( write_enable && !full_flag ) // if write_enable high and buffer not full
fifo_mem[ pointer_write ] <= data_in; // write data_in to fifo_mem with
pointer_write as index
// 0 1 2 3 4 5 6 7
else
fifo_mem[ pointer_write ] <= fifo_mem[ pointer_write ]; // fifo_mem equals
fifo_mem
end
always @( posedge clk or posedge reset) // read in content
begin
if( reset )
data_out <= 0; // if reset then buffer is 0
else
begin
if( read_enable && !empty_flag ) // read_enable high and buffer not
empty then read in fifo_mem
data_out <= fifo_mem[pointer_read]; // into data_out using pointer_read
as the fifo_mem index
else
data_out <= data_out; // data_out equals data_out
end
end
102
always @(posedge clk or posedge reset)
begin
if( reset )
counter_full_or_empty <= 0;
else if( (!full_flag && write_enable) && ( !empty_flag && read_enable ) ) // buffer
not full and write_enable high && buffer not empty and read_enable high
counter_full_or_empty <= counter_full_or_empty;
else if( !full_flag && write_enable ) // buffer not full and write_enable high
counter_full_or_empty <= counter_full_or_empty + 1;
else if( !empty_flag && read_enable ) // buffer not empty and read_enable high
counter_full_or_empty <= counter_full_or_empty - 1;
else
counter_full_or_empty <= counter_full_or_empty; // buffer equals buffer
end
always@(posedge clk or posedge reset) // read and write pointer sections
begin
if( reset )
begin
pointer_write <= 0;
pointer_read <= 0;
end
else
begin
if( !full_flag && write_enable ) // buffer not full and write_enable high
pointer_write <= pointer_write + 1; // write pointer increament
else pointer_write <= pointer_write; // write pointer equals write pointer
if( !empty_flag && read_enable ) // buffer not full and read_enable high
pointer_read <= pointer_read + 1; // read pointer increament
else pointer_read <= pointer_read; // read pointer equals read pointer
end
end
always @(counter_full_or_empty)
begin
full_flag = (counter_full_or_empty==8);
empty_flag = (counter_full_or_empty==0);
end
endmodule
103
//====================UART Top Module=======================//
`timescale 1ns / 1ps
module uart_top ( input wire clk,
input wire reset,
input wire receiver_serial_data,
input wire receiver_read_enable,
input wire transmitter_write_enable,
input wire [7:0] write_parallel_data_in,
output transmitter_full_flag,
output transmitter_serial_data,
output wire [7:0] read_parallel_data_out,
output receiver_empty_flag,
inout scan_in_1,
inout scan_out_1,
inout scan_in_2,
inout scan_out_2,
inout scan_in_3,
inout scan_out_3,
inout scan_in_4,
inout scan_out_4,
inout scan_enable
);
wire [7:0] buff_out_din_tx;
wire done_tick_2_read_tx;
wire empty_flag_tx;
wire samp_sig;
wire done_tick_2_write_receive_data_in;
wire [7:0] dout_w_data_receive_data_in;
wire buff_full_receive_data_in_flag;
// BAUD RATE GENERATOR
baud_generator baud_gen (.clk(clk), .reset(reset), .samp_sig(samp_sig));
// TRANSMITTER STAGE
FIFO1 fifo_transmit ( .clk(clk), .reset(reset), .data_in(write_parallel_data_in),
.data_out(buff_out_din_tx), .write_enable(transmitter_write_enable),
.read_enable(done_tick_2_read_tx), .empty_flag(empty_flag_tx),
.full_flag(transmitter_full_flag), .counter_full_or_empty());
uart_transmitter uart_trans ( .clk(clk), .reset(reset), .start_flag(~empty_flag_tx),
.samp_sig(samp_sig), .transmit_data_in(buff_out_din_tx),
104
.transmit_data_out_done(done_tick_2_read_tx),
.transmit_data_out(transmitter_serial_data));
// RECEIVER STAGE
uart_receiver uart_receiv (.clk(clk), .reset(reset),
.receive_data_in(receiver_serial_data), .samp_sig(samp_sig),
.stop_mid_done(done_tick_2_write_receive_data_in),
.receive_data_out(dout_w_data_receive_data_in));
FIFO1 fifo_receiv (.clk(clk), .reset(reset), .data_in(dout_w_data_receive_data_in),
.data_out(read_parallel_data_out), .write_enable(done_tick_2_write_receive_data_in),
.read_enable(receiver_read_enable), .empty_flag(receiver_empty_flag),
.full_flag(buff_full_receive_data_in_flag), .counter_full_or_empty());
endmodule
105
Appendix B: UART Test Bench
`timescale 1ns / 1ps
module tb_uart_top ();
reg [888:0] label;
reg clk, reset, transmitter_write_enable,
receiver_serial_data,
receiver_read_enable;
reg [7:0] write_parallel_data_in;
wire [7:0] read_parallel_data_out;
wire transmitter_serial_data,
receiver_empty_flag,
transmitter_full_flag;
uart_top uart_top_UUT (.clk(clk), .reset(reset),
.receiver_serial_data(transmitter_serial_data),
.receiver_read_enable(receiver_read_enable),
.transmitter_write_enable(transmitter_write_enable),
.write_parallel_data_in(write_parallel_data_in),
.transmitter_full_flag(transmitter_full_flag),
.transmitter_serial_data(transmitter_serial_data),
.read_parallel_data_out(read_parallel_data_out),
.receiver_empty_flag(receiver_empty_flag));
initial begin
label = 0;
clk = 0;
reset = 1;
transmitter_write_enable = 1'b0;
receiver_read_enable = 1'b0;
#10 reset = 0; // 10ms
#10 write_parallel_data_in = 8'b00101001; //
#10 transmitter_write_enable = 1'b1; //
#700000 label = "parallel data out";
# 100 transmitter_write_enable = 1'b0;
# 100 receiver_read_enable = 1'b1;
#2200000 transmitter_write_enable = 1'b1;
write_parallel_data_in = 8'b11101001; //
label = "second data starts here";
106
$display("first parallel data out = %b",
tb_uart_top.uart_top_UUT.read_parallel_data_out[7:0]);
#520000 $display("second parallel data out = %b",
tb_uart_top.uart_top_UUT.read_parallel_data_out[7:0]);
$finish;
end
always
#5 clk = ~clk;
endmodule
107
Appendix C: Genus Complete Run Script
#### Template Script for RTL->Gate-Level Flow (generated from GENUS 17.20-
p003_1)
if {[file exists /proc/cpuinfo]} {
sh grep "model name" /proc/cpuinfo
sh grep "cpu MHz" /proc/cpuinfo
}
puts "Hostname : [info hostname]"
######################################################################
########
## Preset global variables and attributes
######################################################################
########
set DESIGN uart_top
set GEN_EFF medium
set MAP_OPT_EFF high
set DATE [clock format [clock seconds] -format "%b%d-%T"]
set _OUTPUTS_PATH outputs_${DATE}
set _REPORTS_PATH reports_${DATE}
set _LOG_PATH logs_${DATE}
set ET_WORKDIR modus
set_attribute information_level 7
###############################################################
## Library setup - (Read Target Libraries)
###############################################################
## Set library search path
set_attribute init_lib_search_path ./../library_open_source /
## Read Target Libraries
set_attribute library NangateOpenCellLibrary_typical.lib
## Read LEF Files
set_attribute lef_library ./../library_open_source/NangateOpenCellLibrary.lef /
####################################################################
## Load Design - (Read HDL Files)
####################################################################
## Set RTL search path
set_attribute init_hdl_search_path ./rtl_uart /
## Read the mapped to scan netlist
read_hdl -sv {baud_generator.v uart_transmitter.v uart_receiver.v FIFO1.v uart_top.v}
####################################################################
## Elaborate Design
####################################################################
## Elaborate overall design
elaborate $DESIGN
puts "Runtime & Memory after 'read_hdl'"
108
time_info Elaboration
check_design -unresolved -undriven
set_attribute ungroup_ok false baud_gen
set_attribute ungroup_ok false fifo_transmit
set_attribute ungroup_ok false uart_trans
set_attribute ungroup_ok false uart_receiv
set_attribute ungroup_ok false fifo_receiv
####################################################################
## Constraints Setup - (Set Timing & Design Constraints)
####################################################################
read_sdc read_sdc.sdc
#define_clock -period 10000 -name clk -design /designs/uart_top
puts "The number of exceptions is [llength [find /designs/$DESIGN -exception *]]"
if {![file exists ${_LOG_PATH}]} {
file mkdir ${_LOG_PATH}
puts "Creating directory ${_LOG_PATH}"
}
if {![file exists ${_OUTPUTS_PATH}]} {
file mkdir ${_OUTPUTS_PATH}
puts "Creating directory ${_OUTPUTS_PATH}"
}
if {![file exists ${_REPORTS_PATH}]} {
file mkdir ${_REPORTS_PATH}
puts "Creating directory ${_REPORTS_PATH}"
}
report timing -lint
######################################################################
#############
## Define cost groups (clock-clock, clock-output, input-clock, input-output)
######################################################################
#############
## Uncomment to remove already existing costgroups before creating new ones.
## rm [find /designs/* -cost_group *]
if {[llength [all::all_seqs]] > 0} {
define_cost_group -name I2C -design $DESIGN
define_cost_group -name C2O -design $DESIGN
define_cost_group -name C2C -design $DESIGN
path_group -from [all::all_seqs] -to [all::all_seqs] -group C2C -name C2C
path_group -from [all::all_seqs] -to [all_outputs] -group C2O -name C2O
path_group -from [all_inputs] -to [all::all_seqs] -group I2C -name I2C
}
define_cost_group -name I2O -design $DESIGN
path_group -from [all::all_inps] -to [all::all_outs] -group I2O -name I2O
109
foreach cg [find / -cost_group *] {
report timing -cost_group [list $cg] >> $_REPORTS_PATH/${DESIGN}_pretim.rpt
}
######################################################################
############################
## DFT Setup - (Setup for DFT Rule Checker)
######################################################################
############################
set_attribute dft_scan_style muxed_scan /
set_attribute dft_prefix DFT_ /
set_attribute dft_identify_top_level_test_clocks true /
set_attribute dft_identify_test_signals true /
set_attribute dft_identify_internal_test_clocks false /
set_attribute use_scan_seqs_for_non_dft false /
# DFT Attributes to control scan mapping and connectivity
# tdrc_pass allows only flip-flops that pass DFT rule checks to be mapped during
synthesis
# force_all controls mapping of all non-scan flip-flops. Only use if you plan to fix the
violations
set_attribute dft_scan_map_mode tdrc_pass "/designs/$DESIGN"
#set_attribute dft_scan_map_mode force_all "/designs/$DESIGN"
set_attribute dft_connect_shift_enable_during_mapping tie_off "/designs/$DESIGN"
set_attribute dft_connect_scan_data_pins_during_mapping loopback
"/designs/$DESIGN"
set_attribute dft_scan_output_preference auto "/designs/$DESIGN"
set_attribute dft_lockup_element_type preferred_level_sensitive "/designs/$DESIGN"
# Scan Clock
#define_dft test_clock -name clk -domain clk -period 50000 -rise <integer> -fall
<integer> <portOrpin>
define_dft test_clock -name clk /designs/uart_top/ports_in/clk
set_compatible_test_clocks -all
# scan enable
define_dft shift_enable -name scan_enable -active high
/designs/uart_top/ports_in/scan_enable
set_attr preserve false /uart_top
######################################################################
############################
## DFT Rule Checker - (Run DFT Rule Checker and Report Registers)
######################################################################
############################
check_dft_rules > $_REPORTS_PATH/${DESIGN}-tdrcs
report dft_registers > $_REPORTS_PATH/${DESIGN}-DFTregs
report dft_setup > $_REPORTS_PATH/${DESIGN}-DFTsetup_tdrc
report dft_registers
check_design -multidriven
report dft_violations > $_REPORTS_PATH/${DESIGN}-AdvancedDFTViols
110
#fix_dft_violations -design $DESIGN -test_control
#check_atpg_rules
#analyze_testability
######################################################################
##############################
## Synthesizing to generic
######################################################################
##############################
set_attribute syn_generic_effort $GEN_EFF /
syn_generic
puts "Runtime & Memory after 'syn_generic'"
time_info GENERIC
#report timing -lint
write_snapshot -outdir $_REPORTS_PATH -tag generic
report datapath > $_REPORTS_PATH/generic/${DESIGN}_datapath.rpt
report_summary -outdir $_REPORTS_PATH
####
#set_attribute delete_hier_insts_on_preserved_net true /
######################################################################
##############################
## Synthesizing to gates
######################################################################
##############################
set_attribute syn_map_effort $MAP_OPT_EFF /
syn_map
puts "Runtime & Memory after 'syn_map'"
time_info MAPPED
write_snapshot -outdir $_REPORTS_PATH -tag map
report_summary -outdir $_REPORTS_PATH
report datapath > $_REPORTS_PATH/map/${DESIGN}_datapath.rpt
write_do_lec -revised_design fv_map -logfile
${_LOG_PATH}/rtl2intermediate.lec.log >
${_OUTPUTS_PATH}/rtl2intermediate.lec.do
set_attr lp_insert_clock_gating true
#replace_scan $DESIGN
################## Scan Chains ###################################
###################################################################
### Stable Chains Below, do not delete
# -shared_input was removed from both of them
define_dft scan_chain -name chain1 -sdi /designs/uart_top/ports_in/scan_in_1 -sdo
/designs/uart_top/ports_out/scan_out_1
define_dft scan_chain -name chain2 -sdi /designs/uart_top/ports_in/scan_in_2 -sdo
/designs/uart_top/ports_out/scan_out_2
define_dft scan_chain -name chain3 -sdi /designs/uart_top/ports_in/scan_in_3 -sdo
/designs/uart_top/ports_out/scan_out_3
111
define_dft scan_chain -name chain4 -sdi /designs/uart_top/ports_in/scan_in_4 -sdo
/designs/uart_top/ports_out/scan_out_4
connect_scan_chains $DESIGN
#-auto_create_chains
#connect_scan_chains $DESIGN -preview -auto_create_chains
report dft_registers
report dft_chains
######################################################################
#################################
## Optimize Netlist
######################################################################
#################################
set_attribute syn_opt_effort $MAP_OPT_EFF /
syn_opt
write_snapshot -outdir $_REPORTS_PATH -tag syn_opt
report_summary -outdir $_REPORTS_PATH
puts "Runtime & Memory after 'syn_opt'"
time_info OPT
#############################################
## DFT Reports
#############################################
report dft_setup > $_REPORTS_PATH/${DESIGN}-DFTsetup_final
#write_scandef > ${DESIGN}-scanDEF
#write_dft_abstract_model > ${DESIGN}-scanAbstract
#write_hdl -abstract > ${DESIGN}-logicAbstract
#write_script -analyze_all_scan_chains > ${DESIGN}-writeScript-
analyzeAllScanChains
######################################################################
################################
## write backend file set (verilog, SDC, config, etc.)
######################################################################
################################
report datapath > $_REPORTS_PATH/${DESIGN}_datapath_incr.rpt
report messages > $_REPORTS_PATH/${DESIGN}_messages.rpt
write_snapshot -outdir $_REPORTS_PATH -tag final
report_summary -outdir $_REPORTS_PATH
write_hdl > uart_top_netlist.v
## write_script > ${_OUTPUTS_PATH}/${DESIGN}_m.script
write_sdc > uart_top_m.sdc
#################################
### write_do_lec
#################################
write_do_lec -revised_design uart_top_netlist.v > rtl2final.lec.do
################# ATPG STARTS HERE ###############################3
# write_dft_atpg is the latest updated command for modus
112
write_et_atpg -library "./../library_open_source/NangateOpenCellLibrary_typical.lib" -
directory ./et_atpg_output $DESIGN -ncsim_library
"./../library_open_source/NangateOpenCellLibrary.v"
# .... Invoke the script from OS command line as 'modus -file
./et_atpg_output/runmodus.atpg.tcl'.
puts "Final Runtime & Memory."
time_info FINAL
puts "============================"
puts "Synthesis Finished ........."
puts "============================"
#file copy [get_attribute stdout_log /] ${_LOG_PATH}/.
##quit
113
Appendix D: Genus’ DFT Rule Checker
//====================UART Top Module=======================//
Checking DFT rules for 'uart_top' module under 'muxed_scan' style
Processing techlib NangateOpenCellLibrary for muxed_scan scan cells
Identified a usable, flop scan cell 'SDFFR_X1'
active clock edge: rising
Identified a usable, flop scan cell 'SDFFR_X2'
active clock edge: rising
Identified a usable, flop scan cell 'SDFFS_X1'
active clock edge: rising
Identified a usable, flop scan cell 'SDFFS_X2'
active clock edge: rising
Identified 4 valid usable scan cells
Checking DFT rules for clock pins
Traced or defined DFT clock: clk in domain: clk at pin clk
Checking DFT rules for async. pins
Checking DFT rules for shift registers.
Detected 0 DFT rule violation(s)
Summary of check_dft_rules
**************************
Number of usable scan cells: 4
Clock Rule Violations:
---------------------
Internally driven clock net: 0
Tied constant clock net: 0
Undriven clock net: 0
Conflicting async & clock net: 0
Misc. clock net: 0
Async. set/reset Rule Violations:
--------------------------------
Internally driven async net: 0
Tied active async net: 0
Undriven async net: 0
Misc. async net: 0
Total number of DFT violations: 0
Total number of Test Clock Domains: 1
DFT Test Clock Domain: clk
Test Clock 'clk' (Positive edge) has 207 registers
Number of user specified non-Scan registers: 0
Number of registers that fail DFT rules: 0
114
Number of registers that pass DFT rules: 207
Percentage of total registers that are scannable: 100%
115
Appendix E: Genus’ Report Registers Log
//====================UART Top Module=======================//
legacy_genus:/> report dft_registers
Reporting registers that pass DFT rules
baud_gen/sum_reg_reg[0] PASS; Test clock: clk/rise; Mapped for DFT;
baud_gen/sum_reg_reg[1] PASS; Test clock: clk/rise; Mapped for DFT;
baud_gen/sum_reg_reg[2] PASS; Test clock: clk/rise; Mapped for DFT;
baud_gen/sum_reg_reg[3] PASS; Test clock: clk/rise; Mapped for DFT;
baud_gen/sum_reg_reg[4] PASS; Test clock: clk/rise; Mapped for DFT;
baud_gen/sum_reg_reg[5] PASS; Test clock: clk/rise; Mapped for DFT;
baud_gen/sum_reg_reg[6] PASS; Test clock: clk/rise; Mapped for DFT;
baud_gen/sum_reg_reg[7] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/counter_full_or_empty_reg[0] PASS; Test clock: clk/rise; Mapped for
DFT;
fifo_receiv/counter_full_or_empty_reg[1] PASS; Test clock: clk/rise; Mapped for
DFT;
fifo_receiv/counter_full_or_empty_reg[2] PASS; Test clock: clk/rise; Mapped for
DFT;
fifo_receiv/counter_full_or_empty_reg[3] PASS; Test clock: clk/rise; Mapped for
DFT;
fifo_receiv/data_out_reg[0] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/data_out_reg[1] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/data_out_reg[2] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/data_out_reg[3] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/data_out_reg[4] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/data_out_reg[5] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/data_out_reg[6] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/data_out_reg[7] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[0][0] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[0][1] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[0][2] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[0][3] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[0][4] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[0][5] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[0][6] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[0][7] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[1][0] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[1][1] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[1][2] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[1][3] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[1][4] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[1][5] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[1][6] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[1][7] PASS; Test clock: clk/rise; Mapped for DFT;
116
fifo_receiv/fifo_mem_reg[2][0] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[2][1] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[2][2] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[2][3] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[2][4] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[2][5] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[2][6] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[2][7] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[3][0] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[3][1] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[3][2] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[3][3] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[3][4] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[3][5] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[3][6] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[3][7] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[4][0] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[4][1] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[4][2] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[4][3] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[4][4] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[4][5] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[4][6] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[4][7] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[5][0] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[5][1] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[5][2] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[5][3] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[5][4] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[5][5] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[5][6] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[5][7] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[6][0] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[6][1] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[6][2] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[6][3] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[6][4] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[6][5] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[6][6] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[6][7] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[7][0] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[7][1] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[7][2] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[7][3] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[7][4] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[7][5] PASS; Test clock: clk/rise; Mapped for DFT;
117
fifo_receiv/fifo_mem_reg[7][6] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/fifo_mem_reg[7][7] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/pointer_read_reg[0] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/pointer_read_reg[1] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/pointer_read_reg[2] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/pointer_write_reg[0] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/pointer_write_reg[1] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_receiv/pointer_write_reg[2] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/counter_full_or_empty_reg[0] PASS; Test clock: clk/rise; Mapped for
DFT;
fifo_transmit/counter_full_or_empty_reg[1] PASS; Test clock: clk/rise; Mapped for
DFT;
fifo_transmit/counter_full_or_empty_reg[2] PASS; Test clock: clk/rise; Mapped for
DFT;
fifo_transmit/counter_full_or_empty_reg[3] PASS; Test clock: clk/rise; Mapped for
DFT;
fifo_transmit/data_out_reg[0] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/data_out_reg[1] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/data_out_reg[2] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/data_out_reg[3] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/data_out_reg[4] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/data_out_reg[5] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/data_out_reg[6] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/data_out_reg[7] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[0][0] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[0][1] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[0][2] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[0][3] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[0][4] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[0][5] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[0][6] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[0][7] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[1][0] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[1][1] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[1][2] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[1][3] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[1][4] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[1][5] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[1][6] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[1][7] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[2][0] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[2][1] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[2][2] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[2][3] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[2][4] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[2][5] PASS; Test clock: clk/rise; Mapped for DFT;
118
fifo_transmit/fifo_mem_reg[2][6] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[2][7] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[3][0] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[3][1] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[3][2] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[3][3] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[3][4] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[3][5] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[3][6] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[3][7] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[4][0] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[4][1] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[4][2] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[4][3] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[4][4] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[4][5] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[4][6] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[4][7] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[5][0] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[5][1] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[5][2] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[5][3] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[5][4] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[5][5] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[5][6] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[5][7] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[6][0] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[6][1] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[6][2] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[6][3] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[6][4] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[6][5] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[6][6] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[6][7] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[7][0] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[7][1] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[7][2] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[7][3] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[7][4] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[7][5] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[7][6] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/fifo_mem_reg[7][7] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/pointer_read_reg[0] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/pointer_read_reg[1] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/pointer_read_reg[2] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/pointer_write_reg[0] PASS; Test clock: clk/rise; Mapped for DFT;
119
fifo_transmit/pointer_write_reg[1] PASS; Test clock: clk/rise; Mapped for DFT;
fifo_transmit/pointer_write_reg[2] PASS; Test clock: clk/rise; Mapped for DFT;
uart_receiv/assemble_reg_reg[0] PASS; Test clock: clk/rise; Mapped for DFT;
uart_receiv/assemble_reg_reg[1] PASS; Test clock: clk/rise; Mapped for DFT;
uart_receiv/assemble_reg_reg[2] PASS; Test clock: clk/rise; Mapped for DFT;
uart_receiv/assemble_reg_reg[3] PASS; Test clock: clk/rise; Mapped for DFT;
uart_receiv/assemble_reg_reg[4] PASS; Test clock: clk/rise; Mapped for DFT;
uart_receiv/assemble_reg_reg[5] PASS; Test clock: clk/rise; Mapped for DFT;
uart_receiv/assemble_reg_reg[6] PASS; Test clock: clk/rise; Mapped for DFT;
uart_receiv/assemble_reg_reg[7] PASS; Test clock: clk/rise; Mapped for DFT;
uart_receiv/onefive_reg_reg[0] PASS; Test clock: clk/rise; Mapped for DFT;
uart_receiv/onefive_reg_reg[1] PASS; Test clock: clk/rise; Mapped for DFT;
uart_receiv/onefive_reg_reg[2] PASS; Test clock: clk/rise; Mapped for DFT;
uart_receiv/onefive_reg_reg[3] PASS; Test clock: clk/rise; Mapped for DFT;
uart_receiv/seven_reg_reg[0] PASS; Test clock: clk/rise; Mapped for DFT;
uart_receiv/seven_reg_reg[1] PASS; Test clock: clk/rise; Mapped for DFT;
uart_receiv/seven_reg_reg[2] PASS; Test clock: clk/rise; Mapped for DFT;
uart_receiv/state_reg_reg[0] PASS; Test clock: clk/rise; Mapped for DFT;
uart_receiv/state_reg_reg[1] PASS; Test clock: clk/rise; Mapped for DFT;
uart_trans/disassemble_reg_reg[0] PASS; Test clock: clk/rise; Mapped for DFT;
uart_trans/disassemble_reg_reg[1] PASS; Test clock: clk/rise; Mapped for DFT;
uart_trans/disassemble_reg_reg[2] PASS; Test clock: clk/rise; Mapped for DFT;
uart_trans/disassemble_reg_reg[3] PASS; Test clock: clk/rise; Mapped for DFT;
uart_trans/disassemble_reg_reg[4] PASS; Test clock: clk/rise; Mapped for DFT;
uart_trans/disassemble_reg_reg[5] PASS; Test clock: clk/rise; Mapped for DFT;
uart_trans/disassemble_reg_reg[6] PASS; Test clock: clk/rise; Mapped for DFT;
uart_trans/disassemble_reg_reg[7] PASS; Test clock: clk/rise; Mapped for DFT;
uart_trans/onefive_reg_reg[0] PASS; Test clock: clk/rise; Mapped for DFT;
uart_trans/onefive_reg_reg[1] PASS; Test clock: clk/rise; Mapped for DFT;
uart_trans/onefive_reg_reg[2] PASS; Test clock: clk/rise; Mapped for DFT;
uart_trans/onefive_reg_reg[3] PASS; Test clock: clk/rise; Mapped for DFT;
uart_trans/seven_reg_reg[0] PASS; Test clock: clk/rise; Mapped for DFT;
uart_trans/seven_reg_reg[1] PASS; Test clock: clk/rise; Mapped for DFT;
uart_trans/seven_reg_reg[2] PASS; Test clock: clk/rise; Mapped for DFT;
uart_trans/state_reg_reg[0] PASS; Test clock: clk/rise; Mapped for DFT;
uart_trans/state_reg_reg[1] PASS; Test clock: clk/rise; Mapped for DFT;
uart_trans/transmit_data_state_out_reg_reg PASS; Test clock: clk/rise; Mapped for
DFT;
Reporting registers that fail DFT rules
Reporting registers that are preserved or marked dont-scan
Reporting registers that are marked Abstract Segment Dont Scan
Reporting registers that are part of shift register segments
Reporting registers that are identified as lockup elements
Reporting registers that are level-sensitive elements
Reporting misc. non-scan registers
Summary:
120
Total registers that pass DFT rules: 207
Total registers that fail DFT rules: 0
Total registers that are marked preserved or dont-scan: 0
Total registers that are marked Abstract Segment dont-scan: 0
Total registers that are part of shift register segments: 0
Total registers that are lockup elements: 0
Total registers that are level-sensitive: 0
Total registers that are misc. non-scan: 0
121
Appendix F: Genus’ DFT Setup TDRC Log
//====================UART Top Module=======================//
Design Name
===========
uart_top
Scan Style
==========
muxed_scan
Design has a valid DFT rule check status
Global Constraints
==================
Minimum number of scan chains: no_value
Maximum length of scan chains: no_value
Lock-up element type: preferred_level_sensitive
Mix clock edges in scan chain: false
Prefix for unnamed scan objects: DFT_
Test signal objects
===================
shift_enable:
object name: scan_enable
pin name: scan_enable
hookup_pin: scan_enable
hookup_polarity: non_inverted
function: shift_enable
active: high
ideal: false
user defined: true
test_mode:
object name: reset
pin name: reset
hookup_pin: reset
hookup_polarity: non_inverted
function: async_set_reset
active: low
ideal: false
user defined: false
Test clock objects
122
==================
test_clock:
object name: clk
test_clock_domain: clk
user defined: true
source: clk
root source: clk
root source polarity: non_inverting
hookup_pin: clk
period: 50000.0
DFT controllable objects
========================
DFT don't scan objects
======================
DFT abstract don't scan objects
===============================
DFT scan segment constraints
============================
DFT scan chain constraints
==========================
DFT actual scan chains
======================
123
Appendix G: Genus’ Scan Chain Report Log
//====================UART Top Module=======================//
Reporting 4 scan chains (muxed_scan)
Chain 1: chain1
scan_in: scan_in_1
scan_out: scan_out_1
shift_enable: scan_enable (active high)
clock_domain: clk (edge: rise)
length: 52
bit 1 baud_gen/sum_reg_reg[0] <clk (rise)>
bit 2 baud_gen/sum_reg_reg[1] <clk (rise)>
bit 3 baud_gen/sum_reg_reg[2] <clk (rise)>
bit 4 baud_gen/sum_reg_reg[3] <clk (rise)>
bit 5 baud_gen/sum_reg_reg[4] <clk (rise)>
bit 6 baud_gen/sum_reg_reg[5] <clk (rise)>
bit 7 baud_gen/sum_reg_reg[6] <clk (rise)>
bit 8 baud_gen/sum_reg_reg[7] <clk (rise)>
bit 9 fifo_receiv/counter_full_or_empty_reg[0] <clk (rise)>
bit 10 fifo_receiv/counter_full_or_empty_reg[1] <clk (rise)>
bit 11 fifo_receiv/counter_full_or_empty_reg[2] <clk (rise)>
bit 12 fifo_receiv/counter_full_or_empty_reg[3] <clk (rise)>
bit 13 fifo_receiv/data_out_reg[0] <clk (rise)>
bit 14 fifo_receiv/data_out_reg[1] <clk (rise)>
bit 15 fifo_receiv/data_out_reg[2] <clk (rise)>
bit 16 fifo_receiv/data_out_reg[3] <clk (rise)>
bit 17 fifo_receiv/data_out_reg[4] <clk (rise)>
bit 18 fifo_receiv/data_out_reg[5] <clk (rise)>
bit 19 fifo_receiv/data_out_reg[6] <clk (rise)>
bit 20 fifo_receiv/data_out_reg[7] <clk (rise)>
bit 21 fifo_receiv/fifo_mem_reg[0][0] <clk (rise)>
bit 22 fifo_receiv/fifo_mem_reg[0][1] <clk (rise)>
bit 23 fifo_receiv/fifo_mem_reg[0][2] <clk (rise)>
bit 24 fifo_receiv/fifo_mem_reg[0][3] <clk (rise)>
bit 25 fifo_receiv/fifo_mem_reg[0][4] <clk (rise)>
bit 26 fifo_receiv/fifo_mem_reg[0][5] <clk (rise)>
bit 27 fifo_receiv/fifo_mem_reg[0][6] <clk (rise)>
bit 28 fifo_receiv/fifo_mem_reg[0][7] <clk (rise)>
bit 29 fifo_receiv/fifo_mem_reg[1][0] <clk (rise)>
bit 30 fifo_receiv/fifo_mem_reg[1][1] <clk (rise)>
bit 31 fifo_receiv/fifo_mem_reg[1][2] <clk (rise)>
bit 32 fifo_receiv/fifo_mem_reg[1][3] <clk (rise)>
bit 33 fifo_receiv/fifo_mem_reg[1][4] <clk (rise)>
bit 34 fifo_receiv/fifo_mem_reg[1][5] <clk (rise)>
124
bit 35 fifo_receiv/fifo_mem_reg[1][6] <clk (rise)>
bit 36 fifo_receiv/fifo_mem_reg[1][7] <clk (rise)>
bit 37 fifo_receiv/fifo_mem_reg[2][0] <clk (rise)>
bit 38 fifo_receiv/fifo_mem_reg[2][1] <clk (rise)>
bit 39 fifo_receiv/fifo_mem_reg[2][2] <clk (rise)>
bit 40 fifo_receiv/fifo_mem_reg[2][3] <clk (rise)>
bit 41 fifo_receiv/fifo_mem_reg[2][4] <clk (rise)>
bit 42 fifo_receiv/fifo_mem_reg[2][5] <clk (rise)>
bit 43 fifo_receiv/fifo_mem_reg[2][6] <clk (rise)>
bit 44 fifo_receiv/fifo_mem_reg[2][7] <clk (rise)>
bit 45 fifo_receiv/fifo_mem_reg[3][0] <clk (rise)>
bit 46 fifo_receiv/fifo_mem_reg[3][1] <clk (rise)>
bit 47 fifo_receiv/fifo_mem_reg[3][2] <clk (rise)>
bit 48 fifo_receiv/fifo_mem_reg[3][3] <clk (rise)>
bit 49 fifo_receiv/fifo_mem_reg[3][4] <clk (rise)>
bit 50 fifo_receiv/fifo_mem_reg[3][5] <clk (rise)>
bit 51 fifo_receiv/fifo_mem_reg[3][6] <clk (rise)>
bit 52 fifo_receiv/fifo_mem_reg[3][7] <clk (rise)>
------------------------
Chain 2: chain2
scan_in: scan_in_2
scan_out: scan_out_2
shift_enable: scan_enable (active high)
clock_domain: clk (edge: rise)
length: 52
bit 1 fifo_receiv/fifo_mem_reg[4][0] <clk (rise)>
bit 2 fifo_receiv/fifo_mem_reg[4][1] <clk (rise)>
bit 3 fifo_receiv/fifo_mem_reg[4][2] <clk (rise)>
bit 4 fifo_receiv/fifo_mem_reg[4][3] <clk (rise)>
bit 5 fifo_receiv/fifo_mem_reg[4][4] <clk (rise)>
bit 6 fifo_receiv/fifo_mem_reg[4][5] <clk (rise)>
bit 7 fifo_receiv/fifo_mem_reg[4][6] <clk (rise)>
bit 8 fifo_receiv/fifo_mem_reg[4][7] <clk (rise)>
bit 9 fifo_receiv/fifo_mem_reg[5][0] <clk (rise)>
bit 10 fifo_receiv/fifo_mem_reg[5][1] <clk (rise)>
bit 11 fifo_receiv/fifo_mem_reg[5][2] <clk (rise)>
bit 12 fifo_receiv/fifo_mem_reg[5][3] <clk (rise)>
bit 13 fifo_receiv/fifo_mem_reg[5][4] <clk (rise)>
bit 14 fifo_receiv/fifo_mem_reg[5][5] <clk (rise)>
bit 15 fifo_receiv/fifo_mem_reg[5][6] <clk (rise)>
bit 16 fifo_receiv/fifo_mem_reg[5][7] <clk (rise)>
bit 17 fifo_receiv/fifo_mem_reg[6][0] <clk (rise)>
bit 18 fifo_receiv/fifo_mem_reg[6][1] <clk (rise)>
bit 19 fifo_receiv/fifo_mem_reg[6][2] <clk (rise)>
bit 20 fifo_receiv/fifo_mem_reg[6][3] <clk (rise)>
bit 21 fifo_receiv/fifo_mem_reg[6][4] <clk (rise)>
125
bit 22 fifo_receiv/fifo_mem_reg[6][5] <clk (rise)>
bit 23 fifo_receiv/fifo_mem_reg[6][6] <clk (rise)>
bit 24 fifo_receiv/fifo_mem_reg[6][7] <clk (rise)>
bit 25 fifo_receiv/fifo_mem_reg[7][0] <clk (rise)>
bit 26 fifo_receiv/fifo_mem_reg[7][1] <clk (rise)>
bit 27 fifo_receiv/fifo_mem_reg[7][2] <clk (rise)>
bit 28 fifo_receiv/fifo_mem_reg[7][3] <clk (rise)>
bit 29 fifo_receiv/fifo_mem_reg[7][4] <clk (rise)>
bit 30 fifo_receiv/fifo_mem_reg[7][5] <clk (rise)>
bit 31 fifo_receiv/fifo_mem_reg[7][6] <clk (rise)>
bit 32 fifo_receiv/fifo_mem_reg[7][7] <clk (rise)>
bit 33 fifo_receiv/pointer_read_reg[0] <clk (rise)>
bit 34 fifo_receiv/pointer_read_reg[1] <clk (rise)>
bit 35 fifo_receiv/pointer_read_reg[2] <clk (rise)>
bit 36 fifo_receiv/pointer_write_reg[0] <clk (rise)>
bit 37 fifo_receiv/pointer_write_reg[1] <clk (rise)>
bit 38 fifo_receiv/pointer_write_reg[2] <clk (rise)>
bit 39 fifo_transmit/counter_full_or_empty_reg[0] <clk (rise)>
bit 40 fifo_transmit/counter_full_or_empty_reg[1] <clk (rise)>
bit 41 fifo_transmit/counter_full_or_empty_reg[2] <clk (rise)>
bit 42 fifo_transmit/counter_full_or_empty_reg[3] <clk (rise)>
bit 43 fifo_transmit/data_out_reg[0] <clk (rise)>
bit 44 fifo_transmit/data_out_reg[1] <clk (rise)>
bit 45 fifo_transmit/data_out_reg[2] <clk (rise)>
bit 46 fifo_transmit/data_out_reg[3] <clk (rise)>
bit 47 fifo_transmit/data_out_reg[4] <clk (rise)>
bit 48 fifo_transmit/data_out_reg[5] <clk (rise)>
bit 49 fifo_transmit/data_out_reg[6] <clk (rise)>
bit 50 fifo_transmit/data_out_reg[7] <clk (rise)>
bit 51 fifo_transmit/fifo_mem_reg[0][0] <clk (rise)>
bit 52 fifo_transmit/fifo_mem_reg[0][1] <clk (rise)>
------------------------
Chain 3: chain3
scan_in: scan_in_3
scan_out: scan_out_3
shift_enable: scan_enable (active high)
clock_domain: clk (edge: rise)
length: 52
bit 1 fifo_transmit/fifo_mem_reg[0][2] <clk (rise)>
bit 2 fifo_transmit/fifo_mem_reg[0][3] <clk (rise)>
bit 3 fifo_transmit/fifo_mem_reg[0][4] <clk (rise)>
bit 4 fifo_transmit/fifo_mem_reg[0][5] <clk (rise)>
bit 5 fifo_transmit/fifo_mem_reg[0][6] <clk (rise)>
bit 6 fifo_transmit/fifo_mem_reg[0][7] <clk (rise)>
bit 7 fifo_transmit/fifo_mem_reg[1][0] <clk (rise)>
bit 8 fifo_transmit/fifo_mem_reg[1][1] <clk (rise)>
126
bit 9 fifo_transmit/fifo_mem_reg[1][2] <clk (rise)>
bit 10 fifo_transmit/fifo_mem_reg[1][3] <clk (rise)>
bit 11 fifo_transmit/fifo_mem_reg[1][4] <clk (rise)>
bit 12 fifo_transmit/fifo_mem_reg[1][5] <clk (rise)>
bit 13 fifo_transmit/fifo_mem_reg[1][6] <clk (rise)>
bit 14 fifo_transmit/fifo_mem_reg[1][7] <clk (rise)>
bit 15 fifo_transmit/fifo_mem_reg[2][0] <clk (rise)>
bit 16 fifo_transmit/fifo_mem_reg[2][1] <clk (rise)>
bit 17 fifo_transmit/fifo_mem_reg[2][2] <clk (rise)>
bit 18 fifo_transmit/fifo_mem_reg[2][3] <clk (rise)>
bit 19 fifo_transmit/fifo_mem_reg[2][4] <clk (rise)>
bit 20 fifo_transmit/fifo_mem_reg[2][5] <clk (rise)>
bit 21 fifo_transmit/fifo_mem_reg[2][6] <clk (rise)>
bit 22 fifo_transmit/fifo_mem_reg[2][7] <clk (rise)>
bit 23 fifo_transmit/fifo_mem_reg[3][0] <clk (rise)>
bit 24 fifo_transmit/fifo_mem_reg[3][1] <clk (rise)>
bit 25 fifo_transmit/fifo_mem_reg[3][2] <clk (rise)>
bit 26 fifo_transmit/fifo_mem_reg[3][3] <clk (rise)>
bit 27 fifo_transmit/fifo_mem_reg[3][4] <clk (rise)>
bit 28 fifo_transmit/fifo_mem_reg[3][5] <clk (rise)>
bit 29 fifo_transmit/fifo_mem_reg[3][6] <clk (rise)>
bit 30 fifo_transmit/fifo_mem_reg[3][7] <clk (rise)>
bit 31 fifo_transmit/fifo_mem_reg[4][0] <clk (rise)>
bit 32 fifo_transmit/fifo_mem_reg[4][1] <clk (rise)>
bit 33 fifo_transmit/fifo_mem_reg[4][2] <clk (rise)>
bit 34 fifo_transmit/fifo_mem_reg[4][3] <clk (rise)>
bit 35 fifo_transmit/fifo_mem_reg[4][4] <clk (rise)>
bit 36 fifo_transmit/fifo_mem_reg[4][5] <clk (rise)>
bit 37 fifo_transmit/fifo_mem_reg[4][6] <clk (rise)>
bit 38 fifo_transmit/fifo_mem_reg[4][7] <clk (rise)>
bit 39 fifo_transmit/fifo_mem_reg[5][0] <clk (rise)>
bit 40 fifo_transmit/fifo_mem_reg[5][1] <clk (rise)>
bit 41 fifo_transmit/fifo_mem_reg[5][2] <clk (rise)>
bit 42 fifo_transmit/fifo_mem_reg[5][3] <clk (rise)>
bit 43 fifo_transmit/fifo_mem_reg[5][4] <clk (rise)>
bit 44 fifo_transmit/fifo_mem_reg[5][5] <clk (rise)>
bit 45 fifo_transmit/fifo_mem_reg[5][6] <clk (rise)>
bit 46 fifo_transmit/fifo_mem_reg[5][7] <clk (rise)>
bit 47 fifo_transmit/fifo_mem_reg[6][0] <clk (rise)>
bit 48 fifo_transmit/fifo_mem_reg[6][1] <clk (rise)>
bit 49 fifo_transmit/fifo_mem_reg[6][2] <clk (rise)>
bit 50 fifo_transmit/fifo_mem_reg[6][3] <clk (rise)>
bit 51 fifo_transmit/fifo_mem_reg[6][4] <clk (rise)>
bit 52 fifo_transmit/fifo_mem_reg[6][5] <clk (rise)>
------------------------
Chain 4: chain4
127
scan_in: scan_in_4
scan_out: scan_out_4
shift_enable: scan_enable (active high)
clock_domain: clk (edge: rise)
length: 51
bit 1 fifo_transmit/fifo_mem_reg[6][6] <clk (rise)>
bit 2 fifo_transmit/fifo_mem_reg[6][7] <clk (rise)>
bit 3 fifo_transmit/fifo_mem_reg[7][0] <clk (rise)>
bit 4 fifo_transmit/fifo_mem_reg[7][1] <clk (rise)>
bit 5 fifo_transmit/fifo_mem_reg[7][2] <clk (rise)>
bit 6 fifo_transmit/fifo_mem_reg[7][3] <clk (rise)>
bit 7 fifo_transmit/fifo_mem_reg[7][4] <clk (rise)>
bit 8 fifo_transmit/fifo_mem_reg[7][5] <clk (rise)>
bit 9 fifo_transmit/fifo_mem_reg[7][6] <clk (rise)>
bit 10 fifo_transmit/fifo_mem_reg[7][7] <clk (rise)>
bit 11 fifo_transmit/pointer_read_reg[0] <clk (rise)>
bit 12 fifo_transmit/pointer_read_reg[1] <clk (rise)>
bit 13 fifo_transmit/pointer_read_reg[2] <clk (rise)>
bit 14 fifo_transmit/pointer_write_reg[0] <clk (rise)>
bit 15 fifo_transmit/pointer_write_reg[1] <clk (rise)>
bit 16 fifo_transmit/pointer_write_reg[2] <clk (rise)>
bit 17 uart_receiv/assemble_reg_reg[0] <clk (rise)>
bit 18 uart_receiv/assemble_reg_reg[1] <clk (rise)>
bit 19 uart_receiv/assemble_reg_reg[2] <clk (rise)>
bit 20 uart_receiv/assemble_reg_reg[3] <clk (rise)>
bit 21 uart_receiv/assemble_reg_reg[4] <clk (rise)>
bit 22 uart_receiv/assemble_reg_reg[5] <clk (rise)>
bit 23 uart_receiv/assemble_reg_reg[6] <clk (rise)>
bit 24 uart_receiv/assemble_reg_reg[7] <clk (rise)>
bit 25 uart_receiv/onefive_reg_reg[0] <clk (rise)>
bit 26 uart_receiv/onefive_reg_reg[1] <clk (rise)>
bit 27 uart_receiv/onefive_reg_reg[2] <clk (rise)>
bit 28 uart_receiv/onefive_reg_reg[3] <clk (rise)>
bit 29 uart_receiv/seven_reg_reg[0] <clk (rise)>
bit 30 uart_receiv/seven_reg_reg[1] <clk (rise)>
bit 31 uart_receiv/seven_reg_reg[2] <clk (rise)>
bit 32 uart_receiv/state_reg_reg[0] <clk (rise)>
bit 33 uart_receiv/state_reg_reg[1] <clk (rise)>
bit 34 uart_trans/disassemble_reg_reg[0] <clk (rise)>
bit 35 uart_trans/disassemble_reg_reg[1] <clk (rise)>
bit 36 uart_trans/disassemble_reg_reg[2] <clk (rise)>
bit 37 uart_trans/disassemble_reg_reg[3] <clk (rise)>
bit 38 uart_trans/disassemble_reg_reg[4] <clk (rise)>
bit 39 uart_trans/disassemble_reg_reg[5] <clk (rise)>
bit 40 uart_trans/disassemble_reg_reg[6] <clk (rise)>
bit 41 uart_trans/disassemble_reg_reg[7] <clk (rise)>
128
bit 42 uart_trans/onefive_reg_reg[0] <clk (rise)>
bit 43 uart_trans/onefive_reg_reg[1] <clk (rise)>
bit 44 uart_trans/onefive_reg_reg[2] <clk (rise)>
bit 45 uart_trans/onefive_reg_reg[3] <clk (rise)>
bit 46 uart_trans/seven_reg_reg[0] <clk (rise)>
bit 47 uart_trans/seven_reg_reg[1] <clk (rise)>
bit 48 uart_trans/seven_reg_reg[2] <clk (rise)>
bit 49 uart_trans/state_reg_reg[0] <clk (rise)>
bit 50 uart_trans/state_reg_reg[1] <clk (rise)>
bit 51 uart_trans/transmit_data_state_out_reg_reg <clk (rise)>
129
Appendix H: Modus’ Run Script
//====================UART Top Module=======================//
# Generated by Genus(TM) Synthesis Solution 17.20-p003_1
# Modus ATPG Script
#-------------------------------------------------------------------------------
# BUILD THE LOGIC MODEL
#-------------------------------------------------------------------------------
build_model \
cell=uart_top \
techlib=./../../library_open_source/NangateOpenCellLibrary.v \
designsource=./uart_top.test_netlist.v \
allowmissingmodules=no \
#-------------------------------------------------------------------------------
# BUILD THE TEST MODEL
#-------------------------------------------------------------------------------
build_testmode \
testmode=FULLSCAN \
assignfile=./uart_top.FULLSCAN.pinassign \
modedef=FULLSCAN \
#-------------------------------------------------------------------------------
# REPORT THE TEST MODEL
#-------------------------------------------------------------------------------
report_test_structures \
testmode=FULLSCAN \
reportscanchain=all \
reportclockaffiliation=scan \
#-------------------------------------------------------------------------------
# VERIFY THE TEST MODEL
#-------------------------------------------------------------------------------
verify_test_structures \
messagecount=TSV-016=10,TSV-024=10,TSV-315=10,TSV-027=10 \
testmode=FULLSCAN \
#-------------------------------------------------------------------------------
# BUILD THE FAULT MODEL
#-------------------------------------------------------------------------------
build_faultmodel \
includedynamic=no \
130
#-------------------------------------------------------------------------------
# ATPG - TEST GENERATION
#-------------------------------------------------------------------------------
create_scanchain_tests \
experiment=uart_top_atpg \
testmode=FULLSCAN \
create_logic_tests \
experiment=uart_top_atpg \
testmode=FULLSCAN \
append=yes \
report_faults \
testmode=FULLSCAN \
experiment=uart_top_atpg \
faultstatus=tested,untested,untestable \
faulttype=static \
statussummary=yes \
write_toggle_gram \
testmode=FULLSCAN \
experiment=uart_top_atpg \
write_vectors \
inexperiment=uart_top_atpg \
testmode=FULLSCAN \
language=verilog \
scanformat=parallel \
exportdir=./testresults/verilog_parallel \
testrange=all \
#-------------------------------------------------------------------------------
# ATPG - Report Vectors
#-------------------------------------------------------------------------------
report_vectors \
experiment=uart_top_atpg \
testmode=FULLSCAN \
format=vector \
testrange=all \
131
Appendix I: Modus Build Model Output Log
//====================UART Top Module=======================//
Starting Command: build_model
INFO (TDA-005): Command Line Invocation:
build_model stepid=cl__build_model_040918191312-868563000 cell=uart_top
allowmissingmodules=no
workdir=/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output
designsource=./uart_top.test_netlist.v
techlib=./../../library_open_source/NangateOpenCellLibrary.v [end TDA_005]
-------------------------------------------------------------------------------------------
Cadence(R) Modus(TM) Test Solution, Version 17.10-p006_1, built May 22 2017
(linux26_64)
-------------------------------------------------------------------------------------------
INFO (TDA-007): Job Information:
Date Started: Monday Apr 09 19:13:13 2018 PDT
Host machine is dcd159, x86_64 running Linux 2.6.32-696.6.3.el6.x86_64.
This job is process number 4156.
[end TDA_007]
INFO (TDA-009): Keywords/Values information.
(keywords marked with '*' have program generated values,
keywords marked with '+' were specified to default.)
WORKDIR=/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output
cell=uart_top
TECHLIB=./../../library_open_source/NangateOpenCellLibrary.v
LOGFILE=/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output/testresult
s/logs/log_build_model_040918191312-868563000
stepid=cl__build_model
DESIGNSOURCE=./uart_top.test_netlist.v
+ allowmissingmodules=no
[end TDA_009]
INFO (TEI-195): Build Model - Controller starting: [end TEI_195]
Search Order 1: "./uart_top.test_netlist.v"
Search Order 2: "./../../library_open_source/NangateOpenCellLibrary.v"
132
Reading Verilog data from ./uart_top.test_netlist.v
XM Verilog Parser complete - 6 modules, 128 gates, 0 user defined primitives.
Reading Verilog data from ./../../library_open_source/NangateOpenCellLibrary.v
XM Verilog Parser complete - 134 modules, 526 gates, 29 user defined primitives.
INFO (TEI-196): Build Model - Hierarchical Model Build starting: [end TEI_196]
WARNING (TEI-110): Pin 'NOTIFIER' of 'cell seq_SDFFR_X1' has no external net
connection for any usage in the design. Cell contents file:
'/home/users6/aem61296/Grad_Project/library_open_source/NangateOpenCellLibrary.
v'. [end TEI_110]
WARNING (TEI-110): Pin 'NOTIFIER' of 'cell seq_SDFFS_X1' has no external net
connection for any usage in the design. Cell contents file:
'/home/users6/aem61296/Grad_Project/library_open_source/NangateOpenCellLibrary.
v'. [end TEI_110]
Number of blocks in the hierarchical model is: 8006.
INFO (TEI-197): Build Model - Hierarchical Model Build completed. [end TEI_197]
INFO (TEI-198): Build Model - Flat Model Build starting: [end TEI_198]
defaultTIE = X
defaultDFN = T
WARNING (TLM-108): Bidi primary output net 'scan_enable' of 'cell uart_top'
has no dotting function(DFN) properties specified. Input keyword
defaultDFN=T is used to model the net. [end TLM_108]
WARNING (TLM-108): Bidi primary output net 'scan_in_1' of 'cell uart_top'
has no dotting function(DFN) properties specified. Input keyword
defaultDFN=T is used to model the net. [end TLM_108]
WARNING (TLM-108): Bidi primary output net 'scan_in_2' of 'cell uart_top'
has no dotting function(DFN) properties specified. Input keyword
133
defaultDFN=T is used to model the net. [end TLM_108]
WARNING (TLM-108): Bidi primary output net 'scan_in_3' of 'cell uart_top'
has no dotting function(DFN) properties specified. Input keyword
defaultDFN=T is used to model the net. [end TLM_108]
WARNING (TLM-108): Bidi primary output net 'scan_in_4' of 'cell uart_top'
has no dotting function(DFN) properties specified. Input keyword
defaultDFN=T is used to model the net. [end TLM_108]
WARNING (TLM-108): Bidi primary output net 'scan_out_1' of 'cell uart_top'
has no dotting function(DFN) properties specified. Input keyword
defaultDFN=T is used to model the net. [end TLM_108]
WARNING (TLM-108): Bidi primary output net 'scan_out_2' of 'cell uart_top'
has no dotting function(DFN) properties specified. Input keyword
defaultDFN=T is used to model the net. [end TLM_108]
WARNING (TLM-108): Bidi primary output net 'scan_out_3' of 'cell uart_top'
has no dotting function(DFN) properties specified. Input keyword
defaultDFN=T is used to model the net. [end TLM_108]
WARNING (TLM-108): Bidi primary output net 'scan_out_4' of 'cell uart_top'
has no dotting function(DFN) properties specified. Input keyword
defaultDFN=T is used to model the net. [end TLM_108]
INFO (TLM-055): Design Summary
--------------
Hierarchical Model: Flattened Model:
8,006 Blocks 5,615 Blocks
22,965 Pins 5,615 Nodes
12,689 Nets
Primary Inputs: Primary Outputs:
13 Input Only 11 Output Only
9 Input/Output 9 Input/Output
22 Total Inputs 20 Total Outputs
Tied Nets: Dotted Nets:
78 Tied to 0 0 Two-State
257 Tied to 1 9 Three-State
0 Tied to X 9 Total Dotted Nets
335 Total Tied Nets
Selected Primitive Functions:
0 Clock Chopper (CHOP) primitives
0 RAMs
0 ROMs
0 TSDs
0 Resistors
0 Transistors
134
0 Latches
207 Flip-Flops
[end TLM_055]
Optimization removed logic for 2 of 32 cells in this design.
Optimization removed a total of 0 tied Latch Ports.
Optimization removed a total of 0 non-controlling inputs.
Optimization removed a total of 1,656 dangling logic nodes.
INFO (TEI-199): Build Model - Flat Model Build completed. [end TEI_199]
INFO (TDA-001): Maximum Memory used during the run and Cumulative Time in
hours:minutes:seconds:
Total Memory = 96,340,880 bytes
CPU Time = 0:00:00.96
Elapsed Time = 0:00:07.00 [end TDA_001]
INFO (TEI-200): Build Model - Controller completed. [end TEI_200]
-------------------------------------------------------------------------------
* Message Summary *
-------------------------------------------------------------------------------
Count Number First Instance of Message Text
------- ------ ------------------------------
INFO Messages...
1 INFO (TEI-195): Build Model - Controller starting:
1 INFO (TEI-196): Build Model - Hierarchical Model Build starting:
1 INFO (TEI-197): Build Model - Hierarchical Model Build completed.
1 INFO (TEI-198): Build Model - Flat Model Build starting:
1 INFO (TEI-199): Build Model - Flat Model Build completed.
1 INFO (TEI-200): Build Model - Controller completed.
1 INFO (TLM-055): Design Summary
WARNING Messages...
135
2 WARNING (TEI-110): Pin 'NOTIFIER' of 'cell seq_SDFFR_X1' has no external
net connection for any usage in the design. Cell contents file:
'/home/users6/aem61296/Grad_Project/library_open_source/NangateOpenCellLibrary.
v'.
9 WARNING (TLM-108): Bidi primary output net 'scan_enable' of 'cell uart_top'
For a detailed explanation of a message and a suggested user response execute
'msgHelp <message id>'. For example: msgHelp TDA-009
-------------------------------------------------------------------------------
136
Appendix J: Modus FULLSCAN Build Test Mode Output Log
//====================UART Top Module=======================//
Starting Command: build_testmode
INFO (TDA-005): Command Line Invocation:
build_testmode stepid=cl__build_testmode_040918191439-465700000
modedef=FULLSCAN testmode=FULLSCAN
assignfile=./uart_top.FULLSCAN.pinassign
workdir=/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output [end
TDA_005]
-------------------------------------------------------------------------------------------
Cadence(R) Modus(TM) Test Solution, Version 17.10-p006_1, built May 22 2017
(linux26_64)
-------------------------------------------------------------------------------------------
INFO (TDA-007): Job Information:
Date Started: Monday Apr 09 19:14:39 2018 PDT
Host machine is dcd159, x86_64 running Linux 2.6.32-696.6.3.el6.x86_64.
This job is process number 4222.
[end TDA_007]
INFO (TDA-009): Keywords/Values information.
(keywords marked with '*' have program generated values,
keywords marked with '+' were specified to default.)
WORKDIR=/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output
TESTMODE=FULLSCAN
ASSIGNFILE=./uart_top.FULLSCAN.pinassign
LOGFILE=/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output/testresult
s/logs/log_build_testmode_FULLSCAN_040918191439-465700000
MODEDEF=FULLSCAN
stepid=cl__build_testmode
[end TDA_009]
MODEDEFPATH set to:
/opt/cadence/MODUS171/tools.lnx86/tb/defaults/rules/modedef
TDRPATH set to: /opt/cadence/MODUS171/tools.lnx86/tb/defaults/rules/tdr
Modus Build Test Mode(s) beginning...
TDR NAME = dummy.tdr
137
SCAN_TYPE = GSD
BOUNDARY = NONE
IN = PI
OUT = PO
INFO (TTM-391): A default modeinit sequence will be generated. [end TTM_391]
INFO (TTM-387): A default scanop sequence will be generated. [end TTM_387]
INFO (THM-814): Testmode contains 97.72% active logic, 2.28% inactive logic and
0.00% constraint logic. [end THM_814]
INFO (TTM-357): There are 4 scan chains which are controllable and observable.
[end TTM_357]
There are no PPIs for Test Mode: FULLSCAN
Information for Test Mode: FULLSCAN
-------------------------
Scan Type = GSD
Latch Summary for Test Mode: FULLSCAN
Latch Type #Active #Inactive Total
--------------------- --------- --------- ---------
Test Constraint (TC) 0 0 0
Scan Enable (SE) 0 0 0
Fixed Value (FV) 0 0 0
Floating 0 0 0
Finite State (FSM) 0 0 0
INFO (TTM-800): build_testmode has created mode FULLSCAN. [end TTM_800]
Test Function Pin Information for Test Mode: FULLSCAN
-------------------------------------------
2 SC (System Clock) Pins
0 AC (A Shift Clock) Pins
0 BC (B Shift Clock) Pins
0 PC (P Shift Clock) Pins
1 EC (E Shift Clock) Pins
0 OSC (Oscillator) Pins
0 TI (Test Inhibit) Pins
5 SE (Scan Enable) Pins
0 CI (Clock Isolation) Pins
138
0 OI (Output Inhibit) Pins
4 SI (Scan Input) Pins
4 SO (Scan Output) Pins
Pin Index Type Test Function Pin Name / Net Name
--------- ---- ---------------------------------- -------------------
3 PI -SC reset / reset
0 PI -EC -SC clk / clk
22 PI* +SE scan_enable / scan_enable
27 PI* ZSE scan_out_1 / scan_out_1
28 PI* ZSE scan_out_2 / scan_out_2
29 PI* ZSE scan_out_3 / scan_out_3
30 PI* ZSE scan_out_4 / scan_out_4
23 PI* SI scan_in_1 / scan_in_1
24 PI* SI1 scan_in_2 / scan_in_2
25 PI* SI2 scan_in_3 / scan_in_3
26 PI* SI3 scan_in_4 / scan_in_4
27 PO* SO scan_out_1 / scan_out_1
28 PO* SO1 scan_out_2 / scan_out_2
29 PO* SO2 scan_out_3 / scan_out_3
30 PO* SO3 scan_out_4 / scan_out_4
* pin is Input/Output
Cumulative Time in hours:minutes:seconds:
CPU Time = 0:00:00.22
Elapsed Time = 0:00:01.72
-------------------------------------------------------------------------------
* Message Summary *
-------------------------------------------------------------------------------
Count Number First Instance of Message Text
------- ------ ------------------------------
INFO Messages...
1 INFO (THM-814): Testmode contains 97.72% active logic, 2.28% inactive logic
and 0.00% constraint logic.
1 INFO (TTM-357): There are 4 scan chains which are controllable and observable.
1 INFO (TTM-387): A default scanop sequence will be generated.
1 INFO (TTM-391): A default modeinit sequence will be generated.
1 INFO (TTM-800): build_testmode has created mode FULLSCAN.
139
For a detailed explanation of a message and a suggested user response execute
'msgHelp <message id>'. For example: msgHelp TDA-009
-------------------------------------------------------------------------------
140
Appendix K: Modus Report Test Structures Output Log
//====================UART Top Module=======================//
Starting Command: report_test_structures
INFO (TDA-005): Command Line Invocation:
report_test_structures stepid=cl__report_test_structures_040918191516-
761476000 reportscanchain=all testmode=FULLSCAN reportclockaffiliation=scan
workdir=/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output [end
TDA_005]
-------------------------------------------------------------------------------------------
Cadence(R) Modus(TM) Test Solution, Version 17.10-p006_1, built May 22 2017
(linux26_64)
-------------------------------------------------------------------------------------------
INFO (TDA-007): Job Information:
Date Started: Monday Apr 09 19:15:16 2018 PDT
Host machine is dcd159, x86_64 running Linux 2.6.32-696.6.3.el6.x86_64.
This job is process number 4251.
[end TDA_007]
INFO (TDA-009): Keywords/Values information.
(keywords marked with '*' have program generated values,
keywords marked with '+' were specified to default.)
WORKDIR=/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output
TESTMODE=FULLSCAN
LOGFILE=/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output/testresult
s/logs/log_report_test_structures_FULLSCAN_040918191516-761476000
stepid=cl__report_test_structures
reportscanchain=all
reportclockaffiliation=scan
[end TDA_009]
INFO (TLM-055): Design Summary
--------------
Hierarchical Model: Flattened Model:
8,006 Blocks 5,615 Blocks
22,965 Pins 5,615 Nodes
12,689 Nets
141
Primary Inputs: Primary Outputs:
13 Input Only 11 Output Only
9 Input/Output 9 Input/Output
22 Total Inputs 20 Total Outputs
Tied Nets: Dotted Nets:
78 Tied to 0 0 Two-State
257 Tied to 1 9 Three-State
0 Tied to X 9 Total Dotted Nets
335 Total Tied Nets
Selected Primitive Functions:
0 Clock Chopper (CHOP) primitives
0 RAMs
0 ROMs
0 TSDs
0 Resistors
0 Transistors
0 Latches
207 Flip-Flops
[end TLM_055]
Information for Test Mode: FULLSCAN
-------------------------
Scan Type = GSD
Control/Observe Chain Information for Test Mode: FULLSCAN
-----------------------------------------------
4 Control Chains (0 Control Only)
4 Observe Chains (0 Observe Only)
4 Chains are Control and Observe
Longest Scan Chain: 52 bits
Average Scan Chain Length: 52 bits
Control Chain: 1
Load Point Pin Index/Name 23/scan_in_1
142
Length: 52
Scan Section: Scan_Section_Sequence
Scan Clock Affiliations: clk: -EC
Observe Chain: 1
Unload Point Pin Index/Name 27/scan_out_1
Unload Point In Phase with Load Point
Length: 52
Scan Section: Scan_Section_Sequence
Position LTYPE Blk Index/IO ObserveChn ObservePos Block Name Clock
Affiliation
-------- ------- ------------ ---------- ---------- ---------- -----------------
1 rDFF_c 4 ++ 1 52
baud_gen.\sum_reg_reg[0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC inPhase
2 rDFF_c 32 -- 1 51
baud_gen.\sum_reg_reg[1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC inPhase
3 rDFF_c 60 ++ 1 50
baud_gen.\sum_reg_reg[2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC inPhase
4 rDFF_c 88 -- 1 49
baud_gen.\sum_reg_reg[3].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC inPhase
5 rDFF_c 116 ++ 1 48
baud_gen.\sum_reg_reg[4].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC inPhase
6 rDFF_c 144 -- 1 47
baud_gen.\sum_reg_reg[5].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC inPhase
7 rDFF_c 172 ++ 1 46
baud_gen.\sum_reg_reg[6].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC inPhase
8 rDFF_c 200 -- 1 45
baud_gen.\sum_reg_reg[7].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC inPhase
9 rDFF_c 282 ++ 1 44
fifo_receiv.\counter_full_or_empty_reg[0].__iNsT0.dff_primitive clk: -EC inPhase
clk: -SC inPhase
10 rDFF_c 310 -- 1 43
fifo_receiv.\counter_full_or_empty_reg[1].__iNsT0.dff_primitive clk: -EC inPhase
clk: -SC inPhase
11 rDFF_c 338 ++ 1 42
fifo_receiv.\counter_full_or_empty_reg[2].__iNsT0.dff_primitive clk: -EC inPhase
clk: -SC inPhase
12 rDFF_c 366 -- 1 41
fifo_receiv.\counter_full_or_empty_reg[3].__iNsT0.dff_primitive clk: -EC inPhase
clk: -SC inPhase
13 rDFF_c 394 ++ 1 40
fifo_receiv.\data_out_reg[0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC inPhase
14 rDFF_c 422 -- 1 39
fifo_receiv.\data_out_reg[1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC inPhase
15 rDFF_c 450 ++ 1 38
fifo_receiv.\data_out_reg[2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC inPhase
143
16 rDFF_c 478 -- 1 37
fifo_receiv.\data_out_reg[3].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC inPhase
17 rDFF_c 506 ++ 1 36
fifo_receiv.\data_out_reg[4].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC inPhase
18 rDFF_c 534 -- 1 35
fifo_receiv.\data_out_reg[5].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC inPhase
19 rDFF_c 562 ++ 1 34
fifo_receiv.\data_out_reg[6].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC inPhase
20 rDFF_c 590 -- 1 33
fifo_receiv.\data_out_reg[7].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC inPhase
21 rDFF_s 618 ++ 1 32
fifo_receiv.\fifo_mem_reg[0][0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
22 rDFF_s 646 -- 1 31
fifo_receiv.\fifo_mem_reg[0][1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
23 rDFF_s 674 ++ 1 30
fifo_receiv.\fifo_mem_reg[0][2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
24 rDFF_s 702 -- 1 29
fifo_receiv.\fifo_mem_reg[0][3].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
25 rDFF_s 730 ++ 1 28
fifo_receiv.\fifo_mem_reg[0][4].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
26 rDFF_s 758 -- 1 27
fifo_receiv.\fifo_mem_reg[0][5].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
27 rDFF_s 786 ++ 1 26
fifo_receiv.\fifo_mem_reg[0][6].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
28 rDFF_s 814 -- 1 25
fifo_receiv.\fifo_mem_reg[0][7].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
29 rDFF_s 842 ++ 1 24
fifo_receiv.\fifo_mem_reg[1][0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
30 rDFF_s 870 -- 1 23
fifo_receiv.\fifo_mem_reg[1][1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
31 rDFF_s 898 ++ 1 22
fifo_receiv.\fifo_mem_reg[1][2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
32 rDFF_s 926 -- 1 21
fifo_receiv.\fifo_mem_reg[1][3].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
144
33 rDFF_s 954 ++ 1 20
fifo_receiv.\fifo_mem_reg[1][4].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
34 rDFF_s 982 -- 1 19
fifo_receiv.\fifo_mem_reg[1][5].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
35 rDFF_s 1010 ++ 1 18
fifo_receiv.\fifo_mem_reg[1][6].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
36 rDFF_s 1038 -- 1 17
fifo_receiv.\fifo_mem_reg[1][7].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
37 rDFF_s 1066 ++ 1 16
fifo_receiv.\fifo_mem_reg[2][0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
38 rDFF_s 1094 -- 1 15
fifo_receiv.\fifo_mem_reg[2][1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
39 rDFF_s 1122 ++ 1 14
fifo_receiv.\fifo_mem_reg[2][2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
40 rDFF_s 1150 -- 1 13
fifo_receiv.\fifo_mem_reg[2][3].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
41 rDFF_s 1178 ++ 1 12
fifo_receiv.\fifo_mem_reg[2][4].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
42 rDFF_s 1206 -- 1 11
fifo_receiv.\fifo_mem_reg[2][5].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
43 rDFF_s 1234 ++ 1 10
fifo_receiv.\fifo_mem_reg[2][6].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
44 rDFF_s 1262 -- 1 9
fifo_receiv.\fifo_mem_reg[2][7].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
45 rDFF_s 1290 ++ 1 8
fifo_receiv.\fifo_mem_reg[3][0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
46 rDFF_s 1318 -- 1 7
fifo_receiv.\fifo_mem_reg[3][1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
47 rDFF_s 1346 ++ 1 6
fifo_receiv.\fifo_mem_reg[3][2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
145
48 rDFF_s 1374 -- 1 5
fifo_receiv.\fifo_mem_reg[3][3].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
49 rDFF_s 1402 ++ 1 4
fifo_receiv.\fifo_mem_reg[3][4].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
50 rDFF_s 1430 -- 1 3
fifo_receiv.\fifo_mem_reg[3][5].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
51 rDFF_s 1458 ++ 1 2
fifo_receiv.\fifo_mem_reg[3][6].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
52 rDFF_s 1486 -- 1 1
fifo_receiv.\fifo_mem_reg[3][7].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
Control Chain: 2
Load Point Pin Index/Name 24/scan_in_2
Length: 52
Scan Section: Scan_Section_Sequence
Scan Clock Affiliations: clk: -EC
Observe Chain: 2
Unload Point Pin Index/Name 28/scan_out_2
Unload Point In Phase with Load Point
Length: 52
Scan Section: Scan_Section_Sequence
Position LTYPE Blk Index/IO ObserveChn ObservePos Block Name Clock
Affiliation
-------- ------- ------------ ---------- ---------- ---------- -----------------
1 rDFF_s 1514 ++ 2 52
fifo_receiv.\fifo_mem_reg[4][0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
2 rDFF_s 1542 -- 2 51
fifo_receiv.\fifo_mem_reg[4][1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
3 rDFF_s 1570 ++ 2 50
fifo_receiv.\fifo_mem_reg[4][2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
4 rDFF_s 1598 -- 2 49
fifo_receiv.\fifo_mem_reg[4][3].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
5 rDFF_s 1626 ++ 2 48
fifo_receiv.\fifo_mem_reg[4][4].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
146
6 rDFF_s 1654 -- 2 47
fifo_receiv.\fifo_mem_reg[4][5].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
7 rDFF_s 1682 ++ 2 46
fifo_receiv.\fifo_mem_reg[4][6].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
8 rDFF_s 1710 -- 2 45
fifo_receiv.\fifo_mem_reg[4][7].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
9 rDFF_s 1738 ++ 2 44
fifo_receiv.\fifo_mem_reg[5][0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
10 rDFF_s 1766 -- 2 43
fifo_receiv.\fifo_mem_reg[5][1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
11 rDFF_s 1794 ++ 2 42
fifo_receiv.\fifo_mem_reg[5][2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
12 rDFF_s 1822 -- 2 41
fifo_receiv.\fifo_mem_reg[5][3].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
13 rDFF_s 1850 ++ 2 40
fifo_receiv.\fifo_mem_reg[5][4].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
14 rDFF_s 1878 -- 2 39
fifo_receiv.\fifo_mem_reg[5][5].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
15 rDFF_s 1906 ++ 2 38
fifo_receiv.\fifo_mem_reg[5][6].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
16 rDFF_s 1934 -- 2 37
fifo_receiv.\fifo_mem_reg[5][7].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
17 rDFF_s 1962 ++ 2 36
fifo_receiv.\fifo_mem_reg[6][0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
18 rDFF_s 1990 -- 2 35
fifo_receiv.\fifo_mem_reg[6][1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
19 rDFF_s 2018 ++ 2 34
fifo_receiv.\fifo_mem_reg[6][2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
20 rDFF_s 2046 -- 2 33
fifo_receiv.\fifo_mem_reg[6][3].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
147
21 rDFF_s 2074 ++ 2 32
fifo_receiv.\fifo_mem_reg[6][4].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
22 rDFF_s 2102 -- 2 31
fifo_receiv.\fifo_mem_reg[6][5].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
23 rDFF_s 2130 ++ 2 30
fifo_receiv.\fifo_mem_reg[6][6].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
24 rDFF_s 2158 -- 2 29
fifo_receiv.\fifo_mem_reg[6][7].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
25 rDFF_s 2186 ++ 2 28
fifo_receiv.\fifo_mem_reg[7][0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
26 rDFF_s 2214 -- 2 27
fifo_receiv.\fifo_mem_reg[7][1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
27 rDFF_s 2242 ++ 2 26
fifo_receiv.\fifo_mem_reg[7][2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
28 rDFF_s 2270 -- 2 25
fifo_receiv.\fifo_mem_reg[7][3].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
29 rDFF_s 2298 ++ 2 24
fifo_receiv.\fifo_mem_reg[7][4].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
30 rDFF_s 2326 -- 2 23
fifo_receiv.\fifo_mem_reg[7][5].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
31 rDFF_s 2354 ++ 2 22
fifo_receiv.\fifo_mem_reg[7][6].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
32 rDFF_s 2382 -- 2 21
fifo_receiv.\fifo_mem_reg[7][7].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
33 rDFF_c 2410 ++ 2 20
fifo_receiv.\pointer_read_reg[0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
34 rDFF_c 2438 -- 2 19
fifo_receiv.\pointer_read_reg[1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
35 rDFF_c 2466 ++ 2 18
fifo_receiv.\pointer_read_reg[2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
148
36 rDFF_c 2494 -- 2 17
fifo_receiv.\pointer_write_reg[0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
37 rDFF_c 2522 ++ 2 16
fifo_receiv.\pointer_write_reg[1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
38 rDFF_c 2550 -- 2 15
fifo_receiv.\pointer_write_reg[2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
39 rDFF_c 3414 ++ 2 14
fifo_transmit.\counter_full_or_empty_reg[0].__iNsT0.dff_primitive clk: -EC inPhase
clk: -SC inPhase
40 rDFF_c 3442 -- 2 13
fifo_transmit.\counter_full_or_empty_reg[1].__iNsT0.dff_primitive clk: -EC inPhase
clk: -SC inPhase
41 rDFF_c 3470 ++ 2 12
fifo_transmit.\counter_full_or_empty_reg[2].__iNsT0.dff_primitive clk: -EC inPhase
clk: -SC inPhase
42 rDFF_c 3498 -- 2 11
fifo_transmit.\counter_full_or_empty_reg[3].__iNsT0.dff_primitive clk: -EC inPhase
clk: -SC inPhase
43 rDFF_c 3526 ++ 2 10
fifo_transmit.\data_out_reg[0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
44 rDFF_c 3554 -- 2 9
fifo_transmit.\data_out_reg[1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
45 rDFF_c 3582 ++ 2 8
fifo_transmit.\data_out_reg[2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
46 rDFF_c 3610 -- 2 7
fifo_transmit.\data_out_reg[3].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
47 rDFF_c 3638 ++ 2 6
fifo_transmit.\data_out_reg[4].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
48 rDFF_c 3666 -- 2 5
fifo_transmit.\data_out_reg[5].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
49 rDFF_c 3694 ++ 2 4
fifo_transmit.\data_out_reg[6].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
50 rDFF_c 3722 -- 2 3
fifo_transmit.\data_out_reg[7].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
149
51 rDFF_s 3750 ++ 2 2
fifo_transmit.\fifo_mem_reg[0][0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
52 rDFF_s 3778 -- 2 1
fifo_transmit.\fifo_mem_reg[0][1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
Control Chain: 3
Load Point Pin Index/Name 25/scan_in_3
Length: 52
Scan Section: Scan_Section_Sequence
Scan Clock Affiliations: clk: -EC
Observe Chain: 3
Unload Point Pin Index/Name 29/scan_out_3
Unload Point In Phase with Load Point
Length: 52
Scan Section: Scan_Section_Sequence
Position LTYPE Blk Index/IO ObserveChn ObservePos Block Name Clock
Affiliation
-------- ------- ------------ ---------- ---------- ---------- -----------------
1 rDFF_s 3806 ++ 3 52
fifo_transmit.\fifo_mem_reg[0][2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
2 rDFF_s 3834 -- 3 51
fifo_transmit.\fifo_mem_reg[0][3].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
3 rDFF_s 3862 ++ 3 50
fifo_transmit.\fifo_mem_reg[0][4].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
4 rDFF_s 3890 -- 3 49
fifo_transmit.\fifo_mem_reg[0][5].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
5 rDFF_s 3918 ++ 3 48
fifo_transmit.\fifo_mem_reg[0][6].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
6 rDFF_s 3946 -- 3 47
fifo_transmit.\fifo_mem_reg[0][7].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
7 rDFF_s 3974 ++ 3 46
fifo_transmit.\fifo_mem_reg[1][0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
8 rDFF_s 4002 -- 3 45
fifo_transmit.\fifo_mem_reg[1][1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
150
9 rDFF_s 4030 ++ 3 44
fifo_transmit.\fifo_mem_reg[1][2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
10 rDFF_s 4058 -- 3 43
fifo_transmit.\fifo_mem_reg[1][3].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
11 rDFF_s 4086 ++ 3 42
fifo_transmit.\fifo_mem_reg[1][4].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
12 rDFF_s 4114 -- 3 41
fifo_transmit.\fifo_mem_reg[1][5].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
13 rDFF_s 4142 ++ 3 40
fifo_transmit.\fifo_mem_reg[1][6].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
14 rDFF_s 4170 -- 3 39
fifo_transmit.\fifo_mem_reg[1][7].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
15 rDFF_s 4198 ++ 3 38
fifo_transmit.\fifo_mem_reg[2][0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
16 rDFF_s 4226 -- 3 37
fifo_transmit.\fifo_mem_reg[2][1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
17 rDFF_s 4254 ++ 3 36
fifo_transmit.\fifo_mem_reg[2][2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
18 rDFF_s 4282 -- 3 35
fifo_transmit.\fifo_mem_reg[2][3].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
19 rDFF_s 4310 ++ 3 34
fifo_transmit.\fifo_mem_reg[2][4].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
20 rDFF_s 4338 -- 3 33
fifo_transmit.\fifo_mem_reg[2][5].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
21 rDFF_s 4366 ++ 3 32
fifo_transmit.\fifo_mem_reg[2][6].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
22 rDFF_s 4394 -- 3 31
fifo_transmit.\fifo_mem_reg[2][7].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
23 rDFF_s 4422 ++ 3 30
fifo_transmit.\fifo_mem_reg[3][0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
151
24 rDFF_s 4450 -- 3 29
fifo_transmit.\fifo_mem_reg[3][1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
25 rDFF_s 4478 ++ 3 28
fifo_transmit.\fifo_mem_reg[3][2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
26 rDFF_s 4506 -- 3 27
fifo_transmit.\fifo_mem_reg[3][3].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
27 rDFF_s 4534 ++ 3 26
fifo_transmit.\fifo_mem_reg[3][4].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
28 rDFF_s 4562 -- 3 25
fifo_transmit.\fifo_mem_reg[3][5].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
29 rDFF_s 4590 ++ 3 24
fifo_transmit.\fifo_mem_reg[3][6].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
30 rDFF_s 4618 -- 3 23
fifo_transmit.\fifo_mem_reg[3][7].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
31 rDFF_s 4646 ++ 3 22
fifo_transmit.\fifo_mem_reg[4][0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
32 rDFF_s 4674 -- 3 21
fifo_transmit.\fifo_mem_reg[4][1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
33 rDFF_s 4702 ++ 3 20
fifo_transmit.\fifo_mem_reg[4][2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
34 rDFF_s 4730 -- 3 19
fifo_transmit.\fifo_mem_reg[4][3].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
35 rDFF_s 4758 ++ 3 18
fifo_transmit.\fifo_mem_reg[4][4].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
36 rDFF_s 4786 -- 3 17
fifo_transmit.\fifo_mem_reg[4][5].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
37 rDFF_s 4814 ++ 3 16
fifo_transmit.\fifo_mem_reg[4][6].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
38 rDFF_s 4842 -- 3 15
fifo_transmit.\fifo_mem_reg[4][7].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
152
39 rDFF_s 4870 ++ 3 14
fifo_transmit.\fifo_mem_reg[5][0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
40 rDFF_s 4898 -- 3 13
fifo_transmit.\fifo_mem_reg[5][1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
41 rDFF_s 4926 ++ 3 12
fifo_transmit.\fifo_mem_reg[5][2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
42 rDFF_s 4954 -- 3 11
fifo_transmit.\fifo_mem_reg[5][3].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
43 rDFF_s 4982 ++ 3 10
fifo_transmit.\fifo_mem_reg[5][4].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
44 rDFF_s 5010 -- 3 9
fifo_transmit.\fifo_mem_reg[5][5].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
45 rDFF_s 5038 ++ 3 8
fifo_transmit.\fifo_mem_reg[5][6].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
46 rDFF_s 5066 -- 3 7
fifo_transmit.\fifo_mem_reg[5][7].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
47 rDFF_s 5094 ++ 3 6
fifo_transmit.\fifo_mem_reg[6][0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
48 rDFF_s 5122 -- 3 5
fifo_transmit.\fifo_mem_reg[6][1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
49 rDFF_s 5150 ++ 3 4
fifo_transmit.\fifo_mem_reg[6][2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
50 rDFF_s 5178 -- 3 3
fifo_transmit.\fifo_mem_reg[6][3].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
51 rDFF_s 5206 ++ 3 2
fifo_transmit.\fifo_mem_reg[6][4].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
52 rDFF_s 5234 -- 3 1
fifo_transmit.\fifo_mem_reg[6][5].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
Control Chain: 4
Load Point Pin Index/Name 26/scan_in_4
153
Length: 51
Scan Section: Scan_Section_Sequence
Scan Clock Affiliations: clk: -EC
Observe Chain: 4
Unload Point Pin Index/Name 30/scan_out_4
Unload Point Inverted from Load Point
Length: 51
Scan Section: Scan_Section_Sequence
Position LTYPE Blk Index/IO ObserveChn ObservePos Block Name Clock
Affiliation
-------- ------- ------------ ---------- ---------- ---------- -----------------
1 rDFF_s 5262 +- 4 51
fifo_transmit.\fifo_mem_reg[6][6].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
2 rDFF_s 5290 -+ 4 50
fifo_transmit.\fifo_mem_reg[6][7].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
3 rDFF_s 5318 +- 4 49
fifo_transmit.\fifo_mem_reg[7][0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
4 rDFF_s 5346 -+ 4 48
fifo_transmit.\fifo_mem_reg[7][1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
5 rDFF_s 5374 +- 4 47
fifo_transmit.\fifo_mem_reg[7][2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
6 rDFF_s 5402 -+ 4 46
fifo_transmit.\fifo_mem_reg[7][3].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
7 rDFF_s 5430 +- 4 45
fifo_transmit.\fifo_mem_reg[7][4].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
8 rDFF_s 5458 -+ 4 44
fifo_transmit.\fifo_mem_reg[7][5].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
9 rDFF_s 5486 +- 4 43
fifo_transmit.\fifo_mem_reg[7][6].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
10 rDFF_s 5514 -+ 4 42
fifo_transmit.\fifo_mem_reg[7][7].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
11 rDFF_c 5542 +- 4 41
fifo_transmit.\pointer_read_reg[0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
154
12 rDFF_c 5570 -+ 4 40
fifo_transmit.\pointer_read_reg[1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
13 rDFF_c 5598 +- 4 39
fifo_transmit.\pointer_read_reg[2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
14 rDFF_c 5626 -+ 4 38
fifo_transmit.\pointer_write_reg[0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
15 rDFF_c 5654 +- 4 37
fifo_transmit.\pointer_write_reg[1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
16 rDFF_c 5682 -+ 4 36
fifo_transmit.\pointer_write_reg[2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
17 rDFF_c 6560 +- 4 35
uart_receiv.\assemble_reg_reg[0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
18 rDFF_c 6588 -+ 4 34
uart_receiv.\assemble_reg_reg[1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
19 rDFF_c 6616 +- 4 33
uart_receiv.\assemble_reg_reg[2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
20 rDFF_c 6644 -+ 4 32
uart_receiv.\assemble_reg_reg[3].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
21 rDFF_c 6672 +- 4 31
uart_receiv.\assemble_reg_reg[4].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
22 rDFF_c 6700 -+ 4 30
uart_receiv.\assemble_reg_reg[5].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
23 rDFF_c 6728 +- 4 29
uart_receiv.\assemble_reg_reg[6].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
24 rDFF_c 6756 -+ 4 28
uart_receiv.\assemble_reg_reg[7].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
25 rDFF_c 6784 +- 4 27
uart_receiv.\onefive_reg_reg[0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
26 rDFF_c 6812 -+ 4 26
uart_receiv.\onefive_reg_reg[1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
155
27 rDFF_c 6840 +- 4 25
uart_receiv.\onefive_reg_reg[2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
28 rDFF_c 6868 -+ 4 24
uart_receiv.\onefive_reg_reg[3].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
29 rDFF_c 6896 +- 4 23
uart_receiv.\seven_reg_reg[0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
30 rDFF_c 6924 -+ 4 22
uart_receiv.\seven_reg_reg[1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
31 rDFF_c 6952 +- 4 21
uart_receiv.\seven_reg_reg[2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
32 rDFF_c 6980 -+ 4 20
uart_receiv.\state_reg_reg[0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
33 rDFF_c 7008 +- 4 19
uart_receiv.\state_reg_reg[1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
34 rDFF_c 7258 -+ 4 18
uart_trans.\disassemble_reg_reg[0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
35 rDFF_c 7286 +- 4 17
uart_trans.\disassemble_reg_reg[1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
36 rDFF_c 7314 -+ 4 16
uart_trans.\disassemble_reg_reg[2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
37 rDFF_c 7342 +- 4 15
uart_trans.\disassemble_reg_reg[3].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
38 rDFF_c 7370 -+ 4 14
uart_trans.\disassemble_reg_reg[4].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
39 rDFF_c 7398 +- 4 13
uart_trans.\disassemble_reg_reg[5].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
40 rDFF_c 7426 -+ 4 12
uart_trans.\disassemble_reg_reg[6].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
41 rDFF_c 7454 +- 4 11
uart_trans.\disassemble_reg_reg[7].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
156
42 rDFF_c 7482 -+ 4 10
uart_trans.\onefive_reg_reg[0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
43 rDFF_c 7510 +- 4 9
uart_trans.\onefive_reg_reg[1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
44 rDFF_c 7538 -+ 4 8
uart_trans.\onefive_reg_reg[2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
45 rDFF_c 7566 +- 4 7
uart_trans.\onefive_reg_reg[3].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
46 rDFF_c 7594 -+ 4 6
uart_trans.\seven_reg_reg[0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
47 rDFF_c 7622 +- 4 5
uart_trans.\seven_reg_reg[1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
48 rDFF_c 7650 -+ 4 4
uart_trans.\seven_reg_reg[2].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC
inPhase
49 rDFF_c 7678 +- 4 3
uart_trans.\state_reg_reg[0].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC inPhase
50 rDFF_c 7706 -+ 4 2
uart_trans.\state_reg_reg[1].__iNsT0.dff_primitive clk: -EC inPhase clk: -SC inPhase
51 rDFF_s 7980 +- 4 1
uart_trans.transmit_data_state_out_reg_reg.__iNsT0.dff_primitive clk: -EC inPhase
clk: -SC inPhase
Report completed.
INFO (TDA-001): Maximum Memory used during the run and Cumulative Time in
hours:minutes:seconds:
Total Memory = 7,434,832 bytes
CPU Time = 0:00:00.01
Elapsed Time = 0:00:00.32 [end TDA_001]
Date Ended: Monday Apr 09 19:15:17 2018 PDT
157
-------------------------------------------------------------------------------
* Message Summary *
-------------------------------------------------------------------------------
Count Number First Instance of Message Text
------- ------ ------------------------------
INFO Messages...
1 INFO (TLM-055): Design Summary
For a detailed explanation of a message and a suggested user response execute
'msgHelp <message id>'. For example: msgHelp TDA-009
-------------------------------------------------------------------------------
158
Appendix L: Modus Verify Test Structure Output Log
//====================UART Top Module=======================//
Starting Command: verify_test_structures
INFO (TDA-005): Command Line Invocation:
verify_test_structures stepid=cl__verify_test_structures_040918191541-
401790000 testmode=FULLSCAN
workdir=/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output
messagecount=TSV-016=10,TSV-024=10,TSV-315=10,TSV-027=10 [end TDA_005]
-------------------------------------------------------------------------------------------
Cadence(R) Modus(TM) Test Solution, Version 17.10-p006_1, built May 22 2017
(linux26_64)
-------------------------------------------------------------------------------------------
INFO (TDA-007): Job Information:
Date Started: Monday Apr 09 19:15:41 2018 PDT
Host machine is dcd159, x86_64 running Linux 2.6.32-696.6.3.el6.x86_64.
This job is process number 4261.
[end TDA_007]
INFO (TDA-009): Keywords/Values information.
(keywords marked with '*' have program generated values,
keywords marked with '+' were specified to default.)
WORKDIR=/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output
TESTMODE=FULLSCAN
messagecount=TSV-016=10,TSV-024=10,TSV-315=10,TSV-027=10
LOGFILE=/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output/testresult
s/logs/log_verify_test_structures_FULLSCAN_040918191541-401790000
stepid=cl__verify_test_structures
[end TDA_009]
INFO (TSV-900): verify_test_structures processing has started Mon Apr 9 19:15:41
2018 [end TSV_900]
------------------- verify_test_structures Process Preview ---------------------
apply constraints ...................................... constraints=yes
Effort level ........................................... effort=low
Print 1 message per source of clock race ............... limitcisource=yes
Print 1 Message per capture of clock race .............. limitcicapture=yes
Check for mutually exclusive gating logic (MEG) ........ megraces=yes
Use raise message severity attributes if they exist .... raisemsgsev=no
159
Reporting options ...................................... report[option]=yes/no
Process Preview ...................................... preview=yes
Circuit Statistics ................................... circuit=yes
Message Summary ...................................... summary=yes
Specific Messages .................................... specific=yes
Tests Status ......................................... status=no
Output File Names and Size ........................... filestats=yes
Display messages for cloaked objects ................. cloakedobj=no
Rerun verify_test_structures test(s) ................... reruntests=no
Use message suppression attributes if they exist ....... suppressmsg=no
Test selected .......................................... test[option]=yes/no
Analyze test clock control of memory elements ........ testclockusage=yes
Analyze three-state drivers for contention ........... tsdcontention=yes
Analyze feedback loops and keeper devices ............ feedback=yes
Analyze clock choppers ............................... clockchopper=yes
Analyze flip-flop and latch scan characteristics ..... latchusage=yes
Analyze explicit fixed value latches ................. explicitfvlatch=yes
Analyze potential clock signal races ................. clocksignalraces=yes
Analyze internal scan chains ......................... internalscanchains=yes
--------------------Circuit Statistics--------------------
INFO (TLM-055): Design Summary
--------------
Hierarchical Model: Flattened Model:
8,006 Blocks 5,615 Blocks
22,965 Pins 5,615 Nodes
12,689 Nets
Primary Inputs: Primary Outputs:
13 Input Only 11 Output Only
9 Input/Output 9 Input/Output
22 Total Inputs 20 Total Outputs
Tied Nets: Dotted Nets:
78 Tied to 0 0 Two-State
257 Tied to 1 9 Three-State
0 Tied to X 9 Total Dotted Nets
335 Total Tied Nets
Selected Primitive Functions:
0 Clock Chopper (CHOP) primitives
0 RAMs
0 ROMs
0 TSDs
160
0 Resistors
0 Transistors
0 Latches
207 Flip-Flops
[end TLM_055]
Test Function Pin Information for Test Mode: FULLSCAN
-------------------------------------------
2 SC (System Clock) Pins
0 AC (A Shift Clock) Pins
0 BC (B Shift Clock) Pins
0 PC (P Shift Clock) Pins
1 EC (E Shift Clock) Pins
0 OSC (Oscillator) Pins
0 TI (Test Inhibit) Pins
5 SE (Scan Enable) Pins
0 CI (Clock Isolation) Pins
0 OI (Output Inhibit) Pins
4 SI (Scan Input) Pins
4 SO (Scan Output) Pins
Pin Index Type Test Function Pin Name / Net Name
--------- ---- ---------------------------------- -------------------
3 PI -SC reset / reset
0 PI -EC -SC clk / clk
22 PI* +SE scan_enable / scan_enable
27 PI* ZSE scan_out_1 / scan_out_1
28 PI* ZSE scan_out_2 / scan_out_2
29 PI* ZSE scan_out_3 / scan_out_3
30 PI* ZSE scan_out_4 / scan_out_4
23 PI* SI scan_in_1 / scan_in_1
24 PI* SI1 scan_in_2 / scan_in_2
25 PI* SI2 scan_in_3 / scan_in_3
26 PI* SI3 scan_in_4 / scan_in_4
27 PO* SO scan_out_1 / scan_out_1
28 PO* SO1 scan_out_2 / scan_out_2
29 PO* SO2 scan_out_3 / scan_out_3
30 PO* SO3 scan_out_4 / scan_out_4
* pin is Input/Output
161
Analyze test clocks' control of memory elements
Analyze test clocks' control of memory elements process has completed.
CPU time = 0:00:00.01 Elapsed time = 0:00:00.12
Analyze three-state drivers for contention
Analyze three-state drivers for contention process has completed.
CPU time = 0:00:00.01 Elapsed time = 0:00:00.17
Analyze feedback loops and keeper devices
Analyze feedback loops and keeper devices process has completed.
CPU time = 0:00:00.00 Elapsed time = 0:00:00.08
Analyze clock choppers
Analyze clock choppers process has completed.
CPU time = 0:00:00.00 Elapsed time = 0:00:00.11
Analyze flip-flop and latch scan characteristics
INFO (TSV-068): The length of the longest scan chain is 52 bit positions, which is
101% of the average scan chain length 52 (based on 207 total scan chain bits and 4
valid scan chains). [end TSV_068]
INFO (TSV-378): Scan chain beginning at 'pin scan_in_1' and ending at 'pin
scan_out_1' is controllable and observable. The length of the scan chain is 52 bit
positions. [end TSV_378]
INFO (TSV-378): Scan chain beginning at 'pin scan_in_2' and ending at 'pin
scan_out_2' is controllable and observable. The length of the scan chain is 52 bit
positions. [end TSV_378]
INFO (TSV-378): Scan chain beginning at 'pin scan_in_3' and ending at 'pin
scan_out_3' is controllable and observable. The length of the scan chain is 52 bit
positions. [end TSV_378]
INFO (TSV-378): Scan chain beginning at 'pin scan_in_4' and ending at 'pin
scan_out_4' is controllable and observable. The length of the scan chain is 51 bit
positions. [end TSV_378]
INFO (TSV-567): There are 4 controllable scan chains fed by Scan In (SI) primary
inputs. [end TSV_567]
INFO (TSV-568): There are 4 observable scan chains feeding to Scan Out (SO)
primary outputs. [end TSV_568]
INFO (TSV-569): There are 0 controllable scan chains fed by on-product Pattern
Generator(s). [end TSV_569]
INFO (TSV-570): There are 0 observable scan chains feeding to on-product Multiple-
Input Signature Register (MISRs). [end TSV_570]
162
Analyze flip-flop and latch scan characteristics process has completed.
CPU time = 0:00:00.01 Elapsed time = 0:00:00.19
Analyze explicit fixed value latches
Analyze explicit fixed value latches process has completed.
CPU time = 0:00:00.00 Elapsed time = 0:00:00.09
Analyze potential clock signal races
Check for mutually exclusive gating logic (MEG)
Analyze potential clock signal races process has completed.
CPU time = 0:00:00.01 Elapsed time = 0:00:00.22
Analyze internal scan chains
Analyze channel inputs for validity process has completed.
CPU time = 0:00:00.01 Elapsed time = 0:00:00.10
--------------------File Information----------------------
57344
/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output/tbdata/TSVmessageF
ile.FULLSCAN
INFO (TSV-908): verify_test_structures processing complete. [end TSV_908]
INFO (TDA-001): Maximum Memory used during the run and Cumulative Time in
hours:minutes:seconds:
Total Memory = 8,022,464 bytes
CPU Time = 0:00:00.08
Elapsed Time = 0:00:01.65 [end TDA_001]
Date Ended: Monday Apr 09 19:15:43 2018 PDT
-------------------------------------------------------------------------------
* Message Summary *
-------------------------------------------------------------------------------
Count Number First Instance of Message Text
------- ------ ------------------------------
163
INFO Messages...
1 INFO (TLM-055): Design Summary
1 INFO (TSV-068): The length of the longest scan chain is 52 bit positions, which
is 101% of the average scan chain length 52 (based on 207 total scan chain bits and 4
valid scan chains).
4 INFO (TSV-378): Scan chain beginning at 'pin scan_in_1' and ending at 'pin
scan_out_1' is controllable and observable. The length of the scan chain is 52 bit
positions.
1 INFO (TSV-567): There are 4 controllable scan chains fed by Scan In (SI)
primary inputs.
1 INFO (TSV-568): There are 4 observable scan chains feeding to Scan Out (SO)
primary outputs.
1 INFO (TSV-569): There are 0 controllable scan chains fed by on-product Pattern
Generator(s).
1 INFO (TSV-570): There are 0 observable scan chains feeding to on-product
Multiple-Input Signature Register (MISRs).
1 INFO (TSV-900): verify_test_structures processing has started Mon Apr 9
19:15:41 2018
1 INFO (TSV-908): verify_test_structures processing complete.
For a detailed explanation of a message and a suggested user response execute
'msgHelp <message id>'. For example: msgHelp TDA-009
-------------------------------------------------------------------------------
164
Appendix M: Modus Build Fault Model Output Log
//====================UART Top Module=======================//
Starting Command: build_faultmodel
INFO (TDA-005): Command Line Invocation:
build_faultmodel stepid=cl__build_faultmodel_040918191558-377913000
includedynamic=no
workdir=/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output [end
TDA_005]
-------------------------------------------------------------------------------------------
Cadence(R) Modus(TM) Test Solution, Version 17.10-p006_1, built May 22 2017
(linux26_64)
-------------------------------------------------------------------------------------------
INFO (TDA-007): Job Information:
Date Started: Monday Apr 09 19:15:58 2018 PDT
Host machine is dcd159, x86_64 running Linux 2.6.32-696.6.3.el6.x86_64.
This job is process number 4283.
[end TDA_007]
INFO (TDA-009): Keywords/Values information.
(keywords marked with '*' have program generated values,
keywords marked with '+' were specified to default.)
WORKDIR=/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output
LOGFILE=/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output/testresult
s/logs/log_build_faultmodel_040918191558-377913000
includedynamic=no
stepid=cl__build_faultmodel
[end TDA_009]
INFO (TFM-099): Build Fault Model started. [end TFM_099]
INFO (TFM-102): Creating faultModel file
/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output/tbdata/faultModel.
[end TFM_102]
Global Ignored Static Fault Count 256
Global Ignored Dynamic Fault Count 0
Global Statistics
165
-- ATCov -- ------------- Global Faults ----------------------
Global Total Tested Possibly Redundant Untested
Total Static 0.00 6950 0 0 0 6950
Collapsed Static 0.00 4815 0 0 0 4815
PI Static 0.00 44 0 0 0 44
PO Static 0.00 40 0 0 0 40
Total Dynamic 0
Parametric
IDDq 0.00 6950 0 6950
INFO (TFM-103): Creating faultStatus file
/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output/tbdata/faultStatus.
[end TFM_103]
Testmode Statistics: FULLSCAN
---- ATCov ---- ---------------- Testmode Faults -------------------- -----------
------- Global Faults --------------------
Testmode Global Total Tested Possibly Redundant Untested
Total Tested Possibly Redundant Untested
Total Static 0.00 0.00 6950 0 0 0 6950 6950 0
0 0 6950
Collapsed Static 0.00 0.00 4815 0 0 0 4815 4815
0 0 0 4815
PI Static 0.00 0.00 44 0 0 0 44 44 0
0 0 44
PO Static 0.00 0.00 40 0 0 0 40 40 0
0 0 40
Total Dynamic 0
Parametric
IDDq 0.00 0.00 6950 0 6950 6950 0
6950
Path 0.00 0.00 0 0 0 0 0
0
166
INFO (TFM-704): Maximum Global Test Coverage Statistics:
%Active #Faults #Active #Inactive
Total Static 100.00 6950 6950 0
Collapsed Static 100.00 4815 4815 0
PI Static 100.00 44 44 0
PO Static 100.00 40 40 0
Total Dynamic 0
Parametric
There are 1 test mode(s) defined:
FULLSCAN
[end TFM_704]
INFO (TFM-109): Build Fault Model has completed with highest level severity
message of INFO. [end TFM_109]
INFO (TDA-001): Maximum Memory used during the run and Cumulative Time in
hours:minutes:seconds:
Total Memory = 10,037,104 bytes
CPU Time = 0:00:00.01
Elapsed Time = 0:00:00.47 [end TDA_001]
Date Ended: Monday Apr 09 19:15:58 2018 PDT
-------------------------------------------------------------------------------
* Message Summary *
-------------------------------------------------------------------------------
Count Number First Instance of Message Text
------- ------ ------------------------------
INFO Messages...
1 INFO (TFM-099): Build Fault Model started.
1 INFO (TFM-102): Creating faultModel file
/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output/tbdata/faultModel.
1 INFO (TFM-103): Creating faultStatus file
/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output/tbdata/faultStatus.
167
1 INFO (TFM-109): Build Fault Model has completed with highest level severity
message of INFO.
1 INFO (TFM-704): Maximum Global Test Coverage Statistics:
For a detailed explanation of a message and a suggested user response execute
'msgHelp <message id>'. For example: msgHelp TDA-009
-------------------------------------------------------------------------------
168
Appendix N: Modus Create Scan Chain Test Output Log
//====================UART Top Module=======================//
Starting Command: create_scanchain_tests
INFO (TDA-005): Command Line Invocation:
create_scanchain_tests stepid=cl__create_scanchain_tests_040918191700-
289757000 experiment=uart_top_atpg testmode=FULLSCAN
workdir=/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output [end
TDA_005]
-------------------------------------------------------------------------------------------
Cadence(R) Modus(TM) Test Solution, Version 17.10-p006_1, built May 22 2017
(linux26_64)
-------------------------------------------------------------------------------------------
INFO (TDA-007): Job Information:
Date Started: Monday Apr 09 19:17:00 2018 PDT
Host machine is dcd159, x86_64 running Linux 2.6.32-696.6.3.el6.x86_64.
This job is process number 4293.
[end TDA_007]
INFO (TDA-009): Keywords/Values information.
(keywords marked with '*' have program generated values,
keywords marked with '+' were specified to default.)
WORKDIR=/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output
TESTMODE=FULLSCAN
EXPERIMENT=uart_top_atpg
LOGFILE=/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output/testresult
s/logs/log_create_scanchain_tests_FULLSCAN_uart_top_atpg_040918191700-
289757000
stepid=cl__create_scanchain_tests
[end TDA_009]
**********************************************************************
****************
Coverage Definitions:
#Faults : Number of Active Faults (observable).
#Tested : Number of Active Faults marked tested.
#Possibly: Number of Active Faults marked possibly tested
169
(good value is 0 or 1; fault value is X).
#Redund : Number of Active Faults untestable due to redundancy.
#Untested: Number of Active Faults untested.
%TCov (%Test Coverage) : #Tested / #Faults
%ATCov (%Adjusted TCov) : #Tested / (#Faults-#Redund)
**********************************************************************
****************
**********************************************************************
****************
Testmode Statistics: FULLSCAN
#Faults #Tested #Possibly #Redund #Untested %TCov %ATCov
Total Static 6950 0 0 0 6950 0.00 0.00
Global Statistics
#Faults #Tested #Possibly #Redund #Untested %TCov %ATCov
Total Static 6950 0 0 0 6950 0.00 0.00
**********************************************************************
****************
**********************************************************************
***************************************
INFO (TTC-110): Starting Scan Test generation [end
TTC_110]
INFO (TDA-220): --- Tests --- Faults ---- ATCov ---- -- Faults -- - Elapsed
Time - [end TDA_220]
INFO (TDA-220): Sim. Eff. Detected Tmode Global Untested
[end TDA_220]
INFO (TDA-220): 4 4 1814 26.10% 26.10% 5136 00:01.01
[end TDA_220]
INFO (TTC-110): Ending Scan Test generation [end
TTC_110]
**********************************************************************
***************************************
**********************************************************************
****************
Testmode Statistics: FULLSCAN
#Faults #Tested #Possibly #Redund #Untested %TCov %ATCov
Total Static 6950 1818 0 0 5132 26.16 26.16
Global Statistics
170
#Faults #Tested #Possibly #Redund #Untested %TCov %ATCov
Total Static 6950 1818 0 0 5132 26.16 26.16
**********************************************************************
****************
----Final Pattern Statistics----
Test Section Type # Test Sequences
----------------------------------------------------------
Scan 4
----------------------------------------------------------
Total 4
(I) File(s) generated (bytes and name):
73728
/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output/tbdata/faultStatus.FU
LLSCAN.uart_top_atpg
5953
/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output/tbdata/TBDbin.FUL
LSCAN.uart_top_atpg
INFO (TDA-001): Maximum Memory used during the run and Cumulative Time in
hours:minutes:seconds:
Total Memory = 6,823,488 bytes
CPU Time = 0:00:00.11
Elapsed Time = 0:00:01.22 [end TDA_001]
Date Ended: Monday Apr 09 19:17:01 2018 PDT
-------------------------------------------------------------------------------
* Message Summary *
-------------------------------------------------------------------------------
Count Number First Instance of Message Text
------- ------ ------------------------------
INFO Messages...
3 INFO (TDA-220): --- Tests --- Faults ---- ATCov ---- -- Faults -- -
Elapsed Time -
2 INFO (TTC-110): Starting Scan Test generation
171
For a detailed explanation of a message and a suggested user response execute
'msgHelp <message id>'. For example: msgHelp TDA-009
-------------------------------------------------------------------------------
172
Appendix O: Modus Create Logic Test Output Log
//====================UART Top Module=======================//
Starting Command: create_logic_tests
INFO (TDA-005): Command Line Invocation:
create_logic_tests stepid=cl__create_logic_tests_040918191752-642154000
append=yes experiment=uart_top_atpg testmode=FULLSCAN
workdir=/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output [end
TDA_005]
-------------------------------------------------------------------------------------------
Cadence(R) Modus(TM) Test Solution, Version 17.10-p006_1, built May 22 2017
(linux26_64)
-------------------------------------------------------------------------------------------
INFO (TDA-007): Job Information:
Date Started: Monday Apr 09 19:17:52 2018 PDT
Host machine is dcd159, x86_64 running Linux 2.6.32-696.6.3.el6.x86_64.
This job is process number 4315.
[end TDA_007]
INFO (TDA-009): Keywords/Values information.
(keywords marked with '*' have program generated values,
keywords marked with '+' were specified to default.)
WORKDIR=/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output
TESTMODE=FULLSCAN
EXPERIMENT=uart_top_atpg
LOGFILE=/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output/testresult
s/logs/log_create_logic_tests_FULLSCAN_uart_top_atpg_040918191752-642154000
append=yes
stepid=cl__create_logic_tests
[end TDA_009]
**********************************************************************
****************
Coverage Definitions:
#Faults : Number of Active Faults (observable).
#Tested : Number of Active Faults marked tested.
#Possibly: Number of Active Faults marked possibly tested
173
(good value is 0 or 1; fault value is X).
#Redund : Number of Active Faults untestable due to redundancy.
#Untested: Number of Active Faults untested.
%TCov (%Test Coverage) : #Tested / #Faults
%ATCov (%Adjusted TCov) : #Tested / (#Faults-#Redund)
**********************************************************************
****************
**********************************************************************
****************
Testmode Statistics: FULLSCAN
#Faults #Tested #Possibly #Redund #Untested %TCov %ATCov
Total Static 6950 1818 0 0 5132 26.16 26.16
Global Statistics
#Faults #Tested #Possibly #Redund #Untested %TCov %ATCov
Total Static 6950 1818 0 0 5132 26.16 26.16
**********************************************************************
****************
**********************************************************************
***************************************
INFO (TTC-110): Starting Reset/Set Test Generation [end
TTC_110]
INFO (TDA-220): --- Tests --- Faults ---- ATCov ---- -- Faults -- - Elapsed
Time - [end TDA_220]
INFO (TDA-220): Sim. Eff. Detected Tmode Global Untested
[end TDA_220]
INFO (TDA-220): 1 1 85 27.38% 27.38% 5047 00:00.97
[end TDA_220]
INFO (TDA-220): 2 2 1 27.40% 27.40% 5046 00:00.97
[end TDA_220]
INFO (TTC-110): Ending Reset/Set Test Generation [end
TTC_110]
**********************************************************************
***************************************
**********************************************************************
***************************************
INFO (TTC-110): Starting Static Logic Test generation [end
TTC_110]
INFO (TDA-220): --- Tests --- Faults ---- ATCov ---- -- Faults -- - Elapsed
Time - [end TDA_220]
174
INFO (TDA-220): Sim. Eff. Detected Tmode Global Untested
[end TDA_220]
INFO (TDA-220): 16 16 4520 92.43% 92.43% 518 00:01.41
[end TDA_220]
INFO (TDA-220): 32 32 348 97.44% 97.44% 170 00:01.42
[end TDA_220]
INFO (TDA-220): 40 40 148 99.57% 99.57% 22 00:01.42
[end TDA_220]
INFO (TDA-220): 42 40 0 99.57% 99.57% 22 00:01.47
[end TDA_220]
INFO (TDA-220): 48 46 12 99.74% 99.74% 10 00:01.53
[end TDA_220]
INFO (TDA-221): 48 46 0 99.74% 99.74% 10 00:01.53
[end TDA_221]
INFO (TTC-110): Ending Static Logic Test generation [end
TTC_110]
**********************************************************************
***************************************
**********************************************************************
****************
Testmode Statistics: FULLSCAN
#Faults #Tested #Possibly #Redund #Untested %TCov %ATCov
Total Static 6950 6932 8 0 10 99.74 99.74
Global Statistics
#Faults #Tested #Possibly #Redund #Untested %TCov %ATCov
Total Static 6950 6932 8 0 10 99.74 99.74
**********************************************************************
****************
----Final Pattern Statistics----
Test Section Type # Test Sequences
----------------------------------------------------------
Scan 4
Logic 48
----------------------------------------------------------
Total 52
(I) File(s) generated (bytes and name):
175
86016
/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output/tbdata/faultStatus.FU
LLSCAN.uart_top_atpg
118042
/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output/tbdata/TBDbin.FUL
LSCAN.uart_top_atpg
INFO (TDA-001): Maximum Memory used during the run and Cumulative Time in
hours:minutes:seconds:
Total Memory = 7,951,664 bytes
CPU Time = 0:00:00.29
Elapsed Time = 0:00:02.81 [end TDA_001]
Date Ended: Monday Apr 09 19:17:55 2018 PDT
-------------------------------------------------------------------------------
* Message Summary *
-------------------------------------------------------------------------------
Count Number First Instance of Message Text
------- ------ ------------------------------
INFO Messages...
11 INFO (TDA-220): --- Tests --- Faults ---- ATCov ---- -- Faults -- -
Elapsed Time -
1 INFO (TDA-221): 48 46 0 99.74% 99.74% 10
00:01.53
4 INFO (TTC-110): Starting Reset/Set Test Generation
For a detailed explanation of a message and a suggested user response execute
'msgHelp <message id>'. For example: msgHelp TDA-009
-------------------------------------------------------------------------------
176
Appendix P: Modus’ Write Vectors Output Log
//====================UART Top Module=======================//
Starting Command: write_vectors
INFO (TDA-005): Command Line Invocation:
write_vectors stepid=cl__write_vectors_040918191844-745672000
language=verilog inexperiment=uart_top_atpg testmode=FULLSCAN testrange=all
exportdir=./testresults/verilog_parallel scanformat=parallel
workdir=/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output [end
TDA_005]
-------------------------------------------------------------------------------------------
Cadence(R) Modus(TM) Test Solution, Version 17.10-p006_1, built May 22 2017
(linux26_64)
-------------------------------------------------------------------------------------------
INFO (TDA-007): Job Information:
Date Started: Monday Apr 09 19:18:44 2018 PDT
Host machine is dcd159, x86_64 running Linux 2.6.32-696.6.3.el6.x86_64.
This job is process number 4357.
[end TDA_007]
INFO (TDA-009): Keywords/Values information.
(keywords marked with '*' have program generated values,
keywords marked with '+' were specified to default.)
WORKDIR=/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output
TESTMODE=FULLSCAN
INEXPERIMENT=uart_top_atpg
EXPORTDIR=./testresults/verilog_parallel
testrange=all
LOGFILE=/home/users6/aem61296/Grad_Project/dft_design/et_atpg_output/testresult
s/logs/log_write_vectors_FULLSCAN_uart_top_atpg_040918191844-745672000
stepid=cl__write_vectors
scanformat=parallel
+ language=verilog
[end TDA_009]
INFO (TVE-001): Verilog write vectors started. [end TVE_001]
INFO (TVE-103): There was no specified TEST offset for this clock 'pin clk'. A
default clock offset of 8.000000 ns will be used. [end TVE_103]
177
INFO (TVE-103): There was no specified SCAN offset for this clock 'pin clk'. A
default clock offset of 16.000000 ns will be used. [end TVE_103]
INFO (TVE-103): There was no specified TEST offset for this clock 'pin reset'. A
default clock offset of 8.000000 ns will be used. [end TVE_103]
INFO (TVE-004): Reading test section 1.1. Test section type equals scan. [end
TVE_004]
INFO (TVE-003): Verilog write vectors output file will be:
./testresults/verilog_parallel/cycleMap.FULLSCAN.uart_top_atpg. [end TVE_003]
INFO (TVE-003): Verilog write vectors output file will be:
./testresults/verilog_parallel/VER.FULLSCAN.uart_top_atpg.data.scan.ex1.ts1.verilog.
[end TVE_003]
INFO (TVE-005): Created 267 total cycles, of which 7 are test cycles, 260 are scan
cycles, 0 are dynamic timed cycles and 0 are dynamic cycles that are not timed. [end
TVE_005]
INFO (TVE-008): Created 828 total measures, of which 0 are PO measures and 828 are
SO (Scan Out) measures. [end TVE_008]
INFO (TVE-004): Reading test section 1.2. Test section type equals logic. [end
TVE_004]
INFO (TVE-003): Verilog write vectors output file will be:
./testresults/verilog_parallel/VER.FULLSCAN.uart_top_atpg.data.logic.ex1.ts2.verilog
. [end TVE_003]
INFO (TVE-005): Created 2701 total cycles, of which 153 are test cycles, 2548 are
scan cycles, 0 are dynamic timed cycles and 0 are dynamic cycles that are not timed.
[end TVE_005]
INFO (TVE-008): Created 10746 total measures, of which 810 are PO measures and
9936 are SO (Scan Out) measures. [end TVE_008]
INFO (TVE-003): Verilog write vectors output file will be:
./testresults/verilog_parallel/VER.FULLSCAN.uart_top_atpg.mainsim.v. [end
TVE_003]
INFO (TVE-050): TEST SEQUENCE COVERAGE SUMMARY REPORT
Test | Global | Global | Global | Global | Global | Global | Sequence |
Overlapped | Total |
Sequence | Static | Static | Static | Dynamic | Dynamic | Dynamic | Cycle |
Cycle | Cycle |
| Total | Delta | Adjusted | Total | Delta | Adjusted | Count | Count
| Count |
| Coverage | Coverage | Total | Coverage | Coverage | Total | |
| |
| | | Coverage | | | Coverage | | | |
1.1.1.1.1 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 1 | 0 |
1 |
1.1.1.2.1 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 106 | 53 |
107 |
1.1.1.3.1 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 53 | 53 |
160 |
178
1.1.1.3.2 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 0.00 | 53 | 53 |
213 |
1.1.1.3.3 | 26.10 | 0.00 | 26.10 | 0.00 | 0.00 | 0.00 | 54 | 0 |
267 |
1.2.1.1.1 | 26.10 | 0.00 | 26.10 | 0.00 | 0.00 | 0.00 | 1 | 0 |
268 |
1.2.1.2.1 | 27.32 | 1.22 | 27.32 | 0.00 | 0.00 | 0.00 | 107 | 53 |
375 |
1.2.1.3.1 | 27.34 | 0.01 | 27.34 | 0.00 | 0.00 | 0.00 | 54 | 53 |
429 |
1.2.1.4.1 | 30.42 | 3.08 | 30.42 | 0.00 | 0.00 | 0.00 | 55 | 53 |
484 |
1.2.1.4.2 | 32.82 | 2.40 | 32.82 | 0.00 | 0.00 | 0.00 | 55 | 53 |
539 |
1.2.1.4.3 | 45.91 | 13.09 | 45.91 | 0.00 | 0.00 | 0.00 | 55 | 53 |
594 |
1.2.1.4.4 | 46.94 | 1.02 | 46.94 | 0.00 | 0.00 | 0.00 | 55 | 53 |
649 |
1.2.1.4.5 | 48.03 | 1.09 | 48.03 | 0.00 | 0.00 | 0.00 | 55 | 53 |
704 |
1.2.1.4.6 | 54.79 | 6.76 | 54.79 | 0.00 | 0.00 | 0.00 | 55 | 53 |
759 |
1.2.1.4.7 | 55.71 | 0.92 | 55.71 | 0.00 | 0.00 | 0.00 | 55 | 53 |
814 |
1.2.1.4.8 | 57.77 | 2.06 | 57.77 | 0.00 | 0.00 | 0.00 | 55 | 53 |
869 |
1.2.1.4.9 | 58.96 | 1.19 | 58.96 | 0.00 | 0.00 | 0.00 | 55 | 53 |
924 |
1.2.1.4.10 | 60.36 | 1.40 | 60.36 | 0.00 | 0.00 | 0.00 | 55 | 53 |
979 |
1.2.1.4.11 | 65.04 | 4.68 | 65.04 | 0.00 | 0.00 | 0.00 | 55 | 53 |
1034 |
1.2.1.4.12 | 65.61 | 0.58 | 65.61 | 0.00 | 0.00 | 0.00 | 55 | 53 |
1089 |
1.2.1.4.13 | 66.22 | 0.60 | 66.22 | 0.00 | 0.00 | 0.00 | 55 | 53 |
1144 |
1.2.1.4.14 | 67.01 | 0.79 | 67.01 | 0.00 | 0.00 | 0.00 | 55 | 53 |
1199 |
1.2.1.4.15 | 90.73 | 23.73 | 90.73 | 0.00 | 0.00 | 0.00 | 55 | 53 |
1254 |
1.2.1.4.16 | 92.37 | 1.64 | 92.37 | 0.00 | 0.00 | 0.00 | 55 | 53 |
1309 |
1.2.1.5.1 | 92.69 | 0.32 | 92.69 | 0.00 | 0.00 | 0.00 | 55 | 53 |
1364 |
1.2.1.5.2 | 92.89 | 0.20 | 92.89 | 0.00 | 0.00 | 0.00 | 55 | 53 |
1419 |
179
1.2.1.5.3 | 93.48 | 0.59 | 93.48 | 0.00 | 0.00 | 0.00 | 55 | 53 |
1474 |
1.2.1.5.4 | 94.09 | 0.60 | 94.09 | 0.00 | 0.00 | 0.00 | 55 | 53 |
1529 |
1.2.1.5.5 | 94.30 | 0.22 | 94.30 | 0.00 | 0.00 | 0.00 | 55 | 53 |
1584 |
1.2.1.5.6 | 94.45 | 0.14 | 94.45 | 0.00 | 0.00 | 0.00 | 55 | 53 |
1639 |
1.2.1.5.7 | 94.88 | 0.43 | 94.88 | 0.00 | 0.00 | 0.00 | 55 | 53 |
1694 |
1.2.1.5.8 | 95.17 | 0.29 | 95.17 | 0.00 | 0.00 | 0.00 | 55 | 53 |
1749 |
1.2.1.5.9 | 95.38 | 0.22 | 95.38 | 0.00 | 0.00 | 0.00 | 55 | 53 |
1804 |
1.2.1.5.10 | 95.63 | 0.24 | 95.63 | 0.00 | 0.00 | 0.00 | 55 | 53 |
1859 |
1.2.1.5.11 | 95.97 | 0.35 | 95.97 | 0.00 | 0.00 | 0.00 | 55 | 53 |
1914 |
1.2.1.5.12 | 96.13 | 0.16 | 96.13 | 0.00 | 0.00 | 0.00 | 55 | 53 |
1969 |
1.2.1.5.13 | 96.39 | 0.26 | 96.39 | 0.00 | 0.00 | 0.00 | 55 | 53 |
2024 |
1.2.1.5.14 | 96.95 | 0.56 | 96.95 | 0.00 | 0.00 | 0.00 | 55 | 53 |
2079 |
1.2.1.5.15 | 97.04 | 0.09 | 97.04 | 0.00 | 0.00 | 0.00 | 55 | 53 |
2134 |
1.2.1.5.16 | 97.38 | 0.35 | 97.38 | 0.00 | 0.00 | 0.00 | 55 | 53 |
2189 |
1.2.1.6.1 | 97.47 | 0.09 | 97.47 | 0.00 | 0.00 | 0.00 | 56 | 53 |
2245 |
1.2.1.6.2 | 97.86 | 0.39 | 97.86 | 0.00 | 0.00 | 0.00 | 56 | 53 |
2301 |
1.2.1.6.3 | 98.33 | 0.47 | 98.33 | 0.00 | 0.00 | 0.00 | 56 | 53 |
2357 |
1.2.1.6.4 | 98.45 | 0.12 | 98.45 | 0.00 | 0.00 | 0.00 | 56 | 53 |
2413 |
1.2.1.6.5 | 98.76 | 0.32 | 98.76 | 0.00 | 0.00 | 0.00 | 56 | 53 |
2469 |
1.2.1.6.6 | 99.02 | 0.26 | 99.02 | 0.00 | 0.00 | 0.00 | 56 | 53 |
2525 |
1.2.1.6.7 | 99.25 | 0.23 | 99.25 | 0.00 | 0.00 | 0.00 | 56 | 53 |
2581 |
1.2.1.6.8 | 99.51 | 0.26 | 99.51 | 0.00 | 0.00 | 0.00 | 56 | 53 |
2637 |
1.2.1.7.1 | 99.53 | 0.01 | 99.53 | 0.00 | 0.00 | 0.00 | 55 | 53 |
2692 |
180
1.2.1.7.2 | 99.55 | 0.03 | 99.55 | 0.00 | 0.00 | 0.00 | 55 | 53 |
2747 |
1.2.1.7.3 | 99.58 | 0.03 | 99.58 | 0.00 | 0.00 | 0.00 | 55 | 53 |
2802 |
1.2.1.7.4 | 99.63 | 0.04 | 99.63 | 0.00 | 0.00 | 0.00 | 55 | 53 |
2857 |
1.2.1.7.5 | 99.67 | 0.04 | 99.67 | 0.00 | 0.00 | 0.00 | 55 | 53 |
2912 |
1.2.1.7.6 | 99.68 | 0.01 | 99.68 | 0.00 | 0.00 | 0.00 | 56 | 0 |
2968 |
[end TVE_050]
INFO (TDA-001): Maximum Memory used during the run and Cumulative Time in
hours:minutes:seconds:
Total Memory = 7,850,000 bytes
CPU Time = 0:00:00.09
Elapsed Time = 0:00:01.76 [end TDA_001]
Date Ended: Monday Apr 09 19:18:46 2018 PDT
INFO (TVE-002): Verilog write vectors has completed. [end TVE_002]
-------------------------------------------------------------------------------
* Message Summary *
-------------------------------------------------------------------------------
Count Number First Instance of Message Text
------- ------ ------------------------------
INFO Messages...
1 INFO (TVE-001): Verilog write vectors started.
1 INFO (TVE-002): Verilog write vectors has completed.
4 INFO (TVE-003): Verilog write vectors output file will be:
./testresults/verilog_parallel/cycleMap.FULLSCAN.uart_top_atpg.
2 INFO (TVE-004): Reading test section 1.1. Test section type equals scan.
2 INFO (TVE-005): Created 267 total cycles, of which 7 are test cycles, 260 are
scan cycles, 0 are dynamic timed cycles and 0 are dynamic cycles that are not timed.
2 INFO (TVE-008): Created 828 total measures, of which 0 are PO measures and
828 are SO (Scan Out) measures.
1 INFO (TVE-050): TEST SEQUENCE COVERAGE SUMMARY REPORT
3 INFO (TVE-103): There was no specified TEST offset for this clock 'pin clk'. A
default clock offset of 8.000000 ns will be used.
181
Appendix Q: Incisive Irun ATPG Simulation Run Script
//====================UART Top Module=======================//
export WORKDIR=./
irun \
-gui \
+access+rwc \
+ncstatus \
+nc64bit \
+TESTFILE1=$WORKDIR/testresults/verilog_parallel/VER.FULLSCAN.uart_top_at
pg.data.scan.ex1.ts1.verilog \
+TESTFILE2=$WORKDIR/testresults/verilog_parallel/VER.FULLSCAN.uart_top_at
pg.data.logic.ex1.ts2.verilog \
+HEARTBEAT \
+FAILSET \
+nctimescale+1ns/1ps \
+ncoverride_timescale \
+ncseq_udp_delay+2ps \
+libext+.v+.V+.z+.Z+.gz \
+nclibdirname+$WORKDIR/Inca_libs_18_40_48 \
-l $WORKDIR/ncverilog_FULLSCAN.log \
-v ./../../library_open_source/NangateOpenCellLibrary.v \
$WORKDIR/uart_top.test_netlist.v \
$WORKDIR/testresults/verilog_parallel/VER.FULLSCAN.uart_top_atpg.mainsim.v
182
Appendix R: Incisive Irun Test Vector Reduced Log
//====================UART Top Module=======================//
irun(64): 15.20-p001: (c) Copyright 1995-2016 Cadence Design Systems, Inc.
TOOL: irun(64) 15.20-p001: Started on Apr 09, 2018 at 19:32:10 PDT
irun
-gui
+access+rwc
+ncstatus
+nc64bit
+TESTFILE1=.//testresults/verilog_parallel/VER.FULLSCAN.uart_top_atpg.d
ata.scan.ex1.ts1.verilog
+TESTFILE2=.//testresults/verilog_parallel/VER.FULLSCAN.uart_top_atpg.d
ata.logic.ex1.ts2.verilog
+HEARTBEAT
+FAILSET
+nctimescale+1ns/1ps
+ncoverride_timescale
+ncseq_udp_delay+2ps
+libext+.v+.V+.z+.Z+.gz
+nclibdirname+.//Inca_libs_18_40_48
-l .//ncverilog_FULLSCAN.log
-v ./../../library_open_source/NangateOpenCellLibrary.v
.//uart_top.test_netlist.v
.//testresults/verilog_parallel/VER.FULLSCAN.uart_top_atpg.mainsim.v
User defined plus("+") options:
+TESTFILE1=.//testresults/verilog_parallel/VER.FULLSCAN.uart_top_atpg.d
ata.scan.ex1.ts1.verilog
+TESTFILE2=.//testresults/verilog_parallel/VER.FULLSCAN.uart_top_atpg.d
ata.logic.ex1.ts2.verilog
+HEARTBEAT
+FAILSET
irun: *W,LEXTSF: Unknown suffix (.z) found in a libext option. The suffixes will be
mapped to Verilog.
irun: *W,LEXTSF: Unknown suffix (.Z) found in a libext option. The suffixes will be
mapped to Verilog.
irun: *W,LEXTSF: Unknown suffix (.gz) found in a libext option. The suffixes will be
mapped to Verilog.
file: ./../../library_open_source/NangateOpenCellLibrary.v
Loading native compiled code: .................... Done
Design hierarchy summary:
Instances Unique
Modules: 744 35
183
UDPs: 207 2
Primitives: 4651 5
Registers: 284 81
Scalar wires: 2550 -
Expanded wires: 8 1
Initial blocks: 1 1
Cont. assignments: 213 10
Pseudo assignments: 8 8
Simulation timescale: 1ps
Writing initial simulation snapshot:
worklib.et_atpg_output_FULLSCAN_uart_top_atpg:v
ncelab: Memory Usage - 49.0M program + 35.9M data = 85.0M total (Peak 90.0M)
ncelab: CPU Usage - 0.1s system + 0.2s user = 0.2s total (1.2s, 17.9% cpu)
-------------------------------------
Relinquished control to SimVision...
ncsim>
ncsim> source /opt/cadence/INCISIVE152/tools/inca/files/ncsimrc
ncsim> database -open waves -into waves.shm -default
Created default SHM database waves
ncsim> probe -create -shm
et_atpg_output_FULLSCAN_uart_top_atpg.uart_top_inst.read_parallel_data_out
et_atpg_output_FULLSCAN_uart_top_atpg.uart_top_inst.clk
et_atpg_output_FULLSCAN_uart_top_atpg.uart_top_inst.receiver_empty_flag
et_atpg_output_FULLSCAN_uart_top_atpg.uart_top_inst.receiver_read_enable
et_atpg_output_FULLSCAN_uart_top_atpg.uart_top_inst.receiver_serial_data
et_atpg_output_FULLSCAN_uart_top_atpg.uart_top_inst.reset
et_atpg_output_FULLSCAN_uart_top_atpg.uart_top_inst.scan_enable
et_atpg_output_FULLSCAN_uart_top_atpg.uart_top_inst.scan_in_1
et_atpg_output_FULLSCAN_uart_top_atpg.uart_top_inst.scan_in_2
et_atpg_output_FULLSCAN_uart_top_atpg.uart_top_inst.scan_in_3
et_atpg_output_FULLSCAN_uart_top_atpg.uart_top_inst.scan_in_4
et_atpg_output_FULLSCAN_uart_top_atpg.uart_top_inst.scan_out_1
et_atpg_output_FULLSCAN_uart_top_atpg.uart_top_inst.scan_out_2
et_atpg_output_FULLSCAN_uart_top_atpg.uart_top_inst.scan_out_3
et_atpg_output_FULLSCAN_uart_top_atpg.uart_top_inst.scan_out_4
et_atpg_output_FULLSCAN_uart_top_atpg.uart_top_inst.transmitter_full_flag
et_atpg_output_FULLSCAN_uart_top_atpg.uart_top_inst.transmitter_serial_data
et_atpg_output_FULLSCAN_uart_top_atpg.uart_top_inst.transmitter_write_enable
et_atpg_output_FULLSCAN_uart_top_atpg.uart_top_inst.write_parallel_data_in
Created probe 1
ncsim> run
INFO (TVE-200): Reading vector file:
.//testresults/verilog_parallel/VER.FULLSCAN.uart_top_atpg.data.scan.ex1.ts1.verilog
184
INFO (TVE-202): Simulating pattern 1.1.1.1.1.1 at Time 0.00 ps.
INFO (TVE-202): Simulating pattern 1.1.1.2.1.1 at Time 80000.00 ps.
INFO (TVE-202): Simulating pattern 1.1.1.2.1.2 at Time 240000.00 ps.
INFO (TVE-202): Simulating pattern 1.1.1.3.1.1 at Time 240000.00 ps.
INFO (TVE-202): Simulating pattern 1.1.1.3.1.2 at Time 400000.00 ps.
INFO (TVE-202): Simulating pattern 1.1.1.3.2.1 at Time 400000.00 ps.
INFO (TVE-202): Simulating pattern 1.1.1.3.2.2 at Time 560000.00 ps.
INFO (TVE-202): Simulating pattern 1.1.1.3.3.1 at Time 560000.00 ps.
INFO (TVE-202): Simulating pattern 1.1.1.3.3.2 at Time 720000.00 ps.
INFO (TVE-201): Simulation complete on vector file:
.//testresults/verilog_parallel/VER.FULLSCAN.uart_top_atpg.data.scan.ex1.ts1.verilog
INFO (TVE-206): The number of good comparing vectors for the file just completed is
828
INFO (TVE-205): The number of miscomparing vectors for the file just completed is 0
INFO (TVE-200): Reading vector file:
.//testresults/verilog_parallel/VER.FULLSCAN.uart_top_atpg.data.logic.ex1.ts2.verilo
g
INFO (TVE-202): Simulating pattern 1.2.1.1.1.1 at Time 960000.00 ps.
INFO (TVE-202): Simulating pattern 1.2.1.2.1.1 at Time 1040000.00 ps.
INFO (TVE-202): Simulating pattern 1.2.1.2.1.2 at Time 1200000.00 ps.
INFO (TVE-202): Simulating pattern 1.2.1.2.1.3 at Time 1200000.00 ps.
………………….
INFO (TVE-202): Simulating pattern 1.2.1.7.6.3 at Time 16720000.00 ps.
INFO (TVE-202): Simulating pattern 1.2.1.7.6.4 at Time 16720000.00 ps.
INFO (TVE-202): Simulating pattern 1.2.1.7.6.5 at Time 16800000.00 ps.
185
INFO (TVE-202): Simulating pattern 1.2.1.7.6.6 at Time 16880000.00 ps.
INFO (TVE-201): Simulation complete on vector file:
.//testresults/verilog_parallel/VER.FULLSCAN.uart_top_atpg.data.logic.ex1.ts2.verilo
g
INFO (TVE-206): The number of good comparing vectors for the file just completed is
10746
INFO (TVE-205): The number of miscomparing vectors for the file just completed is 0
INFO (TVE-204): The total number of good comparing vectors is 11574
INFO (TVE-203): The total number of miscomparing vectors is 0
Simulation complete via $finish(1) at time 17120 NS + 0
./testresults/verilog_parallel/VER.FULLSCAN.uart_top_atpg.mainsim.v:658
$finish;
186
Appendix S: Cadence Sample test_cell Syntax
/*********************************************************************
*********************
Module : DFFS_X1
Cell Description : Pos.edge D-Flip-Flop with active low set, and drive strength
X1
**********************************************************************
*********************/
cell (DFFS_X1) {
drive_strength : 1;
ff ("IQ" , "IQN") {
next_state : "D";
clocked_on : "CK";
preset : "!SN";
}
test_cell() {
ff ("IQ" , "IQN") {
next_state : "D";
clocked_on : "CK";
preset : "!SN";
}
pin(D) {
direction : input;
}
pin(SN) {
direction : input
}
pin(CK) {
direction: input;
}
pin(Q) {
direction: output;
function: "IQ";
}
pin(QN) {
direction: output;
function: "IQN";
}
}
187
Appendix T: Cadence Sample Power Consumption Report
legacy_genus:/> report power
============================================================
Generated by: Genus(TM) Synthesis Solution 17.23-s026_1
Generated on: Nov 27 2018 11:03:30 am
Module: uart_top
Technology library: NangateOpenCellLibrary revision 1.0
Operating conditions: typical
Interconnect mode: global
Area mode: physical library
============================================================
Leakage Dynamic Total
Instance Cells Power(nW) Power(nW)
------------------------------------------------------
uart_top 737 36893.775 338703.788 375597.562
fifo_transmit 273 14459.944 123113.359 137573.304
fifo_receiv 266 14269.443 114077.592 128347.036
uart_trans 89 3468.311 31218.175 34686.486
uart_receiv 81 3276.097 27938.159 31214.256
baud_gen 27 1405.615 11684.295 13089.910
