California State University, Northridge Design For

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

Augusto Euler Mannucci

December 2018

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

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.

iii

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

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

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

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

vii

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

viii

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

ABSTRACT

IMPLEMENTATION, VERIFICATION AND SIMULATION OF BOUNDARY SCAN ARCHITECTURE

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.

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.

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.

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.

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.

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

5 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.

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]

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.

• 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]

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

10 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

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].

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].

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]

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-

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].

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].

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,

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]

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].

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]

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]

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

23 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]

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]

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]

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].

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

28 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

29 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].

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].

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

32 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].

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

34 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]

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

36 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.

푆푦푠푡푒푚퐶푙표푐푘 (1) 16∗퐵푎푢푑푅푎푡푒

퐵푎푢푑푅푎푡푒 = 38400 (2)

푆푦푠푡푒푚퐶푙표푐푘 = 100푀퐻푧 (3)

100푀퐻푧 = 163 (4) 16∗38400

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.

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

38 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

39 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.

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.

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.

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]

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.

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.

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.

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.

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

48 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

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.

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

51 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

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

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.

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.

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/

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

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

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.

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

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

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.

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 /

• 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:

• 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

• 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

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__[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:

• syn_generic

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

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 /designs/uart_top

• Set_attribute dft_max_length_of_scan_chains /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:

• 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

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.

Figure 4.4 - Genus' Top Level Post Scan Schematic View

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.

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

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

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:

• 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

74 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

75 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

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

77 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.

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= \ techlib= \ cell=

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= \ 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 “” test_function =

The 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

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= \

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.

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= \

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

the faults that were generated. The Fault Model output log can be seen in Appendix

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= \ experiment= \

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= \ experiment= \

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.

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= \ 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= \ testmode= \ language= \

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

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

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

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

88 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.

Figure 4.15 - Test Vector Simulation Waveform Viewer

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

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

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.

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/

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

//======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@(*)

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;

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

//======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;

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

onefive_next=onefive_reg+1; // increament 16 times to arrive to mid stop_state bit endcase end endmodule

100

//======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

101 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

102

//======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),

103

.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

104

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";

105

$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

106

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'"

107 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

108 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 -fall 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

109

#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

110 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

111 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

112

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

113

Number of registers that pass DFT rules: 207 Percentage of total registers that are scannable: 100%

114

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;

115 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;

116

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;

117 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;

118

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:

119

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

120

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

121

======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 ======

122

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] bit 2 baud_gen/sum_reg_reg[1] bit 3 baud_gen/sum_reg_reg[2] bit 4 baud_gen/sum_reg_reg[3] bit 5 baud_gen/sum_reg_reg[4] bit 6 baud_gen/sum_reg_reg[5] bit 7 baud_gen/sum_reg_reg[6] bit 8 baud_gen/sum_reg_reg[7] bit 9 fifo_receiv/counter_full_or_empty_reg[0] bit 10 fifo_receiv/counter_full_or_empty_reg[1] bit 11 fifo_receiv/counter_full_or_empty_reg[2] bit 12 fifo_receiv/counter_full_or_empty_reg[3] bit 13 fifo_receiv/data_out_reg[0] bit 14 fifo_receiv/data_out_reg[1] bit 15 fifo_receiv/data_out_reg[2] bit 16 fifo_receiv/data_out_reg[3] bit 17 fifo_receiv/data_out_reg[4] bit 18 fifo_receiv/data_out_reg[5] bit 19 fifo_receiv/data_out_reg[6] bit 20 fifo_receiv/data_out_reg[7] bit 21 fifo_receiv/fifo_mem_reg[0][0] bit 22 fifo_receiv/fifo_mem_reg[0][1] bit 23 fifo_receiv/fifo_mem_reg[0][2] bit 24 fifo_receiv/fifo_mem_reg[0][3] bit 25 fifo_receiv/fifo_mem_reg[0][4] bit 26 fifo_receiv/fifo_mem_reg[0][5] bit 27 fifo_receiv/fifo_mem_reg[0][6] bit 28 fifo_receiv/fifo_mem_reg[0][7] bit 29 fifo_receiv/fifo_mem_reg[1][0] bit 30 fifo_receiv/fifo_mem_reg[1][1] bit 31 fifo_receiv/fifo_mem_reg[1][2] bit 32 fifo_receiv/fifo_mem_reg[1][3] bit 33 fifo_receiv/fifo_mem_reg[1][4] bit 34 fifo_receiv/fifo_mem_reg[1][5]

