Boundary Scan Process Guide

Software Version 8.2007_3

August 2007

© 1999-2007 Mentor Graphics Corporation

All rights reserved.

This document contains information that is proprietary to Mentor Graphics Corporation. The original recipient of this
document may duplicate this document in whole or in part for internal business purposes only, provided that this entire
notice appears in all copies. In duplicating any part of this document, the recipient agrees to make every reasonable
effort to prevent the unauthorized use and distribution of the proprietary information.
This document is for information and instruction purposes. Mentor Graphics reserves the right to make
changes in specifications and other information contained in this publication without prior notice, and the
reader should, in all cases, consult Mentor Graphics to determine whether any changes have been
made.

The terms and conditions governing the sale and licensing of Mentor Graphics products are set forth in
written agreements between Mentor Graphics and its customers. No representation or other affirmation
of fact contained in this publication shall be deemed to be a warranty or give rise to any liability of Mentor
Graphics whatsoever.

MENTOR GRAPHICS MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE.

MENTOR GRAPHICS SHALL NOT BE LIABLE FOR ANY INCIDENTAL, INDIRECT, SPECIAL, OR
CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT LIMITED TO LOST PROFITS)
ARISING OUT OF OR RELATED TO THIS PUBLICATION OR THE INFORMATION CONTAINED IN IT,
EVEN IF MENTOR GRAPHICS CORPORATION HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.

RESTRICTED RIGHTS LEGEND 03/97

U.S. Government Restricted Rights. The SOFTWARE and documentation have been developed entirely
at private expense and are commercial computer software provided with restricted rights. Use,
duplication or disclosure by the U.S. Government or a U.S. Government subcontractor is subject to the
restrictions set forth in the license agreement provided with the software pursuant to DFARS 227.7202-
3(a) or as set forth in subparagraph (c)(1) and (2) of the Commercial Computer Software - Restricted
Rights clause at FAR 52.227-19, as applicable.

Contractor/manufacturer is:
Mentor Graphics Corporation
8005 S.W. Boeckman Road, Wilsonville, Oregon 97070-7777.
Telephone: 503.685.7000
Toll-Free Telephone: 800.592.2210
Website: www.mentor.com
SupportNet: supportnet.mentor.com/
Send Feedback on Documentation: supportnet.mentor.com/user/feedback_form.cfm

TRADEMARKS: The trademarks, logos and service marks ("Marks") used herein are the property of
Mentor Graphics Corporation or other third parties. No one is permitted to use these Marks without the
prior written consent of Mentor Graphics or the respective third-party owner. The use herein of a third-
party Mark is not an attempt to indicate Mentor Graphics as a source of a product, but is intended to
indicate a product from, or associated with, a particular third party. A current list of Mentor Graphics’
trademarks may be viewed at: www.mentor.com/terms_conditions/trademarks.cfm.
 Table of Contents

Chapter 1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Understanding Boundary Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Benefits of Boundary Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Boundary Scan Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Boundary Scan Insertion With BSDArchitect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Top-Down Design Flows Using BSDArchitect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
BSDArchitect Design Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
BSDArchitect User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Control Panel Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Command Line Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Running Batch Mode Using Dofiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Generating a Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Running UNIX Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Interrupting the Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Exiting the Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Resetting the State of BSDArchitect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Chapter 2
External Boundary Scan Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
BSDArchitect External Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
BSDArchitect Output Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
BSDArchitect Output Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Design Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Logic Type of Entity Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Escaped Identifiers for Verilog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Handling Tri-State and Bidirectional Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Recommended Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Preparing for Boundary Scan Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Boundary Scan Example Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Creating the HDL Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Creating the Package Mapping File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Invoking BSDArchitect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Setting Up the Boundary Scan Specification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Boundary Scan Insertion Using BSDArchitect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
The Example Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Running BSDArchitect in an External Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Chapter 3
Internal Boundary Scan Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Understanding BSDArchitect Internal Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Boundary Scan Process Guide, V8.2007_3 3

August 2007
 Table of Contents

Inputs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Building I/O Pad Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Invoking the BSDArchitect Internal Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Example Boundary Scan Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Reporting Circuit Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Adding I/O Pads to Ports Without Pads. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Reporting Pad Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Adding Boundary Scan Cells. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Boundary Scan Cell Placement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Adding Boundary Scan Cells to Control Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Boundary Scan Cell Placement for Control Ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Loading Pin Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Making Top-Level Port Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Placing and Connecting External Registers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Sharing Functional Pins With TDO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Uniquification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Unsupported Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Chapter 4
Boundary Scan Customizations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Creating Customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Technology Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Technology Mapping Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Design Rules Checking for Technology Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Defining Boundary Scan Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Defining Boundary Scan Cells With Built-In Pads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Defining I/O Pads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Using a Pin Mapping File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Pin Map File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Pin Map File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Pin Mapping Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Using User-Defined Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Connecting Internal Scan Circuitry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Adding Dummy Scan Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Specifying the Scan Architecture and Testing Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Specifying the Internal Scan Chain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Defining the Scan Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Combining Multiple Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Chapter 5
Output Testing and Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Understanding BSDArchitect Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
HDL Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Top-Level Interface Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
HDL Test Bench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
BSDL Description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

4 Boundary Scan Process Guide, V8.2007_3

August 2007
Table of Contents

Synthesis Script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Parametric Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
ATPG Setup Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Using BSDArchitect in a BSDL Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Inserting Boundary Scan Circuitry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Creating Output Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Verifying the HDL Boundary Scan Circuitry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Verifying the Gate-Level Boundary Scan Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Troubleshooting the Test Bench Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Boundary Scan Test Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
JTAG Logic Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Parametric Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Appendix A
Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Online Command Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Mentor Graphics Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Examples and Solutions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Appendix B
Cell Type Assignments for Bidirectional Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Understanding Cell Type Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Cell Type Correspondence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Index
Third-Party Information
End-User License Agreement

Boundary Scan Process Guide, V8.2007_3 5

August 2007
 List of Examples

Example 3-1. Internal Boundary Scan Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Example 3-2. Internal Boundary Scan Output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Example 3-3. Boundary Scan Cell Placement on Single Data Port. . . . . . . . . . . . . . . . . . . . 54
Example 3-4. Boundary Scan Cell Placement on Multiple Data Ports . . . . . . . . . . . . . . . . . 55
Example 3-5. No Top-Level Signal for a Tri-State Control Port . . . . . . . . . . . . . . . . . . . . . 56
Example 3-6. Single Control Signal Without Inverter/Buffer . . . . . . . . . . . . . . . . . . . . . . . . 57
Example 3-7. Single Control Signal With Inverter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Example 3-8. Multiple Control Signals Without Inverter/Buffer . . . . . . . . . . . . . . . . . . . . . 58
Example 3-9. Multiple Control Signals With Inverter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Example 3-10. Design Core Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Example 3-11. Resulting Design Core. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Example 3-12. Pin Sharing Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6 Boundary Scan Process Guide, V8.2007_3

August 2007
 List of Figures

Figure 1-1. Boundary Scan Chips on Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Figure 1-2. Boundary Scan Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Figure 1-3. State Diagram of TAP Controller Circuitry . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Figure 1-4. Control Panel Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figure 1-5. Command Line Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figure 2-1. BSDArchitect External Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 2-2. Boundary Scan Output Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figure 2-3. BSDArchitect Output Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figure 2-4. “my_mod_top.v” Output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figure 2-5. “my_mod_bscan_unbuff.v” Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figure 2-6. “my_mod_bscan.v” Output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figure 2-7. Handling of Enable Signals Not Used in Core . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figure 2-8. Handling of Enable Signals Used in Core. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figure 2-9. Accessing the Enable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Figure 3-1. BSDArchitect Internal Flow Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . 47
Figure 3-2. BSDArchitect Internal Tool Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Figure 3-3. Top-Level Port Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figure 4-1. Generic BC_1 Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Figure 4-2. Generic BC_2 Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Figure 4-3. Generic BC_2_A Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Figure 4-4. Generic BC_2_A_EXT Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Figure 4-5. Generic BC_2_B Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Figure 4-6. Generic BC_3 Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Figure 4-7. Generic BC_4 Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Figure 4-8. Generic BC_5 Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Figure 4-9. Generic BC_7 Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Figure 4-10. Generic BC_7_LOW Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Figure 4-11. Generic BC_8 Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Figure 4-12. Generic BC_9 Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Figure 4-13. Generic BC_10 Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Figure 4-14. BC_X Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Figure 4-15. Basic Input Pad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Figure 4-16. Basic Output Pad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Figure 4-17. Basic Tri-State Pad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Figure 4-18. Basic Bidirectional Pad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Figure 4-19. H-Type Open Collector Output Pad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Figure 4-20. L-Type Open Collector Output Pad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Figure 4-21. Generic Differential Input and Output Pads . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Figure 4-22. Clocking Circuitry Created for Mux-DFF Architecture . . . . . . . . . . . . . . . . . . 109
Figure 4-23. Clocking Circuitry Created for Clocked Scan Architecture . . . . . . . . . . . . . . . 110

Boundary Scan Process Guide, V8.2007_3 7

August 2007
 List of Figures

Figure 4-24. Default Architecture for Testing Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Figure 4-25. Internal Scan Instruction Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Figure 4-26. Connection of Multiple Scan Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Figure 5-1. Test Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

8 Boundary Scan Process Guide, V8.2007_3

August 2007
 List of Tables

Table 3-1. Control Port Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Table 4-1. Library Attributes vs. Command Line Arguments . . . . . . . . . . . . . . . . . . . . . . . 67
Table 4-2. H-Type Open Collector Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Table 4-3. L-Type Open Collector Truth Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Table 4-4. Differential Pad Truth Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Table B-1. BC_2_* to BC_7* Cell Type Correspondence . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Boundary Scan Process Guide, V8.2007_3 9

August 2007
 List of Tables

10 Boundary Scan Process Guide, V8.2007_3

August 2007
 Chapter 1
Overview

Understanding Boundary Scan

Boundary scan, sometimes referred to as JTAG (for Joint Test Action Group, the committee
that formulated the IEEE standard 1149.1 that describes boundary scan), is a DFT technique
that facilitates the testing of printed circuit board (and MCM) interconnect circuitry and, to a
limited extent, the chips on those boards. Boundary scan test structures greatly improve board-
level testing, thus shortening the manufacturing test and diagnostics processes.

The IEEE standard for JTAG is 1149.1 and was originally published in April of 1990. The
standard was revised in 1993, and that document is commonly referred to as IEEE
1149.1a-1993. This 1993 supplement included the definitions of the TAP architecture and the
shift registers implemented within boundary scan elements, along with the new CLAMP and
HIGHZ instructions.

The next extension of the standard came in 1994, and is commonly referred to as the IEEE
1149.1b-1994, which contained the documentation on the Boundary-Scan Description
Language (BSDL).

The most recent revision to the standard occurred in 2001 and is known as IEEE 1149.1-2001.
This version of the standard included modifications to the EXTEST instruction and split the
mandatory SAMPLE/PRELOAD instructions into two separate instructions.

Benefits of Boundary Scan

As the usefulness of in-circuit test diminishes owing to the increasing popularity of surface
mount devices, boundary scan provides the same benefits, but without requiring physical access
to each electrical network. Adding boundary scan logic to your board lets you detect the vast
majority of board manufacturing process faults using boundary scan test methods. These faults
include wrong components, missing components, incorrectly oriented components, components
with stuck pins, shorts, opens, and blown wire bonds.

Although your engineering costs may increase slightly because of the additional silicon and
ports used for the boundary scan circuitry, implementing the IEEE 1149.1 standard can
dramatically reduce a design’s manufacturing costs.

Boundary Scan Overview

When used on a board, boundary scan provides access to the input and output ports of the chips
by linking them together into a long scan path. Data shifts along the scan path, starting at the

Boundary Scan Process Guide, V8.2007_3 11

August 2007
Overview
Understanding Boundary Scan

edge-connector input TDI (test data in) and ending at the edge-connector output TDO (test data
out). In between, the scan path connects all the devices on the board that contain boundary scan
circuitry. The TDO of one chip feeds the TDI of the next, all the way around the board. The
inputs, TCK (test clock) and TMS (test mode select), connect in parallel to each boundary scan
device in the scan path. With this configuration you can test board interconnections, perform a
snapshot of normal system data, or test individual chips. The TAP (test access port) controller is
a state machine that controls the operation of the boundary scan circuitry.

Boundary scan circuitry’s primary use is in board-level testing, but it can also control circuit-
level test structures, such as BIST or internal scan. By adding boundary scan circuitry to your
design, you create a standard interface for accessing and testing chips at the board level.

Figure 1-1 shows a board containing two chips with boundary scan circuitry.

Figure 1-1. Boundary Scan Chips on Board

BOARD

CHIP 1 CHIP 2

TDI

TCK TAP
TAP CIRCUIT PRIOR TO CIRCUIT PRIOR TO
CTRL BOUNDARY SCAN CTRL BOUNDARY SCAN
TMS INSERTION INSERTION

TDO

Simple Boundary Scan Architecture

This section discusses boundary scan circuitry in detail.

12 Boundary Scan Process Guide, V8.2007_3

August 2007
 Overview
Understanding Boundary Scan

Figure 1-2. Boundary Scan Architecture

Boundary Scan
Register (boundary Boundary Boundary
scan path connecting I/O Pad
Scan Cell Scan Path
boundary scan cells)

TDI INSTRUCTION
REGISTER

OPTIONAL
TMS TEST DATA
REGISTERS
Test Access Port (TAP)

TRST
TAP CONTROLLER CIRCUIT PRIOR TO
BOUNDARY SCAN

TCK
BYPASS
REGISTER

TDO
MUX

Figure 1-2 shows the general configuration of a chip after the addition of boundary scan logic.
This simple boundary scan architecture contains the following components:

• Circuit Prior to Boundary Scan — This is the application logic of the original design
before adding boundary scan logic. This logic might already contain internal scan
circuitry (or at least internal scan ports so boundary scan circuitry can connect to the
internal scan circuitry).
• Boundary Scan Cells — These contain memory elements for capturing data from the
circuit, test receivers for capturing transitions on AC pins (per IEEE 1149.6), loading
data into the circuit, or serially shifting data to the next scan cell in the path. The tool

Boundary Scan Process Guide, V8.2007_3 13

August 2007
Overview
Understanding Boundary Scan

places boundary scan cells between the internal logic and each input, bidirectional, and
2- or 3-state output pin. Boundary scan cells collectively comprise a parallel-in, parallel-
out shift register that runs along the periphery, or boundary, of the original design.
• Test Access Port (TAP) — The TAP consists of a minimum of four pins for the four
signals that make up the test bus. These signals include the test clock (TCK), the test
data input (TDI), the test data output (TDO), and the test mode selector (TMS). Also
shown is an optional asynchronous test reset (TRST).
• TAP Controller — The TAP controller is a finite state machine that controls the
operation of the instruction and test data registers. The TAP controller’s state depends
on the value of the TMS line at each clock pulse.
• Boundary Scan Register — Considered the main test data register, the boundary scan
register is a virtual shift register (consisting of the connection of the individual boundary
scan cells) that can, either serially or in parallel, load and unload input and output data
for the circuit.
• Bypass Register — The bypass register shortens the serial path between TDI and TDO
to one cell when there is no requirement to test a particular device. This shortened path
in effect bypasses the chip, allowing more efficient data shifting to other ICs in the
chain.
• Optional Test Data Registers:
o Device Identification Register — This register contains a device identification
code or programming code used to check that the board has proper chips.
o Data-Specific Registers — These registers allow access to the chip’s test support
features, such as BIST and internal scan paths.
• Instruction Register — The instruction register controls the boundary scan circuitry by
connecting a specific test data register between the TDI and TDO pins. It controls the
operation affecting the data in that register, using a predefined set of instructions. Three
instructions are mandatory, and several others are optional.
The mandatory instructions include:
o EXTEST — This instruction tests circuitry external to the ICs themselves, such as
board interconnect. EXTEST is the main test instruction for boundary scan testing.
o SAMPLE/PRELOAD — This instruction takes data from the chips’s I/O pads and
latches it in the boundary scan register (during normal board operation). The IEEE
Std. 1149.1-2001 has redefined this instruction as two separate instructions
(SAMPLE and PRELOAD).
o SAMPLE — This instruction takes data from the chip’s I/O pads and latches it in
the boundary scan register (during normal board operation).
o PRELOAD — This instruction allows the loading of data into the boundary scan
register before selecting another instruction.

14 Boundary Scan Process Guide, V8.2007_3

August 2007
 Overview
Understanding Boundary Scan

o BYPASS — This instruction enables bypassing of chips not being tested. For
example, if you only want to test one chip in a board with 20 chips in the boundary
scan chain, all chips except the chip under test would be bypassed. Consequently,
shifted data needs to go through only one extra shift to pass through each of the
chips not being tested (as opposed to the entire boundary scan register).
The optional instructions include:
o INTEST — This instruction tests a chip’s internal circuitry by applying a test vector
to, and capturing the output response from, the application logic.
o IDCODE — This instruction connects the device identification register between
TDI and TDO. The device identification register contains the device ID code, which
is normally used to determine if the chip belongs on the board.
o USERCODE — This instruction also selects the identification register, but the
information placed in that register is now user-defined and is meant to expand on the
IDCODE information.
o CLAMP — This instruction forces static 1s or 0s on selected nodes in order to
create a testable situation or block interfering signals.
o HIGHZ — This instruction forces an IC’s output and bidirectional pins into a high-
impedance state. In this condition, an in-circuit tester can test it safely without the
potential for overdrive damage.
o RUNBIST — This instruction executed the circuit’s internal BIST procedure.

TAP Controller State Machine

Figure 1-3 shows the finite state machine for the TAP controller of a IEEE 1149.1 circuit.

Boundary Scan Process Guide, V8.2007_3 15

August 2007
Overview
Understanding Boundary Scan

Figure 1-3. State Diagram of TAP Controller Circuitry

1 TEST-LOGIC
RESET INSTRUCTION
DATA REGISTER
0 REGISTER
(SCAN & BOUNDARY SCAN)
RUN-TEST/ SELECT- SELECT-
0 IDLE 1 DR-SCAN 1 1
IR-SCAN
0 0

CAPTURE-DR CAPTURE-IR
1 1
0 0
SHIFT-DR 0 SHIFT-IR 0
1 1
EXIT1-DR EXIT1-IR
1 1
0 0

PAUSE-DR 0 PAUSE-IR 0
1 1
0 0
EXIT2-DR EXIT2-IR
1 1

UPDATE-DR UPDATE-IR
0 0
1 1

The TMS signal (the value shown adjacent to each state transition) controls the state transitions.
The rising edge of the TCK clock captures the TAP controller inputs. Therefore, to avoid race
conditions, the signals whose states require the positive edge of TCK are retimed to propagate
out of the TAP controller at the negative edge of TCK.

The following example pseudocode of the TAP controller state machine illustrates when the
controller needs to retime the signals to avoid the possibility of race conditions:

always @ (negedge trstl or negedge tck)