123

bit 35 fifo_receiv/fifo_mem_reg[1][6] bit 36 fifo_receiv/fifo_mem_reg[1][7] bit 37 fifo_receiv/fifo_mem_reg[2][0] bit 38 fifo_receiv/fifo_mem_reg[2][1] bit 39 fifo_receiv/fifo_mem_reg[2][2] bit 40 fifo_receiv/fifo_mem_reg[2][3] bit 41 fifo_receiv/fifo_mem_reg[2][4] bit 42 fifo_receiv/fifo_mem_reg[2][5] bit 43 fifo_receiv/fifo_mem_reg[2][6] bit 44 fifo_receiv/fifo_mem_reg[2][7] bit 45 fifo_receiv/fifo_mem_reg[3][0] bit 46 fifo_receiv/fifo_mem_reg[3][1] bit 47 fifo_receiv/fifo_mem_reg[3][2] bit 48 fifo_receiv/fifo_mem_reg[3][3] bit 49 fifo_receiv/fifo_mem_reg[3][4] bit 50 fifo_receiv/fifo_mem_reg[3][5] bit 51 fifo_receiv/fifo_mem_reg[3][6] bit 52 fifo_receiv/fifo_mem_reg[3][7] ------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] bit 2 fifo_receiv/fifo_mem_reg[4][1] bit 3 fifo_receiv/fifo_mem_reg[4][2] bit 4 fifo_receiv/fifo_mem_reg[4][3] bit 5 fifo_receiv/fifo_mem_reg[4][4] bit 6 fifo_receiv/fifo_mem_reg[4][5] bit 7 fifo_receiv/fifo_mem_reg[4][6] bit 8 fifo_receiv/fifo_mem_reg[4][7] bit 9 fifo_receiv/fifo_mem_reg[5][0] bit 10 fifo_receiv/fifo_mem_reg[5][1] bit 11 fifo_receiv/fifo_mem_reg[5][2] bit 12 fifo_receiv/fifo_mem_reg[5][3] bit 13 fifo_receiv/fifo_mem_reg[5][4] bit 14 fifo_receiv/fifo_mem_reg[5][5] bit 15 fifo_receiv/fifo_mem_reg[5][6] bit 16 fifo_receiv/fifo_mem_reg[5][7] bit 17 fifo_receiv/fifo_mem_reg[6][0] bit 18 fifo_receiv/fifo_mem_reg[6][1] bit 19 fifo_receiv/fifo_mem_reg[6][2] bit 20 fifo_receiv/fifo_mem_reg[6][3] bit 21 fifo_receiv/fifo_mem_reg[6][4]

124

bit 22 fifo_receiv/fifo_mem_reg[6][5] bit 23 fifo_receiv/fifo_mem_reg[6][6] bit 24 fifo_receiv/fifo_mem_reg[6][7] bit 25 fifo_receiv/fifo_mem_reg[7][0] bit 26 fifo_receiv/fifo_mem_reg[7][1] bit 27 fifo_receiv/fifo_mem_reg[7][2] bit 28 fifo_receiv/fifo_mem_reg[7][3] bit 29 fifo_receiv/fifo_mem_reg[7][4] bit 30 fifo_receiv/fifo_mem_reg[7][5] bit 31 fifo_receiv/fifo_mem_reg[7][6] bit 32 fifo_receiv/fifo_mem_reg[7][7] bit 33 fifo_receiv/pointer_read_reg[0] bit 34 fifo_receiv/pointer_read_reg[1] bit 35 fifo_receiv/pointer_read_reg[2] bit 36 fifo_receiv/pointer_write_reg[0] bit 37 fifo_receiv/pointer_write_reg[1] bit 38 fifo_receiv/pointer_write_reg[2] bit 39 fifo_transmit/counter_full_or_empty_reg[0] bit 40 fifo_transmit/counter_full_or_empty_reg[1] bit 41 fifo_transmit/counter_full_or_empty_reg[2] bit 42 fifo_transmit/counter_full_or_empty_reg[3] bit 43 fifo_transmit/data_out_reg[0] bit 44 fifo_transmit/data_out_reg[1] bit 45 fifo_transmit/data_out_reg[2] bit 46 fifo_transmit/data_out_reg[3] bit 47 fifo_transmit/data_out_reg[4] bit 48 fifo_transmit/data_out_reg[5] bit 49 fifo_transmit/data_out_reg[6] bit 50 fifo_transmit/data_out_reg[7] bit 51 fifo_transmit/fifo_mem_reg[0][0] bit 52 fifo_transmit/fifo_mem_reg[0][1] ------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] bit 2 fifo_transmit/fifo_mem_reg[0][3] bit 3 fifo_transmit/fifo_mem_reg[0][4] bit 4 fifo_transmit/fifo_mem_reg[0][5] bit 5 fifo_transmit/fifo_mem_reg[0][6] bit 6 fifo_transmit/fifo_mem_reg[0][7] bit 7 fifo_transmit/fifo_mem_reg[1][0] bit 8 fifo_transmit/fifo_mem_reg[1][1]

125

bit 9 fifo_transmit/fifo_mem_reg[1][2] bit 10 fifo_transmit/fifo_mem_reg[1][3] bit 11 fifo_transmit/fifo_mem_reg[1][4] bit 12 fifo_transmit/fifo_mem_reg[1][5] bit 13 fifo_transmit/fifo_mem_reg[1][6] bit 14 fifo_transmit/fifo_mem_reg[1][7] bit 15 fifo_transmit/fifo_mem_reg[2][0] bit 16 fifo_transmit/fifo_mem_reg[2][1] bit 17 fifo_transmit/fifo_mem_reg[2][2] bit 18 fifo_transmit/fifo_mem_reg[2][3] bit 19 fifo_transmit/fifo_mem_reg[2][4] bit 20 fifo_transmit/fifo_mem_reg[2][5] bit 21 fifo_transmit/fifo_mem_reg[2][6] bit 22 fifo_transmit/fifo_mem_reg[2][7] bit 23 fifo_transmit/fifo_mem_reg[3][0] bit 24 fifo_transmit/fifo_mem_reg[3][1] bit 25 fifo_transmit/fifo_mem_reg[3][2] bit 26 fifo_transmit/fifo_mem_reg[3][3] bit 27 fifo_transmit/fifo_mem_reg[3][4] bit 28 fifo_transmit/fifo_mem_reg[3][5] bit 29 fifo_transmit/fifo_mem_reg[3][6] bit 30 fifo_transmit/fifo_mem_reg[3][7] bit 31 fifo_transmit/fifo_mem_reg[4][0] bit 32 fifo_transmit/fifo_mem_reg[4][1] bit 33 fifo_transmit/fifo_mem_reg[4][2] bit 34 fifo_transmit/fifo_mem_reg[4][3] bit 35 fifo_transmit/fifo_mem_reg[4][4] bit 36 fifo_transmit/fifo_mem_reg[4][5] bit 37 fifo_transmit/fifo_mem_reg[4][6] bit 38 fifo_transmit/fifo_mem_reg[4][7] bit 39 fifo_transmit/fifo_mem_reg[5][0] bit 40 fifo_transmit/fifo_mem_reg[5][1] bit 41 fifo_transmit/fifo_mem_reg[5][2] bit 42 fifo_transmit/fifo_mem_reg[5][3] bit 43 fifo_transmit/fifo_mem_reg[5][4] bit 44 fifo_transmit/fifo_mem_reg[5][5] bit 45 fifo_transmit/fifo_mem_reg[5][6] bit 46 fifo_transmit/fifo_mem_reg[5][7] bit 47 fifo_transmit/fifo_mem_reg[6][0] bit 48 fifo_transmit/fifo_mem_reg[6][1] bit 49 fifo_transmit/fifo_mem_reg[6][2] bit 50 fifo_transmit/fifo_mem_reg[6][3] bit 51 fifo_transmit/fifo_mem_reg[6][4] bit 52 fifo_transmit/fifo_mem_reg[6][5] ------Chain 4: chain4