if (trstl == 1’b0;
begin
resetl <= 1’b0;
enable <= 1’b0;
capturedr <= 1’b0;
shiftdr <=1’b0;
shiftir <=1’b0;
end
else

16 Boundary Scan Process Guide, V8.2007_3

August 2007
 Overview
Understanding Boundary Scan

begin
resetl <= reset_d;
enable <= enable_d;
capturedr <= capturedr_d;
shiftdr <= shiftdr_d;
shiftir <= shiftir_d;
end

Signals in which the event happens at the positive edge of TCK (where the TAP controller
needs to retime the signals to avoid race conditions) are as follows:

• resetl — The Test-Logic-Reset state and the resetl signal is retimed to occur at the
negative edge of TCK.
• enable — This signal is the control signal of the TDO tristate buffer. The enable signal
is retimed to occur at the negative edge of TCK since the TDO signal needs to occur at
the falling edge of TCK.
• capturedr (Capture-DR state)
• shiftdr (Shift-DR state)
• shiftir (Shift-IR state)
The states in which the event happens at the negative edge of TCK (where the TAP controller
does not need to retime the signals) are as follows:

• captureir (Capture-IR state)

• updatedr (Update-DR state)
• updateir (Update-IR state)
The following signals are derived from tap states by default, which the tool generates in the
RTL and also the logic of these signals. The signals are as follows:

clockir = ((pstate == capture_IR) || (pstate == shift_IR)) ? 1'b1 : 1'b0;

clockdr = ((pstate == capture_DR) || (pstate == shift_DR)) ? 1'b1 : 1'b0;
And if clock gating is on, the signals are as follows:

clockir = ((pstate == capture_IR) || (pstate == shift_IR)) ? tck : 1'b1;

clockdr = ((pstate == capture_DR) || (pstate == shift_DR)) ? tck : 1'b1;
This section is only an overview of boundary scan architecture. For a more comprehensive
description of the boundary scan standard, refer to IEEE Standard 1149.1-1990 “Test Access
Port and Boundary-Scan Architecture”, available through IEEE.

Boundary Scan Process Guide, V8.2007_3 17

August 2007
Overview
Understanding Boundary Scan

Boundary Scan Insertion With BSDArchitect

BSDArchitect™ is the Mentor Graphics boundary scan insertion tool. The tool creates and
interconnects RTL-level boundary scan logic compliant with the IEEE 1149.1 and 1149.1a
standards.

Features of the BSDArchitect tool:

• Instruction support — Full support of required IEEE standards 1149.1 and 1149.1a
instructions.
• Extension support — Support of base extensions to IEEE 1149.1, such as the Device
ID register.
• Compliant VHDL — Generation of VHDL ('93 standard) output that is compliant with
ModelSim® (VHDL), Synopsys' Design Compiler, and other industry synthesis tools.
• Compliant Verilog — Generation of Verilog (OVI version 2.0) that is compliant with
the ModelSim (Verilog), Synopsys' Design Compiler, and other industry synthesis tools.
• RTL-level boundary scan generation — Insertion and interconnection of boundary
scan circuitry at the RTL level, moving generation of test circuitry to earlier in the
design process.
• Customized boundary scan — Generation of default or user-customized boundary
scan architectures.
• I/O pad synthesis — Generation of generic I/O pads or technology-specific I/O pads.
• Automatic connection — Automatic connection of boundary scan to internal scan
logic.
• Test bench generation — Generation of a test bench, which allows testing of the
boundary scan logic after interconnection with the core application logic.
• Test vector generation — Generation of boundary scan test vectors in WGL or
FlexTest Table format, a test pattern format accepted by FlexTest.
• Setup file generation — Generation of ATPG setup files, for designs with generated
boundary scan circuitry controlling internal scan circuitry.
• Compliant BSDL — Production of BSDL output that is compliant with IEEE standard
1149.1b supplement of the IEEE 1149.1 specification.
• Generic element mapping — Mapping of boundary scan elements to generic boundary
scan library cells (which enhances re-targetability of the boundary scan circuitry).
• Technology-specific element mapping — Mapping of boundary scan, I/O pad, and
TAP controller elements to technology-specific library cells. Technology mapping
provides support for replacing generic boundary scan cells, I/O pads, and the TAP
controller by equivalent technology-specific cells.

18 Boundary Scan Process Guide, V8.2007_3

August 2007
 Overview
Top-Down Design Flows Using BSDArchitect

For information on using BSDArchitect in your design flow, refer to BSDArchitect Design
Flows. For detailed information on the BSDArchitect command set, refer to the BSDArchitect
Reference Manual.

Top-Down Design Flows Using BSDArchitect

For information on using BSDArchitect in an ATPG process flow, refer to “Top-Down Design
Flow with DFT” in the Scan and ATPG Process Guide.

For information on using BSDArchitect in a BIST process flow, refer to the MBISTArchitect
Process Guide and the LBISTArchitect Process Guide.

In the overall design process, the generation of boundary scan logic typically occurs after the
insertion of internal scan chains and before test pattern generation. However, because
BSDArchitect works at the RTL level, it allows you (but does not require you) to perform
boundary scan insertion earlier in the design process.

Note
It is important for you to check with your vendor early on in your design process for
specific requirements and restrictions that may affect your DFT strategies. For example,
the vendor's test equipment may only be able to handle single scan chains, have memory
limitations, or have special timing requirements that affect the way you generate scan
circuitry and test patterns.

BSDArchitect Design Flows

There are three design flows for BSDArchitect:

• External Flow
For the External flow, the boundary scan logic is added to the design externally.
BSDArchitect creates a new top-level module adding another level of hierarchy to the
design. An instance of the original design core is placed in the new module along with
the TAP controller instance. The I/O pad cells and boundary scan cells are placed
between the original design core and the new top-level ports. This flow cannot be used
for designs that contain I/O pads. For more information, refer to “External Boundary
Scan Synthesis” on page 25.

Note
The External flow was named the “default” flow in previous versions of the Boundary
Scan Process Guide and the BSDArchitect Reference Manual.

• Internal Flow

Boundary Scan Process Guide, V8.2007_3 19

August 2007
Overview
BSDArchitect User Interface

For the Internal flow, the boundary scan logic is added to the design internally. The TAP
controller instance is placed within the original top-level of the design and the boundary
scan cells are inserted between the I/O pads and the core logic. Currently, the original
design must contain I/O pads to use this flow. For more information, refer to “Internal
Boundary Scan Synthesis” on page 47.
• BSDL Flow
For the BSDL flow, the boundary scan logic is already present in the design. The
BSDArchitect tool checks the logic for compliance to the IEEE 1149.1-2001 standard
and generates patterns and the test bench. For more information, refer to “Using
BSDArchitect in a BSDL Flow” on page 119.

BSDArchitect User Interface

You can invoke BSDArchitect in either the typical command-line mode (-NOGui) or the default
GUI mode. When you invoke BSDArchitect in graphical mode, the Control Panel (Figure 1-4)
and the Command Line (Figure 1-5) windows are opened.

Control Panel Window

The BSDArchitect Control Panel window lets you setup the different aspects of your design in
order to insert boundary scan. By using the panes in the control panels, you can perform
multiple commands at once.

20 Boundary Scan Process Guide, V8.2007_3

August 2007
 Overview
BSDArchitect User Interface

Figure 1-4. Control Panel Window

Define Internal Scan Interface Boundary Scan Cell Setup
(scan clock pin, test clock name, tie-0/1 signals)
BSDArchitect Control Panel

Report
Environment
Boundary Scan Setup
Setup
IO IO Instructions...
Connect and
Define ID Scan Scan
Run
Cell Cell
Registers
(ID code, user code) Output
File Names...
I Scan Source Scan I
Internal Cell
O Cell Core module A O Report
Logic end BSCAN Status
module B
I Scan end
Scan I Save Results...
O Cell Cell O
Internal View Saved
Scan Design Files
T Interface T
D D
I O
Bypass Reset State...

Identification Register

Instruction Register Dofile...

TCK TAP
TRST TMS Controller Exit...
Define
Instruction Help
Registers
(core registers,
instructions, size) Add/Remove TAP Reset

The graphic pane, on the left half of the BSDArchitect Control Panel window, shows the
functional blocks that represent the typical relationship between a core design and its boundary
scan logic. You can click the left mouse button on an active functional block (highlighted in
yellow) in the graphic pane and BSDArchitect opens a dialog box that lets you set up the
boundary scan configuration prior to performing a synthesis run. The button pane lists the
actions most commonly used while in BSDArchitect. Click the left mouse button on a button in
the button pane and BSDArchitect performs the appropriate run control.

Command Line Window

The Command Line window in the GUI, shown in Figure 1-5, provides several ways for you to
issue commands to BSDArchitect. If you are in command-line mode, the Command Line is
simply the prompt (BSDA>). If you are in GUI mode, for those of you that are mouse oriented,

Boundary Scan Process Guide, V8.2007_3 21

August 2007
Overview
BSDArchitect User Interface

there are pulldown and popup menu items. In either case, the session and command transcript
panes provide a running log of your session.

Figure 1-5. Command Line Window

Command Line Window

<Tool_Name>
File Setup Kernel Report Windows Help
BSDA> dof bsda.do
//command: add tech cell \
inpad input \
-inputs my_pin \
-outputs my_din
-connect my_pin/pin \
my_din/din
//Analyzing Input Pad Cell
// ‘inpad’.....
// Note: Technology Cell
// ‘inpad’ successfully
// added

dofile bsda.do

BSDA> |

Pulldown Command Session

Command Transcript Transcript
Menus Line

The session transcript is the largest pane in the Command Line window, and it lists all
commands performed and tool messages. In command-line mode, by default, the session
transcripts to the shell window.

Commands follow the 3-2-1 minimum typing convention in both the command-line and GUI
modes. As a short cut (in most cases) you need only type the first three characters of the first
command word, the first two characters of the second command word, and the first character of
the third command word. In cases where the 3-2-1 rule leads to ambiguity between commands,
such as with Set Bscan Capture and Set Bscan Controller (both reducing to “set bs c”), you need
to specify the additional characters to alleviate the ambiguity. Here, the minimum typing for the
Set Bscan Capture command becomes “set bs ca,” and for the Set Bscan Controller command it
becomes “set bs co.”

You should also be aware that when you issue commands with very long argument lists, you
can use the “\” line continuation character. For example, you can specify the Add Technology
Cell command within a dofile (or at the system mode prompt) as follows:

22 Boundary Scan Process Guide, V8.2007_3

August 2007
 Overview
BSDArchitect User Interface

add technology cell vendor_pad_bidi bidirectional \

-inputs PI E D SLOWDRV \
-outputs PONF PO \
-inouts IO \
-connect PO/din D/dout E/oe IO/pin PI/local_pi PONF/open SLOWDRV/pwr \
-nonexistent TH

For more information on dofile scripts, see the “Running Batch Mode Using Dofiles”.

Running Batch Mode Using Dofiles

You can run the tool in batch mode by using a dofile to pipe commands into the application.
Dofiles let you automatically control the operations of the tool. The dofile is a text file that you
create that contains a list of application commands that you want to run, but without entering
them individually. If you have a large number of commands, or a common set of commands that
you use frequently, you can save time by placing these commands in a dofile. You can specify a
dofile at invocation by using the -Dofile switch, or by typing Dofile at the command line.

If you place all commands, including the Exit command, in a dofile, you can run the entire
session as a batch process. Once you generate a dofile, you can run it at invocation. For
example, to run the tool as a batch process using the commands contained in my_dofile.do,
enter:

shell> <mgcdft tree>/bin/bsdarchitect -dofile my_dofile.do

The following shows an example BSDArchitect dofile:

add tristate port -in IO_IN -out IO_OUT -ctrl IO_CTRL \

-Active high
add port mapping IO_OUT_t IO
add tristate port -out PAD -ctrl PAD_EN -Active high
load pin map pin_map
run
report bscan cell
save bscan -unbuffered -replace
exit

By default, if the tool encounters an error when running one of the commands in the dofile, it
stops dofile execution; however, you can turn this setting off by using the Set Dofile Abort
command

Generating a Log File

Log files provide a useful way to examine the operation of the tool, especially when you run the
tool in batch mode using a dofile. If errors occur, you can examine the log file to see exactly
what happened. The log file contains all DFT application operations and any notes, warning, or
error messages that occur during the session.

You can generate log files by using the -Logfile switch when you invoke the tool.

Boundary Scan Process Guide, V8.2007_3 23

August 2007
Overview
BSDArchitect User Interface

<mgcdft tree>/bin/bsdarchitect example_ckt -vhdl -logfile log1

Running UNIX Commands

You can run UNIX operating system commands within DFT applications by using the System
command. For example, the following command executes the UNIX operating system
command ls within a DFT application session:

BSDA> system ls

Interrupting the Session

To interrupt the invocation of a DFT product and return to the operating system, enter Control-
C. You can also use the Control-C key sequence to interrupt the current operation and return
control to the tool.

Exiting the Session

To exit a DFT application and return to the operating system, you can execute the File > Exit
menu item, click on the Exit button in the Control Panel, or enter Exit at the command line:

BSDA> exit

If you have generated circuitry that you have not saved, the tool will prompt you as to whether
or not to save the information.

Resetting the State of BSDArchitect

At times, you may find it necessary to disregard all the commands you have entered and start
over from the beginning. The Reset State command lets you do this. The effect of this command
is to reset all the command arguments and values to their default values, which is equivalent to
exiting the tool and invoking the tool again on the same design. The tool allows only one
synthesis run per session—unless you issue the Reset State command to reset the tool back to its
system defaults.

24 Boundary Scan Process Guide, V8.2007_3

August 2007
 Chapter 2
External Boundary Scan Synthesis

This chapter and outlines how to use BSDArchitect tool to synthesize and verify boundary scan
circuitry for your design using the External flow.

BSDArchitect External Flow

Figure 2-1 shows the External design flow for BSDArchitect.

Figure 2-1. BSDArchitect External Design Flow

The External design flow begins with an HDL model, which can be either a VHDL entity or
Verilog module. If you plan to insert internal scan circuitry into your design, you need to modify
the entity or module description to include the scan ports that will eventually be part of the

Boundary Scan Process Guide, V8.2007_3 25

August 2007
External Boundary Scan Synthesis
BSDArchitect Output Model

design. If your design is already synthesized and contains scan circuitry, you only need to create
an HDL entity of the top-level of your design to use as input to BSDArchitect.

If you are using custom library packages for a VHDL design, you need to supply a package
mapping file (dft.map) in your working directory that contains the packages/libraries used in the
core entity description.

You can now run BSDArchitect to create and insert boundary scan circuitry into your design.

BSDArchitect can create a number of different output types:

• A buffered or unbuffered HDL description with boundary scan inserted

<prefix>_bscan.<suffix>
• A description of the inputs and outputs for the top-level boundary scan core
entity/module <prefix>_top.<suffix>
• A buffered HDL test bench <prefix>_tb.<suffix>
• A BSDL description of the boundary scan circuitry which you can use with board
testing tools <prefix>_bscan.bsd
• ATPG setup files <prefix>.testproc and <prefix>.dofile
• FlexTest table or WGL format test vectors
You use the HDL test bench to verify that the boundary scan logic generated is correct. The test
bench contains vectors used as stimulus for the boundary scan circuitry. You can choose to have
BSDArchitect write these vectors into a separate file in FlexTest table or WGL format. You can
then use FlexTest to fault grade these vectors and utilize them as a starting point for ATPG.

Once you verify that the boundary scan circuitry is compliant, you can synthesize the VHDL or
Verilog model of the boundary scan circuitry to a gate-level model. If the circuit contains
internal scan circuitry controlled by the boundary scan circuitry, you can use BSDArchitect to
generate two ATPG setup files: a dofile, for setting up scan circuitry information, and a test
procedure file, for specifying the operation of the scan circuitry. The “Test Procedure Files”
section in the Scan and ATPG Process Guide discusses test procedure files in more detail. You
can re-use the HDL test bench to verify correct operation and IEEE compliance of the
synthesized design.

The second half of this section discusses how to use these outputs for boundary scan
verification further along in the design flow.

BSDArchitect Output Model

BSDArchitect produces a boundary scan design model in VHDL or Verilog. This model
contains a new level of hierarchy, instantiating the boundary scan circuitry and connecting it to

26 Boundary Scan Process Guide, V8.2007_3

August 2007
 External Boundary Scan Synthesis
BSDArchitect Output Model

the core design. Following boundary scan insertion, by default, the top-level module typically
contains the following components:

• Core Logic block

• Boundary Scan Register instance(s)
• TAP block
• External register (optional)
• User Code register (optional)
• I/O Buffer Block instance(s)
Figure 2-2 shows the top-level model that BSDArchitect produces.

Figure 2-2. Boundary Scan Output Model

Top-Level Module

TDI
TDO
I/O BSR Core Logic TAP TCK
Buffer
TMS
TRST

External Register User Code Register

In case of technology mapping, even if ASIC vendor boundary scan cells contain I/O pads, the
boundary scan cells are placed in the BSR instance only.

If a USERCODE instruction is added using the Set Bscan Usercode -Port command,
BSDArchitect generates another top level block for the Device Identification Register.

The tool can also generate an unbuffered top-level design (no I/O Buffer-block instances).
However, the following must be taken into account when generating an unbuffered top-level
design.

• If you add tri-state ports, the top-level unbuffered output will have interface signals for
the tri-state’s control ports.
• If you add bidirectional ports, the tool will make available their control and input signals
at the top-level.

Boundary Scan Process Guide, V8.2007_3 27

August 2007
External Boundary Scan Synthesis
BSDArchitect Output Model

• If you add differential ports, they will not be used in the top-level module and only one
corresponding signal will be made available at the top-level.
To save unbuffered outputs, use the Save Bscan command with the -Unbuffered switch. The
tool will not generate an RTL test bench or a BSDL description.

BSDArchitect Output Example

The Design
The design, example.v, is shown below:

module my_mod (CLK, D, EN1, IN_IO, OUT_IO, PAD_IN, PAD_OUT,Q);

input CLK;
input D;

input [3:0] IN_IO; // inputs on bidi port

output [3:0] OUT_IO; // outputs of bidi port

output EN1; // bidi port enable

input [1:0] PAD_IN; // bidi pin
output [1:0] PAD_OUT; // bidi pin

output Q;

// You can define a bidi by using the specparam

specify
specparam mgc_bs_port_info = "\
(PAD_IN[0]/in, PAD_OUT[0]/out, \
EN1/ctrl/active_high, PAD[0]/top) \
(PAD_IN[1]/in, PAD_OUT[1]/out, \
EN1/ctrl/active_high, PAD[1]/top) \

(IN_IO/in, OUT_IO/out, IO_CTRL/ctrl/active_high, IO/top) ";

endspecify
//
// Where mgc_bs_port_info is the attribute defining I/O or
// tri-state port information to BSD Architect
//
// Where IN_IO/in is the input signal name
//
// Where OUT_IO/out is the output signal name
//
// Where IO_CTRL/ctrl/active_high is the output control
// signal and active state
//
// Where IO/top is the top level port name
endmodule

The Pinmap File

The following example shows a pin mapping file named pinmap. For information on the
pinmap file, refer to “Using a Pin Mapping File”.

28 Boundary Scan Process Guide, V8.2007_3

August 2007
 External Boundary Scan Synthesis
BSDArchitect Output Model

--
-- Example pin map file. File name “pin_map”.
--
-- Syntax:
--
-- logical_name PINID -p pad_name -c cell_names
--
-- The command to load the pinmap file is:
--
-- load pin map pin_map
--
--
CLK clk -c BC_4 -inv;
D d_id -c BC_3;
--
// note that you only specify the out pin for BC_7
//
PAD_OUT[0] PAD_O[0] -c BC_7;
PAD_OUT[1] PAD_O[1] -c BC_1;
PAD_IN[1] PAD_I[1] -c BC_1;
EN1 VOID -c BC_2_A;
--
-- The ports for the I/O Bus IN_IO and OUT_IO are
-- added. The control for this port is an external
-- signal IO_CTRL (not in original design IO).
--
-- logical_name PINID -p pad_number -c cell_names
--
IO[0] out[0] -c BC_7;
IO[1] out[1] -c BC_1;
IN_IO[1] IN[1] -c BC_1;
IO[2] out[2] -c BC_7;
IO[3] out[3] -c BC_7;
--
--
Q DFFQ -c BC_1;
--
-- The format for specifying a differential port’s pin
--
-- ID’s. If the core port is “SUM”, the pin map will be:
--
-- SUM S1 S2 -c BC_1;
--
-- where S1 and S2 are the pin ID’s for the differential
-- port.
--
-- If a pad with no connections is desired. Use the value
-- “VOID” for both the port_name and PINID fields.
--
-- VOID VOID -p 1;
-- VOID VOID -p a2;
--

Boundary Scan Process Guide, V8.2007_3 29

August 2007
External Boundary Scan Synthesis
BSDArchitect Output Model

The Output
Figure 2-3 shows the four basic BSDArchitect output files generated by a default run

Figure 2-3. BSDArchitect Output Files.

Run Boundary
Scan Insertion

my_mod.bsd my_mod_tb.v

my_mod_top.v
my_mod_bscan.v

Figure 2-4. “my_mod_top.v” Output

30 Boundary Scan Process Guide, V8.2007_3

August 2007
 External Boundary Scan Synthesis
BSDArchitect Output Model

Figure 2-5. “my_mod_bscan_unbuff.v” Output

bsr_i1
bsr_out
TDI bsr_in po_CLK
clockdr_io po_D
intestl po_EN1
mode [0:3] my_mod_top.v po_IO_IN
EN1
CLK pi_CLK po_IO_CTRL IO_CTRL_o
D pi_D po_IO_OUT IO_OUT
pi_EN1 po_PAD_IN [0:1]
IO_IN pi_IO_IN po_PAD_OUT [0:1] PAD_OUT [1:0]
IO_CTRL_i pi_IO_CTRL po_Q Q
pi_IO_OUT
PAD_IN [1:0] pi_PAD_IN [0:1]
pi_PAD_OUT [0:1]
pi_Q
shiftdr
updatedr_io bsr_entity_0

tap_i
core_i
clockdr
CLK EN1 clock_bsr
D IO_OUT
my_mod_top.v enable TDO_enable
my_mod_top.v

IO_IN PAD_OUT [1:0] boundary_in intestl

PAD_IN [1:0] Q
tck mode [0:3]
my_mod tdi reset1
tms shiftdr
TCK
trst tdo TDO
TMS
updatedr
TRST update_bsr
updateir
tap

Boundary Scan Process Guide, V8.2007_3 31

August 2007
External Boundary Scan Synthesis
Design Issues

Figure 2-6. “my_mod_bscan.v” Output

The following sections discuss design and library issues you should understand before
proceeding with boundary scan insertion.

Design Issues
The following subsections discuss design issues and the methods for handling these issues to
achieve proper boundary scan insertion.

Logic Type of Entity Ports

You must declare all the ports in the VHDL entity to be of type std_ulogic or std_logic.

Escaped Identifiers for Verilog

BSDArchitect supports the use of Verilog escaped identifiers. BSDArchitect preserves the
name specified in the port list. Therefore, if the port list name contains an escaped identifier, the
BSDArchitect output name will also contain the escaped identifier. BSDArchitect considers
legal Verilog names with and without escaped identifiers to be unique. That is, BSDArchitect
does not equate “net1” with “\net1”.

Handling Tri-State and Bidirectional Ports

If your design contains bidirectional and/or tri-state devices, you should be aware of several
important issues:

32 Boundary Scan Process Guide, V8.2007_3

August 2007
 External Boundary Scan Synthesis
Design Issues

• Width of enables
BSDArchitect handles scalar, vector, or vector slice enables for each tri-state bus and
each bidirectional bus.
• Widths of bidirectional signal
The widths of bidirectional input and output signals must be the same. BSDArchitect
checks width constraints and reports errors when violations occur.
• Specifying tri-state and bidirectional ports
You must specify all tri-state and bidirectional enable signals. This means that for tri-
state ports, you must specify the output and control signals, and for bidirectional ports,
you must specify the input, output, and control signals. You can do so either by using the
mgc_bs_port_info attribute in VHDL or ‘specparam’ statement in Verilog, or from the
BSDArchitect session using the Add Tristate Port command. For best performance, use
the mgc_bs_port_info attribute or the specparam statement. However, to work from the
interactive BSDArchitect session, use the Add Tristate Port command.
Either method allows you to specify the input and output signals as a scalar (single port
or indexed signal), vector (buses or indexed signals), or vector slices (a range of ports or
indexed signals). You can also specify the control (enable) signal using the same
criteria, as well as its (their) active level, either “active_high” or “active_low” (the
default).
The following paragraphs provide examples of using mgc_bs_port_info in VHDL and
Verilog, and of using the Add Tristate Port command from a BSDArchitect session.
A VHDL example of the mgc_bs_port_info attribute for a bidirectional port is:
attribute mgc_bs_port_info : string;
attribute mgc_bs_port_info of example_core : entity is
"(d_i/in, d_o/out, d_ctrl/ctrl/active_high)";

A VHDL example of the mgc_bs_port_info attribute for a bidirectional port using

VHDL range indicators is:
attribute mgc_bs_port_info : string;
attribute mgc_bs_port_info of example_core : entity is
"(d_i(0 to 1)/in, d_o(0 to 1)/out, d_ctrl(1)/ctrl/active_high)";

NOTE: Using mismatched range indicators in mgc_bs_port_info will map as expected.

For example, if you used the following ‘downto’ and ‘to’ range indicators, d_i(0) is
mapped to d_o(1) as you might expect—and d_i(1) is mapped to d_o(0):
(d_i(1 downto 0)/in, d_o(0 to 1)/out, d_ctrl...)

A VHDL example for a tri-state port is:

attribute mgc_bs_port_info : string;
attribute mgc_bs_port_info of example_core : entity is
"(a_o/out, a_ctrl/ctrl/active_low)";

A VHDL example for handling multiple bidirectional or tri-state ports is:

Boundary Scan Process Guide, V8.2007_3 33

August 2007
External Boundary Scan Synthesis
Design Issues

library ieee;
use ieee.std_logic_1164.all;

entity tri is
port(data_in : in std_logic_vector(31 downto 0);
data_out : out std_logic_vector(31 downto 0);
ctrl_bus : out std_logic_vector(1 downto 0);
ctrl : out std_logic);

attribute mgc_bs_port_info : string;

attribute mgc_bs_port_info of tri : entity is \
"(data_in(31 downto 24)/in, data_out(31 downto 24)/out,\
ctrl_bus(1)/ctrl) (data_in(23 downto 16)/in,
data_out(23 downto 16)/out, ctrl_bus(0)/ctrl)
(data_in(15 downto 0)/in, data_out(15 downto 0)/out,
ctrl/ctrl/active_high)";

end tri;

architecture only of tri is

begin
end only;

Do not use quotes, ampersands, or newlines between the parentheses defining the
signals in the entity description. Line continuation characters and multiple attributes
(with same name) are not allowed in VHDL. Specify multiple ports by placing them in a
single continuous line as shown above.
Because Verilog simulators do not support user-defined attributes, you must use the
specparam method to specify tri-state and bidirectional information.
A Verilog example of the mgc_bs_port_info specparam for specifying multiple tri-state
ports is:
module aha(co,sum,c,b,a,d_i,d_o,d_c);
input a,b,c;
output sum,co;
input d_i;
output d_o, d_c;

specify
specparam mgc_bs_port_info = "(d_i/in, d_o/out, d_c/ctrl)";
endspecify

endmodule

An Add Tristate Port command example for a bidirectional port is:

add tristate port -in d_i -out d_o -ctrl d_ctrl -active high

An Add Tristate Port command example for a bidirectional port using VHDL range
indicators is:
add tristate port -in “d_in(3 downto 2)” -out “d_out(0 to 1)” -ctrl d_ctrl(1) -active high

An Add Tristate Port command example for a tri-state port is:

34 Boundary Scan Process Guide, V8.2007_3

August 2007
 External Boundary Scan Synthesis
Design Issues

add tristate port -out a_o -ctrl a_ctrl -active low

• Naming conventions
You can specify your own naming convention by entering the name in the
mgc_bs_port_info attribute. BSDArchitect adds one level of hierarchy to the design and
names the top-level tri-state or bidirectional signals to match the output port name. Use
the following syntax if you want to define a unique name for the top-level port:
<top_level_port_name>/top

For example:
attribute mgc_bs_port_info of example_core:entity is
"(d_i/in, d_o/out, d_ctrl_o/ctrl/active_high, d_out/top)";

• Types of enable signals

Control signals for designs that contain tri-state or bidirectional ports fit into one of two
categories: internally-generated or externally-supplied. The following list describes the
different categories of enable signals:
o Internally-generated control signals
If the core logic’s internal circuitry generates the control signal for a bidirectional or
tri-state output, you need to specify the control signal in two different ways: as a port
of mode “out” in the port map of the entity description and by specifying it with the
mgc_bs_port_info attribute.
o Externally-supplied control signals
There are two cases for externally-supplied control signals. In the first case (see
“Case A” that follows), the core logic does not use the enable signals that control
these tri-state and/or bidirectional ports. In the second case (see “Case B” that
follows), the core logic does use the enable signals that control these ports.
BSDArchitect handles each case differently.
• Case A (core does not use enable)
Because the internal circuitry does not use the enable, you must specify the
enable signal in the mgc_bs_port_info attribute, but not in the core logic’s entity
port map. For example, if your design has three input ports (a, b, c), one
bidirectional port (d), and two output ports (e, f), all of type std_ulogic, your
entity description should look like this:
entity example_core is port (
a: in std_ulogic;
b: in std_ulogic;
c: in std_ulogic;
d_i: in std_ulogic; --d_i and d_o are bi-dir port
d_o: out std_ulogic;

Boundary Scan Process Guide, V8.2007_3 35

August 2007
External Boundary Scan Synthesis
Design Issues

e: out std_ulogic;
f: out std_ulogic);
attribute mgc_bs_port_info : string;
attribute mgc_bs_port_info of example_core:entity is
"(d_i/in, d_o/out, d_ctrl/ctrl/active_high)";
end example_core;

In this case, when BSDArchitect processes the mgc_bs_port_info attribute in the

entity and finds an enable signal that is not in the port declaration, it adds the
signal at the top level and uses it as an enable, as shown in Figure 2-7.

Figure 2-7. Handling of Enable Signals Not Used in Core

In this case, the tool places a single boundary scan cell on the enable signal. You
can use your own naming convention for the top-level bidirectional signal name
by following the “Naming conventions” on page 35.
• Case B (core uses enable)
Because the enable signal controls the output ports as well as some of the
internal core circuitry, you should include the enable signal in the port map for
the core logic. For example, if your design has three input ports (a, b, c), a
bidirectional port (d), and two output ports (e, f), all of type std_ulogic, your
entity description should look like this:

36 Boundary Scan Process Guide, V8.2007_3

August 2007
 External Boundary Scan Synthesis
Design Issues

entity example_core is port (

a: in std_ulogic;
b: in std_ulogic;
c: in std_ulogic;
d_i: in std_ulogic; --d_i and d_o are bi-dir ports
d_ctrl_i: in std_ulogic;
d_o: out std_ulogic;
d_ctrl_o: out std_ulogic;
e: out std_ulogic;
f: out std_ulogic);
attribute mgc_bs_port_info : string;
attribute mgc_bs_port_info of example_core:entity is
"(d_i/in, d_o/out, d_ctrl_o/ctrl/active_high)";
end example_core;

You should connect d_ctrl_o to d_ctrl_i inside the core. When BSDArchitect
processes the entity and finds the enable signal in the port map, it places one
boundary scan cell on the input side (d_ctrl_i) and one boundary scan cell on the
output side (d_ctrl_o), as shown in Figure 2-8.

Figure 2-8. Handling of Enable Signals Used in Core

• Accessing core-generated enable signals at the top level

Figure 2-9shows an example of an enable signal generated by the core. As is also the
case in both Figure 2-7 and Figure 2-8, when BSDArchitect generates a bidirectional or
tri-state port within the boundary scan circuitry, the enable signal is not available as an
output at the top level. If you need to access this enable, you must connect a dummy
signal to the enable signal within the core circuitry and specify the name of the signal as
an output of the core logic in the port map.

Boundary Scan Process Guide, V8.2007_3 37

August 2007
External Boundary Scan Synthesis
Limitations

Figure 2-9. Accessing the Enable

Limitations
You should be aware of the following limitations when you use BSDArchitect:

• No testing of user-supplied instructions unless core register length is specified.

The test bench only tests user-supplied instructions when the core register length is
known. The test bench tests all other user-supplied instructions.
• No testing of INTEST and RUNBIST instructions.
The test bench does not test the INTEST or the RUNBIST instructions.
• Support for only one internal scan interconnection method.
BSDArchitect supports interconnection with internal scan circuitry, but currently there
is only one method for achieving this. If your design contains internal scan, refer to
“Connecting Internal Scan Circuitry” on page 107 for the recommended method of
connecting the internal scan circuitry with the boundary scan circuitry.
Support for only mux-DFF and clocked-scan internal scan architectures. Currently,
the tool supports only the mux-DFF and clocked-scan internal scan architectures.
• VHDL extended identifier support limitation.
Extended identifiers for VHDL are not supported at this time.
• Timing issues BSDArchitect does not handle.
You are responsible for designing the clock distribution tree and ensuring that no timing
problems arise due to clock skew. BSDArchitect itself does not check for these
problems.

38 Boundary Scan Process Guide, V8.2007_3

August 2007
 External Boundary Scan Synthesis
Limitations

• Verilog support has some limitations or differences from the standard.

There are some differences between the Verilog supported by BSDArchitect and that
defined by the standard.
Specifically, BSDArchitect does not support the following:
o Non-optional list_of_module_connections in module_instance.
For example, BSDArchitect does not allow the following syntax:
module muxed_scan_cell(D, Q, clk, S_in, S_en);
input D, clk, S_in, S_en;
output Q;
reg Q;
wire dff_d;
mux2 mux (S_in, D, S_en, dff_d);
test_scan_cell test (); // <- no module_connections in
// module_instance
always @(posedge clk)
#1 Q = dff_d;
endmodule

o Non-optional specify_output_terminal_descriptor in list_of_path_outputs.

For example, BSDArchitect will not parse the path declaration /***/ if written as
follows:
(clear *> q, nq) = (tRiseCtlQ, tFallCtlQ); /***/
(clear, preset *> q) = (tRiseCtlQ, tFallCtlQ); /***/

o Optional if-expression in edge_sensitive_path_description (non_optional).

For example, you cannot use the following syntax:
( posedge clock => ( q +: in ) ) = ( 10, 8 );

Additionally, it is a good idea to put port declarations before any other module
items. Thus, if the port declarations are first in the file, you need not worry if the
remainder of the file contains unsupported constructs or syntax.
• Adding pull-up resistors to the boundary scan ports.
The IEEE Std 1149.1-1990 and IEEE Std 1149.1a-1993 specification states that
boundary scan ports TDI, TMS, and TRST (if used) require pull-up resistors to power
up and keep these signals at known states when they are idle. BSDArchitect produces an
output VHDL file that supports this requirement. After completing synthesis and
optimization, you must manually add I/O ports that contain these pull-up resistors to the
design.
• Power-up reset circuitry.
BSDArchitect does not create power-up reset circuitry. You can initialize a simulator to
simulate the circuitry BSDArchitect creates. However, you must eventually add

Boundary Scan Process Guide, V8.2007_3 39

August 2007
External Boundary Scan Synthesis
Recommended Practices

circuitry to the test logic that controls the power-up reset of the TAP controller to avoid
bus contention and possible damage to the on-chip logic.
• Clocking for internal scan chains.
If you have a single internal scan chain that spans a design, and this design contains
various components controlled by clocks of different frequencies, you must make sure
that the clocking for your internal scan chain functions properly. BSDArchitect does not
perform this type of checking.
• Unsupported 1149.1-1990 BSDL attributes
The following 1149.1-1990 attributes, which were dropped from the 1149.1-1994 and
on standards, are not supported by BSDArchitect:
o INSTRUCTION_GUARD
o INSTRUCTION_DISABLE
o INSTRUCTION_SEQUENCE
o INSTRUCTION_USAGE
o BOUNDARY_CELLS

Recommended Practices
The following are recommended practices:

• Using TRST in the TAP (1149.1 Recommended Practice)

To ensure deterministic operation of the test logic when testing the reset TAP controller
state, you should hold TMS at 1 while TRST changes from a 0 to a 1. This makes sure
that the test logic responds predictably when the signal applied to TRST changes from 0
to 1. If rising edges occur simultaneously at TRST and TCK (when a logic 0 is applied
to TMS) a race condition occurs. This can cause the TAP controller to either remain in
the Test-Logic-Reset state or enter the Run-Test/Idle state.
• Using BSDArchitect-reserved identifiers
o Do not use the names for JTAG ports, IEEE instructions, and TAP signals as port
names in your HDL model or netlist. For a list of these names, refer to tables D-5
through D-7 in Appendix D of the BSDArchitect Reference Manual. The JTAG port
names may be used in your design only if they define ports intended for use with the
generated TAP controller.
o Do not use the BSDArchitect-generated component names for boundary scan cells,
JTAG modules, buffers, and pad cells as module names in your design. Refer to
tables D-1 through D-4 in Appendix D of the BSDArchitect Reference Manual for a
complete list of generated names.

40 Boundary Scan Process Guide, V8.2007_3

August 2007
 External Boundary Scan Synthesis
Preparing for Boundary Scan Insertion

Preparing for Boundary Scan Insertion

The following subsections discuss the tasks you must perform to prepare for boundary scan
insertion.

Boundary Scan Example Design

This section uses an example full-adder called “aha” to demonstrate the boundary scan design
process. The VHDL description of the “aha” component follows.

library ieee;
use ieee.std_logic_1164.all;

entity aha is
port( s:out std_ulogic;
co:out std_ulogic;
a:in std_ulogic;
b:in std_ulogic;
c:in std_ulogic);
end aha;

architecture rtl of aha is

begin
s<=a xor b xor c;
co <=(a and b) or (a and c) or (b and c);
end rtl;

Creating the HDL Description

BSDArchitect requires an HDL definition (in either VHDL or Verilog) as a high-level interface
to your design. You should specify the top level module using the -top argument at invocation
when more than one entity/module is present in a design.

Creating the Package Mapping File

BSDArchitect optionally supports placing a package mapping file called dft.map in your
working directory for using custom library packages for VHDL designs. This mapping file
specifies any packages/libraries used in the core entity description. By default, without a
package mapping file, BSDArchitect uses the following required standard library packages:

For VHDL:

<mgcdft tree>/pkgs/dft.any/vhdl_src/stdlogic.vhd
<mgcdft tree>/pkgs/dft.any/vhdl_src/standard.vhd

If you do not specify the location of the std_logic_1164 and standard packages in your custom
dft.map file, BSDArchitect searches these locations by default.

Boundary Scan Process Guide, V8.2007_3 41

August 2007
External Boundary Scan Synthesis
Setting Up the Boundary Scan Specification

For more information on the syntax of this file, refer to “Package Mapping File Syntax” in the
BSDArchitect Reference Manual.

Invoking BSDArchitect
To invoke BSDArchitect, enter the following at the shell prompt:

shell> <mgcdft tree>/bin/bsdarchitect hdl_design_name -nogui

After BSDArchitect invokes, it displays the following prompt and the command line:

BSDA>

If you want BSDArchitect to invoke in the GUI mode, omit the -nogui switch.

You can now proceed to set up for and insert boundary scan logic. The invocation for VHDL
input and Verilog input is identical. BSDArchitect reads in either format, and later produces
output in the same format used as input.

Setting Up the Boundary Scan Specification

You have two choices for setting up the boundary scan logic: using system defaults, or
customizing the boundary scan architecture. If you choose to use the system defaults,
BSDArchitect requires no prior setup. You just execute the boundary scan insertion by issuing
the Run command.

The boundary scan specification consists of a set of commands that customize your particular
boundary scan implementation. Refer to “Boundary Scan Customizations” for more
information. You can either enter commands interactively at the BSDA> command line prompt,
store the setup commands in a file and run it using the Dofile command, or enter the commands
in the command line window of the graphical user interface. For more information on dofiles,
refer to “Running Batch Mode Using Dofiles” on page 23.

Boundary Scan Insertion Using BSDArchitect

The following example tells BSDArchitect to create a standard boundary scan architecture for
the same example Verilog design, example.v.

The Example Design

The HDL description for the design, example.v, is the following:

42 Boundary Scan Process Guide, V8.2007_3

August 2007
 External Boundary Scan Synthesis
Boundary Scan Insertion Using BSDArchitect

module my_mod (CLK, D, EN1, IN_IO, OUT_IO, PAD_IN, PAD_OUT,Q);

input CLK;
input D;

input [3:0] IN_IO; // inputs on bidi port

output [3:0] OUT_IO; // outputs of bidi port

output EN1; // bidi port enable

input [1:0] PAD_IN; // bidi pin
output [1:0] PAD_OUT; // bidi pin

output Q;

// another way to define a bidi is by using the specparam

specify
specparam mgc_bs_port_info = "\
(PAD_IN[0]/in, PAD_OUT[0]/out, \
EN1/ctrl/active_high, PAD[0]/top) \
(PAD_IN[1]/in, PAD_OUT[1]/out, \
EN1/ctrl/active_high, PAD[1]/top) \

(IN_IO/in, OUT_IO/out, IO_CTRL/ctrl/active_high, IO/top) ";

endspecify
//
// Where mgc_bs_port_info is the attribute defining I/O or
// tri-state port information to BSD Architect
//
// Where IN_IO/in is the input signal name
//
// Where OUT_IO/out is the output signal name
//
// Where IO_CTRL/ctrl/active_high is the output control
// signal and active state
//
// Where IO/top is the top level port name

endmodule

Running BSDArchitect in an External Flow

1. First you invoke BSDArchitect at the shell:
shell> <mgcdft tree>/bin/bsdarchitect example.v -verilog -nogui

2. Then enter the following commands at the “BSDA>” prompt:

load pin map pin_map
run
report bscan cell
report bscan status
save bscan -replace
exit

This example loads a pin mapping file, runs the boundary scan insertion with all system defaults
(using the Run command with no prior setup) and reports on the logic that BSDArchitect adds.
BSDArchitect then saves the buffered output (my_mod_bscan.v), the interface description file

Boundary Scan Process Guide, V8.2007_3 43

August 2007
External Boundary Scan Synthesis
Boundary Scan Insertion Using BSDArchitect

(my_mod_top.v), the test bench file (my_mod_tb.v), and the BSDL description file
(my_mod_bscan.bsd).

Note
You must save the output netlist in the same format (VHDL or Verilog) as was the input
netlist that you read into the tool. For more information see the Set Output Format
command.

The following report shows the default architecture created in this session.

-------------------------------------------------------------
BSDArchitect Report
-------------------------------------------------------------
Design : my_mod
Date & Time : Fri Dec 17 13:27:49 1999

Asynchronous TAP Reset : Yes

Device Identification Register : No
User Identification Register : No
Instruction Register Width : 4

INSTRUCTION REPORT:
-------------------------------------------------------------
Instruction Target Register Opcode
-------------------------------------------------------------
EXTEST BOUNDARY 0000
BYPASS BYPASS 1111
SAMPLE_PRELOAD BOUNDARY 0001
-------------------------------------------------------------

PORT REPORT:
-------------------------------------------------------------
No. Port BSC Mode Type Cell Name
-------------------------------------------------------------
1 CLK YES Observe bc_4 BC_4
2 D YES Both bc_3 BC_3
3 PAD[0] YES Both bc_7 BC_7
4 PAD[1] YES Both bc_1 BC_1
5 PAD_IN[1] YES Both bc_1 BC_1
6 EN1 YES Both bc_2_a bc_2_a
7 IO[0] YES Both bc_7 BC_7
8 IO[1] YES Both bc_1 BC_1
9 IN_IO[1] YES Both bc_1 BC_1
10 IO[2] YES Both bc_7 BC_7
11 IO[3] YES Both bc_7 BC_7
12 Q YES Both bc_1 BC_1
13 IN_IO[0] NO
14 IN_IO[2] NO
15 IN_IO[3] NO
16 PAD_IN[0] NO
TCK NO
TMS NO
TDI NO
TRST NO

44 Boundary Scan Process Guide, V8.2007_3

August 2007
 External Boundary Scan Synthesis
Boundary Scan Insertion Using BSDArchitect

TDO NO
-------------------------------------------------------------
Total no. of external control BS cells : 1
Total no. of core BS cells : 12
Total no. of BS cells : 13
Note: Port ordering is from TDO to TDI.

Boundary Scan Process Guide, V8.2007_3 45

August 2007
External Boundary Scan Synthesis
Boundary Scan Insertion Using BSDArchitect

46 Boundary Scan Process Guide, V8.2007_3

August 2007
 Chapter 3
Internal Boundary Scan Synthesis

This chapter outlines how to use BSDArchitect to synthesize boundary scan circuitry for your
design using the Internal flow. For specific information on BSDArchitect functionality or
commands, refer to the BSDArchitect Reference Manual.

Understanding BSDArchitect Internal Flow

For the Internal flow, BSDArchitect adds the boundary scan logic the design internally. That is,
the TAP controller instance is placed within the original top-level of the design and the
boundary scan cells are inserted between the I/O pads and the core logic. Designs that already
include I/O pads should use the Internal flow. Figure 3-1 shows the inputs and outputs for a
design using the Internal flow.

Figure 3-1. BSDArchitect Internal Flow Inputs and Outputs

Inputs
There are two required inputs: the design netlist and the I/O pad descriptions. The design netlist
must be formatted in Verilog and the I/O pad descriptions must use Verilog specparams. The
I/O pad descriptions may be contained within the netlist. For more information, see “Building
I/O Pad Definitions” on page 48. Refer to “Recommended Practices” on page 40 for more
information on formatting your design.

Optional input files include the pin mapping file and user dofile. For more information on pin
mapping files, see “Loading Pin Maps” on page 59. You can execute a dofile using the Dofile

Boundary Scan Process Guide, V8.2007_3 47

August 2007
Internal Boundary Scan Synthesis
Building I/O Pad Definitions

command or the -Dofile switch at invocation. Refer to “Running Batch Mode Using Dofiles” on
page 23 for more information on dofiles.

Note
VHDL netlists are not supported in the Internal flow.

Outputs
BSDArchitect formats the output HDL models and test bench files in the Internal flow in
Verilog. For example, the <prefix>_bscan.<suffix> output file will be <prefix>_bscan.v. The
remaining file formats are as described in “BSDArchitect External Flow” on page 25 .

Building I/O Pad Definitions

To insert boundary scan cells, you must define the I/O pad cells in your design. These pads may
be located in any level of hierarchy in the netlist. You create the I/O pad cell descriptions using
Verilog specparams in one of two methods:

• In a separate Verilog file — Direct the tool to read this file by including the -Library
switch at invocation. Design updates may be simplified with this method because
updates for the I/O pad definitions do not require changes to the original netlist. This is
the recommended method.
• In the design netlist — When you place Verilog specparams within the design netlist,
the netlist must contain the Verilog descriptions of the I/O pad cells and you must put
the specparams within these descriptions. The -Library switch is not needed at
invocation for this method.
The important parameters in both of these methods are the name of the design and the mapping
information. This information, along with the Verilog descriptions of the I/O pads, is enough for
the tool to search for existing I/O pads in the design. For more information on using Verilog
specparams, refer to “Defining I/O Pads” on page 92.

Invoking the BSDArchitect Internal Flow

Use the following command to invoke BSDArchitect in Internal mode:

shell> <mgcdft tree>/bin/bsdarchitect design_name.v -internal_flow \

-library pad_definitions.v -nogui

Use the -Internal_flow switch to invoke the BSDArchitect Internal flow. Include the -Library
switch along with the name of the appropriate I/O pad descriptions file. You do not need to use
the -Library switch if your design netlist already contains Verilog specparams to define the I/O

48 Boundary Scan Process Guide, V8.2007_3

August 2007
 Internal Boundary Scan Synthesis
Invoking the BSDArchitect Internal Flow

pads. Refer to “Shell Command Dictionary” in the BSDArchitect Reference Manual for more
information on the invocation and available switches.

Figure 3-2. BSDArchitect Internal Tool Flow

Figure 3-2 illustrates the Internal tool flow for BSDArchitect. The flow begins with the tool
invocation including the -Internal_flow switch. Once invoked, BSDArchitect searches the
specified netlist for I/O pads. If existing pads are found, the tool continues and inserts the
necessary boundary scan logic. If there are no I/O pads in the design or the existing I/O pads are
not recognized, the tool reports that no pad instance was found and exits the invocation. Designs
that do not have existing I/O pads must use the External flow. If BSDArchitect is not detecting
your existing pads, see “Defining I/O Pads” on page 92 to verify that your pads are defined
correctly.

Note
BSDArchitect supports all pad types for I/O pads included in the netlist but only supports
adding input and output pads on ports without I/O pads in the netlist. Bidirectional ports
without pads are ignored.

Example Boundary Scan Insertion

Consider a simple design where all I/O pad cells are defined and all pads exist in the same
hierarchy. Example 3-1 shows this simple example where the small grey squares are the
instances of I/O pads and the red circles are where BSDArchitect will insert boundary scan
cells.

Boundary Scan Process Guide, V8.2007_3 49

August 2007
Internal Boundary Scan Synthesis
Reporting Circuit Components

Example 3-1. Internal Boundary Scan Input

Top-Level Module

Core Logic

The tool searches for the pad cells and locates the ports on each pad. When the Run command is
issued, the tool traces the pad connections checking for errors. When no errors are found, the
tool inserts the boundary scan circuitry.

Example 3-2 shows the resulting boundary scan register (BSR) inserted by the tool highlighted
in red. The red squares represent the newly inserted boundary scan cells.

Example 3-2. Internal Boundary Scan Output

Top-Level Module
TCK TMS
TRST
TAP Controller
TDI TDO

Core Logic

Reporting Circuit Components

The Report Circuit Components command can help in debugging by providing a hierarchical
list of all the instances in a design.

Use the following command to report all the instances in the design:

report circuit components

50 Boundary Scan Process Guide, V8.2007_3

August 2007
 Internal Boundary Scan Synthesis
Adding I/O Pads to Ports Without Pads

Or include the optional design_name argument to display the hierarchical tree structure of all
the instances within a specific instance. For example:

report circuit components my_design

Adding I/O Pads to Ports Without Pads

BSDArchitect allows you to add I/O pads only to ports without pads in the netlist. Furthermore,
only input and output pads can be added. The pads specified in the netlist cannot be changed.
You can use custom defined pad cells provided they are of type input or output. If a port does
not have an existing pad cell and you do not specify one, BSDArchitect inserts a default I/O pad
cell. The tool places this default pad cell at the top level of the design hierarchy and locates the
boundary scan cell next to it.

Pads are added using the following commands:

• Add Technology Cell — Defines cell information for technology mapping of boundary
scan cells, I/O pad cells, and custom TAP controllers.
• Set Technology Mapping — Sets a target technology when creating technology-specific
boundary scan logic.
• Add Pad Cell — Associates a specified I/O pad cell with specified core ports.
• Set Pad Cell — Associates specified I/O pad cells with specified port types.
The tool adds JTAG ports and pads after creating the boundary scan logic. For new JTAG ports,
the tool creates five new pins and adds default pads to those pins. A tri-state pad is added for
TDO. For more information on optional TDO connections, see “Sharing Functional Pins With
TDO” on page 62. Custom input and output pads can be added for JTAG ports.

Existing JTAG ports are recognized in one of two ways:

• The ports have standard names (tdi, tms, tck, trst, tdo). The tool automatically
recognizes the ports and adds the default or user-specified I/O pads.
• The ports have user-specified names given by the Set Controller Naming command.
This command is either entered in the command line or executed within a dofile.
BSDArchitect places all new pads in the same module at the top level of the design. This
includes pads added on both ports without pads and on JTAG ports. You cannot use the Set Pad
Instances command in the Internal flow to change this behavior.

The following example defines and associates an output pad pad_out_1 with output port out1:

add technology cell pad_out_1 output -inputs in -outputs out -connect in/dout out/pin
add pad cell pad_out_1 out1

Boundary Scan Process Guide, V8.2007_3 51

August 2007
Internal Boundary Scan Synthesis
Reporting Pad Cells

Reporting Pad Cells

When you issue the Report Pad Cell command in the Internal flow, the tool displays the pad cell
information sorted into two sections. The sections vary depending on whether the report
command is issued before or after the Run command. The possible sections are:

• Ports on which pads were FOUND

This section is always included in the report regardless of the Run command. It lists the
information for all pad cells detected in the original netlist.
• Ports on which new pads are to be ADDED
This section is included only when you issue the Report Pad Cell command before the
Run command. It lists the pads intended for the ports. These may be default pads from
the tool or user-specified pads. The instance name column is not included because the
pads have not yet been added to the design. The pads are added to the design during the
Run command.
• Ports on which new pads are ADDED
This section is included only when you issue the Report Pad Cell command after the
Run command. It lists the pads that were added to the design. The pads listed in this
section are the same pads listed in “Ports on which new pads are to be ADDED.” The
instance names are included because the pads were added.
The following example shows a report issued before the Run command:

BSDA> report pad cell

------------------------------------------------------------------
BSDArchitect Pad Report
------------------------------------------------------------------
Design: test_chip
Date: Tue Oct 5 13:25:41 2004
------------------------------------------------------------------
Ports on which pads were FOUND
------------------------------------------------------------------
Core-Port Top_Port Type Cell Name Instance
------------------------------------------------------------------
bit_bidi bit_bidi Bidi... bidi_pad test_chip/test_pad_inst/b...
bus_bidi[1] bus_bidi[1] Bidi... bidi_pad test_chip/test_pad_inst/b...
bus_bidi[0] bus_bidi[0] Bidi... bidi_pad test_chip/test_pad_inst/b...
bit_o bit_o Output out_pad test_chip/test_pad_inst/o...
bit_tri_o bit_tri_o Tristate tri_pad test_chip/test_pad_inst/t...
bus_o[0] bus_o[0] Output out_pad test_chip/test_pad_inst/o...
bus_o[1] bus_o[1] Output out_pad test_chip/test_pad_inst/o...
bus_tri_o[0] bus_tri_o[0] Tristate tri_pad test_chip/test_pad_inst/t...
bus_tri_o[1] bus_tri_o[1] Tristate tri_pad test_chip/test_pad_inst/t...
bus_i[0] bus_i[0] Input in_pad test_chip/test_pad_inst/i...
bus_i[0] bus_i[0] Input in_pad test_chip/test_pad_inst/i...

52 Boundary Scan Process Guide, V8.2007_3

August 2007
 Internal Boundary Scan Synthesis
Adding Boundary Scan Cells

Ports on which pads are to be ADDED

------------------------------------------------------------------
Core-Port Top-Port Type Cell Name
------------------------------------------------------------------
bit_i bit_i Input io_pad_in
tdi tdi Input io_pad_in
tms my_tms Input io_pad_in
tck my_tck Input io_pad_in
tdo tdo Tristate tri_enable_high
trst my_trst Input io_pad_in
------------------------------------------------------------------

Adding Boundary Scan Cells

To specify boundary scan cells for your ports, use one of the following:

• To specify a boundary scan cell for one or more specific ports, use the Add Bscan Cell
command. The following example places a BC_1 type cell on the output ports out1 and
out2:
add bscan cell bc_1 out1 out2

• If you do not want a boundary scan cell placed on a particular port, use the Add Bscan
Cell command and specify ‘none’ for the boundary scan cell type. The following
example specifies that no boundary scan cell is placed on output port out3:
add bscan cell none out3

• To specify boundary scan cells for all ports or ports of a given type, use the Set Bscan
Cell command. For example you can specify a cell for placement on all input ports. Any
cells specified with the Add Bscan Cell command will override the Set Bscan Cell
command regardless of the command order. The following example places a BC_1 type
cell on all output ports:
set bscan cell -out bc_1

• To specify boundary scan cells for each port and specify the port order, use a pin
mapping file. For more information on using a pin mapping file, see “Loading Pin
Maps” on page 59.
After specifying boundary scan cells, verify your changes with the Report Bscan Cell
command. BSDArchitect inserts the specified or default boundary scan cells in your design
when you issue the Run command.

Boundary Scan Cell Placement

The following sections describe the placement of boundary scan cells for data ports. For
information on bidirectional and tri-state control ports, see “Boundary Scan Cell Placement for
Control Ports” on page 56.

Boundary Scan Process Guide, V8.2007_3 53

August 2007
Internal Boundary Scan Synthesis
Adding Boundary Scan Cells

Ports Without I/O Pads in the Netlist

Boundary scan cells are added to the top level of the design. For more information, see “Adding
I/O Pads to Ports Without Pads” on page 51.

Ports With I/O Pads in the Netlist

Boundary scan cells are inserted in the parent module of the I/O pad if there is only one instance
of the parent module in the design. If there is more than one instance of the I/O pad parent
module, the placement is as follows:

• Boundary Scan Cells on a Single Data Port

The boundary scan cell is placed at the highest hierarchy between the I/O pad port and
any logic encountered along the data path. In Example 3-3, the BC_1 cell is placed
between the dout port and the buffer. The highest hierarchy between them is
parent_parent_outpad_inst1.

Example 3-3. Boundary Scan Cell Placement on Single Data Port

• Boundary Scan Cells on Multiple Data Ports

For the bidirectional 2-cell model, the two data ports, din and dout, share a single
boundary scan cell. Each port is traced back to any logic and the boundary scan cell is
placed at the highest hierarchy common to both ports. In Example 3-4, the dout port can
be traced back to the buffer in parent_bidi_inst1, and the din port can be traced back to
the buffer in parent_parent_bidi_inst1. The highest hierarchy common to both ports is
parent_bidi_inst1, which is where the BC_7 cell is placed.

54 Boundary Scan Process Guide, V8.2007_3

August 2007
 Internal Boundary Scan Synthesis
Adding Boundary Scan Cells to Control Ports

Example 3-4. Boundary Scan Cell Placement on Multiple Data Ports

Note
Your design may be modified, if necessary, to uniquify modules. For more information,
see “Uniquification” on page 63.

Adding Boundary Scan Cells to Control Ports

BSDArchitect adds the following cells for bidirectional and tri-state ports:

• Tri-state ports — Two boundary scan cells are added: one cell for the output port and
one for the control port. BSDArchitect uses a BC_1 cell for both ports by default.
• Bidirectional 3-cell model — Three boundary scan cells are added: one cell is added for
each of the input, output, and control ports.
• Bidirectional 2-cell model — Two boundary scan cells are added: one combined cell for
the input and output data ports and one cell for the control port. BSDArchitect uses the
bidirectional 2-cell model by default with a BC_7 combined cell for the data ports and a
BC_2_A cell for the control port.
In the Internal flow, BSDArchitect inserts all boundary scan circuitry into the existing netlist.
The control ports for tri-state and bidirectional pads may not be visible at the top level of the
design. To access these ports, use the notation in Table 3-1 for the Add Bscan Cell and Delete
Bscan Cell commands.

Table 3-1. Control Port Notation

Port Notation
Output (tri-state) <port_name>
Inout Interface (bidirectional) <port_name>
Control <port_name>/oe
Input (bidirectional) <port_name>/din

Use parentheses when specifying a control port of a bus signal. For example:

Boundary Scan Process Guide, V8.2007_3 55

August 2007
Internal Boundary Scan Synthesis
Adding Boundary Scan Cells to Control Ports

BSDA> add bscan cell my_bc_2 bus_tri_o(0)/oe

The following example adds a BC_1 type cell to the port named “tri” and its control port:

add bscan cell BC_1 tri tri/oe

The following example adds the user-defined cell my_BC_7 to the bidirectional port named
“bidi_X”:

add bscan cell my_BC_7 bidi_X

The following example adds the boundary scan cell my_BC_2_A to the control ports of the
bidirectional ports named “bidi_X” and “bidi_Y”:

add bscan cell my_BC_2_A bidi_X/oe bidi_Y/oe

The following example of a bidirectional 3-cell model adds a BC_1 boundary scan cell to the
output, control, and input of the bidirectional port named “bidi_K”:

add bscan cell BC_1 bidi_K bidi_K/oe bidi_K/din

Example 3-5 illustrates where there is no top level signal associated with the control port of the
tri-state pad. The following commands add boundary scan cells to the tri-state port x using the
notation in Table 3-1:

add bscan cell bc_1 x

add bscan cell bc_1 x/oe

Example 3-5. No Top-Level Signal for a Tri-State Control Port

Boundary Scan Cell Placement for Control Ports

The placement of bidirectional or tri-state control boundary scan cells depends on the control
signal configuration. Each of the following configurations apply to both internal and external
control signal sources.

56 Boundary Scan Process Guide, V8.2007_3

August 2007
 Internal Boundary Scan Synthesis
Adding Boundary Scan Cells to Control Ports

• The control signal supports a single pad and does not pass through an inverter or buffer.
BSDArchitect places the control boundary scan cell in the parent module of the
bidirectional or tri-state pad. Example 3-6 shows the BC_2 cell placed within the parent
module at the same hierarchy as the bidirectional pad instance.

Example 3-6. Single Control Signal Without Inverter/Buffer

• The control signal supports a single pad and passes through one or more buffers or
inverters.
BSDArchitect places the control boundary scan cell behind all buffers in the control
signal path at the same hierarchy as the parent module of the first buffer or inverter. If
multiple instances of the parent module exist, the control boundary scan cell is placed at
the highest hierarchy between the signal source and the buffer or inverter. Example 3-7
shows the BC_2 cell placed at the same hierarchy as the inverter parent instance
parent_inv_inst1. If multiple instances of parent_sig_inst exist, the BC_2 cell would be
in the same position because this location is also the highest hierarchy between the
signal and the inverter parent instance.

Example 3-7. Single Control Signal With Inverter

• The control signal supports multiple pads and does not pass through an inverter or
buffer.
BSDArchitect places the control boundary scan cell immediately before the common
point within the same module as the common point. Example 3-8 shows the BC_2 cell
placed in the top module just before the control signal splits to the separate pads. If this
example only contained the first two bidirectional pads and the common point was

Boundary Scan Process Guide, V8.2007_3 57

August 2007
Internal Boundary Scan Synthesis
Adding Boundary Scan Cells to Control Ports

contained in parent_bidi_group_inst1, then the BC_2 cell would also be placed in

parent_bidi_group_inst1.

Example 3-8. Multiple Control Signals Without Inverter/Buffer

• The control signal supports multiple pads and passes through one or more inverters or
buffers.
BSDArchitect places the control boundary scan cell before the common point behind all
inverters or buffers in the control signal path within the parent module of the buffer or
inverter closest to the signal source. If multiple instances of that parent module exist in
the design, the control boundary scan cell is placed at the highest hierarchy between the
signal source and the inverter or buffer. Example 3-9 shows the BC_2 cell placed within
the parent module of the inverter. If there were multiple instances of
parent_parent_sig_inst, the BC_2 cell would be at the same position because this
location is also the highest hierarchy between the inverter and the signal source.

58 Boundary Scan Process Guide, V8.2007_3

August 2007
 Internal Boundary Scan Synthesis
Loading Pin Maps

Example 3-9. Multiple Control Signals With Inverter

Loading Pin Maps

Use the Load Pin Map command to add boundary scan cells and specify port ordering for your
design in a single file. Refer to “Using a Pin Mapping File” on page 100 for more information
on formatting this file.

When mapping tri-state or bidirectional ports in the Internal flow, use the syntax outlined in
Table 3-1 on page 55. Use the keyword “void” for the pinID of the control (oe) and input (din)
ports because they are not mapped directly to a packaging pin.

When power or ground ports are declared in the pin mapping file by the -pwr or -gnd switch, the
tool checks the netlist for the pad cells and makes appropriate connections. Consider the
following four cases:

1. The port exists at the top level, and there is no pad cell specified in the pin map file.
If a pad is found in the netlist, the tool issues an error. If no pad is found in the netlist,
the tool removes the specified port from the top level, adds linkage in the BSDL file, and
adds a generic pad cell to the port.
2. The port exists at the top level, and a pad cell exists in the netlist and is specified in the
pin map file.
The pad cell specified in the file must be predefined by the Add Technology Cell
command or the tool issues an error. The tool removes the port from the top level and
adds linkage in the BSDL file.

Boundary Scan Process Guide, V8.2007_3 59

August 2007
Internal Boundary Scan Synthesis
Making Top-Level Port Connections

3. The port does not exist at the top level, and there is no pad cell specified in the pin map
file.
In this case, it is not clear that a power pad is desired. The tool adds linkage in the BSDL
file but does not add a pad cell.
4. The port does not exist at the top level, and a pad cell exists in the netlist and is specified
in the pin map file.
The pad cell specified in the file must be predefined by the Add Technology Cell
command or the tool will issue an error. Linkage will be added in the BSDL file.
The following is an example pin map file for use with the Internal flow:

//-----------------------------------------------------------------------
//Port Pin Power/ Cell Pad Cell Safe
//Name ID Ground Type Name Value Inv
//-----------------------------------------------------------------------
bit_bidi/oe void -cell bc_2_a ;
bit_bidi 0 -cell bc_7_low -safe X ;
bit_diff_o 3 4 -cell bc_1 -safe X ;
bit_int_o 7 -cell bc_1 -safe X ;
bit_o 9 -cell bc_1 -safe X ;
bit_oc_o 10 -cell bc_1 -safe X ;
bit_tri/oe void -cell bc_1 ;
bit_tri 12 -cell bc_1 -safe X ;
bit_bidi2/oe void -cell bc_1 ;
bit_bidi2 13 -cell bc_1 -safe X ;
bit_bidi2/din void -cell bc_1 ;
bit_diff_i 1 2 -cell bc_1 -safe X ;
bit_gnd 5 -gnd -p ground_cell ;
bit_i 6 -cell bc_1 -safe X ;
bit_inv_i 8 -cell bc_1 -safe X ;
bit_pwr 11 -pwr -p power_cell ;
tdi 14 ;
tms 15 ;
tck 16 ;
tdo 17 ;
trst 18 ;

Making Top-Level Port Connections

This section describes the connections made for the following commands:

• Add Port Connection

• Connect Core Chains
• Connect Iscan Chains
For a port connection to a primary output port, the connection is made from the parallel_input of
the boundary scan cell for the output port as shown in Figure 3-3. Similarly, for a connection to

60 Boundary Scan Process Guide, V8.2007_3

August 2007
 Internal Boundary Scan Synthesis
Placing and Connecting External Registers

a primary input port, the connection is made from the parallel_output of the boundary scan cell
for the input port.

Figure 3-3. Top-Level Port Connections

Placing and Connecting External Registers

The Add External Register command is unique in that it adds a new module and instance to the
top-level design. Consider the design core in Example 3-10:

Example 3-10. Design Core Example

The following commands add an external register to the design and remove the ports connected
to the capture and update ports of external register from the top level:

BSDA> add external register my_reg 2

// Added external register "my_reg" of length "2".

BSDA> add bscan instruction my_inst -reg_name my_reg

// Added instruction "my_inst" with opcode "0010".

Boundary Scan Process Guide, V8.2007_3 61

August 2007
Internal Boundary Scan Synthesis
Sharing Functional Pins With TDO

BSDA> set external_register interface my_reg -capture X Y -update P Q

// Note: External register interface for register "my_reg" done.

To make the ports visible at the top level, use the Delete Nontop Port command. For example:

BSDA> delete nontop port Q Y

// Port "Q" will be available at top.

// Port "Y" will be available at top.

The resulting core is illustrated in Example 3-11. Port Q has a multiplexer controlled by the
instruction signal, my_inst. This mux is placed within the TAP module. The input port P and the
output port X are no longer available at the top level.

Example 3-11. Resulting Design Core

Sharing Functional Pins With TDO

In your design, you may want to avoid adding an additional pin for the TDO port. It is possible
to share a functional pin with TDO. The pin functions as designed during normal chip operation
and functions as TDO during chip testing.

To set up your design for TDO pin sharing, the netlist must include a top-level output port
named TDO with a tristate pad. The ports on the tristate pad must be connected to core signals.
BSDArchitect recognizes this as intension for pin sharing and adds the necessary circuitry.

62 Boundary Scan Process Guide, V8.2007_3

August 2007
 Internal Boundary Scan Synthesis
Uniquification

For TDO pin sharing, the tool adds two multiplexers as illustrated in Example 3-12. Multiplexer
M1 controls the signal that operates the output enable (oe) of the tri-state or bidirectional pad.
Multiplexer M2 controls the signal for the dout port of the pad. The select signal for both M1
and M2 comes from the instruction decoder in the TAP controller. When the instruction register
contains an unused opcode (not defined as a JTAG or user instruction), the tool assumes that the
chip is in functional mode and the TDO pin is controlled by the core. When the instruction
register contains a defined opcode, the tool assumes the chip is in testing mode, and the TDO
pin is used accordingly.

There is one problem with TDO pin sharing. According to the IEEE 1149.1 - 2001 standard, the
presence of an unused opcode in the instruction register should trigger a bypass of the chip.
Because TDO pin sharing uses the unused opcodes to define when the chip is in functional
mode, the unused opcodes are not used for bypass. You must define opcodes for bypass use.

Example 3-12. Pin Sharing Example

Uniquification
When a design has I/O pads defined in the netlist, BSDArchitect inserts boundary scan cells at
the same hierarchy as the pads. When boundary scan cells are added to an existing module, the
module definition is modified. Any change to the module definition will change all instances of
that module unless the modified instance is uniquified.

The tool uniquifies the module instance by creating a new unique module to replace the
modified module. The instance name remains the same. The process is repeated for parent
modules if there are multiple instances of the parent module.

When I/O pads are at the top level, and boundary scan cells are also at the top level, there is no
need for Uniquification. This is the case for the External flow and for I/O pads and boundary
scan cells added on ports without pads in the Internal flow.

Boundary Scan Process Guide, V8.2007_3 63

August 2007
Internal Boundary Scan Synthesis
Unsupported Commands

Unsupported Commands
The following commands are not available in the Internal flow:

Add Bypass Mux Delete Bypass Mux Report Bypass Mux

Add Datacontrol Port Delete Datacontrol Port Report Datacontrol Port
Add Differential Port Delete Differential Port Report Port Mapping
Add New Port Delete New Port Set Bsr Instances
Add Opencollector Port Delete Opencollector Port Set Configuration Specification
Add Port Mapping Delete Port Mapping Save Design Unit
Add Tristate Port Delete Tristate Port

Refer to the Command Dictionary in the BSDArchitect Reference Manual for more information
on specific commands.

64 Boundary Scan Process Guide, V8.2007_3

August 2007
 Chapter 4
Boundary Scan Customizations

You can run boundary scan insertion after customizing the setup. Examples of customizations
include changing the width of the instruction register, adding optional instructions, setting up
for technology-mapped output, and connecting boundary scan circuitry to internal scan
circuitry.

Creating Customizations
Customizations can be entered as individual commands in the command line window or
command prompt, or they can be entered into a dofile. To issue commands in a dofile, enter the
following command at the “BSDA>” prompt:

dofile cust_bscan.do

In this example, the dofile, cust_bscan.do, contains the customized setup commands. The
following example shows contents of this dofile:

//
// Specify the pin ordering using a pinmap file
//
// There are two methods that can be used to specify the port ordering.
// The following displays an example of each.
//
// Here we display the use of the set bscell command in a dofile.
//
//* add bscan cell BC_4 CLK
//* add bscan cell BC_3 CLR
//
// define the order of the boundary scan cells
//* set port order CLK CLR D EN1 IN_IO ...
//
// Here we display the use of a pin map file.
//
load pin map pin_map
// if the load pin map command is used after the d1_pins.do dofile then
// the definitions in the pinmap replace those made in the dofile
//
// Do not connect a boundary scan cell to pin D
add bscan cell none D

// Change the instruction register length from default (4 bits)

// to 3 bits and add an idcode instruction
set bscan IR_size 3
add bscan instruction idcode -reg_name bscan_id_reg \
-code 010
set bscan idcode -manufacturer_name vlsi \
-manufacturer_id 00010101011 \

Boundary Scan Process Guide, V8.2007_3 65

August 2007
Boundary Scan Customizations
Technology Mapping

-part_number 0000111100001111 -version 0001

//
// Define the directory and file names to use for saving the
// new boundary scan files.
setup file naming -root temp_files/my_mod -testbench \ my_testbench.v
run
report bscan status -file bscan_report -replace -all
save bscan -replace
exit

Technology Mapping
Technology mapping provides support for replacing generic cells by equivalent technology-
specific cells. Technology-mapped cells can be boundary scan cells, I/O pad cells, boundary
scan cells with built-in I/O pads, and TAP controllers.

Technology mapping support is cell specific rather than instance specific. Consequently, the
attributes specified for a particular technology cell affect all instances of that cell.

The technology-mapped cells may be defined using library files or using the Add Technology
Cell command.

Note
For the internal flow, you can define the I/O pads in the design netlist or in a separate
library file at invocation. After invocation, however, you can only add input and output
I/O pads.

In some ASIC libraries, the boundary scan logic is included in PAD cells. In others cases, ASIC
libraries are separate from pad cells. In both cases, BSDArchitect instantiates boundary scan
cells within the BSR instance entity.

When using technology mapping in your design, refer to “Understanding BSDArchitect Output
Files” on page 115 to write out proper files.

Libraries
Generic library components corresponding to clock_gating options are presented in the
following directory within the Mentor Graphics DFT software tree:

<mgcdft tree>/pkgs/jtag_libs.any/src directory

You use these components to create a generic RTL level description of the boundary scan
circuitry. Once you define a cell in a library file, you can add it to the design using the Set
Technology Mapping command.

66 Boundary Scan Process Guide, V8.2007_3

August 2007
 Boundary Scan Customizations
Technology Mapping

Technology-specific library files contain information about the cells and their interconnections.
BSDArchitect accepts libraries in two formats. If you are using the Internal flow, your library
must be a Verilog file. The following formats define the cells:

• VHDL — You map the vendor components to generic components using the ‘attribute’
statement.
• Verilog — You map the vendor components to generic components using the
‘specparam’ statement.
Table 4-1 shows how the library attributes translate for use with the Add Technology Cell
command.
Table 4-1. Library Attributes vs. Command Line Arguments
Library User-Defined Attributes Add Technology Cell Arguments
mgc_dft_cell_type cell_type
mgc_dft_pin_type -Connect
mgc_dft_connect -Connect
mgc_dft_built_in_pad_type -BUilt_in_pad
mgc_dft_bscell_mode -BScell_mode
mgc_dft_disable_result -Disable_result

Technology Mapping Syntax

The following sections describe BSDArchitect syntax requirements for technology mapping
using both library files and the Add Technology Cell command.

Specifying Cell Type Information

To specify a boundary scan cell type, use the ‘mgc_bs_bsr_type’ or ‘mgc_dft_cell_type’
attribute. For all other types of cells, use the ‘mgc_dft_cell_type’ attribute. The cell type
attribute is used inside the description of the vendor cell.

If you are defining the cell using the Add Technology Cell command, specify the cell type as
the second command argument following the new cell name. For more information, refer to the
Add Technology Cell command in the BSDArchitect Reference Manual.

Specifying Port Mapping Information

To specify the pin mapping information for boundary scan cells, use the ‘mgc_bs_pin_map’ or
‘mgc_dft_pin_type’ attribute. To specify port mapping for all other cells, use the
‘mgc_dft_pin_type’ attribute. The port mapping attribute is used inside the description of the
vendor cell.

Boundary Scan Process Guide, V8.2007_3 67

August 2007
Boundary Scan Customizations
Technology Mapping

If you are defining the cell using the Add Technology Cell command, specify the port mapping
information following the -Connect switch. Refer to the Generic Port Names table for the Add
Technology Cell command for specific port names for all cell types.

You must provide appropriate pin mapping information for all pins in the generic cell and the
vendor cell, otherwise BSDArchitect generates an error message. The Generic Port Names table
shows which ports you must define and which ports are optional.

The following three sections show the pin mapping information for possible cases using
different methods:

Using the ‘mgc_bs_pin_map’ Attribute

The following list illustrates the six different mappings for a vendor pin ‘vpin’ specified using
the ‘mgc_bs_pin_map’ attribute:

1. vpin/lpin — Maps vpin on the vendor cell to lpin on the generic cell.
2. vpin/ground — Maps vpin on the vendor cell to the ground line.
3. vpin/power — Maps vpin on the vendor cell to the power line.
4. delete/lpin — Indicates that lpin on the generic cell does not exist on the vendor cell.
5. vpin/open — Indicates that vpin on the vendor cell is left unconnected.
6. vpin/vpin_n — Maps vpin on the vendor cell to the signal vpin_n in the synthesized
circuitry. If the signal vpin_n is not already available in the instance containing the
mapped cell, BSDArchitect creates a local signal with name vpin_n.
The following snippet specifies the port mapping information for a BC_1 cell vendor_bc1 using
the ‘mgc_bs_pin_map’ attribute:

attribute mgc_bs_pin_map of vendor_bc1 : entity is \

"pi/parallel_input, si/serial_input, po/parallel_output, \
so/serial_output, mode_1/mode_1_v, mode_2/mode_2_v, delete/mode, \
shdr/shiftdr, ckdr/clockdr, updr/updatedr, vcc/power, gnd/ground, \
opn_s/open";

Using the ‘mgc_dft_cell_type’ Attributes

The following list illustrates the same six different mappings for a vendor pin ‘vpin’ specified
using the ‘mgc_dft_cell_type’ attributes:

1. attribute mgc_dft_pin_type of vpin: signal is “lpin”;

2. attribute mgc_dft_pin_type of vpin: signal is “gnd”;
3. attribute mgc_dft_pin_type of vpin: signal is “vdd”;
4. attribute mgc_dft_nonexistent_signals of vendor_cell: entity is “lpin”;

68 Boundary Scan Process Guide, V8.2007_3

August 2007
 Boundary Scan Customizations
Technology Mapping

5. attribute mgc_dft_pin_type of vpin: signal is “open”;

6. attribute mgc_dft_connect of vpin: signal is “vpin_n”;
The following snippet specifies the port mapping information for a BC_1 cell vendor_bc1 using
the ‘mgc_dft_cell_type’ attributes:

attribute mgc_dft_pin_type of pi : signal is “parallel_input”;

attribute mgc_dft_pin_type of si : signal is “serial_input”;
attribute mgc_dft_pin_type of po : signal is “parallel_output”;
attribute mgc_dft_pin_type of so : signal is “serial_output”;
attribute mgc_dft_pin_type of shdr : signal is “shiftdr”;
attribute mgc_dft_pin_type of ckdr : signal is “clockdr”;
attribute mgc_dft_pin_type of updr : signal is “updatedr”;
attribute mgc_dft_pin_type of vcc : signal is “vdd”;
attribute mgc_dft_pin_type of gnd : signal is “gnd”;
attribute mgc_dft_pin_type of opn_s : signal is “open”;
attribute mgc_dft_nonexistent_signals of vendor_bc1 : entity is “mode”;
attribute mgc_dft_connect of mode_1 : signal is “mode_1_v”;
attribute mgc_dft_connect of mode_2 : signal is “mode_2_v”;

Using the Add Technology Cell Command

The following list illustrates the same six different mappings, and one additional mapping for a
vendor pin ‘vpin’ specified using the switches for the Add Technology Cell command:

1. -connect vpin/lpin — Maps vpin on the vendor cell to lpin on the generic cell.
2. -connect vpin/gnd — Maps vpin on the vendor cell to the ground line.
3. -connect vpin/pwr — Maps vpin on the vendor cell to the power line.
4. -nonexistent lpin — Indicates that lpin on the generic cell does not exist on the vendor
cell.
5. -connect vpin/open — Indicates that vpin on the vendor cell is left unconnected.
6. -connect vpin/vpin_n — Maps vpin on the vendor cell to the signal vpin_n in the
synthesized circuitry.
7. -connect vpin/“path/my_net” — (for Internal flow only) Maps vpin on the vendor cell
to the net my_net. Net names must be enclosed in double quotes.
The following snippet specifies the port mapping information for a BC_1 cell vendor_bc1 using
the Add Technology Cell command:

-connect pi/parallel_input si/serial_input po/parallel_output so/serial_output \

mode_1/mode_1_v mode_2/mode_2_v shdr/shiftdr ckdr/clockdr updr/updatedr \
vcc/power gnd/ground opn_s/open \
-nonexistent mode

Boundary Scan Process Guide, V8.2007_3 69

August 2007
Boundary Scan Customizations
Technology Mapping

Design Rules Checking for Technology Mapping

BSDArchitect conducts internal design rules checking to verify that the technology mapping
inputs are consistent and the output generated conforms to the IEEE 1149.1 standard. The tools
reports failure of these checks as errors and does not add boundary scan circuitry. In some
libraries, however, it may not be possible to map the technology dependent component types to
the generic cell types used in BSDArchitect. In such cases, use the Set Drc Handling command
to override the BSDArchitect design checks. This command uses the following syntax:

SET DRc Handling Error | Warning | Ignore

For more information, refer to the Set Drc Handling command in the BSDArchitect Reference
Manual.

Defining Boundary Scan Cells

The following are valid boundary scan cell types available for technology mapping in
BSDArchitect:

BC_1 Cell BC_3 Cell BC_8 Cell

BC_2 Cell BC_4 Cell BC_9 Cell
BC_2_A Cell BC_5 Cell BC_10 Cell
BC_2_A_EXT Cell BC_7 Cell BC_X Cell
BC_2_B Cell BC_7_LOW Cell

After defining a boundary scan cell, the cell may be added using the Add Bscan Cell or Set
Bscan Cell command.

Boundary Scan Rules Checking

When you map a technology-specific boundary scan cell to a generic cell type, BSDArchitect
applies the rules checking for the generic cell to the technology-specific cell as well. These
checks include the following:

• BC_3, BC_4 can be used only with input ports.

• BC_7/BC_2_A can be used only for bidi/bidi control (BC_7 is a combined input/output
cell).
• When a BC_7 is used for a bidi port, the input port cannot have a bscell associated with
it.
• When a BC_7 is used for a bidi port, the enable port must have a BC_2_A cell.
• External control signals must have a BC_5 for tri-state control and a BC_2_A_EXT for
bidirectional control ports.

70 Boundary Scan Process Guide, V8.2007_3

August 2007
 Boundary Scan Customizations
Technology Mapping

• BC_8 is used only for an open-collector bidirectional port.

• BC_9 and BC_10 cells can be used only on output, tri-state, and bidirectional output
ports. These cells can only be used with simple output ports in the Internal flow.

Specifying the Boundary Scan Cell Mode

The IEEE 1149.1 standard allows two different modes for boundary scan cells: ‘observe’ and
‘both.’ Boundary scan cells of observe-only mode can only be used with input ports. Of the
standard boundary scan cell types, BC_4 is of mode ‘observe’ and all others are of mode ‘both’.

When you map a technology boundary scan cell to a standard cell type, the mode information is
inherited from the standard cell type. For bc_x cells, however, you can specify a cell mode by
using the ‘mgc_dft_bscell_mode’ attribute, whose values can be ‘observe’ or ‘both.’ The
default is ‘both.’

BC_1 Cell
Figure 4-1. Generic BC_1 Cell
mode
shiftdr
serial_output G1

parallel_input 1
parallel_output
G1 1

1
1D 1D
1
C1 C1

serial_input
clockdr updatedr

The following example is a Verilog BC_1 definition using the ‘mgc_dft_cell_type’ attribute:

Boundary Scan Process Guide, V8.2007_3 71

August 2007
Boundary Scan Customizations
Technology Mapping

module ctilike_bc_1 (v_shiftdr, v_clockdr, v_updatedr, \

v_parallel_input, v_extra_pin,v_serial_input, v_mode, \
v_serial_output, v_parallel_output);

input v_shiftdr, v_clockdr, v_updatedr, v_parallel_input, \

v_serial_input, v_mode, v_extra_pin;

output v_serial_output, v_parallel_output;

specify
specparam mgc_dft_cell_type = "bc_1";
specparam mgc_dft_connect$v_extra_pin = "extra_pin_forbc1";
specparam mgc_dft_pin_type$v_clockdr = "clockdr";
specparam mgc_dft_pin_type$v_shiftdr = "shiftdr";
specparam mgc_dft_pin_type$v_updatedr = "updatedr";
specparam mgc_dft_pin_type$v_mode = "mode";
specparam mgc_dft_pin_type$v_parallel_input = "parallel_input";
specparam mgc_dft_pin_type$v_parallel_output = "parallel_output";
specparam mgc_dft_pin_type$v_serial_input = "serial_input";
specparam mgc_dft_pin_type$v_serial_output = "serial_output";
endspecify
endmodule
The following example is a Verilog definition using the ‘mgc_bs_bsr_type’ attribute:

module old_syntax_bc_1 ( v_shiftdr, v_clockdr, v_updatedr, \

v_parallel_input, v_extra_pin, v_serial_input, v_mode, \
v_serial_output, v_parallel_output );

input v_shiftdr, v_clockdr, v_updatedr, v_parallel_input,\

v_serial_input, v_mode, v_extra_pin;

output v_serial_output, v_parallel_output;

specify
specparam mgc_bs_bsr_type = "bc_1";
specparam mgc_bs_pin_map = " \
v_extra_pin/extra_pin_forbc1, v_clockdr/clockdr, \
v_shiftdr/shiftdr, v_updatedr/updatedr, v_mode/mode, \
v_parallel_input/parallel_input, \
v_parallel_output/parallel_output, v_serial_input/serial_input ,\
v_serial_output/serial_output";
endspecify
endmodule

The following VHDL example maps the generic cell bc_1 to the vendor cell vendor_bc1:

-- description of generic bc_1 (clock gating on, asynchronous -- version)

entity bc_1 is
port(shiftdr,clockdr,updatedr,parallel_input,serial_input, \
mode : in std_ulogic;
serial_output,parallel_output : out std_ulogic);
end bc_1;

-- description of vendor cell

72 Boundary Scan Process Guide, V8.2007_3

August 2007
 Boundary Scan Customizations
Technology Mapping

entity vendor_bc1 is
port(pi, si : in std_ulogic;
po, so : out std_ulogic;
mode_1, mode_2 : in std_ulogic;
shdr, updr, ckdr : in std_ulogic;
vcc, gnd : in std_ulogic;
opn_s : in std_ulogic);
attribute mgc_bs_bsr_type : string;
attribute mgc_bs_pin_map : string;
attribute mgc_bs_bsr_type of vendor_bc1 : entity is “bc_1”;
attribute mgc_bs_pin_map of vendor_bc1 : entity is \
“pi/parallel_input, si/serial_input, po/parallel_output, \
so/serial_output, mode_1/mode_1_v, mode_2/mode_2_v, delete/mode, \
shdr/shiftdr, ckdr/clockdr, updr/updatedr, vcc/power, gnd/ground, \
opn_s/open”;
end vendor_bc1;

BC_2 Cell
Figure 4-2. Generic BC_2 Cell
mode23 serial_output

G1

parallel_input 1
parallel_output
1 G1

1
1D 1D 1
C1 C1

serial_input
updatedr clockdr shiftdr

The following example is a Verilog BC_2 definition using the ‘mgc_dft_cell_type’ attribute:

Boundary Scan Process Guide, V8.2007_3 73

August 2007
Boundary Scan Customizations
Technology Mapping

module my_bc_2 (my_shiftdr, my_clockdr, my_updatedr, \

my_parallel_input, my_serial_input, my_mode, \
my_serial_output, my_parallel_output);

input my_shiftdr, my_clockdr, my_updatedr, my_parallel_input, \

my_serial_input, my_mode;

output my_serial_output, my_parallel_output;

specify
specparam mgc_dft_cell_type = "bc_2";
specparam mgc_dft_pin_type$my_clockdr = "clockdr";
specparam mgc_dft_pin_type$my_shiftdr = "shiftdr";
specparam mgc_dft_pin_type$my_updatedr = "updatedr";
specparam mgc_dft_pin_type$my_mode = "mode23";
specparam mgc_dft_pin_type$my_parallel_input = "parallel_input";
specparam mgc_dft_pin_type$my_parallel_output = "parallel_output";
specparam mgc_dft_pin_type$my_serial_input = "serial_input";
specparam mgc_dft_pin_type$my_serial_output = "serial_output";
endspecify
endmodule

The following example is a BC_2 cell definition using the Add Technology Cell command:

add technology cell my_bc_2 bc_2

-inputs my_shiftdr my_clockdr my_updatedr my_parallel_input my_serial_input \
my_mode \
-outputs my_serial_output my_parallel_output \
-connect my_shiftdr/shiftdr my_clockdr/clockdr my_updatedr/updatedr \
my_parallel_input/parallel_input my_serial_input/serial_input my_mode/mode23 \
my_serial_output/serial_output my_parallel_output/parallel_output

BC_2_A Cell
Figure 4-3. Generic BC_2_A Cell
mode_1 serial_output mode_3

& control_to_bc7
G1

serial_input 1
parallel_output
1 G1

1
1D 1D 1
C1 C1

serial_input
updatedr clockdr shiftdr

The following example is a Verilog BC_2_A definition using the ‘mgc_dft_cell_type’ attribute:

74 Boundary Scan Process Guide, V8.2007_3

August 2007
 Boundary Scan Customizations
Technology Mapping

module my_bc_2_a (my_shiftdr, my_clockdr, my_updatedr, my_parallel_in,\

my_serial_in, my_mode1, my_mode2 my_serial_out, my_parallel_out, \
my_control_signal);

input my_shiftdr, my_clockdr, my_updatedr, my_parallel_in, my_serial_in,\

my_mode1, my_mode2;

output my_serial_out, my_parallel_out, my_control_signal;

specify
specparam mgc_dft_cell_type = "bc_2_a";
specparam mgc_dft_pin_type$my_clockdr = "clockdr";
specparam mgc_dft_pin_type$my_shiftdr = "shiftdr";
specparam mgc_dft_pin_type$my_updatedr = "updatedr";
specparam mgc_dft_pin_type$my_mode1 = "mode_1";
specparam mgc_dft_pin_type$my_mode2 = "mode_3";
specparam mgc_dft_pin_type$my_parallel_in = "parallel_input";
specparam mgc_dft_pin_type$my_parallel_out = "parallel_output";
specparam mgc_dft_pin_type$my_serial_in = "serial_input";
specparam mgc_dft_pin_type$my_serial_out = "serial_output";
specparam mgc_dft_pin_type$my_control_signal = "control_to_bc7";
endspecify
endmodule

The following example is a BC_2_A cell definition using the Add Technology Cell command:

add technology cell my_bc_2_a bc_2_a

-inputs my_shiftdr my_clockdr my_updatedr my_parallel_in my_serial_in \
my_mode1 my_mode2 \
-outputs my_serial_out my_parallel_out \
-connect my_shiftdr/shiftdr my_clockdr/clockdr my_updatedr/updatedr \
my_parallel_in/parallel_input my_serial_in/serial_input my_mode1/mode_1 \
my_mode2/mode_3 my_serial_out/serial_output my_parallel_out/parallel_output \
my_control_signal/control_to_bc7

Boundary Scan Process Guide, V8.2007_3 75

August 2007
Boundary Scan Customizations
Technology Mapping

BC_2_A_EXT Cell
Figure 4-4. Generic BC_2_A_EXT Cell
mode_1 serial_output mode_3

G1
& control_to_bc7

parallel_input 1
parallel_output
1 G1

1
1D 1D 1
C1 C1

serial_input
updatedr clockdr shiftdr
G1

1
1
intestl

The following example is a Verilog BC_2_A_EXT definition using the ‘mgc_dft_cell_type’

attribute:

module my_bc_2_a_ext (my_shiftdr, my_clockdr, my_updatedr, my_intestl\

my_parallel_in, my_serial_in, my_mode1, my_mode2 my_serial_out, \
my_parallel_out, my_control_signal);

input my_shiftdr, my_clockdr, my_updatedr, my_intestl, my_parallel_in, \

my_serial_in, my_mode1, my_mode2;

output my_serial_out, my_parallel_out, my_control_signal;

specify
specparam mgc_dft_cell_type = "bc_2_a_ext";
specparam mgc_dft_pin_type$my_clockdr = "clockdr";
specparam mgc_dft_pin_type$my_shiftdr = "shiftdr";
specparam mgc_dft_pin_type$my_updatedr = "updatedr";
specparam mgc_dft_pin_type$my_intestl = "intestl";
specparam mgc_dft_pin_type$my_mode1 = "mode_1";
specparam mgc_dft_pin_type$my_mode2 = "mode_3";
specparam mgc_dft_pin_type$my_parallel_in = "parallel_input";
specparam mgc_dft_pin_type$my_parallel_out = "parallel_output";
specparam mgc_dft_pin_type$my_serial_in = "serial_input";
specparam mgc_dft_pin_type$my_serial_out = "serial_output";
specparam mgc_dft_pin_type$my_control_signal = "control_to_bc7";
endspecify
endmodule

76 Boundary Scan Process Guide, V8.2007_3

August 2007
 Boundary Scan Customizations
Technology Mapping

The following example is a BC_2_A_EXT cell definition using the Add Technology Cell
command:

add technology cell my_bc_2_a_ext bc_2_a_ext

-inputs my_shiftdr my_clockdr my_updatedr my_intestl my_parallel_in my_serial_in \
my_mode1 my_mode2 \
-outputs my_serial_out my_parallel_out my_control_signal \
-connect my_shiftdr/shiftdr my_clockdr/clockdr my_updatedr/updatedr \
my_intestl/intestl my_parallel_in/parallel_input my_serial_in/serial_input \
my_mode1/mode_1 my_mode2/mode_3 my_serial_out/serial_output \
my_parallel_out/parallel_output my_control_signal/control_to_bc7

BC_2_B Cell
Figure 4-5. Generic BC_2_B Cell
mode_1 serial_output mode_3

G1
OR control_to_bc7

parallel_input 1
parallel_output
1 G1

1
1D 1D 1
C1 C1

serial_input
updatedr clockdr shiftdr

Boundary Scan Process Guide, V8.2007_3 77

August 2007
Boundary Scan Customizations
Technology Mapping

The following example is a Verilog BC_2_B definition using the ‘mgc_dft_cell_type’ attribute:

module my_bc_2_b (my_shiftdr, my_clockdr, my_updatedr, my_parallel_in,\

my_serial_in, my_mode1, my_mode2 my_serial_out, my_parallel_out, \
my_control_signal);

input my_shiftdr, my_clockdr, my_updatedr, my_parallel_in, my_serial_in,\

my_mode1, my_mode2;

output my_serial_out, my_parallel_out, my_control_signal;

specify
specparam mgc_dft_cell_type = "bc_2_b";
specparam mgc_dft_pin_type$my_clockdr = "clockdr";
specparam mgc_dft_pin_type$my_shiftdr = "shiftdr";
specparam mgc_dft_pin_type$my_updatedr = "updatedr";
specparam mgc_dft_pin_type$my_mode1 = "mode_1";
specparam mgc_dft_pin_type$my_mode2 = "mode_3";
specparam mgc_dft_pin_type$my_parallel_in = "parallel_input";
specparam mgc_dft_pin_type$my_parallel_out = "parallel_output";
specparam mgc_dft_pin_type$my_serial_in = "serial_input";
specparam mgc_dft_pin_type$my_serial_out = "serial_output";
specparam mgc_dft_pin_type$my_control_signal = "control_to_bc7";
endspecify
endmodule

The following example is a BC_2_B cell definition using the Add Technology Cell command:

add technology cell my_bc_2_b bc_2_b

-inputs my_shiftdr my_clockdr my_updatedr my_parallel_in my_serial_in \
my_mode1 my_mode2 \
-outputs my_serial_out my_parallel_out \
-connect my_shiftdr/shiftdr my_clockdr/clockdr my_updatedr/updatedr \
my_parallel_in/parallel_input my_serial_in/serial_input my_mode1/mode_1 \
my_mode2/mode_3 my_serial_out/serial_output my_parallel_out/parallel_output \
my_control_signal/control_to_bc7

BC_3 Cell
Figure 4-6. Generic BC_3 Cell
serial_output

G1
parallel_input
1 parallel_output
G1
1

1
1D
1
C1

shiftdr serial_input mode23

clockdr

78 Boundary Scan Process Guide, V8.2007_3

August 2007
 Boundary Scan Customizations
Technology Mapping

The following example is a Verilog BC_3 definition using the ‘mgc_dft_cell_type’ attribute:

module my_bc_3 (my_shiftdr, my_clockdr, my_parallel_in, my_serial_in \

my_mode, my_serial_out, my_parallel_out;

input my_shiftdr, my_clockdr, my_parallel_in, my_serial_in, my_mode;

output my_serial_out, my_parallel_out;

specify
specparam mgc_dft_cell_type = "bc_3";
specparam mgc_dft_pin_type$my_clockdr = "clockdr";
specparam mgc_dft_pin_type$my_shiftdr = "shiftdr";
specparam mgc_dft_pin_type$my_mode1 = "mode23";
specparam mgc_dft_pin_type$my_parallel_in = "parallel_input";
specparam mgc_dft_pin_type$my_parallel_out = "parallel_output";
specparam mgc_dft_pin_type$my_serial_in = "serial_input";
specparam mgc_dft_pin_type$my_serial_out = "serial_output";
endspecify
endmodule

The following example is a BC_3 cell definition using the Add Technology Cell command:

add technology cell my_bc_3 bc_3

-inputs my_shiftdr my_clockdr my_parallel_in my_serial_in my_mode \
-outputs my_serial_out my_parallel_out \
-connect my_shiftdr/shiftdr my_clockdr/clockdr my_parallel_in/parallel_input \
my_serial_in/serial_input my_mode/mode23 my_serial_out/serial_output \
my_parallel_out/parallel_output

BC_4 Cell
Figure 4-7. Generic BC_4 Cell
serial_output

parallel_input parallel_output

G1

1
1D
1
C1

serial_input
clockdr
shiftdr

Boundary Scan Process Guide, V8.2007_3 79

August 2007
Boundary Scan Customizations
Technology Mapping

The following example is a Verilog BC_4 definition using the ‘mgc_dft_cell_type’ attribute:

module my_bc_4 (my_shiftdr, my_clockdr, my_parallel_in, my_serial_in, \

my_serial_out, my_parallel_out);

input my_shiftdr, my_clockdr, my_parallel_in, my_serial_in;

output my_serial_out, my_parallel_out;

specify
specparam mgc_dft_cell_type = "bc_4";
specparam mgc_dft_pin_type$my_clockdr = "clockdr";
specparam mgc_dft_pin_type$my_shiftdr = "shiftdr";
specparam mgc_dft_pin_type$my_parallel_in = "parallel_input";
specparam mgc_dft_pin_type$my_parallel_out = "parallel_output";
specparam mgc_dft_pin_type$my_serial_in = "serial_input";
specparam mgc_dft_pin_type$my_serial_out = "serial_output";
endspecify
endmodule

The following example is a BC_4 cell definition using the Add Technology Cell command:

add technology cell my_bc_4 bc_4

-inputs my_shiftdr my_clockdr my_parallel_in my_serial_in \
-outputs my_serial_out my_parallel_out \
-connect my_shiftdr/shiftdr my_clockdr/clockdr my_parallel_in/parallel_input \
my_serial_in/serial_input my_serial_out/serial_output \
my_parallel_out/parallel_output

BC_5 Cell
Figure 4-8. Generic BC_5 Cell
intestl shiftdr serial_output mode
G1

parallel_input 1
parallel_output
1
G1
G1
1
1
1 1D 1D
1
C1 C1

serial_input clockdr updatedr

80 Boundary Scan Process Guide, V8.2007_3

August 2007
 Boundary Scan Customizations
Technology Mapping

The following example is a Verilog BC_5 definition using the ‘mgc_dft_cell_type’ attribute:

module my_bc_5 (my_shiftdr, my_clockdr, my_updatedr, my_parallel_in,\

my_serial_in, my_mode, my_intestl, my_serial_out, my_parallel_out);

input my_shiftdr, my_clockdr, my_updatedr, my_parallel_in, my_serial_in,\

my_mode, my_intestl;

output my_serial_out, my_parallel_out;

specify
specparam mgc_dft_cell_type = "bc_5";
specparam mgc_dft_pin_type$my_clockdr = "clockdr";
specparam mgc_dft_pin_type$my_shiftdr = "shiftdr";
specparam mgc_dft_pin_type$my_updatedr = "updatedr";
specparam mgc_dft_pin_type$my_intestl = "intestl";
specparam mgc_dft_pin_type$my_mode = "mode";
specparam mgc_dft_pin_type$my_parallel_in = "parallel_input";
specparam mgc_dft_pin_type$my_parallel_out = "parallel_output";
specparam mgc_dft_pin_type$my_serial_in = "serial_input";
specparam mgc_dft_pin_type$my_serial_out = "serial_output";
endspecify
endmodule

The following example is a BC_5 cell definition using the Add Technology Cell command:

add technology cell my_bc_5 bc_5

-inputs my_shiftdr my_clockdr my_updatedr my_intestl my_parallel_in my_serial_in \
my_mode \
-outputs my_serial_out my_parallel_out \
-connect my_shiftdr/shiftdr my_clockdr/clockdr my_updatedr/updatedr \
my_parallel_in/parallel_input my_serial_in/serial_input my_intestl/intestl \
my_mode/mode my_serial_out/serial_output my_parallel_out/parallel_output

Boundary Scan Process Guide, V8.2007_3 81

August 2007
Boundary Scan Customizations
Technology Mapping

BC_7 Cell
Figure 4-9. Generic BC_7 Cell
control_from_bc2a
mode_1 shiftdr serial_output

G1

parallel_input 1
parallel_output
1
&

G1
G1
1
1 1D 1D
1 C1
1 C1

G1

1 parallel_input_in
parallel_output_in 1

mode_2 clockdr updatedr

serial_input

The following example is a Verilog BC_7 definition using the ‘mgc_dft_cell_type’ attribute:

module my_bc_7 (my_shiftdr, my_clockdr, my_updatedr, my_parallel_in,\

my_parallel_in_in, my_serial_in, my_mode1, my_mode2, \
my_control_signal, my_serial_out, my_parallel_out, \
my_parallel_out_in);

input my_shiftdr, my_clockdr, my_updatedr, my_parallel_in, my_serial_in,\

my_parallel_in_in, my_mode1, my_mode2, my_control_signal;

output my_serial_out, my_parallel_out, my_parallel_out_in;

specify
specparam mgc_dft_cell_type = "bc_7";
specparam mgc_dft_pin_type$my_clockdr = "clockdr";
specparam mgc_dft_pin_type$my_shiftdr = "shiftdr";
specparam mgc_dft_pin_type$my_updatedr = "updatedr";
specparam mgc_dft_pin_type$my_mode1 = "mode_1";
specparam mgc_dft_pin_type$my_mode2 = "mode_2";
specparam mgc_dft_pin_type$my_parallel_in = "parallel_input";
specparam mgc_dft_pin_type$my_parallel_out = "parallel_output";
specparam mgc_dft_pin_type$my_parallel_in_in = "parallel_input_in";
specparam mgc_dft_pin_type$my_parallel_out_in = "parallel_output_in";
specparam mgc_dft_pin_type$my_serial_in = "serial_input";
specparam mgc_dft_pin_type$my_serial_out = "serial_output";
specparam mgc_dft_pin_type$my_control_signal = "control_from_bc2a";
endspecify
endmodule

82 Boundary Scan Process Guide, V8.2007_3

August 2007
 Boundary Scan Customizations
Technology Mapping

The following example is a BC_7 cell definition using the Add Technology Cell command:

add technology cell my_bc_7 bc_7

-inputs my_shiftdr my_clockdr my_updatedr my_parallel_in my_serial_in \
my_parallel_in_in my_mode1 my_mode2 my_control_signal\
-outputs my_serial_out my_parallel_out my_parallel_out_in\
-connect my_shiftdr/shiftdr my_clockdr/clockdr my_updatedr/updatedr \
my_parallel_in/parallel_input my_parallel_in_in/parallel_input_in \
my_serial_in/serial_input my_mode1/mode_1 my_mode2/mode_2 \
my_serial_out/serial_output my_parallel_out/parallel_output \
my_parallel_out_in/parallel_output_in my_control_signal/control_from_bc2a

BC_7_LOW Cell
Figure 4-10. Generic BC_7_LOW Cell
control_from_bc2a
mode_1 shiftdr serial_output

G1

parallel_input 1
parallel_output
1
&

G1
G1
1
1 1D 1D
1 C1
1 C1

G1

1 parallel_input_in
parallel_output_in 1

mode_2 clockdr updatedr

serial_input

Boundary Scan Process Guide, V8.2007_3 83

August 2007
Boundary Scan Customizations
Technology Mapping

The following example is a Verilog BC_7_LOW definition using the ‘mgc_dft_cell_type’

attribute:

module my_bc_7_low (my_shiftdr, my_clockdr, my_updatedr, my_parallel_in,\

my_parallel_in_in, my_serial_in, my_mode1, my_mode2, \
my_control_signal, my_serial_out, my_parallel_out, \
my_parallel_out_in);

input my_shiftdr, my_clockdr, my_updatedr, my_parallel_in, my_serial_in,\

my_parallel_in_in, my_mode1, my_mode2, my_control_signal;

output my_serial_out, my_parallel_out, my_parallel_out_in;

specify
specparam mgc_dft_cell_type = "bc_7_low";
specparam mgc_dft_pin_type$my_clockdr = "clockdr";
specparam mgc_dft_pin_type$my_shiftdr = "shiftdr";
specparam mgc_dft_pin_type$my_updatedr = "updatedr";
specparam mgc_dft_pin_type$my_mode1 = "mode_1";
specparam mgc_dft_pin_type$my_mode2 = "mode_2";
specparam mgc_dft_pin_type$my_parallel_in = "parallel_input";
specparam mgc_dft_pin_type$my_parallel_out = "parallel_output";
specparam mgc_dft_pin_type$my_parallel_in_in = "parallel_input_in";
specparam mgc_dft_pin_type$my_parallel_out_in = "parallel_output_in";
specparam mgc_dft_pin_type$my_serial_in = "serial_input";
specparam mgc_dft_pin_type$my_serial_out = "serial_output";
specparam mgc_dft_pin_type$my_control_signal = "control_from_bc2a";
endspecify
endmodule

The following example is a BC_7_LOW cell definition using the Add Technology Cell
command:

add technology cell my_bc_7_low bc_7_low

-inputs my_shiftdr my_clockdr my_updatedr my_parallel_in my_serial_in \
my_parallel_in_in my_mode1 my_mode2 my_control_signal\
-outputs my_serial_out my_parallel_out my_parallel_out_in\
-connect my_shiftdr/shiftdr my_clockdr/clockdr my_updatedr/updatedr \
my_parallel_in/parallel_input my_parallel_in_in/parallel_input_in \
my_serial_in/serial_input my_mode1/mode_1 my_mode2/mode_2 \
my_serial_out/serial_output my_parallel_out/parallel_output \
my_parallel_out_in/parallel_output_in my_control_signal/control_from_bc2a

84 Boundary Scan Process Guide, V8.2007_3

August 2007
 Boundary Scan Customizations
Technology Mapping

BC_8 Cell
Figure 4-11. Generic BC_8 Cell
mode shiftdr serial_output

G1

parallel_input 1
parallel_output
1

G1

1
1D 1D
1 C1 C1
parallel_output_in parallel_input_in
serial_input clockdr updatedr

The following example is a Verilog BC_8 definition using the ‘mgc_dft_cell_type’ attribute:

module my_bc_8 (my_shiftdr, my_clockdr, my_updatedr, my_parallel_in,\

my_parallel_in_in, my_serial_in, my_mode, my_serial_out, \
my_parallel_out, my_parallel_out_in);

input my_shiftdr, my_clockdr, my_updatedr, my_parallel_in, my_serial_in,\

my_parallel_in_in, my_mode;

output my_serial_out, my_parallel_out, my_parallel_out_in;

specify
specparam mgc_dft_cell_type = "bc_8";
specparam mgc_dft_pin_type$my_clockdr = "clockdr";
specparam mgc_dft_pin_type$my_shiftdr = "shiftdr";
specparam mgc_dft_pin_type$my_updatedr = "updatedr";
specparam mgc_dft_pin_type$my_mode = "mode";
specparam mgc_dft_pin_type$my_parallel_in = "parallel_input";
specparam mgc_dft_pin_type$my_parallel_out = "parallel_output";
specparam mgc_dft_pin_type$my_parallel_in_in = "parallel_input_in";
specparam mgc_dft_pin_type$my_parallel_out_in = "parallel_output_in";
specparam mgc_dft_pin_type$my_serial_in = "serial_input";
specparam mgc_dft_pin_type$my_serial_out = "serial_output";
endspecify
endmodule

Boundary Scan Process Guide, V8.2007_3 85

August 2007
Boundary Scan Customizations
Technology Mapping

The following example is a BC_8 cell definition using the Add Technology Cell command:

add technology cell my_bc_8 bc_8

-inputs my_shiftdr my_clockdr my_updatedr my_parallel_in my_serial_in \
my_parallel_in_in my_mode \
-outputs my_serial_out my_parallel_out my_parallel_out_in \
-connect my_shiftdr/shiftdr my_clockdr/clockdr my_updatedr/updatedr \
my_parallel_in/parallel_input my_parallel_in_in/parallel_input_in \
my_serial_in/serial_input my_mode/mode my_serial_out/serial_output \
my_parallel_out/parallel_output my_parallel_out_in/parallel_output_in

BC_9 Cell
Figure 4-12. Generic BC_9 Cell

mode_1 shiftdr serial_output mode2

G1

parallel_input 1
parallel_output
G1 1

1
1

G1

1
1D 1D
1 C1 C1
pin_monitor parallel_input_in
serial_input clockdr updatedr

86 Boundary Scan Process Guide, V8.2007_3

August 2007
 Boundary Scan Customizations
Technology Mapping

The following example is a Verilog BC_9 definition using the ‘mgc_dft_cell_type’ attribute:

module my_bc_9 (my_shiftdr, my_clockdr, my_updatedr, my_parallel_in,\

my_parallel_in_in, my_serial_in, my_mode1, my_mode2, \
my_serial_out, my_parallel_out, my_pin_monitor);

input my_shiftdr, my_clockdr, my_updatedr, my_parallel_in, my_serial_in,\

my_parallel_in_in, my_mode1, my_mode2;

output my_serial_out, my_parallel_out, my_pin_monitor;

specify
specparam mgc_dft_cell_type = "bc_9";
specparam mgc_dft_pin_type$my_clockdr = "clockdr";
specparam mgc_dft_pin_type$my_shiftdr = "shiftdr";
specparam mgc_dft_pin_type$my_updatedr = "updatedr";
specparam mgc_dft_pin_type$my_mode1 = "mode_1";
specparam mgc_dft_pin_type$my_mode2 = "mode2";
specparam mgc_dft_pin_type$my_parallel_in = "parallel_input";
specparam mgc_dft_pin_type$my_parallel_out = "parallel_output";
specparam mgc_dft_pin_type$my_parallel_in_in = "parallel_input_in";
specparam mgc_dft_pin_type$my_pin_monitor = "pin_monitor";
specparam mgc_dft_pin_type$my_serial_in = "serial_input";
specparam mgc_dft_pin_type$my_serial_out = "serial_output";
endspecify
endmodule

The following example is a BC_9 cell definition using the Add Technology Cell command:

add technology cell my_bc_9 bc_9

-inputs my_shiftdr my_clockdr my_updatedr my_parallel_in my_serial_in \
my_parallel_in_in my_mode1 my_mode2 \
-outputs my_serial_out my_parallel_out my_pin_monitor\
-connect my_shiftdr/shiftdr my_clockdr/clockdr my_updatedr/updatedr \
my_parallel_in/parallel_input my_parallel_in_in/parallel_input_in \
my_serial_in/serial_input my_mode1/mode_1 my_mode2/mode2 \
my_serial_out/serial_output my_parallel_out/parallel_output \
my_pin_monitor/pin_monitor

Boundary Scan Process Guide, V8.2007_3 87

August 2007
Boundary Scan Customizations
Technology Mapping

BC_10 Cell
Figure 4-13. Generic BC_10 Cell
mode shiftdr serial_output

G1

parallel_input 1
parallel_output
1

G1

1
1D 1D
1 C1 C1
pin_monitor parallel_input_in
serial_input clockdr updatedr

The following example is a Verilog BC_10 definition using the ‘mgc_dft_cell_type’ attribute:

module my_bc_10 (my_shiftdr, my_clockdr, my_updatedr, my_parallel_in,\

my_parallel_in_in, my_serial_in, my_mode, my_serial_out, \
my_parallel_out, my_pin_monitor);

input my_shiftdr, my_clockdr, my_updatedr, my_parallel_in, my_serial_in,\

my_parallel_in_in, my_mode;

output my_serial_out, my_parallel_out, my_pin_monitor;

specify
specparam mgc_dft_cell_type = "bc_10";
specparam mgc_dft_pin_type$my_clockdr = "clockdr";
specparam mgc_dft_pin_type$my_shiftdr = "shiftdr";
specparam mgc_dft_pin_type$my_updatedr = "updatedr";
specparam mgc_dft_pin_type$my_mode = "mode";
specparam mgc_dft_pin_type$my_parallel_in = "parallel_input";
specparam mgc_dft_pin_type$my_parallel_out = "parallel_output";
specparam mgc_dft_pin_type$my_parallel_in_in = "parallel_input_in";
specparam mgc_dft_pin_type$my_pin_monitor = "pin_monitor";
specparam mgc_dft_pin_type$my_serial_in = "serial_input";
specparam mgc_dft_pin_type$my_serial_out = "serial_output";
endspecify
endmodule

88 Boundary Scan Process Guide, V8.2007_3

August 2007
 Boundary Scan Customizations
Technology Mapping

The following example is a BC_10 cell definition using the Add Technology Cell command:

add technology cell my_bc_10 bc_10

-inputs my_shiftdr my_clockdr my_updatedr my_parallel_in my_serial_in \
my_parallel_in_in my_mode \
-outputs my_serial_out my_parallel_out my_pin_monitor\
-connect my_shiftdr/shiftdr my_clockdr/clockdr my_updatedr/updatedr \
my_parallel_in/parallel_input my_parallel_in_in/parallel_input_in \
my_serial_in/serial_input my_mode/mode my_serial_out/serial_output \
my_parallel_out/parallel_output my_pin_monitor/pin_monitor

BC_X Cell
It may be difficult to classify certain technology boundary scan cells into any of the standard
boundary scan cell types used in BSDArchitect. In this case, you use the special cell type
‘BC_X’. If you specify this cell type, the design rules checks specified in Boundary Scan Rules
Checking do not prevent the insertion of boundary scan.

Figure 4-14. BC_X Cell

clockdr shiftdr updatedr

parallel_input parallel_output

serial_input serial_output

mode mode_1 mode_2 mode_3 mode23

Boundary Scan Process Guide, V8.2007_3 89

August 2007
Boundary Scan Customizations
Technology Mapping

The following example is a Verilog BC_X definition using the ‘mgc_dft_cell_type’ attribute:

module my_bc_x (my_shiftdr, my_clockdr, my_updatedr, my_parallel_in,\

my_serial_in, my_mode, my_mode1, my_mode2, my_mode3, my_mode4, \
my_serial_out, my_parallel_out);

input my_shiftdr, my_clockdr, my_updatedr, my_parallel_in, my_serial_in,\

my_mode, my_mode1, my_mode2, my_mode3, my_mode4;

output my_serial_out, my_parallel_out;

specify
specparam mgc_dft_cell_type = "bc_x";
specparam mgc_dft_pin_type$my_clockdr = "clockdr";
specparam mgc_dft_pin_type$my_shiftdr = "shiftdr";
specparam mgc_dft_pin_type$my_updatedr = "updatedr";
specparam mgc_dft_pin_type$my_mode = "mode";
specparam mgc_dft_pin_type$my_mode1 = "mode_1";
specparam mgc_dft_pin_type$my_mode2 = "mode_2";
specparam mgc_dft_pin_type$my_mode3 = "mode_3";
specparam mgc_dft_pin_type$my_mode4 = "mode23";
specparam mgc_dft_pin_type$my_parallel_in = "parallel_input";
specparam mgc_dft_pin_type$my_parallel_out = "parallel_output";
specparam mgc_dft_pin_type$my_serial_in = "serial_input";
specparam mgc_dft_pin_type$my_serial_out = "serial_output";
endspecify
endmodule

The following example is a BC_X cell definition using the Add Technology Cell command:

add technology cell my_bc_x bc_x

-inputs my_shiftdr my_clockdr my_updatedr my_parallel_in my_serial_in \
my_mode my_mode1 my_mode2 my_mode3 my_mode4 \
-outputs my_serial_out my_parallel_out \
-connect my_shiftdr/shiftdr my_clockdr/clockdr my_updatedr/updatedr \
my_parallel_in/parallel_input my_serial_in/serial_input my_mode/mode \
my_mode1/mode_1 my_mode2/mode_2 my_mode3/mode_3 my_mode4/mode23 \
my_serial_out/serial_output my_parallel_out/parallel_output

Defining Boundary Scan Cells With Built-In Pads

BSDArchitect supports technology mapping capabilities for boundary scan cells with I/O pads
built into them. To specify a boundary scan cell with built-in I/O pads, you must include the
following VHDL attribute or Verilog specparam:

attribute mgc_dft_built_in_pad_type of tech_pad_name : entity is \

pad_cell_type;
specparam mgc_dft_built_in_pad_type = pad_cell_type;

Valid pad cell types include input, output, differential_in, differential_out, tristate, bidirectional,
and opencollector.

The following two examples illustrate required technology mapping information to map a
boundary scan cell with built-in I/O pads.

90 Boundary Scan Process Guide, V8.2007_3

August 2007
 Boundary Scan Customizations
Technology Mapping

Example 1 — VHDL Example

entity vendor_bc1_outpad is
port (pi, si : in std_ulogic;
so : out std_ulogic;
mode_1, mode_2 : in std_ulogic;
shdr, updr, ckdr : in std_ulogic;
vcc, gnd : in std_ulogic;
opn_s : in std_ulogic;
pad : out std_ulogic;
);
// Boundary scan cell related information
attribute mgc_dft_cell_type : string;
attribute mgc_dft_pin_type : string;
attribute mgc_dft_connect : string;
attribute mgc_dft_cell_type of vendor_bc1_outpad : entity is“bc_1”;
attribute mgc_dft_pin_type of pi : signal is “parallel_input”;
attribute mgc_dft_pin_type of si : signal is “serial_input”;
attribute mgc_dft_pin_type of so : signal is “serial_output”;
attribute mgc_dft_pin_type of shdr : signal is “shiftdr”;
attribute mgc_dft_pin_type of ckdr : signal is “clockdr”;
attribute mgc_dft_pin_type of updr : signal is “updatedr”;
attribute mgc_dft_pin_type of vcc : signal is “vdd”;
attribute mgc_dft_pin_type of gnd: signal is “gnd”;
attribute mgc_dft_pin_type of opn_s : signal is “open”;
attribute mgc_dft_nonexistent_signals of vendor_bc1 : entity is “mode”;
attribute mgc_dft_connect of mode_1 : signal is “mode_1_v”;
attribute mgc_dft_connect of mode_2 : signal is “mode_2_v”;
// Pad output signal
attribute mgc_dft_pin_type of pad : signal is “parallel_output”;
// Built-in pad information
attribute mgc_dft_built_in_pad_type : string;
attribute mgc_dft_built_in_pad_type of vendor_bd1_outpad : entity is \
“output”;
end vendor_bc1_outpad;

Example 2 — Verilog Example

module vendor_bc7_pad (control_from_bc2a, shdr, clkdr, updr,
parallel_input, serial_input, mode_1, mode_2,
serial_output, v_parallel_output_in,
bidi_enable, pad);

input control_from_bc2a, shdr, clkdr, updr, parallel_input,

serial_input, mode_1, mode_2, bidi_enable;
output serial_output, v_parallel_output_in;
inout pad;

specify
specparam mgc_dft_cell_type = “bc_7”;
specparam mgc_dft_pin_type$control_from_bc2a = “control_from_bc2a”;
specparam mgc_dft_pin_type$clkdr = “clockdr”;
specparam mgc_dft_pin_type$shdr = “shiftdr”;
specparam mgc_dft_pin_type$updr = “updatedr”;
specparam mgc_dft_pin_type$mode_1 = “mode_1”;
specparam mgc_dft_pin_type$mode_2 = “mode_2”;
specparam mgc_dft_pin_type$parallel_input =“parallel_input”;

Boundary Scan Process Guide, V8.2007_3 91

August 2007
Boundary Scan Customizations
Technology Mapping

specparam mgc_dft_pin_type$serial_input = “serial_input”;

specparam mgc_dft_pin_type$serial_output = “serial_output”;

// Built-in pad information

specparam mgc_dft_built_in_pad_type = “bidirectional”;

// Pad output, enable, and bidi_in information

specparam mgc_dft_pin_type$pad = “parallel_output”;
specparam mgc_dft_pin_type$bidi_enable = “oe”;
specparam mgc_dft_pin_type$v_parallel_output_in =“parallel_output_in”;
endspecify
endmodule

Defining I/O Pads

BSDArchitect provides the ability to map I/O pads with particular technologies. Using the Add
Pad Cell command, you can map technology cells to the I/O pads you may have previously
added. However, before you associate a particular pad cell with a technology-specific cell, you
must first define the technology cell information with the Add Technology Cell command.

ADD TEchnology Cell cell_name cell_type -INPuts input_port... -Outputs output_port...

[-INOuts inout_port...] -Connect connect_pairs... [-Nonexistent generic_ports...]
Once you’ve defined a technology cell name, you can use the technology cell name as input to
the Add Pad Cell command.

ADD PAd Cell technology_cell_name core_port_name...

BSDArchitect supports the following types of I/O pads:

• Input Pad
• Output Pad
• Tri-state Pad
• Bidirectional Pad
• Open Collector Output Pad
• Differential Input and Output Pads
You add either generic I/O pads or technology-specific I/O pads. The following sections discuss
adding generic I/O pads of these types using the tool commands. You can also define certain
attributes in VHDL or create specparam settings in Verilog to add the same port information.

To add technology-mapped pads to core ports, issue the following command:

ADD PAd Cell {technology_cell_name | None} core_port_name…

For more information on this command, refer to Add Pad Cell in the BSDArchitect Reference
Manual.

92 Boundary Scan Process Guide, V8.2007_3

August 2007
 Boundary Scan Customizations
Technology Mapping

Input Pad
Figure 4-15. Basic Input Pad

pin
din

Input Pad

The following examples create the input pad my_iopad_in using the Add Technology Cell
command and using Verilog specparams:

add technology cell input my_iopad_in -input my_pin -output my_din \

-connect my_pin/pin my_din/din
module my_iopad_in (my_pin, my_din);
input my_pin;
output my_din;

// Define input pad with specparams

specify
// PAD cell type
specparam mgc_dft_cell_type = "input_pad";

// PAD port mapping information

specparam mgc_dft_pin_type$my_pin = "pin";
specparam mgc_dft_pin_type$my_din = "data_input";

endspecify
endmodule

Output Pad
Figure 4-16. Basic Output Pad

pin
dout

Output Pad

The following examples create the output pad my_iopad_out using the Add Technology Cell
command and using Verilog specparams:

add technology cell output my_iopad_out -input my_dout -output my_pin \

-connect my_pin/pin my_dout/dout

Boundary Scan Process Guide, V8.2007_3 93

August 2007
Boundary Scan Customizations
Technology Mapping

module my_iopad_out (my_pin, my_dout);

input my_dout;
output my_pin;

// Define output pad with specparams

specify
// PAD cell type
specparam mgc_dft_cell_type = "output_pad";

// PAD port mapping information

specparam mgc_dft_pin_type$my_dout = "data_output";
specparam mgc_dft_pin_type$my_pin = "pin";

endspecify
endmodule

Tri-state Pad
To add tri-state pads, use the Add Tristate Port command. For more information, refer to the
Add Tristate Port command in the BSDArchitect Reference Manual.

Figure 4-17. Basic Tri-State Pad

oe
pin
dout

Tri-state Pad

The following examples create the tri-state pad my_tri_l using the Add Technology Cell
command and using Verilog specparams:

add technology cell tristate my_tri_l \

-input my_dout my_oe \
-output my_pin \
-connect my_din/din my_dout/dout my_oe/oe

94 Boundary Scan Process Guide, V8.2007_3

August 2007
 Boundary Scan Customizations
Technology Mapping

module my_tri_l (my_dout, my_oe, my_din, PI);

input my_dout, my_oe, PI;
output my_din;

// Define tri-state pad with specparams

specify
// PAD cell type
specparam mgc_dft_cell_type = "tristate_pad";

// PAD port mapping information

specparam mgc_dft_pin_type$my_dout = "data_output";
specparam mgc_dft_pin_type$my_oe = "output_enable_h";
specparam mgc_dft_pin_type$my_din = "pin";
endspecify

endmodule

This Verilog model specifies mapping of the output enable, my_oe, to output_enable_h.
Alternatively, it could map to output_enable_l. These different mappings provide a way to
specify the enable signal of the pad as active high or active low.

Bidirectional Pad
You can add bidirectional pads using the Add Tristate Port command. Figure 4-18 illustrates a
generic bidirectional pad.

Figure 4-18. Basic Bidirectional Pad

oe
pin
dout

din
Bidirectional Pad

The following examples create the bidirectional pad my_bidi_l using the Add Technology Cell
command and using Verilog specparams:

add technology cell bidirectional my_bidi_l -input my_dout my_oe -output my_din \
-inout my_pin -connect my_din/din my_dout/dout my_oe/oe

Boundary Scan Process Guide, V8.2007_3 95

August 2007
Boundary Scan Customizations
Technology Mapping

module my_bidi_l (my_pin, my_dout, my_oe, my_din);

inout my_pin;
input my_dout, my_oe;
output my_din;

// Define bidirectional pad with specparams

specify
// PAD cell type
specparam mgc_dft_cell_type = "bidirectional_pad";

// PAD port mapping information

specparam mgc_dft_pin_type$my_dout = "data_output";
specparam mgc_dft_pin_type$my_oe = "output_enable_l";
specparam mgc_dft_pin_type$my_din = "data_input";
specparam mgc_dft_pin_type$my_pin = "pin";
endspecify

endmodule

This Verilog model specifies mapping of the output enable, my_oe, to output_enable_l.
Alternatively, it could map to output_enable_h. These different mappings provide a way to
specify the enable signal of the pad as active high or active low.

Open Collector Output Pad

To associate open collector output pads with core output ports, use the Add Opencollector Port
command. This command generates a generic open collector pad based on the options you set.

ADD OPencollector Port -Out out_port_name -Disable_result [WEAK0 | WEAK1 | PULL0 |

PULL1]
The only difference between the WEAK and PULL values is the placement of the pull-up (or
pull-down) resistor. For situations when a pull-up or pull-down is internal to the component, use
the PULL values. Otherwise, for external pull-up and pull-down resistors, use the WEAK
values.

For more information, refer to the Add Opencollector Port command in the BSDArchitect
Reference Manual.

There are two types of open collector driver pins: the H-type shown in Figure 4-19, and the
L-type shown in Figure 4-20. The H-type provides strong H (high) data and weak L (low) data
and the L-type provides strong L data and weak H data.

Note
The “open-collector” term is a commonly used name in the industry, although the driver
circuit can also be constructed based on an open-emitter (ECL), open-drain (MOSFET),
or open-source (MOSFET) configuration.

96 Boundary Scan Process Guide, V8.2007_3

August 2007
 Boundary Scan Customizations
Technology Mapping

Figure 4-19 shows the H-type of open collector pad, and Table 4-2 shows the associated truth
table. You use this type of pad with the following configurations: PNP open collector,
P-channel open drain, NPN open emitter, and N-channel open source.

Figure 4-19. H-Type Open Collector Output Pad

dout pin

H-type open collector pad

Table 4-2. H-Type Open Collector Truth Table

dout pin
0 weak0
1 1

To specify an H-type open collector output pad, issue the following command where oc_port is
the name of the port in your design that you are configuring:

add opencollector port -out oc_port -disable_result weak0

Figure 4-20 shows the L-type of open collector pad, and Table 4-3 shows the associated truth
table. You use this type of pad with the following configurations: NPN open collector,
N-channel open drain, PNP open emitter, and P-channel open source.

Figure 4-20. L-Type Open Collector Output Pad

dout pin

L-type open collector pad

Table 4-3. L-Type Open Collector Truth Table

dout pin
0 0
1 weak1

Boundary Scan Process Guide, V8.2007_3 97

August 2007
Boundary Scan Customizations
Technology Mapping

To specify an L-type open collector output pad, issue the following command where oc_port is
the name of the port in your design that you are configuring:

add opencollector port -out oc_port -disable_result weak1

Mapping information is required for pins dout and pin. The mapping information is the same for
both types of open collector pads.

The following examples create the open collector pad my_iopad_oc using the Add Technology
Cell command and using Verilog specparams:

add technology cell opencollector my_iopad_oc -input my_dout -output my_pin \

-connect my_pin/pin my_dout/dout
module my_iopad_oc (my_pin, my_dout);
input my_dout;
output my_pin;

// Define open collector pad with specparams

specify
// PAD cell type
specparam mgc_dft_cell_type = "opencollector_pad";

// PAD port mapping information

specparam mgc_dft_pin_type$my_dout = "data_output_h";
specparam mgc_dft_pin_type$my_pin = "pin_l";
endspecify

endmodule

Dout can be mapped to either data_output_h or data_output_l. Similarly, my_pin can be

mapped to pin_l or pin_h. The various combinations of these mappings determine which of the
open collector pads is used.

Differential Input and Output Pads

To associate differential pad information with specified ports, use the Add Differential Port
command.

ADD DIfferential Port core_port_name… [-Powerdown {None | High | Low}]

[-Type {Voltage | Current}] [-Diff_n_name diff_n_name…]
For more information, refer to the Add Differential Port command in the BSDArchitect
Reference Manual.

Figure 4-21 illustrates the differential input and output pads, while Table 4-3 shows the truth
tables associated with both.

98 Boundary Scan Process Guide, V8.2007_3

August 2007
 Boundary Scan Customizations
Technology Mapping

Figure 4-21. Generic Differential Input and Output Pads

pin_p pin_p

din dout

pin_n pin_n
Input Differential Pad Output Differential Pad

Table 4-4. Differential Pad Truth Tables

Input Differential Pad Output Differential Pad
pin_p pin_n din dout pin_p pin_n
0 0 X 0 0 1
0 1 0 1 1 0
1 0 1
1 1 X

The following examples create the differential input pad my_iopad_diff_in using the Add
Technology Cell command and using Verilog specparams:

add technology cell diff_in my_iopad_diff_in -input my_pin -output my_din \

-connect my_pin_n/pin_n my_din/din my_pin_p/pin_p
module my_iopad_diff_in (my_pin_p, my_pin, n, my_din);
input my_pin_p, my_pin_n;
output my_din;

// Define differential input pad with specparams

specify
// PAD cell type
specparam mgc_dft_cell_type = "differential_input_pad";

// PAD port mapping information

specparam mgc_dft_pin_type$my_pin_n = "pin_n";
specparam mgc_dft_pin_type$my_pin_p = "pin_p";
specparam mgc_dft_pin_type$my_din = "data_input";
endspecify

endmodule

The following examples create the differential output pad my_iopad_diff_out using the Add
Technology Cell command and using Verilog specparams:

add technology cell diff_out my_iopad_diff_out -input my_dout -output my_pin_p my_pin_n \
-connect my_pin_n/pin_n my_pin_n/pin_n my_dout/dout

Boundary Scan Process Guide, V8.2007_3 99

August 2007
Boundary Scan Customizations
Using a Pin Mapping File

module my_iopad_diff_out (my_pin_n, my_pin_p, my_dout);

input my_dout;
output my_pin_n, my_pin_p;

// Define differential output pad with specparams

specify
// PAD cell type
specparam mgc_dft_cell_type = "differential_output_pad";

// PAD port mapping information

specparam mgc_dft_pin_type$my_dout = "data_output";
specparam mgc_dft_pin_type$my_pin_p = "pin_p";
specparam mgc_dft_pin_type$my_pin_n = "pin_n";
endspecify

endmodule

The specparam, mgc_dft_cell_type, can also be specified as “diff_out_pad”.

Using a Pin Mapping File

A pin mapping file provides pin information and port ordering information that BSDArchitect
can use instead of specifying certain application commands. You create this file external to the
tool and read it into BSDArchitect using the Load Pin Map command. Executing a Run
command after loading the pin mapping file causes BSDArchitect to consider both the loaded
pin mapping descriptions and subsequently-entered BSDArchitect commands when generating
boundary scan circuitry.

Loading a pin mapping file can modify information you may have already supplied with
BSDArchitect commands. Specifically, information from the pin map file overrides any port
order defined with the Set Port Order command or any boundary scan cell types defined with
the Add Bscan Cell command. If loading a pin file overrides previously-specified information,
BSDArchitect generates a warning message informing you that your previous definitions have
been modified.

Pin Map File Contents

The pin mapping file contains the following information:

• Pin order information

This entry specifies boundary scan cell connection order. You can use top-level pin
names in the pin mapping file. The pin specified on the first line of the pin mapping file
connects to TDO, and each successive pin specified connects in the next highest
position. Thus, BSDArchitect orders the boundary scan cells sequentially from TDO to
TDI based on the pin order you specify in the pin map file.

100 Boundary Scan Process Guide, V8.2007_3

August 2007
 Boundary Scan Customizations
Using a Pin Mapping File

If you do not specify all the pins in the pin mapping file, unspecified pins follow the
specified pins in the boundary scan cell order. If you choose not to use a pin mapping
file, you can instead specify this information with the Set Port Order command.
• Device package pin mapping
This entry specifies the mapping of logical signals to physical pins of a particular
package. This information creates a PIN_MAP_STRING in the BSDL file.
• Pad cell types
This entry specifies the pad cell types you want to use with the pins in your design. If
you choose not to use a pin mapping file, you can instead specify this information with
the Add Pad Cell, Add Tristate Port, Add Differential Port, and Add Opencollector Port
commands.
• Boundary scan cell types
This entry specifies the boundary scan cell types you want to use with the pins in your
design. If you choose not to use a pin mapping file, you can instead specify this
information with the Add Bscan Cell command.
• Pad Inversion
The pin map file also specifies if the pad used for a particular signal is an inverting pad
or not. This is specified by using the -inv argument when specifying the
logical_port_name.

Pin Map File Syntax

The following general information applies to the pin mapping file:

• Spaces, tabs, and blank lines are equivalent

• Comments begin with either -- or //
• Information for each pin ends with a semicolon (;)
Each entry uses the following syntax:

logical_port_name PINIDs [-pwr | -gnd] [-p padcell_type] [-c cell_names] [-INV]

[-s X | 0 | 1] [-INTernal];
• logical_port_name
A required string specifying the design signal name to which you want to assign the
PINIDs.
For tri-state and bidirectional ports, you must specify the logical_port_name of the
output port. Specify the information for the control port by using a separate entry with a
value of “VOID” for the PINID field.

Boundary Scan Process Guide, V8.2007_3 101

August 2007
Boundary Scan Customizations
Using a Pin Mapping File

If the logical_port_name is TDI, TDO, TMS, TCK, or TRST then only the PINID and
-p options are valid.
Signal names VDD and VSS are valid syntax for power and ground in the pin mapping
file, and you can specify them multiple times. The tool also supports user-defined names
for power and ground pins using the -pwr and -gnd switches.
• PINIDs
A required repeatable integer or alphanumeric identifier specifying the actual pin name
or set of pin names that you want to assign to the logical_port_name. Separate multiple
PINIDs with a space.
You can use multiple PINIDs fields per line each separated by a space. This allows you
to specify a vector using individual bits. For example, the following PINID’s are valid,
and both represent the same information:
a(0) A0 -p my_pad;
a(1) A1 -p my_pad;
a(2) A2 -p my_pad;

or
a A0 A1 A2 -p my_pad my_pad my_pad

For tri-state and bidirectional ports, only one entry should have a PINID field (unless
specified bit by bit in the map file). If an entry contains more than one PINID field, the
BSDL file will contain multiple entries for the same port in the PIN_MAP attribute.
• -p padcell
An optional switch and string pair that specifies the exact pad cell you want to place on
the specified port.
• -c cell_names
An optional switch and repeatable string pair that lists the boundary scan cell (two cells,
if a bidirectional pin) you want to connect to the specified pin.
This switch is not valid when using JTAG ports (TDI, TDO, TMS, TCK, or TRST).
The boundary scan cell_names is an optional field. It may be an ASIC library cell name
or BC_1, BC_2, BC_2_A, BC_2_A_EXT, BC_2_B, BC_3, BC_4, BC_5, BC_7 or
BC_7_LOW, BC_8, BC_9, or BC_10. You must use a logical_port_name whenever
you specify a boundary scan cell name.
• -INV
An optional switch to specify the input data that the pad used with the specific port is
inverted at the output. Note that you must issue the “Set Pad Inversion ON” command in
order for the BSDArchitect to consider the inversion when generating a test bench.
• -s X | 0 | 1

102 Boundary Scan Process Guide, V8.2007_3

August 2007
 Boundary Scan Customizations
Using a Pin Mapping File

An optional switch that specifies the safe value associated with the logical_port_name.
By default, for tri-state and bidirectional boundary scan cells, the safe value is the
inactive value of the corresponding control cell. For boundary scan control cells, the
safe value is the inactive value of that control cell. For all other types of boundary scan
cells, the safe value is X.
This switch is not valid when using JTAG ports (TDI, TDO, TMS, TCK, or TRST).
• -INTernal
An optional switch that specifies that a particular port is an internal port.
Internal ports are those core ports that contain a boundary scan cell on them, but those
ports do not come to the top.
• -pwr | -gnd
An optional switch that declares the value of the logical_port_name argument as either
power or ground. In the resulting BSDL file, these ports will be listed as linkage type.
This switch is not valid when using JTAG ports (TDI, TDO, TMS, TCK, or TRST).
BSDArchitect does not place a boundary scan cell on power and ground pins.
Existing Power or Ground Pins:
If the power or ground pin exists on the core, then the tool places a generic I/O pad cell,
or a specific technology I/O pad cell that you specified with the Add Technology Cell
command using the POWER option.
The following example shows usage of the user-defined names for power and ground
(Note that the technology cell named power_cell had to have been previously defined
with the Add Technology Cell command using the POWER option):
my_pwr 71 -pwr
my_gnd 72 -gnd
custom_pwr 73 -pwr -p power_cell
VDD 74
VDD 75
VSS 76
VSS 77

BSDArchitect generates the following BSDL file when using the preceding
declarations:

Boundary Scan Process Guide, V8.2007_3 103

August 2007
Boundary Scan Customizations
Using a Pin Mapping File

port (
.
.
.
vss : linkage bit_vector(1 downto 0);
my_gnd : linkage bit ;
vdd : linkage bit_vector(1 downto 0);
my_pwr : linkage bit;
custom_pwr : linkage bit;
.
.
.
);

constant DW: PIN_MAP_STRING:=

“vss: (76, 77),” &
“my_gnd: (72),” &
“vdd: (74, 75),” &
“my_pwr: (71),” &
“custom_pwr: (73)”;

Non-existent Power or Ground Pins:

If you specify -pwr or -gnd, as well as -p padcell_type for a pin that does not exist on the
core, the tool adds a dummy I/O pad in the pad ring block.

Note
If you specify -pwr or -gnd without “-p padcell_type”, the tool will not add a pad unless
the power or ground pin already exists on the core.

The following is an excerpt from a pin mapping file specifying “-p pwr_pad -pwr” for a
nonexistent pin:
my_vdd 3 -p pwr_pad -pwr ;

BSDArchitect generates the following output files when using the preceding
declaration:
RTL generated:
module pad_instance
...
pwr_pad pwrsig ( .my_vdd ( my_vdd ));
...
The following shows the resultant BSDL file:
port (
...
my_vdd : linkage bit;
...
);

constant DW: PIN_MAP_STRING:=

...
“my_vdd: (3),” &
...

104 Boundary Scan Process Guide, V8.2007_3

August 2007
 Boundary Scan Customizations
Using a Pin Mapping File

Pin Mapping Example

The following is the default BSDArchitect pinmap file (my_pinmap) that the dofile for this
example generated:

-------------------------------------------------------------------------
-- BSDArchitect Pin Map Report
-------------------------------------------------------------------------
-- Design : test
-------------------------------------------------------------------------
-- Port Name PinID Cell Type Pad Cell Name Safe Value Inv
-------------------------------------------------------------------------
bit_bidi_ctr void -cell bc_2_a ;
bit_bidi_o 0 -cell bc_7_low -safe X ;
bit_diff_o 3 4 -cell bc_1 -safe X ;
bit_int_o 7 -cell bc_1 -safe X ;
bit_o 9 -cell bc_1 -safe ;
bit_oc_o 10 -cell bc_1 -safe X ;
bit_tri_ctrl void -cell bc_1 ;
bit_tri_o 12 -cell bc_1 -safe X ;
bit_diff_i 1 2 -cell bc_1 -safe X ;
bit_gnd 5 -cell bc_1 -safe X ;
bit_i 6 -cell bc_1 -safe X ;
bit_inv_i 8 -cell bc_1 -safe X ;
bit_pwr 11 -cell bc_1 -safe X ;
tdi 13 ;
tms 14 ;
tck 15 ;
tdo 16 ;
trst 17 ;
-------------------------------------------------------------------------

The following pinmap file is a manually edited version of the default file generated by
BSDArchitect (my_pinmap_modified) that the dofile for this example generated:

Boundary Scan Process Guide, V8.2007_3 105

August 2007
Boundary Scan Customizations
Using User-Defined Instructions

------------------------------------------------------------------------
--BSDArchitect Pin Map Report
------------------------------------------------------------------------
--Design : test
-------------------------------------------------------------------------
--Port Name PinID Cell Type Pad Cell Name Safe Value Inv
-------------------------------------------------------------------------
bit_bidi_ctrl void -cell bc_2_a ;
bit_bidi_o 0 -cell bc_7_low -safe X ;
bit_diff_o 3 4 -cell bc_1 -safe X ;
bit_int_o 7 -cell bc_1 -safe X -internal;
bit_o 10 -cell bc_1 -pad outpad -safe 0 ;
bit_oc_o 9 -cell bc_1 -safe X ;
bit_tri_ctrl void -cell bc_1 ;
bit_tri_o 12 -cell bc_1 -safe X ;
bit_diff_i 1 2 -cell bc_4 -safe X ;
bit_gnd 5 -gnd ;
bit_i 6 -cell bc_2 -pad inpad -safe X ;
bit_inv_i 8 -cell bc_1 -pad inpad_inv -safe X -inv ;
bit_pwr 11 -pwr ;
tdi 13 ;
tms 14 ;
tck 15 ;
tdo 16 ;
trst 17 ;
-------------------------------------------------------------------------

Using User-Defined Instructions

BSDArchitect allows you to use user-defined instructions. To do so, you must define a register
for a given user-defined instruction before using the Add Bscan Instruction command to define
the user-defined instruction.

To define a register use the following command:

ADD COre Register register_name input_port_name output_port_name [-Top | -Notop]

[-Length integer] [-Inv]
The input_port_name and output_port_name arguments are core logic ports. If you define a
port as a register for a user-defined instruction, BSDArchitect makes the port available at the
top-level of the design by default. To remove these ports from the top level, use the -notop
argument. Boundary scan cells will not be used for these input and output ports if you issue
either the -notop argument or the Add Bscan Cell none command for these ports.

After defining a register, you can add an instruction for that register by using the following
command:

ADD BScan Instruction instr_name {-Reg_name reg_name} [-Type instruction_type]

[-Code opcode] [-Outputs {Hi_impedance | Cell_value}]
The instr_name argument is the instruction and the reg_name is the name of the register you
defined with the Add Core Register command.

106 Boundary Scan Process Guide, V8.2007_3

August 2007
 Boundary Scan Customizations
Connecting Internal Scan Circuitry

Once you have defined a register and its associated user-defined instruction, BSDArchitect
generates a signal with the same name as the user-defined instruction. This signal becomes
active when you load the instruction in the instruction register.

BSDArchitect generally does not have information about the clock and enable signals
associated with a user-defined register (the internal scan and multiple scan instructions are the
exception). BSDArchitect normally connects the register between TDI and TDO when you load
the instruction in the instruction register. So, you need to manually connect the clock and enable
signals for the register.

The user-defined internal scan and multiple scan instructions are used to denote a particular
category of instructions (internal scan and internal scan + bsr, respectively). The names of these
instructions are not required to be INT_SCAN and MULT_SCAN. For these instructions,
BSDArchitect automatically connects the clock and enable signals.

Additionally, you can use the Add Port Connection command to connect a core-design port
either to a top-level boundary scan port, to internal boundary scan signals, or both.

The following is a simple example of how to use a user-defined instruction. In this example
we’ll show how to define a register named, pcnt_reg, add an associated instruction called,
lbpcnt, and then connect the BSDArchitect-generated lbpcnt signal to a core logic port named,
lbpcnt_b:

add core register pcnt_reg patc_sin patc_sout -length 7

add bscan instruction lbpcnt -reg pcnt_reg
add port connection lbpcnt_b buf lbpcnt

The lbpcnt signal connects to a core logic port named lbpcnt_b when the lbpcnt instruction is
loaded in the instruction register.

You can issue additional Add Port Connection commands to connect the clock and any other
signals. Valid signal_names include all TAP controller signals, instruction enables, core input
ports, core output ports, and available intermediate signals at the TAP level. The runbist signal
name is valid if the RUNBIST instruction has been added via the Add Bscan Instruction
command. For a list of valid signal names, issue the Report Port Connection command with the
-Usable_signals switch.

For a full description, refer to the Add Port Connection command in the BSDArchitect
Reference Manual.

Connecting Internal Scan Circuitry

Board-level interconnect testing does not require access to internal scan chains. It simply tests
the interconnection circuitry between chips on the board. However, chip-level testing and chip-
testing at the board level both require internal scan access. Thus, if your test strategy includes
chip-test at the board level, and you are not using BIST circuitry, you should connect the
internal scan circuitry to the boundary scan circuitry.

Boundary Scan Process Guide, V8.2007_3 107

August 2007
Boundary Scan Customizations
Connecting Internal Scan Circuitry

BSDArchitect can connect the internal scan circuitry to the boundary scan circuitry, and gives
you several options to choose from as you decide how to connect the circuitry together. The
following subsections describe these options and show an example of connecting the boundary
scan circuitry to internal scan.

Adding Dummy Scan Pins

An optional flow is to use BSDArchitect at the RTL-level. At this point, your design most likely
does not contain internal scan circuitry. However, if you know the internal scan strategy you are
going to use, you can add dummy scan ports for the scan ports that will eventually be part of the
design.

The following example contains the entity of the example design “aha” before the addition of
scan insertion. If this design is to contain scan, you would need to add scan ports before using
this entity with BSDArchitect.

library ieee;
use ieee.std_logic_1164.all;
entity aha is
port( s:out std_ulogic;
co:out std_ulogic;
a:in std_ulogic;
b:in std_ulogic;
c:in std_ulogic);
end aha;

For a strategy requiring two scan chains, the entity would look like the following example. This
example assumes that aha_scan2.vhd is the name of the design entity you are using and that the
design contains two internal scan chains.

library ieee;
use ieee.std_logic_1164.all;

entity aha_scan2 is
port( s:out std_ulogic;
co:out std_ulogic;
a:in std_ulogic;
b:in std_ulogic;
c:in std_ulogic;
sclk:in std_ulogic; -- Scan Clock
sc_en:in std_ulogic; -- Scan Enable
sc1_i:in std_ulogic; -- Scan Input Pins
sc2_i:in std_ulogic;
sc1_o:out std_ulogic;-- Scan Output Pins
sc2_o:out std_ulogic);
end aha_scan2;

Specifying the Scan Architecture and Testing Mode

Mux-DFF and clocked-scan are the two supported internal scan architectures. BSDArchitect
does not support LSSD.

108 Boundary Scan Process Guide, V8.2007_3

August 2007
 Boundary Scan Customizations
Connecting Internal Scan Circuitry

You must specify which type of internal scan architecture your design uses. During the
connection to boundary scan circuitry, BSDArchitect creates clocking circuitry depending on
the specified internal scan architecture. Figure 4-22 shows the boundary scan architecture
created for clocking the internal scan circuitry of a mux-DFF design.

Figure 4-22. Clocking Circuitry Created for Mux-DFF Architecture

System Clock
(top_test_clk) A Clock to
A Core Logic
Scan Instruction 0 0 O
(test_clk)
(internal scan or multiple scan) B
SEL1 SEL2

SHIFT_DR

CAPTURE D

Test Clock SEL1 SEL2 O

(top_TCK) R
0 0 A
TRST 0 1 A
(top_TRST) 1 0 0
1 1 B

In Figure 4-22, the multiplexer connects the system clock to the core logic clock before loading
the scan instruction in the instruction register. For more information on scan instructions, see
“Defining the Scan Instruction” on page 112. After the scan instruction loads in the instruction
register, the TAP causes the connection of TCK to the core logic clock during the CAPTURE
and SHIFT_DR states.

Figure 4-23 shows the boundary scan architecture created for clocking the internal scan
circuitry of a clocked-scan design.

Boundary Scan Process Guide, V8.2007_3 109

August 2007
Boundary Scan Customizations
Connecting Internal Scan Circuitry

Figure 4-23. Clocking Circuitry Created for Clocked Scan Architecture

System Clock
(top_test_clk) A Clock to
Scan Instruction A Core Logic
0 0 O
(internal scan or multiple scan) (test_clk)
B
SEL1 SEL2

CAPTURE_DR D SEL1 SEL2 O

Test Clock 0 0 A
R 0 1 A
(top_TCK) 1 0 0
TRST 1 1 B
(top_TRST)
A
Scan Clock Scan Clock
(top_scan_clk) A to Core Logic
0 0 O
(scan_clk)
B
SEL1 SEL2

SHIFT_DR

In Figure 4-23, before loading the scan instruction (internal scan or multiple scan) in the
instruction register, both the system clock and the scan clock connect to the core logic clock.
After the scan instruction loads in the instruction register, TCK connects to the core logic clock
during the TAP controller CAPTURE_DR state and the scan clock connects to the core logic
during the SHIFT_DR state.

When you choose the internal scan architecture, you must also decide the mode in which you
are going to test the chip. If you want the ability to exercise the chip's internal scan circuitry by
using the internal scan ports directly, you should choose standalone mode. If you choose the
standalone testing mode, BSDArchitect creates extra circuitry to give you the option of direct
access to the internal scan ports at the top-level of the design. Standalone mode provides the
most efficient method for internal chip testing.

If you only want access to the internal scan circuitry via the TAP, and you do not want
BSDArchitect to add the extra circuitry for the option of testing in standalone mode, you should
choose nostandalone mode. Nostandalone mode provides a means to restrict internal chip
access, except through the use of boundary scan circuitry, as some testers may require.

110 Boundary Scan Process Guide, V8.2007_3

August 2007
 Boundary Scan Customizations
Connecting Internal Scan Circuitry

Note
If using nonstandalone scan architecture, a fault at the reset pin for the scan cells will not
be detected. This is because for that architecture only one clock can be defined during
capture in FastScan: the test clock by using “Add Capture Clock test_clk -atpg”. In order
to detect a fault at the reset pin, the reset pin needs to be defined as a clock, but this is not
allowed when using nonstandalone scan architecture.

The default circuitry allows testing in standalone mode, as shown in Figure 4-24.

Figure 4-24. Default Architecture for Testing Mode

Figure 4-24 shows the default connections for a core design containing a single scan chain. The
circuitry shown allows you to access the internal scan chain either directly (through sc_in,
sc_out, and sc_en) or by using TAP signals. The thin lines show circuitry that is valid if your
design uses the mux-DFF architecture. The clock signal shown with the heavier line is only
valid if your design uses the clocked-scan architecture.

To specify the internal scan architecture and testing mode, you use the Set Iscan Interface
command. For example:

set iscan interface -type mux_scan -sen sc_en -mode stand_alone -tclk sclk

This example specifies that the type of scan architecture is mux-DFF, that the testing mode
should allow for standalone testing (direct access to the scan chain, without going through the
TAP), that the scan enable is the sc_en port, and that the test clock is the sclk port.

Boundary Scan Process Guide, V8.2007_3 111

August 2007
Boundary Scan Customizations
Connecting Internal Scan Circuitry

Specifying the Internal Scan Chain

If you want BSDArchitect to access the internal scan chain, you must define a register name and
the input and output ports for the register. The following is an example of specifying an internal
scan chain using the Add Core Register command:

add core register int_scan_reg sc1_i sc2_o

This command gives the name “int_scan_reg” to the combined chain bounded by the input port
sc1_i and the output port sc2_o.

Defining the Scan Instruction

The Scan Instruction signal shown in Figures 4-22, 4-23, and 4-24 can be any scan instruction
name so long as it is defined as either an internal or multiple scan instruction. These are user-
defined instructions for the purpose of accessing the internal scan circuitry. You must first
define a register using the Add Core Register command. You then add the instruction and
associate it with the defined register using the Add Bscan Instruction command.

The internal scan instruction connects the internal scan register between the TDI and TDO
ports. The multiple scan instruction connects both the boundary scan register (BSR) and the
internal scan register in series between TDI and TDO.

Figure 4-25 shows simplified circuit diagrams of the internal scan and multiple scan
instructions.

Figure 4-25. Internal Scan Instruction Connections

Internal Scan Connection Multiple Scan Connection

BSR
M BSR
TDI U TDO M
Int Scan Chain X M U TDO
U Int Scan Chain X
TDI X

MULT_SCAN

The circuitry created for the multiple scan instruction includes a multiplexer, controlled by the
multiple scan signal, at the input of the internal scan chain. One input of the mux is the output of
the BSR and the other input is TDI. If you want to use the standalone mode for testing,
BSDArchitect adds an additional mux to connect the internal scan chain with a primary input.

For example, to connect both the internal scan chain and boundary scan register in series
between TDI and TDO, you define the following multiple scan instruction:

add bscan instruction mult_scan -reg_name scan_reg -mult_scan_instr

112 Boundary Scan Process Guide, V8.2007_3

August 2007
 Boundary Scan Customizations
Connecting Internal Scan Circuitry

Note that adding instructions with the internal scan or multiple scan instruction types require the
use of the -reg_name argument to define the internal scan register, because neither the Connect
Iscan Chains nor the Add Core Register command provides this information.

Combining Multiple Chains

BSDArchitect can handle multiple internal scan chains, but you must first combine them into a
single scan chain, as shown in Figure 4-26.

You can connect multiple scan chains into a single chain by using the Connect Iscan Chains
command. All internal scan chain related ports have associated boundary scan cells during
standalone testing. In no-standalone mode, these ports do not appear at the top level and do not
have associated boundary scan cells. The following example shows how to connect two scan
chains into a single chain:

connect iscan chains sc1_i sc1_o sc2_i sc2_o

The input and output ports of the first scan chain are sc1_i and sc1_o, respectively. The input
and output ports of the second scan chain are sc2_i and sc2_o, respectively. This command
connects the first scan chain to the second scan chain so that the input of the combined chain is
sc1_i and the output of the combined chain is sc2_o.

Figure 4-26. Connection of Multiple Scan Chains

Top-Level Logic

TDI Core System Logic

M
U sc1_o
sc1_i Internal Scan Chain 1
X

M
U sc2_o
sc2_i Internal Scan Chain 2
X

internal scan from BYPASS M

instruction register U TDO
enables from boundary X
scan register
from decoder

Boundary Scan Process Guide, V8.2007_3 113

August 2007
Boundary Scan Customizations
Connecting Internal Scan Circuitry

114 Boundary Scan Process Guide, V8.2007_3

August 2007
 Chapter 5
Output Testing and Verification

This chapter outlines how to use BSDArchitect to synthesize and verify boundary scan circuitry
for your design. For specific information on BSDArchitect functionality or commands, refer to
the BSDArchitect Reference Manual.

Understanding BSDArchitect Output Files

The BSDArchitect tool can create a number of different output files. The following sections
describe each file. By default, when you save your design with the Save Bscan command, the
tool generates the following:

• HDL Description
• Top-Level Interface Description
• HDL Test Bench
• BSDL Description
Additional commands are available to create the following:

• Synthesis Script
• Parametric Tests
• Test Vectors
• ATPG Setup Files

HDL Description
The HDL description file contains the design with inserted boundary scan circuitry. This file is
created by the Save Bscan command. You can specify a buffered or unbuffered, mapped or
unmapped HDL description. You may want to specify a mapped file if your design uses
technology-mapped cells or you are using the Internal flow.

The default file name of an unmapped HDL description is <prefix>_bscan.<suffix>, where

<prefix> is the design name specified at invocation and <suffix> is the design format extension.
The default file name for a mapped file is <prefix>_map.<suffix>. You can specify different file
names using the Setup File Naming command.

Boundary Scan Process Guide, V8.2007_3 115

August 2007
Output Testing and Verification
Understanding BSDArchitect Output Files

In general, the mapped output uses IEEE 1149.1 cells from the specified ASIC library. This
output contains direct instantiation of ASIC library cells. For more information, refer to
“Technology Mapping” on page 66.

Note
The HDL description file is not created in the BSDL flow.

Top-Level Interface Description

The top-level interface description file contains a black box model with the inputs and outputs
for the top-level boundary scan core entity/module. This file is created by the Save Bscan
command.

The default file name of the top-level interface description is <prefix>_top.<suffix>, where
<prefix> is the design name specified at invocation and <suffix> is the design format extension.
You can specify a different file name using the Setup File Naming command.

HDL Test Bench

The HDL test bench file contains tests for the boundary scan logic functionality at the RTL
level to verify that the generated boundary scan logic is correct. The parametric tests will be
included in this file by default, but you can choose to have BSDArchitect write these test into a
separate file. For more information, see “Parametric Tests” on page 118. The HDL test bench is
created by the Save Bscan command.

The default file name of the HDL test bench is <prefix>_tb.<suffix>, where <prefix> is the
design name specified at invocation and <suffix> is the design format extension. You can
specify a different file name using the Setup File Naming command.

The test bench does not test the BSDL, check for full compliance with the IEEE 1149.1
standard, or fault grade the boundary scan circuitry. For more detailed information on the test
bench functions, see “Troubleshooting the Test Bench Simulation” on page 125.

The test bench performs the following tests:

• Verification of User-Defined Instructions

The test bench verifies all user-defined instructions (defined by the Add Bscan
Instruction command) that target core registers, external registers, and the boundary
scan register.
• Verification of Public Instructions

116 Boundary Scan Process Guide, V8.2007_3

August 2007
 Output Testing and Verification
Understanding BSDArchitect Output Files

The test bench verifies the following predefined instructions: SAMPLE, PRELOAD,
BYPASS, EXTEST, IDCODE, USERCODE, CLAMP, and HIGHZ. It does not test the
INTEST or RUNBIST instructions.
• Verification of Boundary Scan Register Operation
The test bench verifies the shift, capture, update, and mode capabilities of the boundary
scan registers.
• Verification of Instruction Logic
The test bench verifies the load and unload capability of the instruction register. It also
tests the instruction decode circuitry.
• Verification of TAP Controller Transitions
The test bench implicitly verifies the TAP controller transitions during the testing of the
public instructions. The test bench also explicitly does some testing of other transitions.
• Verification of the Reset Operation
The test bench verifies the reset operation by resetting the design, unloading the data
register, and checking the unloaded data.
Additional test bench files (that contain a subset of the original test bench) can be created using
the Save Testbench command.

BSDL Description
The BSDL description file contains the design with boundary scan circuitry written in BSDL. It
can be used with board testing tools. This file is created by the Save Bscan command.

The default file name of the BSDL description file is <prefix>_bscan.bsd, where <prefix> is the
design name specified at invocation. You can specify a different file name using the Setup File
Naming command.

Synthesis Script
BSDArchitect can generate a synthesis script for synthesizing the HDL output file from
BSDArchitect. This file is not written out in the BSDL flow. Use the optional -Synthesis_script
switch for the Save Bscan command. The script can use either Design Compiler or Leonardo.
You can specify a file name or use the default name:

o <prefix>_leonardo_syn.do for a Leonardo script

o <prefix>_dc_syn.do or <prefix>_dc_syn_tcl.do for a Design Compiler script

Boundary Scan Process Guide, V8.2007_3 117

August 2007
Output Testing and Verification
Understanding BSDArchitect Output Files

Parametric Tests
Parametric tests use parametric measurement units to ensure that the I/O hardware works within
specified limits. I/O parametric tests are important because they test the ability of a chip to work
correctly when placed in an environment with other chips.

BSDArchitect generates two classes of parametric tests:

1. Typical pattern set — The tests use all low voltages (0), all high voltages (1), and highz
(z).
2. Checkerboard pattern set — The tests use checkerboard patterns. For example,
“0101010…” and “1010101…”. In this set, the tool also generates highz patterns.
To generate these tests, issue the following command before inserting the boundary scan
circuitry (issuing the Run command):

set testbench parameters -parametric_test typical

The parametric tests are included in the HDL test bench file and the test vectors file. You can
also write the parametric test into a separate test bench file using the Save Testbench command.
For more information, refer to the Set Testbench Parameters command in the BSDArchitect
Reference Manual.

Test Vectors
BSDArchitect can write out the test bench file as test vectors. You can then use FlexTest to fault
grade these functional vectors to determine the boundary scan logic test coverage using these
vectors. You use the Save Patterns command to write out the test vectors.

For more information on using test vectors, see “Fault Simulation” in the Scan and ATPG
Process Guide.

ATPG Setup Files

If the circuit contains internal scan circuitry controlled by the boundary scan circuitry, you can
use BSDArchitect to generate the following two ATPG setup files:

• Dofile — Used for setting up scan circuitry information.

• Test procedure file — Used for specifying the operation of the scan circuitry. The
“Test Procedure Files” section in the Scan and ATPG Process Guide discusses test
procedure files in more detail.
The file names of the ATPG setup files are <root_name>.testproc and <root_name>.dofile,
where <root_name> is specified with the Save Atpg Setup command.

118 Boundary Scan Process Guide, V8.2007_3

August 2007
 Output Testing and Verification
Using BSDArchitect in a BSDL Flow

This capability assumes the TAP controller conforms to IEEE Std. 1149.1-1990 and IEEE Std.
1149.1a-1993 and that the design contains a single internal scan chain. This would be the case if
you use BSDArchitect to create the boundary scan circuitry and connect it to the internal scan
circuitry.

To save ATPG setup files, issue the following command:

save atpg setup mux_scan_stand

In this case, the root name of the files will be “mux_scan_stand.” BSDArchitect produces the
following four files:

• mux_scan_stand_standalone.dofile
• mux_scan_stand_standalone.testproc
• mux_scan_stand_nostandalone.dofile
• mux_scan_stand_nostandalone.testproc
Refer to “Generating Patterns for a Boundary Scan Circuit” in the Scan and ATPG Process
Guide for a complete test procedure file example for an IEEE 1149.1 circuit using the multiple
scan instruction.

Using BSDArchitect in a BSDL Flow

Use this procedure to check your BSDL file against the IEEE 1149.1 standard and generate the
output files.

Prerequisites
• Your design file must be written in BSDL format.

Procedure
1. Invoke BSDArchitect including the -Bsdl switch.
shell> <mgcdft tree>/bin/bsdarchitect test.bsd -bsdl -nogui

2. (Optional) Make any customizations to the test bench. For more information, refer to the
Set Testbench Parameters command.
3. Check the boundary scan circuitry for compliance to the standard by issuing the run
command.
run

4. Save your design and write out the test bench. For more options on output files, see
“Creating Output Files” on page 121. BSDArchitect will not write an HDL description
file in the BSDL flow.

Boundary Scan Process Guide, V8.2007_3 119

August 2007
Output Testing and Verification
Inserting Boundary Scan Circuitry

save bscan -replace

5. Exit BSDArchitect.
exit

Related Topics
• Verifying the HDL Boundary Scan Circuitry
• Troubleshooting the Test Bench Simulation

Inserting Boundary Scan Circuitry

Use this procedure to check your design for errors and insert the specified boundary scan
circuitry. The boundary scan circuitry will only be added if no errors are found. Only one
successful boundary scan insertion is allowed per BSDArchitect session. To perform another
insertion, reinvoke BSDArchitect or use the Reset State command.

Prerequisites
• You must have specified any customizations for your design and output files. For more
information on available customizations, refer to “Boundary Scan Customizations” on
page 65 and “Understanding BSDArchitect Output Files” on page 115.

Procedure
1. Issue the Run command. BSDArchitect will check your design for errors and insert
boundary scan circuitry if no errors are found.
run

2. Verify the boundary scan circuitry by issuing the following two commands after the Run
command completes successfully:
report bscan status
report bscan cell
-------------------------------------------------------------
BSDArchitect Report
-------------------------------------------------------------
Design : aha_scan2.vhd
-------------------------------------------------------------
Asynchronous TAP Reset : Yes
Asynchronous TAP Reset : Yes
Device Identification Register : No
User Identification Register : No
Instruction Register Width : 4
INSTRUCTION REPORT:
-------------------------------------------------------------
Instruction Target Register Opcode
-------------------------------------------------------------
MULT_SCAN INT_SCAN_REG 0010

120 Boundary Scan Process Guide, V8.2007_3

August 2007
 Output Testing and Verification
Creating Output Files

EXTEST BOUNDARY 0000

SAMPLE_PRELOAD BOUNDARY 0001
BYPASS BYPASS 1111
-------------------------------------------------------------
PORT REPORT:
-------------------------------------------------------------
No Port BSC Mode Type Cell Name
-------------------------------------------------------------
1 s YES Both BC_1 BC_1
2 sc2_o YES Both BC_1 BC_1
3 sc1_o YES Both BC_1 BC_1
4 co YES Both BC_1 BC_1
5 sc2_i YES Both BC_1 BC_1
6 sc1_i YES Both BC_1 BC_1
7 sc_en YES Both BC_1 BC_1
8 sclk YES Observe BC_4 BC_4
9 c YES Both BC_1 BC_1
10 b YES Both BC_1 BC_1
11 a YES Both BC_1 BC_1
TCK NO
TMS NO
TRST NO
TDI NO
TDO NO
-------------------------------------------------------------
Total no. of BS cells: 11
Note: Port ordering is from TDO to TDI.

Related Topics
• Creating Output Files

Creating Output Files

Use this procedure to create the output files for your design. Many of the steps in this procedure
are optional, depending on the types of files you want. For more information on the output file
types and options, refer to “Understanding BSDArchitect Output Files” on page 115.

Prerequisites
• You must have previously issued the Run command without errors.

Procedure
1. (Optional) Generate the test vectors.
save patterns filename -format wgl -replace

2. Save the design and generate the default output files (HDL description, top-level
interface description, HDL test bench, and BSDL description).
save bscan -replace

3. (Optional) Generate additional test bench files for a subset of test bench functionality.

Boundary Scan Process Guide, V8.2007_3 121

August 2007
Output Testing and Verification
Verifying the HDL Boundary Scan Circuitry

save testbench -parametric -file parametric_tb.v -replace

4. (Optional) Generate the ATPG setup files.

save atpg setup file_name_root -replace

5. Exit BSDArchitect.
exit

Related Topics
Verifying the HDL Boundary Scan Circuitry

Verifying the HDL Boundary Scan Circuitry

Use this procedure to verify that the boundary scan circuitry functions as you expect. The
examples in this section use ModelSim and Design Compiler. Where applicable, the different
Verilog and VHDL design examples are shown.

Prerequisites
• You must have completed boundary scan insertion, created all output files, and exited
BSDArchitect.
• You will need the following files for verification: technology-mapped or component
libraries (if applicable), core logic HDL model, boundary scan HDL model, and HDL
test bench.

Procedure
1. Compile the mapped libraries. Any libraries used need to be compiled prior to the
BSDArchitect files. The following example shows how to compile the library using
ModelSim from the directory containing the HDL source of the target technology
(assuming the modelsim.ini file contains a mapping between the h4c_lib label and the
location h4c, which is the compiled library destination):
shell> <mgcdft tree>/bin/vlib h4c
shell> <mgcdft tree>/bin/vmap h4c_lib h4c
shell> <mgcdft tree>/bin/vcom -work h4c_lib -check_synthesis h4c.vhd

2. Define your work directory (for placing compiled boundary scan models).
shell> cd /user/jdoe/bs
shell> <mgcdft tree>/bin/vlib work

3. Compile the HDL source files including the boundary scan component libraries, the core
logic HDL entity, the HDL model with boundary scan, and the test bench. If you do not
already have a compiled model for your core logic, you need to compile this model
before you compile any outputs of BSDArchitect. For instance, you may already have a
synthesized design which has internal scan circuitry added, and you may have created an

122 Boundary Scan Process Guide, V8.2007_3

August 2007
 Output Testing and Verification
Verifying the HDL Boundary Scan Circuitry

HDL model of this design just for input to BSDArchitect. In this case, you would now
compile that model. Before you can run the test bench, you must first compile the HDL
source code generated by BSDArchitect. After you compile the necessary components
and models, compile the test bench for use by the simulator.
Verilog:
shell> cd /user/jdoe/bs/verilog_models
shell> <mgcdft tree>/bin/vlog -work work aha.v aha_bscan.v
shell> <mgcdft tree>/bin/vlog aha_bscan_tb.v

VHDL:
shell> cd /user/jdoe/bs/vhdl_models
shell> <mgcdft tree>/bin/vcom -check_synthesis aha.vhd
shell> <mgcdft tree>/bin/vcom -check_synthesis aha_bscan.vhd
shell> <mgcdft tree>/bin/vcom aha_bscan_tb.vhd

4. Simulate the test bench.

Verilog:
shell> <mgcdft tree>/bin/vsim -lib work aha_bscan_tb -t ps
vsim1> run -all
vsim1> quit -f

VHDL:
shell> <mgcdft tree>/bin/vsim -lib work aha_bscan_tb
vsim1> run -all
vsim1> quit -f

5. Synthesize the design. This step creates a gate-level netlist for your design with
boundary scan.
a. Invoke Design Compiler.
shell> design_analyzer

b. Synthesize and optimize the design.

Input Core File = aha.v or aha.vhd
Bscan logic file = aha_bscan.v or aha_bscan.vhd
Output netlist = aha_bscan_netlist.v or aha_bscan_netlist.vhd
The following Design Compiler dofile assumes that you have completed all of the
required environment setup steps.
Verilog:
include “dc_h4c.setup”
read -f verilog {aha.v aha_bscan.v}
current_design find (design, aha_top_buf)
uniquify
compile -map_effort medium
write -f verilog -h -o aha_bscan_netlist.v

Boundary Scan Process Guide, V8.2007_3 123

August 2007
Output Testing and Verification
Verifying the Gate-Level Boundary Scan Logic

exit

VHDL:
include “dc_h4c.setup”
read -f vhdl {aha.vhd aha_bscan.vhd}
current_design find (design, aha_top_buf)
uniquify
compile -map_effort medium
write -f vhdl -h -o aha_bscan_netlist.vhd
exit

Related Topics
• Verifying the Gate-Level Boundary Scan Logic
• Troubleshooting the Test Bench Simulation

Verifying the Gate-Level Boundary Scan Logic

At this point in the design flow, you have both an HDL model and gate-level model for the
boundary scan logic with the core ASIC logic. Previously you have verified the behavior of the
HDL boundary scan model. Now, after synthesizing this model and performing any necessary
optimizations, you are ready to test the gate-level boundary scan circuitry.

This procedure is nearly identical to the procedure for testing the HDL boundary scan model
using the test bench. As before, you could use a gate-level simulator to verify the operation of
the boundary scan model.

Prerequisites
• You must have a complete design netlist (from verifying the HDL circuitry).

Procedure
1. Define the work directory (for placing the compiled boundary scan models).
shell> cd /user/jdoe/bs
shell> <mgcdft tree>/bin/vlib work

2. Compile the gate_level_models and the test bench.

Verilog:
shell> cd /user/jdoe/bs/gate_level_models
shell> <mgcdft tree>/bin/vlog -work work aha_bscan_netlist.v
shell> <mgcdft tree>/bin/vlog aha_bscan_tb.v

VHDL:

124 Boundary Scan Process Guide, V8.2007_3

August 2007
 Output Testing and Verification
Troubleshooting the Test Bench Simulation

shell> cd /user/jdoe/bs/gate_level_models
shell> <mgcdft tree>/bin/vcom -check_synthesis
aha_bscan_netlist.vhd
shell> <mgcdft tree>/bin/vcom aha_bscan_tb.vhd

3. Simulate the test bench.

Verilog:
shell> <mgcdft tree>/bin/vsim -lib work aha_bscan_tb -t ps
vsim1> run -all
vsim1> quit -f

VHDL:
shell> <mgcdft tree>/bin/vsim -lib work aha_bscan_tb
vsim1> run -all
vsim1> quit -f

Related Topics
• Troubleshooting the Test Bench Simulation

Troubleshooting the Test Bench Simulation

This section describes each test in the test bench in detail and is useful for troubleshooting
errors encountered during simulation.

Boundary Scan Test Architecture

Figure 5-1shows a simple boundary scan implementation. The orange rectangles represent the
boundary scan cells and the blue triangles represent the I/O pads in the design. The different
input configurations are shown on the left and the output configurations are shown on the right.
When you simulate the test bench, the test values may be applied or read in parallel at the
top-level input or output ports or shifted in through the boundary scan or data registers. In the
following sections “apply” refers to the parallel data given to the input or output ports. “Shift”
refers to the series data given to the registers (Boundary Scan, Identification, Bypass, etc.).

Boundary Scan Process Guide, V8.2007_3 125

August 2007
Output Testing and Verification
Troubleshooting the Test Bench Simulation

Figure 5-1. Test Architecture

JTAG Logic Tests

The following sections describe the tests performed when you simulate your test bench. For
more information about the TAP states, refer to “TAP Controller State Machine” on page 15.

By default, the test bench will include Mode-Mux, SAMPLE, EXTEST, PRELOAD, and
BYPASS. Additional instructions are tested when created by the Add Bscan Instruction
command.

Note
RUNBIST and INTEST are not tested. All unassigned opcodes are tested for BYPASS
instruction, except if your design shares a functional pin with TDO. For more
information, refer to “Sharing Functional Pins With TDO” on page 62.

126 Boundary Scan Process Guide, V8.2007_3

August 2007
 Output Testing and Verification
Troubleshooting the Test Bench Simulation

Initialization
1. Perform an asynchronous reset on TAP controller.
a. Set TMS = 1 and TRST = 0.
b. Wait one clock cycle.
c. Set TMS = 0 and TRST=1.
2. Initialize the input boundary scan cells.
a. Apply a 1 to all primary input ports to 1.
b. Apply a 1 to all differential positive inputs and apply a 0 to all differential negative
inputs.
c. Apply a Z to all bidirectional ports.
The following example shows the output for initialization when you simulate the test bench:

# 1. Initialization
# --------------------------------------------------
# 250 OK Initializing BS logic by resetting TAP controller
# 1050 OK Initializing PI of input bscells
# 1250 OK *** Boundary Scan logic has been reset ***
#

Check Instruction Register

After the TAP reset, the default instruction should be loaded into the Instruction Register. The
default instruction is IDCODE. If you did not add the IDCODE instruction, then BYPASS will
be the default. If the IDCODE instruction is loaded, the Identification Register will be selected.
If the BYPASS instruction is loaded, the Bypass Register will be selected.

1. Change state to Shift-DR.

2. Shift out one bit from the selected register through TDO.
3. Check the shifted out bit at TDO.
• 0 — Bypass instruction is selected. The Bypass Register is loaded with a 0 value at
reset.
• 1 — Idcode instruction. The LSB of the Identification Register is always 1.
# 2. Check instruction register after TAP reset
# --------------------------------------------------
# 1250 OK Checking Instruction Register after TAP reset
# 1850 OK *** Active instruction is BYPASS ***
#

Boundary Scan Process Guide, V8.2007_3 127

August 2007
Output Testing and Verification
Troubleshooting the Test Bench Simulation

Test for Capture Pattern

1. Load the BYPASS opcode.
2. Change state to Shift-IR.
3. Shift out the contents of Instruction Register through TDO.
4. Verify the shifted out pattern against the reference pattern.
5. Set TDO to Z. TDO should be set to Z when not shifting.
# 3. Test for capture-pattern
# --------------------------------------------------
# 3250 OK Checking for capture pattern
# 4050 OK *** Capture pattern shifted out properly ***
# 4050 OK *** TDO is set to 'Z' ***
#

Run Through all TAP States

1. Synchronous reset the TAP controller.
a. Set TMS = 1.
b. Pulse TCK 5 times.
2. Transition from Select-IR to Run-Test/Idle state.
a. Change state to Shift-IR.
b. Shift in a predefined pattern into the Instruction Register.
c. Verify the 2 LSB shifted out at TDO.
d. Change state to Pause-IR and Stay for a while.
e. Return to the Shift-IR state. Shift out and verify the rest of the predefined pattern at
TDO.
f. Return to RUn-Test/Idle by traversing TAP states.
3. Transition from Select-DR to Run-Test/Idle state.
a. Load the EXTEST opcode into the Instruction Register.
b. Change state to Shift-DR.
c. Shift in a predefined pattern into the Boundary Scan Register.
d. Verify the 2 LSB shifted out at TDO.
e. Change state to Pause-DR and Stay for a while.
f. Return to the Shift-DR state. Shift out and verify the rest of the predefined pattern at
TDO.

128 Boundary Scan Process Guide, V8.2007_3

August 2007
 Output Testing and Verification
Troubleshooting the Test Bench Simulation

g. Return to Run-Test/Idle by traversing TAP states.

# 4. Run through all TAP controller states
# --------------------------------------------------
# 4450 OK Synchronously resetting TAP controller
# 6050 OK Running all TAP controller states and state transitions
# 6850 OK Checking instruction register shift with pause
# 10850 OK *** Instruction register shifts properly ***
# 15050 OK Checking boundary register shift with pause
# 62650 OK *** Boundary register shifts properly ***
#

Test BYPASS Instruction

1. Load the BYPASS opcode into the Instruction Register.
2. Change state to Shift-DR .
3. Shift out one bit from the Bypass Register and verify a 0 at TDO.
4. Shift in a predefined pattern into the Bypass Register at TDI.
5. Verify the predefined pattern shifted out at TDO.
6. Return to Run-Test/Idle state and set TDO to Z.
# 5. Test for instruction: BYPASS
# --------------------------------------------------
# 110650 OK Testing opcode: 1111 for BYPASS instruction
# 110650 OK *** loading opcode: 1111***
# 113250 OK **** Checking bypass register output
# 115650 OK Data check OK *** Overshifted bypass register output
equals the inserted value 11110011111
# 115650 OK *** TDO is set to 'Z' ***
#

Test SAMPLE Instruction

1. Load the SAMPLE opcode into the Instruction Register. The SAMPLE instruction
targets the Boundary Scan Register.
2. Apply the checkerboard pattern “1010…” to the input ports. Apply a Z to all tri-state
and bidirectional ports.
3. Change state to Shift-DR.
4. Shift out and verify the checkerboard pattern at TDO.
5. Change state out of Shift-DR and set TDO to Z.
6. Apply the checkerboard pattern “0101…” to the input ports. Apply a Z to all tri-state
and bidirectional ports.
7. Change state to Shift-DR.

Boundary Scan Process Guide, V8.2007_3 129

August 2007
Output Testing and Verification
Troubleshooting the Test Bench Simulation

8. Shift out and verify the checkerboard pattern at TDO.

9. Change state out of Shift-DR and set TDO to Z.
# 6. Test for instruction: SAMPLE
# --------------------------------------------------
# 116050 OK Testing opcode: 0001 for SAMPLE instruction
# 116050 OK *** loading opcode: 0001***
# 118050 OK *** setting input signals to '...1010' ***
# 118650 OK **** Checking boundary register serial output with
sampled inputs '..1010'
# 163050 OK Data check OK *** Pattern '...1010' applied to input
bscells shifted out through boundary register
# 163050 OK *** TDO is set to 'Z' ***
# 163450 OK *** setting bidi-input signals to 'z' ***
# 163450 OK *** setting input signals to '...0101' ***
# 164050 OK **** Checking boundary register serial output with
sampled inputs '...0101'
# 208450 OK Data check OK *** Pattern '...0101' applied to input
bscells shifted out through boundary register
# 208450 OK *** TDO is set to 'Z' ***

Test PRELOAD Instruction

1. Apply a Z to all bidirectional ports.
2. Load the PRELOAD opcode into the Instruction Register.
3. Change state to Shift-DR.
4. Shift in a predefined 12-bit pattern at TDI. Pulse TCK for 7 cycles more than the length
of the Boundary Scan Register.
5. Verify the 7 bits of predefined pattern at TDO for the last 7 cycles.
# 208850 OK *** setting bidi-input signals to 'z' ***
# 208850 OK Test for the PRELOAD functionality in SAMPLE_PRELOAD
instruction
# 208850 OK *** loading opcode: 0001***
# 255850 OK *** Boundary register shifts properly in preload mode***
# 255850 OK *** setting bidi-input signals to 'z' ***

Test EXTEST Instruction

1. Test the input ports:
a. Load the EXTEST opcode into the Instruction Register. The EXTEST instruction
targets the Boundary Scan Register.
b. Create a pattern (Para_pattern) that can switch off tri-state, bidirectional, and
open-collector input ports.
c. Change state to Shift-DR.

130 Boundary Scan Process Guide, V8.2007_3

August 2007
 Output Testing and Verification
Troubleshooting the Test Bench Simulation

d. Shift in Para_pattern at TDI and return state to Run-Test/Idle.

e. Apply the checkerboard “1010…” pattern on input ports and apply a Z on
bidirectional ports.
f. Change state to Shift-DR.
g. Shift out and verify the checkerboard pattern at TDO. Bidirectional ports with pull
down should be 0 and bidirectional ports with pull up should be 1.
h. Shift in Para_pattern at TDI and return state to Run-Test/Idle.
i. Apply the checkerboard “0101…” pattern on input ports and apply a Z on
bidirectional ports.
j. Change state to Shift-DR.
k. Shift out and verify the checkerboard pattern at TDO. Bidirectional ports with pull
down should be 0 and bidirectional ports with pull up should be 1.
2. Test the output ports:
a. Create a pattern that activates the control pins for tri-state, bidirectional, and open-
collector output ports.
b. Shift in a pattern of all zeroes “0000...”, with the generated active pattern, into the
Boundary Scan Register.
c. Verify a 0 value on all output ports (simple, differential, tri-state, bidirectional, and
open-collector).
d. Shift in a pattern of all ones “1111...”, with the generated active pattern, into the
Boundary Scan Register.
e. Verify a 1 value on all output ports.
f. Shift in a checkerboard “1010…” pattern, with the generated active pattern, into the
Boundary Scan Register.
g. Verify the checkerboard pattern on all output ports.
h. Shift in a checkerboard “0101…” pattern, with the generated active pattern, into the
Boundary Scan Register.
i. Verify the checkerboard pattern on all output ports.

Boundary Scan Process Guide, V8.2007_3 131

August 2007
Output Testing and Verification
Troubleshooting the Test Bench Simulation

# 7. Test for instruction: EXTEST

# --------------------------------------------------
# 255850 OK Testing opcode: 0000 for EXTEST instruction
# 255850 OK *** loading opcode: 0000***
# 257850 OK Testing on input ports
# 257850 OK Shifting pattern 'z'
# 303250 OK *** setting input signals to '...1010' ***
# 303850 OK **** Checking boundary register serial output with
sampled inputs '..1010'
# 348250 OK Data check OK *** Pattern '...1010' applied to input
bscells shifted out through boundary register
# 348250 OK *** TDO is set to 'Z' ***
# 348650 OK Shifting pattern 'z'
# 394050 OK *** setting input signals to '...0101' ***
# 394650 OK **** Checking boundary register serial output with
sampled inputs '...0101'
# 439050 OK Data check OK *** Pattern '...0101' applied to input
bscells shifted out through boundary register
# 439050 OK *** TDO is set to 'Z' ***
# 439450 OK Testing on output ports
# 439450 OK Creating active pattern to enable tri/bidi/oc and oc
bidis
# 439450 OK Shifting in active and zero pattern in to the BSR
# 484850 OK Checking on simple outputs, bidis, tristates oc, oc bidis
and diff outputs for zero
# 484850 OK Data check OK *** All outputs are set to '0'
# 484850 OK Creating active pattern to enable tri/bidi/oc and oc
bidis
# 484850 OK Shifting in active and zero pattern into the BSR
# 530250 OK Data check OK *** All outputs are set to '1'
# 530250 OK Creating checker board pattern of 0101...
# 530250 OK Shifting in pattern of 0101...into the BSR
# 575650 OK Data check OK *** All outputs are set to '...0101'
# 575650 OK Creating checker board pattern of 1010...
# 575650 OK Shifting in pattern of 1010...into the BSR
# 621050 OK Data check OK *** All outputs are set to '..1010'
# 621050 OK *** setting bidi-input signals to 'z' ***
#

Test HIGHZ Instruction

1. Load the HIGHZ opcode into the Instruction Register. The HIGHZ instruction targets
the Bypass Register.
2. Verify all output ports are in an inactive state:
a. Verify a Z on tri-state, bidirectional, and open-collector ports.
b. Verify a 0 on tri-state, bidirectional, and open-collector ports with pull down.
c. Verify a 1 on tri-state, bidirectional, and open-collector ports with pull up.
d. Verify a 0 on differential ports with power down.
e. Verify a 1 on differential ports with power up.

132 Boundary Scan Process Guide, V8.2007_3

August 2007
 Output Testing and Verification
Troubleshooting the Test Bench Simulation

f. Normal differential output ports are not checked.

3. Change state to Shift-DR.
4. Shift in a predefined pattern into the Bypass Register at TDI and verify the same pattern
at TDO after one cycle.

Test for KEEPERS

1. Load the EXTEST opcode into the Instruction Register.
2. Create a pattern of all ones “1111…” for ports with keepers.
3. Set all tri-state, bidirectional, and open-collector ports to an active state.
4. Change state to Shift-DR.
5. Shift in the ones pattern into the Boundary Scan Register at TDI.
6. Load the HIGHZ opcode into the Instruction Register.
7. Verify the outputs with keepers.
8. Load the EXTEST opcode into the Instruction Register.
9. Create a pattern of all zeros “0000…” for ports with keepers.
10. Set all tri-state, bidirectional, and open-collector ports to an active state.
11. Change state to Shift-DR.
12. Shift in the zeros pattern into the Boundary Scan Register at TDI.
13. Load the HIGHZ opcode into the Instruction Register.
14. Verify the outputs with keepers.

Test CLAMP Instruction

1. Load the SAMPLE opcode into the Instruction Register.
2. Prepare pattern of all zeros (zero_pat) for output ports. Set all tri-state, bidirectional, and
open-collector ports to an active state.
3. Change state to Shift-DR.
4. Shift in the zero_pat pattern into the Boundary Scan Register at TDI.
5. Load the CLAMP opcode into the Instruction Register. The CLAMP instruction targets
the Bypass Register.
6. Change state to Shift-DR.

Boundary Scan Process Guide, V8.2007_3 133

August 2007
Output Testing and Verification
Troubleshooting the Test Bench Simulation

7. Shift in a predefined pattern into the Bypass Register at TDI and observe the same
pattern at TDO after one cycle.
8. Verify that all output ports are set to 0.

Test User-Defined Instructions

1. Load user-defined instruction opcode into the Instruction Register. This instruction will
target the register you specified with the Add Bscan Instruction command.
2. Change state to Shift-DR.
3. Shift in a predefined pattern to the selected register at TDI by pulsing TCK for ‘n + 1’
cycles, where ‘n’ is the size of the selected register.
4. Shift out and verify the predefined pattern at TDO.

Test MBISTArchitect Instructions

1. Load the MBIST opcode into the Instruction Register.
2. Change state to Shift-DR.
3. Shift in the MBIST start pattern at TDI.
4. Change state to Run-Test/Idle and wait for the MBIST test to complete.
5. Synchronize TCK with the Test Clock (for forcing TMS).
• If TCK == 1, skip 1 negedge + 1/4 of TCK period.
• If TCK == 0, skip 1 posedge + 1 negedge + 1/4 of TCK period.
6. Wait for a specified number of cycles.
7. Change state to Capture-DR to capture the MBIST test response.
8. Change state to Shift-DR.
9. Shift out and verify the response at TDO (end at Update-DR state).
10. Repeat the above steps for multiple MBIST test patterns, if required.

Test INT_SCAN and MULT_SCAN Instructions

1. Load the INT_SCAN or MULT_SCAN opcode into the Instruction Register. The
INT_SCAN instruction targets the internal scan chain (core register) you specified with
the Add Bscan Instruction command. The MULT_SCAN instruction targets an internal
scan chain in series with the Boundary Scan Register.
2. Change state to Shift-DR.

134 Boundary Scan Process Guide, V8.2007_3

August 2007
 Output Testing and Verification
Troubleshooting the Test Bench Simulation

3. Shift in a predefined 4-bit pattern at TDI for N+4 cycles, where N is the length of the
selected register.
4. Verify the predefined pattern at TDO.

Test Extest Pulse

1. Load the EXTEST_PULSE opcode into the Instruction Register.
2. Create a pattern of all ones “1111…” and set all ports to an active state.
3. Change state to Shift-DR.
4. Shift in the ones pattern into the Boundary Scan Register at TDI.
5. Change state to Update-DR (pattern applied on PO).
6. Change state to Run-Test/Idle and verify that the pattern is inverted on PO.
7. Remain in Run-Test/Idle for 3 cycles and verify that none of the POs are transitioning.
8. Change state to Update-DR and verify that all POs are restored to their original value.
9. Create a pattern of all zeros “0000…” and set all ports to an active state.
10. Change state to Shift-DR.
11. Shift in the zeros pattern into the Boundary Scan Register at TDI.
12. Change state to Update-DR (pattern applied on PO).
13. Change state to Run-Test/Idle and verify that the pattern is inverted on PO.
14. Remain in Run-Test/Idle for 3 cycles and verify that none of the POs are transitioning.
15. Change state to Update-DR and verify that all POs are restored to their original value.

Test Extest Train

1. Load the EXTEST_TRAIN opcode into the Instruction Register.
2. Create a pattern of all ones “1111…” and set all ports to an active state.
3. Change state to Shift-DR.
4. Shift in the ones pattern into the Boundary Scan Register at TDI.
5. Change state to Update-DR (pattern applied on PO).
6. Change state to Run-Test/Idle and verify that the pattern is inverted on PO.
7. Remain in Run-Test/Idle for 3 cycles and verify that the pattern on PO is getting
inverted on each neg-edge of TCK.
8. Change state to Update-DR and verify that all POs are restored to their original value.

Boundary Scan Process Guide, V8.2007_3 135

August 2007
Output Testing and Verification
Troubleshooting the Test Bench Simulation

9. Create a pattern of all zeros “0000…” and set all ports to an active state.
10. Change state to Shift-DR.
11. Shift in the zeros pattern into the Boundary Scan Register at TDI.
12. Change state to Update-DR (pattern applied on PO).
13. Change state to Run-Test/Idle and verify that the pattern is inverted on PO.
14. Remain in Run-Test/Idle for 3 cycles and verify that the pattern on PO is getting
inverted on each neg-edge of TCK.
15. Change state to Update-DR and verify that all POs are restored to their original value.

Test Mode-Mux
1. Load the SAMPLE opcode into the Instruction Register.
2. Change state to Capture-DR to capture the core outputs.
3. Change state to Shift-DR.
4. Shift out the sampled core data at TDO and store it in an array (bsreg_value).
5. Invert the sampled core data and store it in an array (inv_bsreg_value).
6. Change state to Shift-DR.
7. Shift in the inverted data into the Boundary Scan Register at TDI.
8. Change state to Update-DR and load the data into update register of the boundary scan
cells. At this point, one input of mode mux (PI-PO) contains the sampled data (core
data) and other input (Update Reg to PO) contains the inverted data.
9. Load the EXTEST opcode into the Instruction Register.
10. Verify that the inverted data appears on all POs.
# 8. Test MODE-MUX for all instructions
# --------------------------------------------------
# 623650 OK **** Shifting out the sampled core logic output signal
values
# 668450 OK Shifting inverted core logic signals into the update
register of bsr cells
#
# 713850 OK Testing Mode-mux during EXTEST instruction
# 713850 OK *** loading instruction EXTEST ***
# 715850 OK Data check OK *** All outputs are set to the update
register value
#

Test Unused Opcodes for BYPASS Instruction

1. Load the unused opcode into the Instruction Register.

136 Boundary Scan Process Guide, V8.2007_3

August 2007
 Output Testing and Verification
Troubleshooting the Test Bench Simulation

2. Change state to Shift-DR .

3. Shift out one bit from the Bypass Register and verify a 0 at TDO.
4. Shift in a predefined pattern into the Bypass Register at TDI.
5. Verify the predefined pattern shifted out at TDO.
6. Return to Run-Test/Idle state and set TDO to Z.
# 9. Test unassigned opcodes for equivalence to bypass
# --------------------------------------------------
# 721850 OK *** loading opcode: 0111***
# 724450 OK **** Checking bypass register output
# 726850 OK Data check OK *** Overshifted bypass register output
equals the inserted value 11110011111
# 726850 OK *** TDO is set to 'Z' ***
# 727250 OK *** loading opcode: 1011***
# 729850 OK **** Checking bypass register output
# 732250 OK Data check OK *** Overshifted bypass register output
equals the inserted value 11110011111
# 732250 OK *** TDO is set to 'Z' ***
# 732650 OK *** loading opcode: 1101***
# 735250 OK **** Checking bypass register output
# 737650 OK Data check OK *** Overshifted bypass register output
equals the inserted value 11110011111
# 737650 OK *** TDO is set to 'Z' ***
...

Parametric Testing
The following sections describe the parametric tests that may be included in the test bench.

Typical
1. Load the EXTEST opcode into the Instruction Register.
2. Test the input ports:
a. Create an inactive pattern (para_pattern_z).
b. Change state to Shift-DR.
c. Shift in the para_pattern_z pattern into the Boundary Scan Register at TDI.
d. Apply a 0 to all input ports.
e. Change state to Shift-DR (through Update-DR).
f. Shift out and verify a 0 for all input port positions at TDO.
g. Shift in the para_pattern_z pattern into the Boundary Scan Register at TDI.
h. Apply a 1 to all input ports.

Boundary Scan Process Guide, V8.2007_3 137

August 2007
Output Testing and Verification
Troubleshooting the Test Bench Simulation

i. Change state to Shift-DR (through Update-DR).

j. Shift out and verify a 1 for all input port positions at TDO.
k. Force all bidirectional ports to Z.
3. Test the output ports:
a. Create an active pattern for control cells and a zero pattern for data cells
(para_pattern_0) for all output ports.
b. Change state to Shift-DR.
c. Shift in the para_pattern_0 pattern into the Boundary Scan Register at TDI.
d. Change state to Run-Test/Idle (through Update-DR).
e. Verify that 0 is observed on all output ports.
f. Create an active pattern for control cells and a ones pattern for data cells
(para_pattern_1) for all output ports.
g. Change state to Shift-DR.
h. Shift in the para_pattern_1 pattern into the Boundary Scan Register at TDI.
i. Change state to Run-Test/Idle (through Update-DR).
j. Verify that 1 is observed on all output ports.
k. Load the HIGHZ opcode into the Instruction Register.
l. Verify that all outputs are set to Z.

Checkerboard
1. Load the EXTEST opcode into the Instruction Register.
2. Test the input ports:
a. Create an inactive pattern (para_pattern_z).
b. Change state to Shift-DR.
c. Shift in the para_pattern_z pattern into the Boundary Scan Register at TDI.
d. Apply a checkerboard pattern “0101…” to all input ports.
e. Change state to Shift-DR (through Update-DR).
f. Shift out and verify the checkerboard pattern for all input port positions at TDO.
g. Shift in the para_pattern_z pattern into the Boundary Scan Register at TDI.
h. Apply a checkerboard pattern “1010…” to all input ports.

138 Boundary Scan Process Guide, V8.2007_3

August 2007
 Output Testing and Verification
Troubleshooting the Test Bench Simulation

i. Change state to Shift-DR (through Update-DR).

j. Shift out and verify the checkerboard pattern for all input port positions at TDO.
3. Test the output ports:
a. Create a checkerboard pattern “0101…” for all output ports.
b. Change state to Shift-DR.
c. Shift in the checkerboard pattern into the Boundary Scan Register at TDI.
d. Change state to Run-Test/Idle (through Update-DR).
e. Verify that the checkerboard pattern is observed on the output ports.
f. Create a checkerboard pattern “1010…” for all output ports.
g. Change state to Shift-DR.
h. Shift in the checkerboard pattern into the Boundary Scan Register at TDI.
i. Change state to Run-Test/Idle (through Update-DR).
j. Verify that the checkerboard pattern is observed on all output ports.
k. Load the HIGHZ opcode into the Instruction Register.
l. Verify that all outputs are set to Z.

Ground Bounce Set

1. Test the input ports:
a. Load the EXTEST opcode into the Instruction Register.
b. Create an inactive pattern (para_pattern_z).
c. Change state to Shift-DR.
d. Shift in the para_pattern_z pattern into the Boundary Scan Register at TDI.
e. Change state to Run-Test/Idle.
f. Apply a 0 to all inputs.
g. Wait for 1 TCK cycle.
h. Apply a 1 to all inputs.
i. Change state to Shift-DR.
j. Shift out and verify that a 1 was observed on all input positions at TDO.
k. Set all bidirectional ports to an inactive state.

Boundary Scan Process Guide, V8.2007_3 139

August 2007
Output Testing and Verification
Troubleshooting the Test Bench Simulation

2. Test the output ports:

a. Load the EXTEST opcode into the Instruction Register.
b. Create a zeros pattern (para_pattern_0) for all outputs.
c. Change state to Shift-DR.
d. Shift in the para_pattern_0 pattern into the Boundary Scan Register at TDI.
e. Change state to Run-Test/Idle.
f. Reload the EXTEST opcode into the Instruction Register.
g. Create a ones pattern (para_pattern_1) for all outputs.
h. Change state to Shift-DR.
i. Shift in the para_pattern_1 pattern into the Boundary Scan Register at TDI.
j. Change state to Run-Test/Idle (through Update-DR).
k. Verify that a 1 was observed on all output ports.

VCC Bounce Set

This is the same as the Ground bounce test except that pattern order is reversed:

1. Test the input ports:

a. Load the EXTEST opcode into the Instruction Register.
b. Create an inactive pattern (para_pattern_z).
c. Change state to Shift-DR.
d. Shift in the para_pattern_z pattern into the Boundary Scan Register at TDI.
e. Change state to Run-Test/Idle.
f. Apply a 1 to all input ports.
g. Wait for 1 TCK cycle.
h. Apply a 0 to all input ports.
i. Change state to Shift-DR.
j. Shift out and verify that a 0 was observed on all input positions at TDO.
k. Set all bidirectional ports to an inactive state.
2. Test the output ports:
a. Load the EXTEST opcode into the Instruction Register.

140 Boundary Scan Process Guide, V8.2007_3

August 2007
 Output Testing and Verification
Troubleshooting the Test Bench Simulation

b. Create a ones pattern (para_pattern_1) for all outputs.

c. Change state to Shift-DR.
d. Shift in the para_pattern_1 pattern into the Boundary Scan Register at TDI.
e. Change state to Run-Test/Idle.
f. Reload the EXTEST opcode into the Instruction Register.
g. Create a zeros pattern (para_pattern_0) for all outputs.
h. Change state to Shift-DR.
i. Shift in the para_pattern_0 pattern into the Boundary Scan Register at TDI.
j. Change state to Run-Test/Idle (through Update-DR).
k. Verify that a 0 was observed on all output ports.

Boundary Scan Process Guide, V8.2007_3 141

August 2007
Output Testing and Verification
Troubleshooting the Test Bench Simulation

142 Boundary Scan Process Guide, V8.2007_3

August 2007
 Appendix A
Getting Help

There are several ways to get help when setting up and using DFT software tools. Depending on
your need, help is available from the following sources:

• Documentation
• Online Command Help
• Mentor Graphics Support
• Examples and Solutions

Documentation
A comprehensive set of reference manuals, user guides, and release notes is available in two
formats:

• HTML for searching and viewing online

• PDF for printing
The documentation is available from each software tool and online at:

http://supportnet.mentor.com

For more information on setting up and using DFT documentation, see the “Using DFT
Documentation” chapter in the Managing Mentor Graphics DFT Software manual

Online Command Help

Online command usage information is available from the command line in all DFT tools. You
can use the Help command to display a list of available commands, the syntax usage, or the
entire reference page for a command.

Mentor Graphics Support

Mentor Graphics software support includes software enhancements, access to comprehensive
online services with SupportNet, and the optional On-Site Mentoring service. For details, see:

http://supportnet.mentor.com/about/

Boundary Scan Process Guide, V8.2007_3 143

August 2007
Getting Help
Examples and Solutions

If you have questions about a software release, you can log in to SupportNet and search
thousands of technical solutions, view documentation, or open a Service Request online at:

http://supportnet.mentor.com

If your site is under current support and you do not have a SupportNet login, you can register for
SupportNet by filling out the short form at:

http://supportnet.mentor.com/user/register.cfm

All customer support contact information can be found on our web site at:

http://supportnet.mentor.com/contacts/supportcenters/index.cfm

Examples and Solutions

If you have a current SupportNet login, then you can access the SupportNet Design-for-Test
Circuits and Solutions site, which contains a variety of example circuits and dofiles specific to
DFT. You can access this site at the following URL:

http://supportnet.mentor.com/reference/other-info/dft_circuits/index.cfm

144 Boundary Scan Process Guide, V8.2007_3

August 2007
 Appendix B
Cell Type Assignments for Bidirectional
Ports

Background
By default, the BSDArchitect tool follows the IEEE 1149.1 standard for bidirectional (bidi)
ports. If you have a configured bidi port, then the tool adds the following:

• Control Port — Adds a combined type BC_2_A, BC_2_A_EXT, or BC_2_B.

• Bidi-out Port — Adds a BC_7 or BC_7_LOW cell type.
• Bidi-in Port — Assigns no cell.
Consequently, this configuration allows the tool to skip a cell on the bidi-input port and allows
the same testability as you would have if there was a cell (for example, BC_1 which is a 3-cell
model) each on each port.

To meet this combination, the tool needs a more circuit than that of the standard BC_2 cell and
depending on if the bidi-control is active high or low, the tool also needs a different BC_7 cell
(BC_7 is for active high, and BC_7_LOW for active low pad).

Understanding Cell Type Assignments

When using the BSDArchitect external flow, you declare and configure bidi ports using the Add
Tristate Port command. This command automatically assigns one of the following boundary
scan cell types to the bidi port:

• BC_2_A Cell — A non-IEEE standard cell type for use with a combined I/O bidi
control pin. The tool assigns this cell type when the bidi control pad is active low.
• BC_2_A_EXT Cell — A non-IEEE standard cell type similar to BC_2_A for use with a
combined I/O bidi control pin. The tool assigns this cell type when the bidi-control is an
external control signal.
• BC_2_B Cell — A non-IEEE standard cell type similar to BC_2_A for use with a
combined I/O bidi control pin. The tool assigns this cell type when the bidi control pad
is active high.
• BC_7 Cell — An IEEE-specified cell type. The tool assigns this cell on the output of a
bidi when the bidi pad is active high.

Boundary Scan Process Guide, V8.2007_3 145

August 2007
Cell Type Assignments for Bidirectional Ports
Cell Type Correspondence

• BC_7_LOW Cell — A non-IEEE standard cell type similar to BC_7. The tool assigns
this cell added on the output of a bidi when the bidi pad is active low.
You can modify these cell types assignments to a bidi port using the Add Bscan Cell command.

Cell Type Correspondence

Table B-1 lists the BC_2_* to BC_7* cell type correspondence.

Table B-1. BC_2_* to BC_7* Cell Type Correspondence

Desired Output When Active Value of BC_2_* Cell Required Output
INTEST or RUNBIST Bidi Cell Added Cell Type
Instruction is Present
HIGHZ Low BC_2_B BC_7_LOW
Cell Value Low BC_2_A BC_7_LOW
HIGHZ High BC_2_A BC_7
Cell Value High BC_2_B BC_7

146 Boundary Scan Process Guide, V8.2007_3

August 2007
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Index

—A— Bypass register, 14

ATPG setup files, 118
—C—
—B— Clamp instruction, 15
Batch mode, 23 Command line window, 21
BC_10 cell type, 88 Commands
BC_2 cell type, 73 add bscan cell, 100, 101
BC_2_A cell type, 74 add bscan instruction, 106
BC_2_A_EXT cell type, 76 add core register, 106, 112
BC_3 cell type, 78 add differential port, 98, 101
BC_4 cell type, 79 add external register, 61
BC_5 cell type, 80 add opencollector port, 96, 101
BC_7 cell type, 82 add pad cell, 51, 92, 101
BC_8 cell type, 85 add port connection, 60
BC_9 cell type, 86 add technology cell, 51, 92, 93
Bidirectional ports, 32 add tristate port, 94, 101
Blocks, 21 connect core chains, 60
Boundary scan connect iscan chains, 60, 113
architecture, 13 delete nontop port, 62
board example, 12 dofile, 42, 65
customizing, 65 exit, 24, 43
internal design flow, 47 load pin map, 59, 100
pin mapping, 100 report circuit components, 50
specification, 42 report pad cell, 52
verification, 122 reset state, 24
Boundary scan cell mode, 71 run, 43, 50
Boundary scan cells, 13 save bscan, 43
Boundary scan register, 14 save patterns, 118
BSDArchitect set controller naming, 51
design issues, 32 set dofile abort, 23
external design flow, 25 set iscan interface, 111
features, 18 set pad cell, 51
invocation, 42, 48 set port order, 100
limitations, 38 set technology mapping, 51
output model, 26 Continuation character, 22
recommended practices, 40 Control panel window, 20
reserved words, 40 Control port notation, 55
BSDL, 18 Control signal, 35
BSDL flow, 20 Custom boundary scan, 65
Bypass instruction, 15

Boundary Scan Process Guide, V8.2007_3 147

August 2007
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

—D— —I—
Design I/O Pads. See Pads
BSDL flow, 20 Idcode instruction, 15
external flow, 19, 25 Input
external flow example, 42 I/O pad descriptions, 47, 48
internal flow, 19, 47 pin mapping file, 100
internal flow example, 49 Verilog netlist, 47
issues, 32 Instruction
Dofile, 23, 42, 65 bypass, 15
batch mode, 23 clamp, 15
set dofile abort, 23 extest, 14
Dummy scan pins, 108 highz, 15
idcode, 15
—E— intest, 15, 38
Enable signal, 35 preload, 14
Entity port logic type, 32 runbist, 15, 38
Escaped identifiers, 32 sample, 14
Exit the session, 24 sample_preload, 14
External boundary scan synthesis, 25 usercode, 15
External design flow, 25 Instruction register, 14
External flow, 19 Instructions
External register, 61 user-defined, 106
Extest instruction, 14 Internal boundary scan synthesis, 47
—F— Internal flow, 19
Flows control port notation, 55
BSDL, 20 inputs, 47
external, 19, 25 output, 48
internal, 19 power and ground ports, 59
Functional blocks, 21 tdo pin sharing, 62
top-level port connections, 60
—G— uniquification, 63
Graphical User Interface unsupported commands, 64
command line window, 21 Internal scan circuitry, 38, 107
control panel window, 20 Internal_flow switch, 48
dofiles, 23 Interrupting the session, 24
exit, 24 Intest instruction, 15, 38
functional blocks, 21 Invocation, 42, 48
interrupt, 24
log files, 23 —J—
process flow blocks, 21 JTAG, 11
resetting, 24 JTAG ports, 51
UNIX commands, 24 —L—
Ground ports, 59 Library switch, 48
—H— Limitations, 38
Highz instruction, 15 Line continuation character, 22

148 Boundary Scan Process Guide, V8.2007_3

August 2007
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Log files, 23 —S—

Sample instruction, 14
—N— Sample_preload instruction, 14
Nostandalone mode, 110
Scan
—O— architectures, 108
Output connecting, 107
ATPG setup file, 118 Scan cells
example, 28, 30 boundary, 13
model, 26 Scan chains, 113
types, 26, 115 Scripts, 23
Specparams, 48
—P— Standalone mode, 110
Pads
bidirectional, 95 —T—
differential input, 98 TAP, 14
differential output, 98 TAP controller, 14
input, 93 TDO pin sharing, 62
open collector output, 96 Technology mapping
output, 93 port mapping, 67
setting up, 92 to 99 Test access port, 14
tristate, 94 Test access port controller, 14
Parametric testing, 118 Test bench, 26, 116
Pin mapping, 59, 100 Test data register, 14
Pinmap file Test vectors, 18
contents, 100 Top-down design flows, 19
example, 28, 105 Tri-state ports, 32
loading, 100
—U—
syntax, 101 Uniquification, 63
Power ports, 59 UNIX commands, 24
Preload instruction, 14 Usercode instruction, 15
Process flow blocks, 21 User-defined instructions, 106
—R— —V—
Register Verifying boundary scan
boundary scan, 14 gate-level, 124
bypass, 14 overview, 122
instruction, 14 Verilog escaped identifiers, 32
test data, 14 Verilog support, 39
Reserved words, 40 VHDL entity, 32
Resetting the state, 24
Runbist instruction, 15, 38 —W—
Running the tool Windows
BSDL, 119 command line, 21
external, 43 control panel, 20

Boundary Scan Process Guide, V8.2007_3 149

August 2007
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

150 Boundary Scan Process Guide, V8.2007_3

August 2007
 Third-Party Information
This section provides information on open source and third-party software that may be included in Design-for-Test software
products.

• •This software application may include GTK 2.6.1 third-party software and may be subject to the following copyright(s)
and/or use terms:

Copyright (c) 1998, 1999, 2000 Thai Open Source Software Center Ltd and Clark Cooper

Copyright (c) 2001, 2002 Expat maintainers.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation
files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify,
merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT
OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.

**********************************************************************

Copyright (c) 1998, 1999 Henry Spencer. All rights reserved.

Development of this software was funded, in part, by Cray Research Inc.,

UUNET Communications Services Inc., Sun Microsystems Inc., and Scriptics

Corporation, none of whom are responsible for the results. The author

thanks all of them.

Redistribution and use in source and binary forms -- with or without

modification -- are permitted for any purpose, provided that

redistributions in source form retain this entire copyright notice and

indicate the origin and nature of any modifications.

I'd appreciate being given credit for this package in the documentation

of software which uses it, but that is not a requirement.

THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,

INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY

AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL

HENRY SPENCER BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,

EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,

PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;

OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,

WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR

OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF

ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

**********************************************************************

wxWindows adopted the code out of Tcl 8.4.5. Portions of regc_locale.c

and re_syntax.n were developed by Tcl developers other than Henry Spencer;

these files bear the Tcl copyright and license notice:

**********************************************************************

This software is copyrighted by the Regents of the University of

California, Sun Microsystems, Inc., Scriptics Corporation, ActiveState

Corporation and other parties. The following terms apply to all files

associated with the software unless explicitly disclaimed in

individual files.

The authors hereby grant permission to use, copy, modify, distribute,

and license this software and its documentation for any purpose, provided

that existing copyright notices are retained in all copies and that this

notice is included verbatim in any distributions. No written agreement,

license, or royalty fee is required for any of the authorized uses.

Modifications to this software may be copyrighted by their authors

and need not follow the licensing terms described here, provided that

the new terms are clearly indicated on the first page of each file where

they apply.

IN NO EVENT SHALL THE AUTHORS OR DISTRIBUTORS BE LIABLE TO ANY PARTY

FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES

ARISING OUT OF THE USE OF THIS SOFTWARE, ITS DOCUMENTATION, OR ANY

DERIVATIVES THEREOF, EVEN IF THE AUTHORS HAVE BEEN ADVISED OF THE

POSSIBILITY OF SUCH DAMAGE.

THE AUTHORS AND DISTRIBUTORS SPECIFICALLY DISCLAIM ANY WARRANTIES,

INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY,

FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT. THIS SOFTWARE

IS PROVIDED ON AN "AS IS" BASIS, AND THE AUTHORS AND DISTRIBUTORS HAVE

NO OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR

MODIFICATIONS.

GOVERNMENT USE: If you are acquiring this software on behalf of the

U.S. government, the Government shall have only "Restricted Rights"

in the software and related documentation as defined in the Federal

Acquisition Regulations (FARs) in Clause 52.227.19 (c) (2). If you

are acquiring the software on behalf of the Department of Defense, the

software shall be classified as "Commercial Computer Software" and the

Government shall have only "Restricted Rights" as defined in Clause

252.227-7013 (c) (1) of DFARs. Notwithstanding the foregoing, the

authors grant the U.S. Government and others acting in its behalf
permission to use and distribute the software in accordance with the

terms specified in this license.

**********************************************************************

The wxWindows license applies to further modifications to regcustom.h

and regc_locale.c.

****************************************************************************

-----------------------------------------------------

License for Scintilla and SciTE

Copyright 1998-2003 by Neil Hodgson <[email protected]>

All Rights Reserved

Permission to use, copy, modify, and distribute this software and its

documentation for any purpose and without fee is hereby granted,

provided that the above copyright notice appear in all copies and that

both that copyright notice and this permission notice appear in

supporting documentation.

NEIL HODGSON DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS

SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY

AND FITNESS, IN NO EVENT SHALL NEIL HODGSON BE LIABLE FOR ANY

SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES

WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,

WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER

TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE

OR PERFORMANCE OF THIS SOFTWARE.

-----------------------------------------------------

Copyright (c) 1988-1997 Sam Leffler

Copyright (c) 1991-1997 Silicon Graphics, Inc.

Permission to use, copy, modify, distribute, and sell this software and

its documentation for any purpose is hereby granted without fee, provided

that (i) the above copyright notices and this permission notice appear in

all copies of the software and related documentation, and (ii) the names of

Sam Leffler and Silicon Graphics may not be used in any advertising or

publicity relating to the software without the specific, prior written

permission of Sam Leffler and Silicon Graphics.

THE SOFTWARE IS PROVIDED "AS-IS" AND WITHOUT WARRANTY OF ANY KIND,

EXPRESS, IMPLIED OR OTHERWISE, INCLUDING WITHOUT LIMITATION, ANY

WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

IN NO EVENT SHALL SAM LEFFLER OR SILICON GRAPHICS BE LIABLE FOR

ANY SPECIAL, INCIDENTAL, INDIRECT OR CONSEQUENTIAL DAMAGES OF ANY KIND,

OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,

WHETHER OR NOT ADVISED OF THE POSSIBILITY OF DAMAGE, AND ON ANY THEORY OF

LIABILITY, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE

OF THIS SOFTWARE.

-----------------------------------------------------

(C) 1995-2004 Jean-loup Gailly and Mark Adler

This software is provided 'as-is', without any express or implied

warranty. In no event will the authors be held liable for any damages

arising from the use of this software.

 Permission is granted to anyone to use this software for any purpose,

including commercial applications, and to alter it and redistribute it

freely, subject to the following restrictions:

1. The origin of this software must not be misrepresented; you must not

claim that you wrote the original software. If you use this software

in a product, an acknowledgment in the product documentation would be

appreciated but is not required.

2. Altered source versions must be plainly marked as such, and must not be

misrepresented as being the original software.

3. This notice may not be removed or altered from any source distribution.

Jean-loup Gailly Mark Adler

[email protected] [email protected]

If you use the zlib library in a product, we would appreciate *not*

receiving lengthy legal documents to sign. The sources are provided

for free but without warranty of any kind. The library has been

entirely written by Jean-loup Gailly and Mark Adler; it does not

include third-party code.

If you redistribute modified sources, we would appreciate that you include

in the file ChangeLog history information documenting your changes. Please

read the FAQ for more information on the distribution of modified source

versions.

This software application may include GTK 2.6.1 third-party software and may be subject to the following copyrights.

wxWindows Library Licence, Version 3

====================================
Copyright (C) 1998 Julian Smart, Robert Roebling [, ...]

Everyone is permitted to copy and distribute verbatim copies

of this licence document, but changing it is not allowed.

WXWINDOWS LIBRARY LICENCE

TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION

This library is free software; you can redistribute it and/or modify it

under the terms of the GNU Library General Public Licence as published by

the Free Software Foundation; either version 2 of the Licence, or (at

your option) any later version.

This library is distributed in the hope that it will be useful, but

WITHOUT ANY WARRANTY; without even the implied warranty of

MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library

General Public Licence for more details.

You should have received a copy of the GNU Library General Public Licence

along with this software, usually in a file named COPYING.LIB. If not,

write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330,

Boston, MA 02111-1307 USA.

EXCEPTION NOTICE

1. As a special exception, the copyright holders of this library give

permission for additional uses of the text contained in this release of

the library as licenced under the wxWindows Library Licence, applying

either version 3 of the Licence, or (at your option) any later version of

the Licence as published by the copyright holders of version 3 of the

Licence document.
 2. The exception is that you may use, copy, link, modify and distribute

under the user's own terms, binary object code versions of works based

on the Library.

3. If you copy code from files distributed under the terms of the GNU

General Public Licence or the GNU Library General Public Licence into a

copy of this library, as this licence permits, the exception does not

apply to the code that you add in this way. To avoid misleading anyone as

to the status of such modified files, you must delete this exception

notice from such code and/or adjust the licensing conditions notice

accordingly.

4. If you write modifications of your own for this library, it is your

choice whether to permit this exception to apply to your modifications.

If you do not wish that, you must delete the exception notice from such

code and/or adjust the licensing conditions notice accordingly.

• This software application may include GTK+ third-party software, portions of which may be subject to the GNU Library
General Public License. You can view the complete license at: http://www.gnu.org/copyleft/library.html, or find the file
at mgcdft_tree/docs/legal/.

• To obtain a copy of the GTK+ source code, send a request to [email protected]. This offer may be
accepted for three years from the date Mentor Graphics Corporation first distributed the GTK+ source code.
• This software application may include freestdf third-party software that may be subject to the following copyright(s):

© 2004 Nelson Ingersoll <[email protected]>

© 2004-2005 Mike Frysinger [email protected]. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following
conditions are met:

Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer
in the documentation and/or other materials provided with the distribution.

Neither the name of the FREESTDF nor the names of its contributors may be used to endorse or promote products derived
from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 End-User License Agreement
The latest version of the End-User License Agreement is available on-line at:
www.mentor.com/terms_conditions/enduser.cfm

IMPORTANT INFORMATION

USE OF THIS SOFTWARE IS SUBJECT TO LICENSE RESTRICTIONS. CAREFULLY READ THIS

LICENSE AGREEMENT BEFORE USING THE SOFTWARE. USE OF SOFTWARE INDICATES YOUR
COMPLETE AND UNCONDITIONAL ACCEPTANCE OF THE TERMS AND CONDITIONS SET FORTH
IN THIS AGREEMENT. ANY ADDITIONAL OR DIFFERENT PURCHASE ORDER TERMS AND
CONDITIONS SHALL NOT APPLY.

END-USER LICENSE AGREEMENT (“Agreement”)

This is a legal agreement concerning the use of Software between you, the end user, as an authorized
representative of the company acquiring the license, and Mentor Graphics Corporation and Mentor Graphics
(Ireland) Limited acting directly or through their subsidiaries (collectively “Mentor Graphics”). Except for license
agreements related to the subject matter of this license agreement which are physically signed by you and an
authorized representative of Mentor Graphics, this Agreement and the applicable quotation contain the parties'
entire understanding relating to the subject matter and supersede all prior or contemporaneous agreements. If you
do not agree to these terms and conditions, promptly return or, if received electronically, certify destruction of
Software and all accompanying items within five days after receipt of Software and receive a full refund of any
license fee paid.

1. GRANT OF LICENSE. The software programs, including any updates, modifications, revisions, copies, documentation
and design data (“Software”), are copyrighted, trade secret and confidential information of Mentor Graphics or its
licensors who maintain exclusive title to all Software and retain all rights not expressly granted by this Agreement.
Mentor Graphics grants to you, subject to payment of appropriate license fees, a nontransferable, nonexclusive license to
use Software solely: (a) in machine-readable, object-code form; (b) for your internal business purposes; (c) for the license
term; and (d) on the computer hardware and at the site authorized by Mentor Graphics. A site is restricted to a one-half
mile (800 meter) radius. Mentor Graphics’ standard policies and programs, which vary depending on Software, license
fees paid or services purchased, apply to the following: (a) relocation of Software; (b) use of Software, which may be
limited, for example, to execution of a single session by a single user on the authorized hardware or for a restricted period
of time (such limitations may be technically implemented through the use of authorization codes or similar devices); and
(c) support services provided, including eligibility to receive telephone support, updates, modifications, and revisions.

2. EMBEDDED SOFTWARE. If you purchased a license to use embedded software development (“ESD”) Software, if
applicable, Mentor Graphics grants to you a nontransferable, nonexclusive license to reproduce and distribute executable
files created using ESD compilers, including the ESD run-time libraries distributed with ESD C and C++ compiler
Software that are linked into a composite program as an integral part of your compiled computer program, provided that
you distribute these files only in conjunction with your compiled computer program. Mentor Graphics does NOT grant
you any right to duplicate, incorporate or embed copies of Mentor Graphics' real-time operating systems or other
embedded software products into your products or applications without first signing or otherwise agreeing to a separate
agreement with Mentor Graphics for such purpose.

3. BETA CODE. Software may contain code for experimental testing and evaluation (“Beta Code”), which may not be used
without Mentor Graphics’ explicit authorization. Upon Mentor Graphics’ authorization, Mentor Graphics grants to you a
temporary, nontransferable, nonexclusive license for experimental use to test and evaluate the Beta Code without charge
for a limited period of time specified by Mentor Graphics. This grant and your use of the Beta Code shall not be construed
as marketing or offering to sell a license to the Beta Code, which Mentor Graphics may choose not to release
commercially in any form. If Mentor Graphics authorizes you to use the Beta Code, you agree to evaluate and test the
Beta Code under normal conditions as directed by Mentor Graphics. You will contact Mentor Graphics periodically
during your use of the Beta Code to discuss any malfunctions or suggested improvements. Upon completion of your
evaluation and testing, you will send to Mentor Graphics a written evaluation of the Beta Code, including its strengths,
weaknesses and recommended improvements. You agree that any written evaluations and all inventions, product
improvements, modifications or developments that Mentor Graphics conceived or made during or subsequent to this
Agreement, including those based partly or wholly on your feedback, will be the exclusive property of Mentor Graphics.
Mentor Graphics will have exclusive rights, title and interest in all such property. The provisions of this section 3 shall
survive the termination or expiration of this Agreement.
4. RESTRICTIONS ON USE. You may copy Software only as reasonably necessary to support the authorized use. Each
copy must include all notices and legends embedded in Software and affixed to its medium and container as received from
Mentor Graphics. All copies shall remain the property of Mentor Graphics or its licensors. You shall maintain a record of
the number and primary location of all copies of Software, including copies merged with other software, and shall make
those records available to Mentor Graphics upon request. You shall not make Software available in any form to any
person other than employees and on-site contractors, excluding Mentor Graphics' competitors, whose job performance
requires access and who are under obligations of confidentiality. You shall take appropriate action to protect the
confidentiality of Software and ensure that any person permitted access to Software does not disclose it or use it except as
permitted by this Agreement. Except as otherwise permitted for purposes of interoperability as specified by applicable
and mandatory local law, you shall not reverse-assemble, reverse-compile, reverse-engineer or in any way derive from
Software any source code. You may not sublicense, assign or otherwise transfer Software, this Agreement or the rights
under it, whether by operation of law or otherwise (“attempted transfer”), without Mentor Graphics’ prior written consent
and payment of Mentor Graphics’ then-current applicable transfer charges. Any attempted transfer without Mentor
Graphics' prior written consent shall be a material breach of this Agreement and may, at Mentor Graphics' option, result in
the immediate termination of the Agreement and licenses granted under this Agreement. The terms of this Agreement,
including without limitation, the licensing and assignment provisions shall be binding upon your successors in interest
and assigns. The provisions of this section 4 shall survive the termination or expiration of this Agreement.

5. LIMITED WARRANTY.

5.1. Mentor Graphics warrants that during the warranty period Software, when properly installed, will substantially
conform to the functional specifications set forth in the applicable user manual. Mentor Graphics does not warrant
that Software will meet your requirements or that operation of Software will be uninterrupted or error free. The
warranty period is 90 days starting on the 15th day after delivery or upon installation, whichever first occurs. You
must notify Mentor Graphics in writing of any nonconformity within the warranty period. This warranty shall not be
valid if Software has been subject to misuse, unauthorized modification or improper installation. MENTOR
GRAPHICS' ENTIRE LIABILITY AND YOUR EXCLUSIVE REMEDY SHALL BE, AT MENTOR GRAPHICS'
OPTION, EITHER (A) REFUND OF THE PRICE PAID UPON RETURN OF SOFTWARE TO MENTOR
GRAPHICS OR (B) MODIFICATION OR REPLACEMENT OF SOFTWARE THAT DOES NOT MEET THIS
LIMITED WARRANTY, PROVIDED YOU HAVE OTHERWISE COMPLIED WITH THIS AGREEMENT.
MENTOR GRAPHICS MAKES NO WARRANTIES WITH RESPECT TO: (A) SERVICES; (B) SOFTWARE
WHICH IS LICENSED TO YOU FOR A LIMITED TERM OR LICENSED AT NO COST; OR
(C) EXPERIMENTAL BETA CODE; ALL OF WHICH ARE PROVIDED “AS IS.”

5.2. THE WARRANTIES SET FORTH IN THIS SECTION 5 ARE EXCLUSIVE. NEITHER MENTOR GRAPHICS
NOR ITS LICENSORS MAKE ANY OTHER WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, WITH
RESPECT TO SOFTWARE OR OTHER MATERIAL PROVIDED UNDER THIS AGREEMENT. MENTOR
GRAPHICS AND ITS LICENSORS SPECIFICALLY DISCLAIM ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT OF
INTELLECTUAL PROPERTY.

6. LIMITATION OF LIABILITY. EXCEPT WHERE THIS EXCLUSION OR RESTRICTION OF LIABILITY

WOULD BE VOID OR INEFFECTIVE UNDER APPLICABLE LAW, IN NO EVENT SHALL MENTOR GRAPHICS
OR ITS LICENSORS BE LIABLE FOR INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES
(INCLUDING LOST PROFITS OR SAVINGS) WHETHER BASED ON CONTRACT, TORT OR ANY OTHER
LEGAL THEORY, EVEN IF MENTOR GRAPHICS OR ITS LICENSORS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES. IN NO EVENT SHALL MENTOR GRAPHICS' OR ITS LICENSORS'
LIABILITY UNDER THIS AGREEMENT EXCEED THE AMOUNT PAID BY YOU FOR THE SOFTWARE OR
SERVICE GIVING RISE TO THE CLAIM. IN THE CASE WHERE NO AMOUNT WAS PAID, MENTOR
GRAPHICS AND ITS LICENSORS SHALL HAVE NO LIABILITY FOR ANY DAMAGES WHATSOEVER. THE
PROVISIONS OF THIS SECTION 6 SHALL SURVIVE THE EXPIRATION OR TERMINATION OF THIS
AGREEMENT.

7. LIFE ENDANGERING ACTIVITIES. NEITHER MENTOR GRAPHICS NOR ITS LICENSORS SHALL BE
LIABLE FOR ANY DAMAGES RESULTING FROM OR IN CONNECTION WITH THE USE OF SOFTWARE IN
ANY APPLICATION WHERE THE FAILURE OR INACCURACY OF THE SOFTWARE MIGHT RESULT IN
DEATH OR PERSONAL INJURY. THE PROVISIONS OF THIS SECTION 7 SHALL SURVIVE THE
EXPIRATION OR TERMINATION OF THIS AGREEMENT.

8. INDEMNIFICATION. YOU AGREE TO INDEMNIFY AND HOLD HARMLESS MENTOR GRAPHICS AND ITS
LICENSORS FROM ANY CLAIMS, LOSS, COST, DAMAGE, EXPENSE, OR LIABILITY, INCLUDING
ATTORNEYS' FEES, ARISING OUT OF OR IN CONNECTION WITH YOUR USE OF SOFTWARE AS
 DESCRIBED IN SECTION 7. THE PROVISIONS OF THIS SECTION 8 SHALL SURVIVE THE EXPIRATION OR
TERMINATION OF THIS AGREEMENT.

9. INFRINGEMENT.

9.1. Mentor Graphics will defend or settle, at its option and expense, any action brought against you alleging that
Software infringes a patent or copyright or misappropriates a trade secret in the United States, Canada, Japan, or
member state of the European Patent Office. Mentor Graphics will pay any costs and damages finally awarded
against you that are attributable to the infringement action. You understand and agree that as conditions to Mentor
Graphics' obligations under this section you must: (a) notify Mentor Graphics promptly in writing of the action;
(b) provide Mentor Graphics all reasonable information and assistance to defend or settle the action; and (c) grant
Mentor Graphics sole authority and control of the defense or settlement of the action.

9.2. If an infringement claim is made, Mentor Graphics may, at its option and expense: (a) replace or modify Software so
that it becomes noninfringing; (b) procure for you the right to continue using Software; or (c) require the return of
Software and refund to you any license fee paid, less a reasonable allowance for use.

9.3. Mentor Graphics has no liability to you if infringement is based upon: (a) the combination of Software with any
product not furnished by Mentor Graphics; (b) the modification of Software other than by Mentor Graphics; (c) the
use of other than a current unaltered release of Software; (d) the use of Software as part of an infringing process; (e) a
product that you make, use or sell; (f) any Beta Code contained in Software; (g) any Software provided by Mentor
Graphics’ licensors who do not provide such indemnification to Mentor Graphics’ customers; or (h) infringement by
you that is deemed willful. In the case of (h) you shall reimburse Mentor Graphics for its attorney fees and other costs
related to the action upon a final judgment.

9.4. THIS SECTION IS SUBJECT TO SECTION 6 ABOVE AND STATES THE ENTIRE LIABILITY OF MENTOR
GRAPHICS AND ITS LICENSORS AND YOUR SOLE AND EXCLUSIVE REMEDY WITH RESPECT TO
ANY ALLEGED PATENT OR COPYRIGHT INFRINGEMENT OR TRADE SECRET MISAPPROPRIATION
BY ANY SOFTWARE LICENSED UNDER THIS AGREEMENT.

10. TERM. This Agreement remains effective until expiration or termination. This Agreement will immediately terminate
upon notice if you exceed the scope of license granted or otherwise fail to comply with the provisions of Sections 1, 2, or
4. For any other material breach under this Agreement, Mentor Graphics may terminate this Agreement upon 30 days
written notice if you are in material breach and fail to cure such breach within the 30 day notice period. If Software was
provided for limited term use, this Agreement will automatically expire at the end of the authorized term. Upon any
termination or expiration, you agree to cease all use of Software and return it to Mentor Graphics or certify deletion and
destruction of Software, including all copies, to Mentor Graphics’ reasonable satisfaction.

11. EXPORT. Software is subject to regulation by local laws and United States government agencies, which prohibit export
or diversion of certain products, information about the products, and direct products of the products to certain countries
and certain persons. You agree that you will not export any Software or direct product of Software in any manner without
first obtaining all necessary approval from appropriate local and United States government agencies.

12. RESTRICTED RIGHTS NOTICE. Software was developed entirely at private expense and is commercial computer
software provided with RESTRICTED RIGHTS. Use, duplication or disclosure by the U.S. Government or a U.S.
Government subcontractor is subject to the restrictions set forth in the license agreement under which Software was
obtained pursuant to DFARS 227.7202-3(a) or as set forth in subparagraphs (c)(1) and (2) of the Commercial Computer
Software - Restricted Rights clause at FAR 52.227-19, as applicable. Contractor/manufacturer is Mentor Graphics
Corporation, 8005 SW Boeckman Road, Wilsonville, Oregon 97070-7777 USA.

13. THIRD PARTY BENEFICIARY. For any Software under this Agreement licensed by Mentor Graphics from Microsoft
or other licensors, Microsoft or the applicable licensor is a third party beneficiary of this Agreement with the right to
enforce the obligations set forth herein.

14. AUDIT RIGHTS. You will monitor access to, location and use of Software. With reasonable prior notice and during
your normal business hours, Mentor Graphics shall have the right to review your software monitoring system and
reasonably relevant records to confirm your compliance with the terms of this Agreement, an addendum to this
Agreement or U.S. or other local export laws. Such review may include FLEXlm or FLEXnet report log files that you
shall capture and provide at Mentor Graphics’ request. Mentor Graphics shall treat as confidential information all of your
information gained as a result of any request or review and shall only use or disclose such information as required by law
or to enforce its rights under this Agreement or addendum to this Agreement. The provisions of this section 14 shall
survive the expiration or termination of this Agreement.
15. CONTROLLING LAW, JURISDICTION AND DISPUTE RESOLUTION. THIS AGREEMENT SHALL BE
GOVERNED BY AND CONSTRUED UNDER THE LAWS OF THE STATE OF OREGON, USA, IF YOU ARE
LOCATED IN NORTH OR SOUTH AMERICA, AND THE LAWS OF IRELAND IF YOU ARE LOCATED
OUTSIDE OF NORTH OR SOUTH AMERICA. All disputes arising out of or in relation to this Agreement shall be
submitted to the exclusive jurisdiction of Portland, Oregon when the laws of Oregon apply, or Dublin, Ireland when the
laws of Ireland apply. Notwithstanding the foregoing, all disputes in Asia (except for Japan) arising out of or in relation to
this Agreement shall be resolved by arbitration in Singapore before a single arbitrator to be appointed by the Chairman of
the Singapore International Arbitration Centre (“SIAC”) to be conducted in the English language, in accordance with the
Arbitration Rules of the SIAC in effect at the time of the dispute, which rules are deemed to be incorporated by reference
in this section 15. This section shall not restrict Mentor Graphics’ right to bring an action against you in the jurisdiction
where your place of business is located. The United Nations Convention on Contracts for the International Sale of Goods
does not apply to this Agreement.

16. SEVERABILITY. If any provision of this Agreement is held by a court of competent jurisdiction to be void, invalid,
unenforceable or illegal, such provision shall be severed from this Agreement and the remaining provisions will remain in
full force and effect.

17. PAYMENT TERMS AND MISCELLANEOUS. You will pay amounts invoiced, in the currency specified on the
applicable invoice, within 30 days from the date of such invoice. Any past due invoices will be subject to the imposition
of interest charges in the amount of one and one-half percent per month or the applicable legal rate currently in effect,
whichever is lower. Some Software may contain code distributed under a third party license agreement that may provide
additional rights to you. Please see the applicable Software documentation for details. This Agreement may only be
modified in writing by authorized representatives of the parties. Waiver of terms or excuse of breach must be in writing
and shall not constitute subsequent consent, waiver or excuse.

Rev. 060210, Part No. 227900