126 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] bit 2 fifo_transmit/fifo_mem_reg[6][7] bit 3 fifo_transmit/fifo_mem_reg[7][0] bit 4 fifo_transmit/fifo_mem_reg[7][1] bit 5 fifo_transmit/fifo_mem_reg[7][2] bit 6 fifo_transmit/fifo_mem_reg[7][3] bit 7 fifo_transmit/fifo_mem_reg[7][4] bit 8 fifo_transmit/fifo_mem_reg[7][5] bit 9 fifo_transmit/fifo_mem_reg[7][6] bit 10 fifo_transmit/fifo_mem_reg[7][7] bit 11 fifo_transmit/pointer_read_reg[0] bit 12 fifo_transmit/pointer_read_reg[1] bit 13 fifo_transmit/pointer_read_reg[2] bit 14 fifo_transmit/pointer_write_reg[0] bit 15 fifo_transmit/pointer_write_reg[1] bit 16 fifo_transmit/pointer_write_reg[2] bit 17 uart_receiv/assemble_reg_reg[0] bit 18 uart_receiv/assemble_reg_reg[1] bit 19 uart_receiv/assemble_reg_reg[2] bit 20 uart_receiv/assemble_reg_reg[3] bit 21 uart_receiv/assemble_reg_reg[4] bit 22 uart_receiv/assemble_reg_reg[5] bit 23 uart_receiv/assemble_reg_reg[6] bit 24 uart_receiv/assemble_reg_reg[7] bit 25 uart_receiv/onefive_reg_reg[0] bit 26 uart_receiv/onefive_reg_reg[1] bit 27 uart_receiv/onefive_reg_reg[2] bit 28 uart_receiv/onefive_reg_reg[3] bit 29 uart_receiv/seven_reg_reg[0] bit 30 uart_receiv/seven_reg_reg[1] bit 31 uart_receiv/seven_reg_reg[2] bit 32 uart_receiv/state_reg_reg[0] bit 33 uart_receiv/state_reg_reg[1] bit 34 uart_trans/disassemble_reg_reg[0] bit 35 uart_trans/disassemble_reg_reg[1] bit 36 uart_trans/disassemble_reg_reg[2] bit 37 uart_trans/disassemble_reg_reg[3] bit 38 uart_trans/disassemble_reg_reg[4] bit 39 uart_trans/disassemble_reg_reg[5] bit 40 uart_trans/disassemble_reg_reg[6] bit 41 uart_trans/disassemble_reg_reg[7]

127 bit 42 uart_trans/onefive_reg_reg[0] bit 43 uart_trans/onefive_reg_reg[1] bit 44 uart_trans/onefive_reg_reg[2] bit 45 uart_trans/onefive_reg_reg[3] bit 46 uart_trans/seven_reg_reg[0] bit 47 uart_trans/seven_reg_reg[1] bit 48 uart_trans/seven_reg_reg[2] bit 49 uart_trans/state_reg_reg[0] bit 50 uart_trans/state_reg_reg[1] bit 51 uart_trans/transmit_data_state_out_reg_reg

128

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 \

129

#------# 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 \

130

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"

131

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

132

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

133

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...

134

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 '. For example: msgHelp TDA-009

------

135

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

136

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

137

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.

138

For a detailed explanation of a message and a suggested user response execute 'msgHelp '. For example: msgHelp TDA-009

------

139

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

140

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

141

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

142

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

143

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

144

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

145

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

146

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

147

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

148

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

149

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

150

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

151

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

152

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

153

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

154

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

155

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

156

------* 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 '. For example: msgHelp TDA-009

------

157

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

158

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

159

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 is Input/Output

160

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]

161

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 ------

162

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 '. For example: msgHelp TDA-009

------

163

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

164

-- 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

165

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.

166

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 '. For example: msgHelp TDA-009

------

167

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

168

(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

169

#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

170

For a detailed explanation of a message and a suggested user response execute 'msgHelp '. For example: msgHelp TDA-009

------

171

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]

172

#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]

173

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):

174

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 '. For example: msgHelp TDA-009

------

175

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]

176

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 |

177

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 |

178

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 |

179

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.

180

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

181

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

182

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

183

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.

184

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;

185

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"; } }

186

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

187