Etserdes User

SIEMENS EDA
Tessent™ SerdesTest
User’s Manual
Software Version 2021.2 and Later
Unpublished work. © 2021 Siemens
This material contains trade secrets or otherwise confidential information owned by Siemens Industry Software, Inc.,
its subsidiaries or its affiliates (collectively, "Siemens"), or its licensors. Access to and use of this information is
strictly limited as set forth in Customer's applicable agreement with Siemens. This material may not be copied,
distributed, or otherwise disclosed outside of Customer's facilities without the express written permission of
Siemens, and may not be used in any way not expressly authorized by Siemens.
This document is for information and instruction purposes. Siemens 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 Siemens to determine whether any changes have been made. Siemens disclaims all warranties with
respect to this document including, without limitation, the implied warranties of merchantability, fitness for a
particular purpose, and non-infringement of intellectual property.
The terms and conditions governing the sale and licensing of Siemens products are set forth in written agreements
between Siemens and its customers. Siemens' End User License Agreement may be viewed at:
www.plm.automation.siemens.com/global/en/legal/online-terms/index.html.
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 Siemens whatsoever.
TRADEMARKS: The trademarks, logos, and service marks ("Marks") used herein are the property of Siemens or
other parties. No one is permitted to use these Marks without the prior written consent of Siemens or the owner of
the Marks, as applicable. The use herein of third party Marks is not an attempt to indicate Siemens as a source of a
product, but is intended to indicate a product from, or associated with, a particular third party. A list of Siemens'
trademarks may be viewed at: www.plm.automation.siemens.com/global/en/legal/trademarks.html. The registered
trademark Linux® is used pursuant to a sublicense from LMI, the exclusive licensee of Linus Torvalds, owner of the
mark on a world-wide basis.
Support Center: support.sw.siemens.com

Send Feedback on Documentation: support.sw.siemens.com/doc_feedback_form
Table of Contents
Chapter 1
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Embed Test Circuitry in Your IC Design to Test SerDes or PLLs . . . . . . . . . . . . . . . . . . . . 13
Characterize and Diagnose Silicon Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Generate Production Test Patterns for Your IC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Chapter 2
Step 1: Prepare Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
SerDes Suitability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Stable Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
General Implementation Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Step 1.0 — Create Working Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Step 1.1 — ETChecker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Step 1.2 — Indicate TAP Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Provide Connections for Second TAP, If Necessary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Step 1.3 — Indicate Design Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Step 1.4 — Check Clock Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Step 1.5 — Check DFT Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Step 1.6 — Check Default Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Step 1.7 — ETPlanner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Step 1.8 — Check Default Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Step 1.9 — CUT Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Connections for PLLs and DLLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Connections for Single-Clock SerDes Transceivers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Step 1.10 — Collect Design Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Step 1.11 — Update .etplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Connections for Dual-Clock SerDes Transceivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Step 1.12 — PLL Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Chapter 3
Step 2: Embed Test Circuitry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Step 2.0 — Check .etplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Step 2.1 — Generate LVWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Step 2.2 — Specify TAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Step 2.3 — Generate & insert RTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Add muxes and userDRBit connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Custom Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Step 2.4 — Check connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
File hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Step 2.5 — Prepare for simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
User Defined Sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Verilog to SVF conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Tessent™ SerdesTest User’s Manual, v2021.2 and Later 3

Table of Contents
Step 2.6 — Generate LVDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Step 2.7 — Generate test bench. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Step 2.8 — Simulate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
View RTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Simulate one pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Step 2.9 — Diagnose PLLTest SerdesTest simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
tapbistv and P1 patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
P2 pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
P3 pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
P4 pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Step 2.10 — Synthesize logic gates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Step 2.11 — Static timing analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Step 2.12 — Prepare for layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Step 2.13 — Prepare for sign-off. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Step 2.14 — Prepare for test pattern generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Step 2.15 — Generate final LVDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Step 2.16 — Generate post-layout simulation test bench . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Step 2.17 — Simulate post-layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Step 2.18 — Generate sample test patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Step 2.19 — Archive Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Chapter 4
Step 3: Prepare a Board to Characterize Your IC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Step 3.0 — Clocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
ATE Clocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
SRS CG635. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
LMK03000 PLL Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
PLL loop filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Clock Signal Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Master Reference Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Si550 VCXO Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Power Supply Decoupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Step 3.1 — Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Path Length in Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
AC vs. DC Coupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
DC Test Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Step 3.2 — JTAG. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
USB-Signalyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Step 3.3 — Board Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Step 3.4 — .pinmap File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Chapter 5
Step 4: Prepare SiliconInsight to Characterize Your IC . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Step 4.0 — Accessing SiliconInsight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Step 4.1 — Power up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Creating a complete set of tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Step 4.2 — Add a Test Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Step 4.3 — Choose a Test Controller (ULTRA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4 Tessent™ SerdesTest User’s Manual, v2021.2 and Later

Table of Contents
Step 4.4 — Choose test type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Step 4.5 — Set global clock periods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Step 4.6 — Program loadboard PLL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Step 4.7 — Set clock periods for single Test Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Step 4.8 — Add Test Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Step 4.9 — Measure reference frequency offset. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Pause Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Initial Wait Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
User Defined Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Pin Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
User Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Choose Test Controller (ULTRA) options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Test Duration in Beat Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Channel Select, or PLL to Test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Measurement Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Test Time Multiplier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Under Sampling Clock Ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Measurement Edge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Lock Time Pause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Step 4.10 — Measure reference clock jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
JitterFromCDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Chapter 6
Step 5: Characterize your SerDes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Use SiliconInsight to Characterize Your SerDes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Step 5.0 — Optimize frequency offset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Implementing SerDes Transmitter Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Step 5.1 — Measure RJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Data Bit Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Step 5.2 — Measure TJ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Step 5.3 — Measure DCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Step 5.4 — Measure ISI or TDDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Step 5.5 — Measure slew rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Step 5.6 — Measure 20%~80% transition time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Step 5.7 — Measure VCOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Step 5.8 — Measure logic voltages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Step 5.9 — Measure input/output resistances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Implementing SerDes Receiver Tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Step 5.10 — Measure mean sampling instant. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Step 5.11 — Measure systematic sampling error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Step 5.12 — Measure recovered clock jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Step 5.13 — Measure LF jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Implementing SerDes Lane Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Step 5.14 — Measure BER. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Step 5.15 — Detect bit errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Table of Contents
Chapter 7
Step 6: Diagnose and Characterize Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Step 6.0 — Diagnose Basic Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Step 6.1 — Diagnose Measurement Failures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Step 6.2 — Diagnose Jitter Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
P10J, P01J . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Getting Finer Resolution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Reference Clock Jitter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Periodic Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Step 6.3 — Check Lock Time Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Step 6.4 — Measure Repeatability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Step 6.5 — Calculate Test Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
BasicTests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
OffsetFrequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Jitter, DutyCycleDistortion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Jitter, DutyCycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
JitterFromCDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
MeanSamplingInstant, TransitionDensityDependentDelay . . . . . . . . . . . . . . . . . . . . . . . . 134
MultiPhaseSamplingError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
AverageSlewRate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
FunctionalLoopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Step 6.6 — Optimize Test Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Step 6.7 — Characterize many devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Saving Your Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Step 6.8 — Creating scripts for characterization and testing. . . . . . . . . . . . . . . . . . . . . . . . . 138
Chapter 8
Step 7: Generate Production Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Step 7.0 — Generate Generic Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Step 7.1 — Generate WGL, SVF, STIL, Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Step 7.2 — Write Test Program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Formula for RMS from CDF Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Appendix A
Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
The Tessent Documentation System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Global Customer Support and Success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Appendix B
Commands and Control Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Sequence of EDA commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Primary control files that you create . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Appendix C
Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Simplified SerDes model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Table of Contents
Appendix D
Jitter Components and Frequencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Appendix E
Document Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Third-Party Information

Table of Contents

List of Figures
Figure 2-1. Master/Slave TAP Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Figure 2-2. Example .CADSetup File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 2-3. Example .LVICTech File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 2-4. Example .ETDefaults File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 2-5. Design Hierarchy for PLL (or DLL). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figure 2-6. Design Hierarchy and Loopback Paths for Single-Clock SerDes Transceivers . 33
Figure 2-7. Clocking for Odd Number of Transceiver Modules . . . . . . . . . . . . . . . . . . . . . . 37
Figure 2-8. Design Hierarchy and Loopback Paths for Dual-Clock SerDes Transceivers . . 43
Figure 2-9. Example PLL Interface Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figure 2-10. Controlling a PLL for Lock Time and Lock Range Measurement . . . . . . . . . . 45
Figure 3-1. File hierarchy for <chip> = CHIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figure 4-1. Example connections to two LMK03000 PLLs . . . . . . . . . . . . . . . . . . . . . . . . . 74
Figure 4-2. Example Loadboard Layout for Differential Loopback with AC-Coupling Capacitors
and DC-Access Resistors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Figure 4-3. SignalyzerH4 USB-JTAG connector, and pin-out . . . . . . . . . . . . . . . . . . . . . . . 80
Figure 5-1. Example default SiliconInsight GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Figure 5-2. Example test type selection within a Test Step. . . . . . . . . . . . . . . . . . . . . . . . . . 88
Figure 5-3. Setting clock periods that will be applied to all test steps, for independent clock (left),
an LMK03000 (middle), and for LMK04033 (right) . . . . . . . . . . . . . . . . . . . . . . . . 93
Figure 5-4. Example test controller options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Figure 6-1. Rear panel connections to Keithley SourceMeter Unit. . . . . . . . . . . . . . . . . . . . 109
Figure 6-2. Example Force Voltage values for Slew Rate tests . . . . . . . . . . . . . . . . . . . . . . 111
Figure 6-3. GUI for calculating settings for LF jitter measurement . . . . . . . . . . . . . . . . . . . 118
Figure 7-1. Example of failures reported when no connections to the TAP pins, or TDO pin 124
Figure 7-2. Example failure due to test not completing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Figure 7-3. Console display of jitter histogram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Figure 7-4. Measuring Repeatability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Figure D-1. Jitter Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Figure D-2. Jitter Frequencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

List of Figures

List of Tables
Table 5-1. LMK030xx and LMK040xx Parameters, Default Values, and Ranges . . . . . . . 90
Table 6-1. Keithley Terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

List of Tables

Chapter 1
Introduction
This chapter provides an overview.

Embed Test Circuitry in Your IC Design to Test SerDes or PLLs . . . . . . . . . . . . . . . . . 13
Characterize and Diagnose Silicon Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Generate Production Test Patterns for Your IC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Embed Test Circuitry in Your IC Design to Test

SerDes or PLLs
Do the following:
• Verify that your SerDes or PLL and its simulation model are suitable for testing by
SerdesTest or PLLTest.
• Create an .etplan file with all required parameters and SerdesTest connection directives
for the following:
BIST of single-clock SerDes transceivers
BIST of dual-clock SerDes transceivers
BIST of PLLs and DLLs
• Insert SerdesTest RTL into your design, verify connections, simulate, and diagnose any
problems
• Create a Siemens EDA LV Database (LVDB) with all data necessary for automated test
generation
Characterize and Diagnose Silicon

Performance
Do the following:
• Design and manufacture board hardware to allow you to connect a PC's USB port to
your IC's JTAG pins
• Open the SiliconInsight GUI on your PC, select tests, and run them on your IC
• Characterize and diagnose your SerDes or PLL performance on a board or on an ATE
Note - Viewing PDF files within a web browser causes some links not to function. Use HTML for full navigation.
Introduction
Generate Production Test Patterns for Your IC
Generate Production Test Patterns for Your IC

Do the following:
• Generate test patterns in the native code of your LV-Ready ATE
• Generate test patterns in WGL that can be translated or edited to run on any ATE
The information in this document only refers to the preferred options for the majority of cases
and focuses on SerdesTest and PLLTest. If you are implementing other BIST IP in your chip,
such as ETMemory, ETLogic, or ETBoundary, then the various files described here will have
additional lines of information.
This document is created in the order in which you should proceed, providing only the essential
information for each particular step. Information that is applicable to multiple steps is only
presented for the first relevant step.
For quick learning and results, it is recommended that you perform the action described by each
instruction in this document while reading it. Some instructions refer to files or test names
implemented earlier in the flow, but the instructions can also be interpreted generally.
For more detailed information and more options, refer to the LV Flow User’s Manual and the
Reference manuals for each tool.
Note
The embedded test capabilities in the ULTRA family, presently comprising SerdesTest and
PLLTest, use most of the same RTL blocks and software. Despite testing very different
functions, they do not differ a lot in their connections to the circuit-under-test (CUT), choice of
tests, test settings, and test diagnosis. To simplify documentation and learning, procedures that
are identical for SerdesTest and PLLTest are described on the same pages.
PLLTest is a new set of capabilities, and some features are not fully implemented. In most cases
this is noted in this document, especially, where the procedure is not fully automated. The
degree of automation will increase in later releases of the software.
For the complete list of Tessent-specific terms, refer to the Tessent Glossary.
Chapter 2
Step 1: Prepare Your Design
You must first prepare your design.

SerDes Suitability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Stable Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
General Implementation Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Step 1.0 — Create Working Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Step 1.1 — ETChecker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Step 1.2 — Indicate TAP Pins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Step 1.3 — Indicate Design Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Step 1.4 — Check Clock Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Step 1.5 — Check DFT Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Step 1.6 — Check Default Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Step 1.7 — ETPlanner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Step 1.8 — Check Default Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Step 1.9 — CUT Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Step 1.10 — Collect Design Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Step 1.11 — Update .etplan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Step 1.12 — PLL Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
SerDes Suitability
To be tested by SerdesTest, your SerDes must have at least the following six ports and port
functionality (logic might be inserted manually or automatically to provide the required polarity
to the SerdesTest ports):
1. LockToRef — enables receiver to sample its serial input regardless of signal frequency
or phase:
0 must select the receiver/deserializer's normal mode (lock-to-data mode) in which the
receiver samples its serial input synchronously to a clock recovered from the serial data.
1 must select the receiver/deserializer's other mode (lock-to-reference mode) in which
the receiver samples its serial input synchronously to the receiver's reference clock
(RxRef).
Stable Performance
2. RxRef — receiver reference clock at parallel rate or lower:

Must be offset from its nominal frequency, and, hence, asynchronous to TxRef
3. TxRef — parallel-rate transmit word clock:
Must be suitable for clocking parallel data (TxData) into serializer, rising edge active
Must be synchronous to serial output data
4. TxData[ ] — parallel word input to serializer:
Supported widths are 8, 10, 16, 20, 32, 40, 60, and 80 bits
Must be the exact data that is transmitted serially (without any coding)
5. RxRec — parallel-rate recovered word clock:
Must be suitable for clocking parallel data (RxData) out of deserializer, rising edge
active
Must become synchronous to serial input data when receiver is in lock-to-data mode and
phase-locked
Must be synchronous to RxRef clock when receiver is in lock-to-reference mode and
phase-locked
6. RxData[ ] — parallel words output by deserializer:
Must be same port width as TxData
Must be the exact data that is received serially (without any decoding)
Must be active in lock-to-reference mode, regardless of the serial data timing or
amplitude
7. AC-coupled or DC-coupled SerDes serial data inputs—the coupling in the transmitter to
receiver path affects some SerdesTest tests:
Off-chip AC, on-chip DC: all SerdesTest tests can be performed.
Off-chip DC, on-chip DC: as above, except amplitude cannot be measured in receiver.
On-chip AC: as above, except slew rate also cannot be measured. If the receiver has
built-in DC offset voltage injection, then all SerdesTest tests can be performed.
Stable Performance
The circuit-under-test (CUT) characteristics must be stable during testing. If the CUT has
adaptive modes, such as byte alignment (e.g., FIFO), voltage offset cancellation, feed-forward
equalization (FFE), decision-feedback equalization (FFE), then these must be frozen or disabled
during testing.
General Implementation Strategy
• You should directly control the settings of these parameters with TAP userDRBits so
that CUT performance for each setting can be tested individually. Alternatively, allow
the circuitry to adapt, and then freeze the settings before performing CUT tests. This is
recommended for testing the quality of the adaptation algorithm.
• The circuit is expected to have some settling time, such as a lock time. You must provide
the expected maximum lock time in the .etplan file so all tests can automatically include
a pause for this duration before each measurement.
General Implementation Strategy

Verify that your CUT (SerDes, PLL or DLL; not your whole IC) and their models are suitable
for testing by ULTRA. Do this when your CUT module layout is complete (i.e., “hard”), before
attempting simulation for the whole IC. It is faster to diagnose problems while simulating only
one or two CUTs instead of simulating your whole IC.
• First, perform the steps for just the CUT, within an otherwise empty chip. Later, you can
repeat the steps when the CUT is placed within your whole chip.
• Create a temporary chip design that contains only your CUT and nothing else.
• Consider using a simplified or generic HDL model of your CUT initially. Later, replace
the simplified model with a more representative model of your own SerDes or PLL.
• Time resolution in your CUT model should be 100 fs for <1 GHz, 10 fs for 1~10 GHz,
and 1 fs for >10 GHz.
• Tie unused inputs to logic values or provide an initialization pattern to load internal
registers.
• Debug the simulations until they run successfully to completion with zero jitter, and
then with a little jitter (e.g., 0.01 UI rms).
• Optionally, adjust various settings of your SerDes to see their impact on the results.
You should finish your IC design's RTL and simulate it functionally with the CUT operating at
full-speed before adding ULTRA.
If you try to insert and verify ULTRA within your whole chip before fully verifying your
original chip design, then it will be much more difficult to diagnose whether failures are due to
your original design or due to ULTRA connections.
Step 1.0 — Create Working Directories
Step 1.0 — Create Working Directories

In this Step, perform the following operations:
• Create a directory structure for running Embedded Test software on your design (a
whole chip with an IEEE 1149.1 TAP or a sub-module with an IEEE 1500 WTAP) in a
way that does not intrude on your normal design flow.
• Create a working directory, such as mychip or mymodule. Inside your working
directory, create an ETCHECKER directory, and a DFT directory.
All ETChecker steps are run while the ETCHECKER directory is your working
directory.
All other Embedded Test software (ETPlanner, ETAssemble, etc.) is run while DFT (or
one if its sub-directories) is your working directory.
• Check whether the path to the LV Flow tools directory is defined in your UNIX path
with the following command:
which etchecker
If necessary, add the directory to your UNIX path. For example:

setenv PATH \
/wv/lvs_rls/prod/tessent_SoC_2009_5/ETCreate/bin:$PATH
Step 1.1 — ETChecker

• Set your current directory to ETCHECKER.

• Generate a default starter ETChecker file, by typing:
etchecker <chip> -genTemplate On
This will produce the following three files in your current directory:
<chip>.etchecker
<chip>.etchecker.README
Makefile
You can read the .README file for detailed information or simply proceed to the next
step. <chip> is your module name: the top-level will contain a TAP; a lower-level block
will contain a WTAP.
Step 1.2 — Indicate TAP Pins
Step 1.2 — Indicate TAP Pins

In the <chip>.etchecker file, delete the “//” comment characters for the following lines, or
replace the contents with the following text and edit the TAP pin names and SerDes/PLL name
for your design:
lv.Target -type Top // indicates you are working with top-level of chip
lv.EmbeddedTest -bscan Off -memory Off -logic Off //no other BIST for now
lv.JTAGOption -pin myTRST -option TRST
lv.JTAGOption -pin myTCK -option TCK
lv.JTAGOption -pin myTMS -option TMS
lv.JTAGOption -pin myTDI -option TDI
lv.JTAGOption -pin myTDO -option TDO
lv.BlackBoxModule -name mySerdes
lv.ClockDomainBase -pin USClkP -frequency 100.0 -label SamplingClock
-injectPin CHIP/<path>/<some_USClk_destination_port>
Note
Almost all logic in SerdesTest and PLLTest is clocked by the sampling clock.
ClockDomainBase indicates the port that supplies a clock (the sampling clock, in this case)
so that timing constraints will be generated for it. If logic BIST will be inserted in the design,
then a Burst Clock Controller gate will be inserted automatically in this path. If the path also
supplies a reference clock to a PLL, you should use the optional parameter -injectPin to identify
a port connected to that clock path where gating can be inserted without interrupting clocking of
the PLL. If the logic in SerdesTest or PLLTest is to be tested by logic BIST, the default choice
of clock is the sampling clock (via its ClockDomainBase label). If you want a different clock to
be used for this logic BIST testing, then it must be declared as a ClockDomainBase, and by a
line containing "LogicTestClockLabel : <ClockDomainBase_label>;" in the EST wrapper of
your <chip>.etplan file.Please see the Tessent Shell ETChecker for the LV Flow User’s Manual
for details and other options.
A chip is only permitted to have one TAP, or only one TAP active at one time. If a design has
many embedded test controllers (e.g., many instances of SerdesTest, PLLTest, ETMemory, and/
or ETLogic), there can be a lot of on-chip interconnections between the TAP and the embedded
test controllers. It might be more efficient (i.e., use less interconnect) to use the IEEE 1500
approach, in which a wrapper TAP (WTAP) is used for each major block of the chip design, all
accessed via one TAP. However, the primary advantage of the WTAP approach is that it allows
you to insert embedded test, synthesize (or layout), and simulate all SerdesTest tests for a single
block (which might be instantiated multiple times), which greatly reduces design verification
time. Test time is unaffected by WTAPs because all embedded test controllers can be run in
parallel, even if some are at the top level, and others are controlled by WTAPs within lower-
level blocks.
Provide Connections for Second TAP, If Necessary
If you are embedding SerdesTest (or PLLTest) in a “soft” module in your chip that will have a
WTAP, use the following lines instead:
lv.Target -type Block -notPhysicalRegion

lv.EmbeddedTest -memory Off -logic Off
lv.BlackBoxModule -name mySerdes
Provide Connections for Second TAP, If Necessary

SerdesTest and PLLTest must be controlled by a Siemens EDA TAP or WTAP, but you can
have a second TAP on your chip. For this step, the Siemens EDA TAP controller does not need
to be present (it will be created and inserted automatically later) but your chip design must have
at least I/O pad cells for the TAP pins.
A block design that will use a WTAP (IEEE 1500 wrapper TAP) does not need any TAP pins
for this step, so you can proceed directly to Step 1.4 — Check Clock Tree.
If you have more than one TAP controller on your chip, and the Siemens EDA TAP used by
SerdesTest (or PLLTest) is the secondary TAP, then a signaling procedure is needed to control
when the SerdesTest TAP is active. There are several ways to do this, but the simplest way that
does not require any extra pins is to have the SerdesTest TAP as a Slave TAP selected by an IR
bit (preferably, or a DR bit) in your Master TAP, labeled as SelLV, as shown in Figure 2-1 on
page 21. Before proceeding to later steps, perform the following operations:
• Add two 2-to-1 multiplexers between the existing Master TAP and the TDO tri-statable
output pad cell (one for TDO, another for tdoEnable), with their Select input connected
to SelLV.
• Add two And gates (ensure SelLV is active high), one between the TMS pad cell and the
TMS input to the Master TAP, with SelLV as its other input, inverted, and one between
TMS pad cell and the TMS input to the Slave TAP, with SelLV as its other input. Ensure
that SelLV will exist after synthesis by using the PERSISTENT construct in the .sdc file.
• Add the following line to the <chip>.etchecker file:
lv.Assert -pin <MasterTAPInstance>.SelLV - value 1
With the combinational logic circuitry shown in Figure 2-1 on page 21, after the Slave TAP is
selected, the Master TAP’s TMS signal becomes constant logic 0, which gracefully halts the
Master TAP by parking it in Run-Test/Idle state. The only way to regain control of the Master
TAP is to assert TRST (it is active low, so it must be set to 0). This asynchronously resets the
Master TAP’s IR and DR registers, restores SelLV back to 0, and, thus, enables the Master
TAP’s TMS as before.
Alternative ways are to drive SelLV with a Compliance Enable pin, or with an internal signal
possibly derived from a CPU bus.
Step 1.3 — Indicate Design Files
In most cases, SelLV is set via a special instruction, applied with a UserDefinedSequence
before sending data to the Slave TAP as described later in User Defined Sequence.
Figure 2-1. Master/Slave TAP Connections

In the Makefile file, at the line etcOptions=\ enter text like the following (Examples are also
provided in the file):
etcOptions=\
../mychip/RTL/<chip>.vb \ // top-level of design
-y ../mychip/RTL \ // chip design directory (top-level and design can be in any directory)
+libext+.vb+.v \ // file extensions you used
-padLib <path>/pad.library \ // LV-format library
-padLib <path>/cell.library // LV-format library
If your design contains modules for which you have inserted SerdesTest (or PLLTest) and a
WTAP, also add a line like the following to point to the module’s LVDB file, and to point to the
module’s design directory:
-lvdbDir \
<path>/DFT/<module>_LVWS/ETSignOff/
<module>.lvdb_preLayout
or, if it exists
-lvdbDir <path>/DFT/finalLVDB/<module>.lvdb
The referenced pad.library file is a file required to describe I/O pad cells. Similarly, the
cell.library file is a file required to describe core logic cells so that they can be used
automatically and so that logic paths can be checked. For details and to document more
complex I/O pads, consult the manual ETAssemble Tool Reference.
The pad.library file has the following format for example input, output, and tristate output pads
(you can implement as RTL modules in your design directory for simulation, but for layout
these must be hard cells):
PadLibrary (padLibraryFilename) {
Cell (INPADS) {
Pin (A) { Function : padIO; }
Pin (Y) { Function : fromPad; }
}
Cell (OUTPADS) {
Pin (A) { Function: toPad; }
Pin (Y) { Function: padIO; }
}
Cell (OUTPADZ) {
Pin (A) { Function: toPad; }
Pin (Y) { Function: padIO; }
Pin (GZ) { Function: enableLow; }
}
}
The cell.library file has the following format for example multiplexers, combinational logic,
and buffers (you can implement as RTL modules in your design directory for simulation, but for
layout these must be hard cells):
CellLibrary (cellLibraryFilename) {
Buffer (RTLBUF) {
Port (A): Input;
Port (Y): Output;
}
Inverter (RTLINV) {
Port (A): Input;
Port (Y): Output;
}
And2 (RTLAND2) {
Port (A): Input;
Port (B): Input;
Port (Y): Output;
}
Or2 (RTLOR2) {
Port (A): Input;
Port (B): Input;
Port (Y): Output;
}
Multiplexer (RTLMUX21) {
Port (A0): Input0;
Port (A1): Input1;
Port (SEL): Select;
Port (Y): Output;
}
CellsToUseOnFunctionalClockPaths {
ClockMultiplexer (RTLMUX21) {
Port (A0): Input0;
Port (A1): Input1;
Port (SEL): Select;
Port (Y): Output;
}
ClockBuffer (RTLBUF) {
Port (A): Input;
Port (Y): Output;
}
ClockInverter (RTLINV) {
Port (A): Input;
Port (Y): Output;
}
ClockGatingORCell (RTLCGOR) {
Port (CLK): Clock;
Port (TE): TestEnable;
Port (FE): FuncEnable;
Port (CLKOUT): ClockGated;
}
}
If your cell library does not have a ClockGatingORCell or ClockGatingANDCell as defined in

ETAssemble Tool: Reference, then do not define these cells so that ETAssemble will create an
RTL version.
Step 1.4 — Check Clock Tree
Step 1.4 — Check Clock Tree

In this Step, perform the following operation:
• Use the command:

make <chip>.clockInfo
Note
The make command parameters are case-sensitive.
The errors and warnings are saved in an output file:

etCheckInfo/etchecker.rpt_clockInfo_<chip>
Step 1.5 — Check DFT Rules


make <chip>.ruleCheck
• Check the following output file for errors and warnings:

etCheckInfo/etchecker.rpt_ruleCheck_<chip>
The following output file is also produced and is required to run ETPlanner in the next
step:
etcHandoff/<chip>.etCheckerInfo
Step 1.6 — Check Default Files

• Set your current directory to DFT

• Check whether certain environmental variables are defined for you (perhaps by
your.cshrc file), by typing the following:
echo $LV_CADENV_FILE
echo $LV_ICTECH_FILE
echo $LV_ETDEF_FILE
If any of these variables is defined as a file path, then check that the target file is
appropriate for your design because the files will be automatically referenced in the next
step. You can also provide the file locations or contents in the next step.
Step 1.6 — Check Default Files
Caution
• LV_CADENV_FILE should point to a .CADSetup file which describes your CAD

environment, including: -Default simulator, and simulation commands to use-
Synthesis tool-Command to create directories and soft links
• LV_ICTECH_FILE should point to an .LVICTech file which lists your IC
technology model directories and files, or any models, including: -Simulation
models-Embedded Test models and library files-Synthesis models and library files
• - LV_ETDEF_FILE should point to an .ETDefaults file which sets other Embedded
Test parameter values.
Figure 2-2 shows an example of the content for a .CADSetup file.
Figure 2-2. Example .CADSetup File
CADEnvironment {
CreateDirectoryCommand : /bin/mkdir;
CreateSoftLinkCommand : “/bin/ln -s”;
DefaultSimulator : Verilog-XL; // Verilog-XL | NC-Verilog | ModelSim | NCVHDL |
// Leapfrog | VCS
// SynthesisTool : DCTCL | BlastCreate | TalusDesign;
// Default values per Simulator
// --------------------------------------------------------------------------|
// | Verilog-XL|NC-Verilog|VCS| ModelSim |Leapfrog| NCVHDL |
// |-------------------------------------------------------------------------|
// | Language --> | VERILOG |VERILOG|VHDL| VHDL |
// |-------------------------------------------------------------------------|
// |Command |verilog |ncxlmode | vcs | vlog | - | - | - |
// |CompileCommand | - | - | - | - |vcom| cv | ncvhdl |
// |SimulateCommand | - | - | - | - |vsim| sv | ncsim |
// |ElaborateCommand | - | - | - | - | - | ev | ncelab |
// |-------------------------------------------------------------------------|
// You may use the Simulator wrapper below to override the commands shown
// in the table above. Otherwise, the defaults from the table will be used.
// Repeat the Simulator wrapper for each simulator you want to override
// Note: Simulator Commands are case sensitive.
//
Simulator ( Verilog-XL ) { Command : verilog ; }
Simulator ( NC-Verilog ) { Command : ncverilog; }
Simulator ( ModelSim ) { Command : vlog; }
Simulator ( VCS ) { Command : vcs; }
}
Figure 2-3 shows an example of the content for a .LVICTech file.
Step 1.7 — ETPlanner
Figure 2-3. Example .LVICTech File
ICTechnology (tsmc13) {
SimModelDir (verilog) : /HWLib/tsmc13/verilog;
SimModelFile (pads.v) : /HWLib/tsmc13/verilog/pads.v;
ScanModelDir (lvision) : /HWLib/tsmc13/lvision;
SynModelDir (synopsys) : /HWLib/tsmc13/synopsys;
CellExtension : v;
dctclSetupFile: /HWLib/tsmc13/synopsys/.synopsys_dc.setup_tcl/
.synopsys_dc.setup;
ScangLib : /HWLib/tsmc13/TP_PDFF/scang.lib;
PadLib : /HWLib/tsmc13/lvision/pad.library;
PatternType : WGL;
ModulesLV {
SimModelDir(TP_PDFF) : /HWLib/tsmc13/TP_PDFF;
}
FormalityLibFile (FormalVerLib) : /HWLib/tsmc13/synopsys/
dti_tsmc013lv_stdcells.db;
FormalityLibFile (FormalVerMem_128x8_16ww1x): \
/HWLib/tsmc13/memories/1PSRAM/
dti_t13r1p_128x8_16ww1x_typ.db;
}
Figure 2-4 shows an example of the content for a .ETDefaults file.
Figure 2-4. Example .ETDefaults File
EmbeddedTest {
GlobalOptions {
EmbeddedTestMergeFlow: GATE;
}
ModuleOptions (.*) {
LVWSDirectoryName: %_LVWS; // % is replaced by
// Module Name.
}
}

• Set your current directory to DFT .

• Generate a default starter ETPlanner file and other files, using the following command:
etplanner <chip> \
-etCheckerInfoFile ../ETCHECKER/etcHandoff/
<chip>.etCheckerInfo
• If you already have a <chip>.etplan file, the software will try to patch in any updates, but
if it cannot it will report that the patching command failed and rename the previous file
as <chip>.etplan.bak. In this case, delete or rename the <chip>.etplan file, and then
rename <chip>.etplan.bak to <chip>.etplan
• For a chip that contains a module for which you have already inserted a WTAP, and the
SerDes or PLL is within that module, append the following options that point to your
module’s pre-synthesis LVDB directory (omit this option if you have a post-synthesis or
post-layout final LVDB) and a final LVDB directory (if you only have a preLayout
LVDB, point to an empty directory with name <module>.lvdb):
-preLayoutLVDBDir <PATH>/DFT/
<module>_LVWS/ETSignOff/<module>.lvdb_preLayout
-lvdbdir <PATH>/DFT/finalLVDB/<module>.lvdb
The resulting files will be:
• Makefile, which runs next steps (genPlan, checkPlan, genLVWS);

• DFT/<chip>.etplan contains all parameter values and will eventually contains a
description of all SerdesTest or PLLTest connections and clocking in the EST section;
• DFT/<chip>.etplan.README contains the complete syntax of the .etplan file for quick
reference.
Step 1.8 — Check Default Parameters

TheDFT/<chip>.etplan file will contain the following lines, that you should edit appropriately:
ETPlan (<chip>) {
CADEnvironment {
GlobalDefinitionFile: <path>.CADSetup;
}
ICTechnology (<ICtechName>) {
GlobalDefinitionFile: <path>.LVICTech;
PadLib: <path>/pad.library; // if no LVICTech file
CellLib: <path>/cell.library
}
DesignSpecification {
RTLExtension : vb;
GateExtension : v;
ModulesRTL ( <chip> ) {
// IncDir (<linkName>): <HierarchicalDirPath>;
SimModelDir (<softlinkName>): <path>/RTL;
}
ModulesGate (<chip>) {
SimModelDir (<softlinkName>): <path>/gates;
}
PreLayoutSimModelFile (<module>):
\<PATH>/DFT/<module>_LVWS/ETAssemble/
<module>.v_postLV;
SimModelFile (<module>):
\<PATH>/DFT/concatenated_netlists/
<module>.netlist_final ;
} // ensure you have above lines for modules with WTAP
EmbeddedTest {
GlobalOptions {
EmbeddTestMergeFlow: RTL;
TCKFrequency: 32.0; // (MHz)
// For fastest simulation, choose a frequency
// that is 1/N times RX parallel-rate clock
// frequency; where N is 4~32 but not faster
// than TCK can be clocked in silicon.
}
ModuleOptions (.*) {
LVWSDirectoryName: <chip>_LVWS;
}
ModuleOptions (<chip>) {
TopLVHWParentInstance: <top_for_DFT>;
// TAP location, if not at top level
SimulateLowerLevelcontrollers: On;
// Generate tests for WTAP modules too
}
Module (<module>) { // This appears only for
// WTAP modules
SignedOffLVDBPointer: <PATH>/DFT/finalLVDB/
<module>.lvdb;
}
} // End of EmbeddedTest
} // End of ETPlan
For a chip that contains a module for which you have already inserted a WTAP, and the SerDes
or PLL is within that module, skip the rest of these Steps and proceed directly to Step 2: Embed
Test Circuitry.
The next steps will need the following information. These are brief descriptions, for more
details and default values, refer to the manual ETPlanner Tool Reference.
ClockPeriod — the nominal clock period, in nanoseconds, for the reference clock port of the
SerDes (parallel rate) or PLL (input to the block) to be tested.
LockTime — the phase-lock time, with appropriate units appended. Auto-generated test
patterns will have this pause time inserted whenever the mode of the SerDes or PLL changes, to
allow phase-lock to be achieved.
SerDesWordSize — the number of signals that can be monitored for testing. It must be the
parallel port width for SerDes testing but can be any supported width for PLL testing (a width of
8 is usually sufficient). Supported values are 8,10,16,20,32,40,80.
BistClockGating — indicates whether clocks to ULTRA should be gated off whenever tests are
not running. This saves power but adds gates in clock paths which might add jitter to phase
delay measurements.
ScanReady — indicates whether you want extra gates and ports added to ULTRA in preparation
for scan path insertion.
NumberOfPipeliningStages — indicates the number of flip-flops to be added to all inter-block

paths to add path delay tolerance. This is only needed when a circuit-under-test will be placed
far enough from the ULTRA block that the worst case path delay may approach one clock
period.
ParentInstance — indicates where you want the automation to place the generated RTL module.
It can be placed in any synthesizable module. If you want the RTL placed in a new module (just
for SerdesTest logic, for example), then you must first add that module to your design - the
module may be empty.
MaximumFrequencyOffset_ppm — indicates the maximum frequency offset of the

undersampling reference clock, in parts per million. You should use the largest value that your
SerDes model will tolerate (typically 300~3000) in ppm offset between the receiver's reference
clock and the transmitter's reference clock so that you will be warned if you unintentionally
attempt to use a larger frequency offset. If SerdesTest needs to use a smaller value due to other
constraints (in any case, it must always be less than 1956), it will warn you later—you can
simply note the warning or reduce the value in the <chip>.etplan file to eliminate the warning.
The value does not affect RTL generation or production test pattern generation. Almost any
value can be used for PLL testing, up to 1956, so use that value.
NominalFrequencyOffset_ppm — indicates the nominal frequency offset of the undersampling

reference clock, in parts per million. The value will be used to create simulation test benches for
all measurements. Most SerDes jitter tests require this value to be approximately 150 so that the
low frequency cut-off for jitter frequencies will correspond to that of a golden PLL. For PLL
tests, simply choose 1000 to obtain 0.1% clock period resolution. The value does not affect RTL
generation or production test pattern generation. If you try to use a value larger than
MaximumFrequencyOffset_ppm, then a warning will be issued and the maximum value will be
used instead.
Step 1.9 — CUT Type
Step 1.9 — CUT Type

You must do the following.
Connections for PLLs and DLLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Connections for Single-Clock SerDes Transceivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Connections for PLLs and DLLs

An example IC is shown in Figure 2-5, containing two PLLs, configured to use a sampling
clock from off-chip or from the other PLL. This arrangement permits each PLL to test the other,
even in-system, without need for an off-chip sampling clock, and permits testing either PLL in
production if one of them fails.
Compared to SerdesTest, a PLL’s reference clock may be considered as the TX reference clock
(whose frequency is slightly offset) and the sampling clock may be considered as the RX
reference clock (at the nominal frequency in <chip>.etplan file).
Sampling of the PLL signals is done inside PLLTest in a “Sampler” module. If you wish to
customize the Sampler module (for example, to use differential latches that more accurately
measure sub-picosecond jitter), then use the SamplerInterface option in your .etplan file and put
the auto-generated Sampler module (that you customize) inside your “PLL” module -- PLLTest
will omit its own Sampler.
Note
Either all or none of the PLLs within each EST wrapper of your <chip>.etplan file must
have a custom Sampler. ULTRAs in separate EST wrappers can still test PLLs
simultaneously.
Connections for Single-Clock SerDes Transceivers
Figure 2-5. Design Hierarchy for PLL (or DLL)
At this point in this document, the Steps differ for different types of SerDes.
If you are testing a SerDes transceiver PHY block that has only one reference clock input
(shared by transmitter and receiver):
• Proceed to Connections for Single-Clock SerDes Transceivers.

If you are testing a SerDes transceiver PHY block that has two reference clock inputs (one for
transmitter, and one for receiver):
• Proceed to Connections for Dual-Clock SerDes Transceivers.
Note
Many SerDes transceivers have on-chip loopback between their transmitter and
receiver. Dual-clock SerDes transceivers permit SerdesTest testing with on-chip
loopback (especially useful for at-speed wafer testing), but a single-clock transceiver
serial output must be looped back to another transceiver, with another ULTRA, so that
each can use a different reference clock frequency.

On your IC, you will need to have an even number of lanes (operating at same nominal serial
data rate) so that you can have one ULTRA for testing each direction, and for each ULTRA a
loopback from the serial output from one lane's TX to another lane's RX, as shown in
Figure 2-6. One transceiver must use the reference clock's nominal frequency, and the other
transceiver must use a reference clock whose frequency is slightly offset. For one TX-to-RX
direction, the offset will be positive, and for the reverse direction, the offset will be negative.
SerdesTest test generation software will handle this automatically.
Figure 2-6. Design Hierarchy and Loopback Paths for Single-Clock SerDes
Transceivers
Step 1.10 — Collect Design Information

To create an ETPlanner configuration file—DFT/<chip>.etplan) — in Step 1.11 — Update
.etplan, you will need to know the names for the following signals:
ClockSource(testClock) — IC pin(s), single-ended or differential, that are the source of the

undersampling clock used by PLLTest. You may list one default clock that is to be used by all
PLLTest modules, and you may list a different one for any individual PLLTest module. You
may insert a multiplexer (preferably controlled by a userDRBit) in this clock’s path to later
enable selecting an alternate sampling clock source (e.g. another PLL, if it can provide an
appropriate frequency offset), but you must always have an off-chip sampling clock source to
permit automated simulation.
The automatically generated simulation test bench provides a clock with the nominal
ClockPeriod. This clock is used to undersample the PLL or DLL outputs, and should have jitter
that is comparable to or less than that of the PLL under test. If the expected output jitter is <5 ps
RMS, this clock should have differential input pins to reduce the effects of I/O switching; if the
expected output jitter is <2 ps RMS, this clock should (but is not required) be routed
differentially and connected to a differential sampling latch in the Sampler module - the output
of the latch must be single-ended for connection to PLLTest. This clock must be asynchronous
to the PLL’s input and output clocks.
Caution
Jitter in the undersampling clock will be included in any jitter measurement, so choose pins,
routing, and clock buffers that minimize the total delay of this signal path since this will also
minimize its jitter.
ClockSource(Reference) — IC pin(s), single-ended or differential, that are the source of the

primary reference clock for the ULTRA instance.
One of the ULTRA instances in a serial data loopback path must have a frequency-offset clock
at its ClockSource(Reference) pins, with a frequency slightly offset (typically by 150 ppm)
from the primary clock source for the other ULTRA (that ULTRA’s ClockSource(Reference)) -
the automatically generated test bench provides a positive offset.
ClockSource(pllReferenceOffset) — IC pin(s), single-ended or differential, that isare the source

of each PLL’s the second reference clock; different pins may be listed clock for each PLL. You
may list a default clock that is the ULTRA instance, frequency-offset relative to be used by all
PLL modules, and you may list a different one for any individual PLL. its nominal frequency
during SerdesTest testing.
The automatically generated simulation test bench provides a positive frequency offset
(typically by 1000 ppm or 0.1%) relative to the nominal frequency.
SamplerInterface — Use this option only if you want to customize the PLLTest logic’s Sampler
module that interfaces to your PLL, to obtain better measurement accuracy. If you use this
option, then your “PLL” module must contain a Sampler module based on the one that is
automatically generated by the LV Flow. With this option, the PLLTest module will be
generated without an internal Sampler module, and all signals from the “PLL” will be assumed
to be already sampled. If you use this option for one PLL, then you must use it for all PLLs.
InputClockPort — The PLL’s input port for its reference clock. The PLL’s reference clock will
be sampled. If your PLL multiplies its input frequency by N/R, then its rising (or falling) edges
must be phase-aligned to at least every Rth edge of the PLL output data edges for PLLTest to be
able to sample them.
ClockOutputs — The PLL or DLL output clock port (it may be a bus) to be measured. Each
output may have a different post-divider so that each output frequency is different. The post-
divider integers indicate the ratio of the VCO frequency to the output clock frequency.
If the SamplerInterface option is used, then the listed port must be that of the
ULTRA_RPA_Sampler module (contained within your “PLL” module); the signals must then
be sampled versions of the PLL’s output clocks.
LockDetect — The lock detector output port of the PLL. Logic 1 indicates the PLL output is
phase-locked to its input. If your PLL’s lock detector output is active low, you must add an
inverter and provide its output port as the LockDetect signal.
InterceptChangePLL — During BIST insertion (described in “Step 2.3 — Generate & insert
RTL”), the signal to this port is intercepted. During the LockTime test (only), PLLTest inverts
the signal; the signal returns to its non-inverted state at the end of the test or instantly if the
BIST is disabled. You may list any number of these ports on your PLL, and they may be any
bits of a bus port. For example, the port can be least significant bits of a PLL's feedback divider
input value, or a reset signal (active high or low). LockTime is measured as the total time that
the LockDetect signal is logic 0 during the Test Duration in Beat Cycles .
VcoFrequencyMultiplier — This parameter indicates the ratio between the PLL’s internal
voltage-controlled oscillator’s frequency and the PLL’s input reference clock frequency.
TxWordPort[n:0] — Parallel word input port to TX.
An RTL mux will be auto-inserted at this input to select whether normal data or SerdesTest-
generated data will be transmitted. TxData LSB (the indicated '0' bit) is assumed to be
transmitted first—if MSB is transmitted first, write it as TxData[0:n] in the <chip>.etplan file.
WordClk — SerDes parallel-rate word clock port. The source for this must be the
ClockSource(Reference) in the same ULTRA instance wrapper.
The SerDes block's reference clock port name which might be an input or an output port. This
clock must operate at the parallel frequency and be rising-edge active. When testing with
SerdesTest, some SerDes blocks will be connected to the Reference clock, and others will be
connected to the Offset clock via a multiplexer, as shown in Figure 2-6 on page 33 (which
might be controlled from a TAP UserDRBit). The clock will be used by SerdesTest to
synchronously provide TxData to the TX and as a phase reference that is assumed to be phase-
aligned to the TX serial output data edges.
Its nominal frequency must be a simple integer ratio to the source pin’s nominal frequency. The
integer ratio is declared as Clock2PinFrequencyRatio and may be any ratio where the numerator
and the denominator are each 8 or less, e.g., 1, 1/2, 1/8, 2/3, 3/4, 2/5, 3/8.
RxWordPort[n:0] — Parallel word output port of the RX.
The output data words will be latched by SerdesTest using RxRecovWordClock. This data
output is required to be active in lock-to-reference mode even when the CDR is not locked.
RxData LSB (the indicated '0' bit) is assumed to be received first—if MSB is received first,
write it as RxData[0:n] in the <chip>.etplan file.
RxRecovWordClock — Parallel-rate recovered word clock port.
The nominal frequency must be the same as WordClk.
This clock is assumed to be rising-edge active and will be used to synchronously capture
RxData from the RX and as a phase reference that is assumed to be phase-aligned to the
received serial input data edges in lock-to-data mode and to the RxRefClk edges in lock-to-
reference mode.
RxSamplingWithRefClockEnable — RX control input port that enables lock-to-reference

mode.
This receiver input must be able to select the receiver's lock-to-reference mode (when
LockToRef=1) in which the receiver samples its serial input synchronously to the receiver’s
WordClock (but at the serial data rate) and RxRecovWordClock is synchronous to that
WordClock, or lock-to-data mode (when LockToRef=0) which is the normal functional mode
of the receiver in which the sampling clock is recovered from the serial data and
RxRecovWordClock becomes synchronous to the transmitter’s WordClock. An RTL mux will
be auto-inserted (if one does not already exist) in this control input path so that the existing
control is active when SerdesTest is not operating.
TxPin(P), TxPin(N) — TX high-speed serial data output pins, non-inverting & inverting.
RxPin(P), RxPin(N) — RX high-speed serial data input pins, non-inverting & inverting.
TxEncoderBypassEnable — An input port that enables bypassing of any transmit data encoding
or receive data decoding so that the BIST can deliver the exact parallel data that will be
transmitted serially and analyze the exact serial data that was received. The signal from the
BIST is 1 during testing, and returns to 0 when the test is completed or the TAP/WTAP is
reset."
TestPhaseNo — (this feature is preliminary and unverified) When there is an even number of
transceivers but they are in an odd number of multi-transceiver modules, they can be connected
as shown in Figure 2-7, with one of the modules connected to both reference clocks via a
multiplexer. One ULTRA can not be shared among multi-transceiver modules. In Test Phase 1,
the multiplexer accesses fREF1, and only transceivers 1A—3B and 2B—3A can be tested
simultaneously. In Test Phase 2, the multiplexer accesses fREF2, so that transceivers 1B—2A
can be tested simultaneously, i.e., tests with the same TestPhaseNo are tested simultaneously.
For this case, there would be three ULTRA instances, and the .etplan file would be coded as
follows:
1. for Instance 1, ClockSource(Reference) is fREF1, and ClockSource(Offset) is fREF2;

Channel 1A is tested in TestPhaseNo 1, and Channel 1B is tested in TestPhaseNo 2;
Channel 2A is tested in TestPhaseNo 2, and Channel 2B is tested in TestPhaseNo 1;
Channel 3A is tested in TestPhaseNo 1, and Channel 3B is tested in TestPhaseNo 1.
In the <chip>.etSignOff file produced in Step 2.5 — Prepare for simulation, you must manually
enter a UserDefinedSequence (UDS) or UserDRBits to change the multiplexer setting for the
second test phase.
Figure 2-7. Clocking for Odd Number of Transceiver Modules
Step 1.11 — Update .etplan
Identifier — This parameter value (which must be unique in the IC design) is used whenever a
serial data loopback path is connected between transceivers.
AssociatedChannelForTest — This must be the Identifier for the transceiver to which this
transceiver is connected via a serial data loopback path.
Miscellaneous — These are ports that you wish to control via the JTAG interface, implemented
as userDRBits in the TAP controller, with easy-to-use aliases, so that you can automate
characterization of the PLLSerDes. You can insert RTL muxes can be inserted by you later
using ETAssemble (if they do not already exist) in these control input paths so that the function-
mode controls are active when PLL SerdesTest is not operating. Typically, these signals control
PLL division ratiotransmitter pre-emphasis and amplitude, receiver equalization, loop
filtertermination resistance, delayspeed, etc.

Copy and edit the following example text into the EST wrapper of theDFT/<chip>.etplan file,
(which is for the design shown in Figure 2-5 on page 32Figure 2-6 on page 33):
Module (<chip>) {
EST (<prefixForULTRAs>) { // Repeated for every PLLTest group
ClockPeriod : 10.0; // PLL’s nominal reference clock period (ns)
LockTime : 0.02ms; // PLL’s lock time: PLLTest waits for PLL to lock
ChannelType : PLL ;
BistClockGating : Off; // Allows you to gate BIST clock for low-power
ScanReady : On; // Prepares ULTRA for scan insertion
NumberOfPipeliningStages : 0; // Flops to add for inter-block paths
NominalFrequencyOffset_ppm : 1000 ; // Used for all simulations
MaximumFrequencyOffset_ppm : 1956 ; // Maximum permitted for testing by PLLTest
Instance { // Repeated for every ULTRA block
// ULTRA Options
ParentInstance : CORE/DUAL1; // Where to put ULTRA#1 (in Top level)
ClockSource(testClock) { // Undersampling clock used by all PLLTest modules
Pin(P) : USClkP; // Pin name - always present
Pin(N) : USClkN; } // Pin name - differential option
PLL { // Repeated for every PLL
// Channel Options connected to this ULTRA
ParentInstance : CORE/DUAL/SD1; // module in which RPA module is to be placed
TestClockPort : CORE/DUAL/SD1/MUXout; // sampling clock source (default is
// testClock above)
InputClockPort : CORE/DUAL/SD1/PLL1/RefClock // PLL’s reference clock
LockDetect : CORE/DUAL/SD1/PLL1/Locked; // logic 1 when PLL detects lock
InterceptChangePLL {
CORE/DUAL/SD1/PLL1/DIVIDE[2:0]; // rising edge causes PLL to
unlock
}
VcoFrequencyMultiplier : 16; // ratio of PLL VCO freq. to ref clock
ClockOutputs {
CORE/DUAL/SD1/PLL1/S_ClockOut[0] : 1; // this freq. is same as VCO
CORE/DUAL/SD1/PLL1/S_ClockOut[1]: 4; } // this freq. is VCO divided by 4
ClockSource(pllReference) { // PLL’s reference clock - simulated with offset
Pin(P) : RefClkP; // Pin name - always present
Pin(N) : RefClkN; } // Pin name - differential option
SamplerInterface { // optional - only add section if PLL has custom interface
SamplerClock : CORE/DUAL/SD1/PLL2/USCLK; // input port for sampling clock
Enable : CORE/DUAL/SD1/PLL2/Enable; // input port, for signal from ULTRA
SampledPLLRef : CORE/DUAL/SD1/PLL2/S_PLLREF; // output port, to ULTRA
SampledPLLRefDiv2 : CORE/DUAL/SD1/PLL2/S_PLLREF_DIV2; // output to ULTRA
ReSampledPLLRefDiv2 : CORE/DUAL/SD1/PLL2/RS_PLLREF_DIV2; } // delayed output
} // end of PLL wrapper
PLL {
ParentInstance : CORE/DUAL/SD2;
TestClockPort : CORE/DUAL/SD2/MUXout; // sampling clock source (default is
// testClock above)
InputClockPort : CORE/DUAL/SD2/PLL2/RefClock;
LockDetect : CORE/DUAL/SD2/PLL2/Locked;
InterceptChangePLL {
CORE/DUAL/SD2/PLL2/RESET;
CORE/DUAL/SD2/PLL2/Other[2];
}
VcoFrequencyMultiplier : 5;
ClockOutputs {
CORE/DUAL/SD2/PLL2/ClockOut1 : 2;
CORE/DUAL/SD2/PLL2/ClockOut2 : 3; }
ClockSource(pllReference) {
Pin(P) : RefClk2P; }
ClockSource(testClock) { // optional second pin for sampling clock
Pin(P) : USClk2; }
SamplerInterface { // either all PLLs have a custom interface, or none do
SamplerClock : CORE/DUAL/SD2/PLL2/US_CLK; // input port for sampling clock
Enable : CORE/DUAL/SD2/PLL2/ENABLE; // input port, for signal from ULTRA
SampledPLLRef : CORE/DUAL/SD2/PLL2/S_PLLREF; // output port, to ULTRA
SampledPLLRefDiv2 : CORE/DUAL/SD2/PLL2/S_PLLREF_DIV2; // output to ULTRA
ReSampledPLLRefDiv2 : CORE/DUAL/SD2/PLL2/RS_PLLREF_DIV2; } // delayed output
} // end of PLL wrapper
} // end of ULTRA Instance wrapper
} // end of EST group wrapper
} // end of module
Note
All hierarchical names refer to instances. If two different hierarchical names refer to the
same module, the module will be modified only once, in a way that is consistent with both
sets of .etplan descriptions. The LV Flow will check that all ULTRA options within an EST
wrapper for a single module are consistent. If you want a module to have different options for
different instances, you should use different EST wrappers.
Note
In the simulation test bench, the auto-generated sampling clock period will be exactly equal
to the ClockPeriod value and the PLL's reference period will be slightly longer. For simplest
simulation sign-off flow, set the PLL's output-to-input frequency ratio to be an integer, i.e., the
VcoFrequencyMultiplier value divided by the first ClockOutputs divider value. (The ratio for
subsequent ClockOutputs divider values can be fractional.) Later, you will be able to test using
fractional ratios whose denominator is between 1 and 8, as explained for “Under Sampling
Clock Ratio” on page 99.
Module (<chip>) {
EST (<prefixForULTRAs>) { // Repeated for every SerDes group
// SerdesTest Options- same port width, speed, ref. clocks, ULTRA size
ClockPeriod: 4.0; // Parallel-frequency clock period (ns)
LockTime: 0.02ms; // Time for PLL to lock after a change
ChannelType : Serdes ;
SerDesWordSize: 10; // TX/RX parallel port width, in bits
BistClockGating: Off; // Gate BIST clock for low-power?
ScanReady: Off; // Prepare SerdesTest for scan insertion?
NumberOfPipeliningStages: 0; // Flops to add for inter-block paths
NominalFrequencyOffset_ppm: 150; // Used for all simulation
MaximumFrequencyOffset_ppm: 1000; // Choose max of your SerDes’ ability so
// that an error message is issued if you
// try higher
Instance { // Repeated for every ULTRA block
// ULTRA Options
ParentInstance: CORE/DUAL1; // Where to put ULTRA#1 (in Top level)
ClockSource(Reference) { // Reference clock source for this SerDes
// and ULTRA
Pin(P): RefClkP; // Pin name - always present
Pin(N): RefClkN; // Pin name - differential option
Clock2PinFrequencyRatio: 5/2; // use if parallel clock frequency is not
} // equal to clock pin frequency
ClockSource(Offset) { // Ref. clock for associated (far end) SerDes
// and ULTRA
Pin(P): TestClkP;
Pin(N): TestClkN;
Clock2PinFrequencyRatio: 5/2;
}
WordClock: CORE/DUAL1/SD1/SERDES/TxClkOut; // Port name of SerDes parallel
// clock, whether input or output.
// This indicates 1-clock SerDes.
Channel { // Repeated for every transceiver …

// Channel Options connected to this ULTRA
Identifier: CH0; // A unique label for this transceiver
ParentInstance: CORE/DUAL1/SD1; // Where to put its TPG & RPA blocks
RxSamplingWithRefClockEnable: CORE/DUAL1/SD1/SERDES/L2R[0];
TxWordPort: CORE/DUAL1/SD1/SERDES/TxData[9:0];
RxWordPort: CORE/DUAL1/SD1/SERDES/RxData[9:0];
RxRecovWordClock: CORE/DUAL1/SD1/SERDES/RecClk;
RxPin(P): SerInP[0]; // Top-level non-inv. pin for path's RX
RxPin(N): SerInN[0]; // Inverting pin of differential pair
TxPin(P): SerOutP[0]; // Top-level non-inv pin for path's TX
TxPin(N): SerOutN[0]; // Inverting pin of differential pair
// TestPhaseNo : 1; // Only needed if odd number of transceiver
modules
AssociatedChannelForTest : CH3;// Connected via (off-chip) loopback
}
// insert more Channels here that are connected to same ULTRA
// Channel {
// Identifier : CH1;
// ...
// TestPhaseNo : 2;
// AssociatedChannelForTest : CH2;
// } // end of Channel wrapper
} // end of Instance wrapper
Instance { // Repeated for every ULTRA block (you need at least two)
// ULTRA Options
ParentInstance: CORE/DUAL2; // Where to put ULTRA#2 (in top level)
ClockSource(Reference) { // Reference clock source for this SerDes
// and ULTRA
Pin(P): TestClkP; // Note this is different than for previous Instance
Pin(N): TestClkN:
}
ClockSource(Offset) {
Pin(P): RefClkP; // Ref. clock for associated (far end) SerDes and ULTRA
Pin(N): RefClkN;
}
WordClock: CORE/DUAL2/SD1/SERDES/TxClkOut; // Port name of SerDes parallel
// clock, whether input or output.
// This indicates 1-clock SerDes.
Channel {
// Channel Options
Identifier: CH2;
ParentInstance: CORE/DUAL2/SD1;
RxSamplingWithRefClockEnable: CORE/DUAL2/SD1/SERDES/L2R[0];
TXWordPort: CORE/DUAL2/SD1/SERDES/TxData[9:0];
RxWordPort: CORE/DUAL2/SD1/SERDES/RxData[9:0];
RxRecovWordClock: CORE/DUAL2/SD1/SERDES/RecClk;
RxPin(P): SerInP[2];
RxPin(N): SerInN[2];
TxPin(P): SerOutP[2];
TxPin(N): SerOutN[2];
// TestPhaseNo: 1;
AssociatedChannelForTest: CH1;
}
// insert more Channels here that are connected to same ULTRA

// Channel {
// Identifier : CH3;
// ...
// TestPhaseNo : 2;
// AssociatedChannelForTest : CH0;
// } // end of transceiver Channel wrapper
} // end of ULTRA Instance wrapper
} // end of SerdesTest group wrapper
} // end of Module
Here are other ULTRA properties that can be controlled in this file:
CDFSamplesCounterSize: 12; // default; max = 16
Sets number of counter bits for each histogram bin. A larger value increases the gate count but
permits more than 4096 edges (beat cycles) to be measured.
CDFNumberOfBins: 32; // default; other = 0, 8, 16, 64, 128
Sets number of bins in histogram. Recommended values are 32 (default) and 0. A larger value
significantly increases gate count. If set to 0, then no histogram can be generated, which reduces
gate count to ~4K gates per ULTRA (instead of ~10K for default value). One ULTRA per PLL
type should include histogram capability to aid jitter characterization, but this capability may be
omitted for the others to reduce gate count. No other tests are affected.
NoiseShiftRegisterSize: 32; // default; other = 64, 128
Sets the number of samples captured around each edge for RMS jitter measurements.
Recommended value is 32 (default). If the value is larger than CDFNumberOfBins, then
adjacent samples are accumulated in each histogram bin. Increasing the
UnderSamplingClkRatio value, during test, is a simpler way to increase the measurable peak-to-
peak jitter for a histogram (without affecting gate count).
Proceed to Step 2: Embed Test Circuitry.
Connections for Dual-Clock SerDes Transceivers
Connections for Dual-Clock SerDes Transceivers

An example IC is shown in Figure 2-8, containing two transceivers, where the transmitter of
each transceiver uses the reference clock's nominal frequency, and the receiver of each
transceiver uses a reference clock which frequency is slightly offset. For all loopback paths
controlled by a single ULTRA, the frequency offset must be the same. When multiple ULTRAs
are used, each ULTRA might operate at a different or the same nominal frequency as the other
ULTRAs.
If SerdesTest is used for a transmit-only IC, the high-speed serial output should be
undersampled by a differential latch clocked at the parallel rate (plus a frequency offset), the
latch’s clock should be considered as RxRefClk, its inverted version as RxRecovWordClock,
and its Q output as RxWordPort[0].
Figure 2-8. Design Hierarchy and Loopback Paths for Dual-Clock SerDes
Transceivers
Step 1.12 — PLL Interface

Optionally, only if you used the SamplerInterface wrapper in your .etplan file, customize the
Sampler module PLL_LV_ULTRA_RPA and put it in a module that also contains your PLL, as
shown in Figure 2-9. Use a module name and port names that are consistent with
your<chip>.etplan file.
Figure 2-9. Example PLL Interface Schematic
The highest-numbered bit of the PLLOUTPUTS[ ] input port of the Sampler module must be
used for detecting loss-of-lock, and the signal provided to the port must be logic 1 when the
PLL is locked. The PLL is assumed to lose lock when the signal to the InterceptChangePLL
port is inverted because PLLTest only starts measuring after this event and will stop measuring
after Test Duration in Beat Cycles. To force the PLL to lose phase lock, the port identified by
InterceptChangePLL can be used, for example, to invert one or more bits of the PLL's divider
values. This connection also enables you to load in a divider value chosen so that when the bit is
inverted, the PLL is at its maximum or minimum output frequency, which permits lock range to
be tested too.
Alternatively, InterceptChangePLL can force the PLL to lose lock by temporarily connecting a
different reference clock phase or frequency to the PLL input.
Note
To reduce sampling jitter in a custom RPA_SAMPLER, use the falling edge of the
US_CLK for the sampling latches. Almost all activity in the ULTRA module occurs around
the rising edge of the US_CLK.
Figure 2-10. Controlling a PLL for Lock Time and Lock Range Measurement
After you add the interface module, run (again) “Step 1.4 — Check Clock Tree” on page 24,
and “Step 1.5 — Check DFT Rules” on page 24
Proceed to Step 2: Embed Test Circuitry.
Chapter 3
Step 2: Embed Test Circuitry
Perform the following procedures.

Step 2.0 — Check .etplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Step 2.1 — Generate LVWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Step 2.2 — Specify TAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Step 2.3 — Generate & insert RTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Step 2.4 — Check connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Step 2.5 — Prepare for simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Step 2.6 — Generate LVDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Step 2.7 — Generate test bench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Step 2.8 — Simulate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Step 2.9 — Diagnose PLLTest SerdesTest simulations . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Step 2.10 — Synthesize logic gates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Step 2.11 — Static timing analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Step 2.12 — Prepare for layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Step 2.13 — Prepare for sign-off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Step 2.14 — Prepare for test pattern generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Step 2.15 — Generate final LVDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Step 2.16 — Generate post-layout simulation test bench. . . . . . . . . . . . . . . . . . . . . . . . . 67
Step 2.17 — Simulate post-layout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Step 2.18 — Generate sample test patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Step 2.19 — Archive Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Step 2.0 — Check .etplan

• Set your current directory to DFT .

make checkPlan
Step 2.1 — Generate LVWS
to check the .etplan file that you created for syntax, valid file pointers, etc.. Results are reported
to the screen and in DFT/outDir/etplanner.log_checkPlan. Correct any errors, and re-run.
Any time that you make changes in the .etplan file, you should begin the flow again from this
step.
Step 2.1 — Generate LVWS


make genLVWS
which will use the .etplan and .etCheckerInfo files to create or update a Workspace (./
<chip>_LVWS directory).
If you have made changes to your design and are running this command again, you should
rename the present <chip>_LVWS directory (e.g., add .old suffix) to ensure that old files are
not reused. You can later copy files into it that you created manually (<chip>.etassemble).
Step 2.2 — Specify TAP

• Set your current directory to DFT/<chip>_LVWS/ETAssemble .
Step 2.2 — Specify TAP
• Edit ./<chip>_LVWS/ETAssemble/<chip>.etassemble , using your own parameter

values, so that it looks like the following if the file is for your top-level chip (next page
shows a module example):
Configuration (<chip>) {
BoundaryScan { // information for 1149.1 (JTAG) implementation - ignore for now
Overrides {
* : Option(NJTAG); // This declares all pins as non-jtag - ignore for now
}
ACMode { // Information for 1149.6 (AC-JTAG) implementation - ignore for now
}
}
TAP {
InstanceName: LV_TAP;
DeviceIdCode: 16'h0000; // Delete this line if register not needed
ManufacturersIdCode: 11'b000; // Delete this line if register not needed
NumberUserBits: 0; // Instruction Register bits for you to assign
later
NumberUserDRBits: 6; // Data Register bits for you to assign later
UserBitAliases {
Vout: UserDRBit(2:0);// Assign names to bit ranges that will control SerDes/PLL
Equalization: UserDRBit(4:3);
Preemphasis: UserDRBit(5);
}
TestPortConnections { // Provide this wrapper if you prepared for Master/Slave
TAP
TMS : <hierarchicalOutputPortName_SelLVAndGate> ;
TDO : <hierarchicalInputPortName_SelLVMux1> ;
TDO_EN(1 | 0) : <hierarchicalInputPortName_SelLVMux1> ;
}
} // End of TAP
CustomObject ( ) {// for adding muxes, userDRBit connects - ignore for now
}
} // End of Configuration
Example for <module>.etassemble for a module with a WTAP:
Configuration (<module>) {
WTAP {
InstanceName: LV_WTAP1;
NumberUserIRBits: 0; // Instruction Register bits for you to assign
later
} // End of WTAP
CustomObject ( ) {// for adding muxes, userDRBit connects - ignore for now
}
} // End of Configuration
Caution
You should assign UserBitAliases for all UserDRBits, even single bits, to avoid
problems setting them later in SiliconInsight.
Step 2.3 — Generate & insert RTL
Step 2.3 — Generate & insert RTL

Use the command:
make <chip>.etassemble.updateDiff
so that whenever you change the <chip>.etplan file and re-generate the DFT/<chip>_LVWS
directory by using the make genLVWS command, your edited lines will be re-inserted into
<chip>.etassemble .
Note
If you are working at the top level, and your SerdesTest (or PLLTest) is controlled by a
WTAP in a lower level block that you wish to simulate as RTL, then create a soft link called
<chip>.v that points to your original RTL for the chip, as follows (where .v is your suffix for
synthesized logic, and .vb is your suffix for unsynthesized RTL):
ln -s <path>/RTL/<chip>.vb <chip>.v
Use the command:
make embedded_test
to generate RTL for a Siemens EDA TAP controller and SerdesTest (or PLLTest), insert them
into your design, connect them, and create synthesis scripts and design constraint (SDC) files.
No design files are modified or over-written by the software - previously existing files will be
renamed with a .bak suffix.
Add muxes and userDRBit connections

Your original RTL design directory will be referenced automatically by a soft link, all_RTL ,
placed in the DFT/<chip>_LVWS/modulesRTL directory, and the module versions that have
Embedded Test inserted will have the suffix “_et”.
Check that the TxData nets and LockToReference nets were automatically intercepted with
multiplexers to permit SerdesTest to control those signals. Also check them to find the exact
hierarchical names of userDRBit output nets (LV_userDRBitnn), and net names of any control
signals that you want to intercept with multiplexers to permit you to use the TAP userDRBits to
control functions (e.g., SerDes equalization, or PLL feedback dividers).
Custom Connections
Edit the CustomObject wrapper in <chip>.etassemble, like the following, to add a multiplexer
to permit TAP userDRBits to control:
CustomObject (Mux2InterceptSource) {
Var(ModuleName): Mux21; // RTL mux that you create, or a specific gate
Var(InstanceName): myMux1;
Var(OutputPin): Y; // must be single-bit
Var(InterceptPort): U1/A; //e.g., control bit for equalization
Var(Input0Pin): A; // will get connected to original control bit
Var(Input1Pin): B;
Var(Input1Connection): LV_JTAP_INST/userDRBit[1]; // TAP control bit
Var(SelectPin): S;
Var(SelectConnection): LV_JTAP_INST/userDRBit[0]; // Test mode bit
}
ModuleName may refer to an RTL multiplexer module in your design directory, or to a specific
cell in the IC’s technology cell library.
Repeat this for each multiplexer instance to be added to your design.
Caution
You use the CustomObject procedure to insert gates only into instances of modules. Do not
use the CustomObject procedure to insert gates in modules to be instantiated multiple times
in your chip - you must manually add the gates in your module’s original design.
Custom Connections
To measure lock time for PLLTest, you must connect some signals within ULTRA to the PLL
interface module that you created in “Step 1.12 — PLL Interface” on page 43, as follows:
1. Edit the CustomObject wrapper in <chip>.etassemble to add the following connections,

where <instancePath> is the hierarchical name of the instance:
CustomObject (ConnectPortToPort) {
Var(Port1): <instancePath>/<port>;
Var(Port2): <anotherInstancePath>/<port>;
}
}
If you added custom object connections, then in ETAssemble/outDir rename or “mv”

ULTRA__LV_ULTRA_CTRL.vb to ULTRA__LV_ULTRA_CTRL.vb.gen or similar
name.
Other CustomObject types can add combinational or sequential logic. The UserSignal construct
can be used to create logic combinations of userDRBits to control functions. See the
ETAssemble Tool Reference manual.
Step 2.4 — Check connectivity
If you added any custom object connections, then perform the following:
1. Set current directory to DFT/<chip>_LVWS/ETAssemble

2. Run command make <chip>.etassemble.updateDiff
3. Re-run command make embedded_test to re-generate RTL with the new logic inserted.
Step 2.4 — Check connectivity

Your current directory should be DFT/<chip>_LVWS/ETAssemble
Use the command:
make designe
to verify connectivity from the I/O pads to the TAP controller and SerdesTest (or PLLTest).
This step will also create a Test Connection Map file, ./<chip>_LVWS/ETAssemble/
<chip>.tcm, that documents the connections between the TAP and ULTRA, as well as loopback
connections and connections to the tester. This file will be used later to generate test patterns.
If you specified -bscan Off in the <chip>.etchecker file, expect to see a warning about lack of
<chip>.BSDL file, which you can ignore.
If there are any errors, a viewer may automatically be invoked to help show you where errors
are. You can zoom in, etc., then quit.
If you are working at the top level, and your SerdesTest (or PLLTest) was already signed-off
with a WTAP at a lower, block-level, then you must assign clock periods to the top-level
reference clock pins (copy the two lines from the block’s <module>.etSignOff file), but be sure
to use the chip pin names (not the module port names):
• Edit ETAssemble/outDir/<chip>.etv_startup and define clock periods for the two

reference clocks by inserting lines like the following, below the line that defines TCK
clock period:
<REFCLKpin> : 10.0ns; //nominal period
<OFFSETCLKpin> : 9.9985ns; //offset period
File hierarchy
At this time, your file directories will look like those in Figure 3-1 on page 53 (for initial
working directory named mydesign, and a chip named CHIP).
Step 2.5 — Prepare for simulation
Figure 3-1. File hierarchy for <chip> = CHIP

Set your current directory to DFT/<chip>_LVWS/ETAssemble
Use the command:
make config_etSignOff
(remember that make command parameters are case sensitive)
This command creates a ./<chip>/ETAssemble/<chip>.etSignOff file to guide simulation that

verifies your design.
• If you are working at the top level, and your SerdesTest (or PLLTest) was already
signed-off with a WTAP at a lower block-level, then this file will only contain tests for
the top-level TAP and a test to check the reference clocks.
• If you are working at a design level that contains SerdesTest (or PLLTest), then the file
will also contain tests for the Serdes (or PLL). Here are selected lines from the file:
etv ( <chip> ) {
IncludeAllPowerPins : Yes; // Yes, (No)
jtagVerify(<chip>) {
PatternName : tapbistv;
SimulationScript : <chip>_sim.script;
TCKPeriod : 40.0ns;
TestStep ( Default ) {
RunTest : TestLogicReset;
RunTest : InstReg;
...
serdesVerify(<chip>_<prefix>_P1) {
PatternName : serdesv_P1_<chip>_<prefix>;
ClockPeriod : 40.0ns;
TckRatio : 1;
TestStep ( BasicTests ) {
SerdesTest : BasicTests;
Controller ( BP0 ) { // BIST Port 0
...
...
UseDutLoopBacks : Off;
TestStep ( OffsetFrequency ) {
SerdesTest : OffsetFrequency;
Controller ( BP0 ) {
...
serdesVerify(<chip>_<prefix>_P3_I0_CH0) {
PatternName : serdesv_P3_I0_CH0_<chip>_<prefix>;
...
UseAsyncClocks : On;
...
UseDutLoopBacks : On;
DutLoopBacks { <RXserialIn> <= <TXserialOut>; }
TestStep ( RmsJitter ) {
Pattern : P010J;
SerdesTest : Jitter;
Controller ( BP0 ) {
...
DataBitNo : 0;
...
User Defined Sequence
...
UseDutLoopBacks : On;
DutLoopBacks {
<RXserialIn> <= <TXserialOut>;
}
TestStep ( BERT_Test ) {
SerdesTest : FunctionalLoopBack;
Pattern : PRBS;
SanityCheck : On;
InjectErrors : Off;
...
The file includes tests that verify basic functionality of SerdesTest (or PLLTest) within your
chip's design:
tapbistv - test TAP logic

serdesv_P1_<chip>_ULTRA_ - test ULTRA logic
serdesv_P2_<chip>_ULTRA_ - measure clock frequency offset
serdesv_P3_I0_CH0_<chip>_ULTRA_ - measure jitter for Channel0,etc.
serdesv_P4_<chip>_ULTRA_ - measure BER,using PRBS,for SerDes only
The clock period is the value from the ETCHECKER/<chip>.etchecker file, and the TCK
period is 4X this value to get the fastest simulation possible. If necessary you can increase the
TCK period by powers of 2, but do not decrease it. All measured values are expected to be zero.
Notice that serial loopback is automatically connected for P2 and P4.
<chip>.etSignOff information can also be entered within SiliconInsight, when creating tests for
real silicon.
Note
If the PLL's output frequency is not an integer multiple of the reference frequency (as
indicated in your .etplan file via VcoFrequencyMultiplier and ClockOutputs dividers), then
you must edit the period of the "offset test clock" for the _P3 test in your .etSignOff file so that
it equals the nominal period of your PLL's output clock. Later, when you use SiliconInsight, you
can instead adjust the value of USCR to allow different output and sampling frequencies.

No other edits are necessary, unless you require a User Defined Sequence (UDS) to initialize
your chip (for example, if you have Master/Slave TAPs). Use the template shown in the “User-
Verilog to SVF conversion
Defined Sequence Section” section of the ETVerify Tool Reference manual and summarized
here:
etv (<chip>) {
IncludeAllPowerPins : No; // Yes, (No)
UserDefinedSequence (<sequenceName>) { //a unique name
TestStep { // all lines below are optional
PinSettings {<pinName>: 0 | 1; }
PinCompares {<pinName>: 0 | 1 | x;}
InitialWaitCycles : <wCycles>;
Pause : <pTime>[s | (ms) | us | ns | ps];
DRStatus : 0 | 1 | x;
IRStatus : 0 | 1 | x;
UserBitAlias : <binaryNumber>;
UserDRBit(n) : On | (Off);
UserIRBit(n) : On | (Off);
SVFFile : <SVFName.svf>;
} // End of TestStep wrapper
} // End of UserDefinedSequence wrapper
// etc., as shown on previous page
}
} // End of etv wrapper
The following is a simple, example SVF file you could put in the ETAssemble/SVFFiles
directory:
PIOMAP { IN clk(1) IN data(2) IN reset(3) );

PIO (LLH); PIO (LLL); PIO (HLL); PIO (LLL);

To create an SVF file from a Verilog pattern, you must “cyclize” the signal values and convert
the pattern into a series of PIO commands. First, simulate your test bench normally along with a
module like the one below but edited to match your test bench name, pin list, and clock period,
with an appropriate strobe offset. The TB.CHIP.xxx lines refer to pin names you control with
the PIO statements. You can also update the `timescale to be consistent with what you use
elsewhere.
In the example below, 7 pins are toggled during two clock cycles to load a CPU register with a
value in order to enable the TAP controller. “Cycles” is set to 4 in the example to generate 2
clock cycles because the sampling period is must be twice the real clock period in order to
sample the clock high and low for each clock cycle.
`timescale 1ns / 10ps

module SignalStrobe;
real offset = 0.9; // Strobing offset as a fraction of period
real period = 100; // Strobing period in ns, e.g., 2 * clockPeriod
integer cycles = 4; // Number of strobes to make
integer cycle;
integer fhandle;
initial begin
fhandle = $fopen("Data.strobe");
#(offset*period);
for (cycle = 1; cycle <= cycles; cycle = cycle +1) begin
// Edit the signal list below.
// Replace TB by your Testbench module name
// Replace CHIP by the instance of your chip with your testbench
$fdisplay(fhandle,cycle," ",
TB.CHIP.cpuClk, //PIOMAP signal 1
TB.CHIP.cpuRstn, //PIOMAP signal 2
TB.CHIP.cpuData[3],
TB.CHIP.cpuData[2],
TB.CHIP.cpuData[1],
TB.CHIP.cpuData[0],
TB.CHIP.tck); //PIOMAP signal n
#(period);
end
end
endmodule
Running the normal simulation with the extra SignalStrobe module generates an output file
called Data.strobe, which looks like this:
1 01xxxx1
2 00zzzz1
3 0100001
4 1100001
With these cyclized vectors, you create PIO commands using the following command (a Tcl
program in ETCreate/bin):
strobe2pio Data.strobe > MyInitSequence.svf
Step 2.6 — Generate LVDB
In the output file, add a PIOMAP header to indicate pins are IN or INOUT and their order in
each PIO line. The resulting file looks like the following:
PIOMAP ( IN cpuClk IN cpuRstn IN cpuData(3) IN cpuData(2)

IN cpuData(1) IN cpuData(0) IN tck );
! comment
PIO (LHZZZZH );
PIO (LLZZZZH );
PIO (LHLLLLH );
PIO (HHLLLLH );
!toggle TCK to bring TAP into RunTestIdle State for 3 TCK cycles
RUNTEST 3 TCK ENDSTATE IDLE;
Note
PIO patterns cannot be applied to TAP pins. You must use other SVF commands (such as
RUNTEST) for TAP pins.
A UserDefinedSequence can be applied immediately before or after the Siemens EDA TAP is
reset/accessed, as follows:
etv (<designName>) {
...
UserDefinedSequence (<sequenceName1>) {
...
}
...
...
PreTAPUserDefinedSequence : <sequenceName1>;
}
}
• PreTAPUserDefinedSequence - applied immediately preceding the TRST pulse and five

consecutive 1’s on TDI that resets the TAP at the beginning of each test pattern. If you
have a Master/Slave TAP, you need this type of UDS.
• PostTAPUserDefinedSequence - applied immediately following the TRST pulse and
five consecutive 1’s on TDI that resets the TAP at the beginning of each test pattern,
before the test instructions, userDRBits, test parameters, etc. are shifted in.
Step 2.6 — Generate LVDB

Use the command:
make lvdb_preLayout
Step 2.7 — Generate test bench
to create a pre-layout LVDB directory:
../ETSignOff/<chip>.lvdb_preLayout
It documents all the test circuitry in your design and is used by SiliconInsight and ETVerify as
the sole source of data for test pattern generation, until you create a finalLVDB in “Step 2.15 —
Generate final LVDB” on page 67.
Step 2.7 — Generate test bench

Use the command:
make testbench
to run ETVerify which produces a Verilog simulation test bench for each of the patterns in
ETAssemble/<chip>.etSignOff .
If you make changes to <chip>.etSignOff and then re-run make testbench, your edited lines will
be automatically re-inserted (see the changes in <chip>.etSignOff.diff).
Step 2.8 — Simulate

Use the command:
make sim
to launch a simulation script that runs all generated test benches. Questa® SIM, VCS, NC-
Verilog, and Verilog-XL are supported directly; you can edit the scripts to support other
simulators. Simulations can be executed with RTL, gate-level models, or a mixture.
You can ignore warnings about “too few module port connections” for the two tests that connect
to only the JTAG pins and reference clocks.
Caution
If your SerDes (or PLL) model is very simple, the simulation of all five patterns may require
only a few minutes and produce a summary output like that below (along with warnings
about “Too few module port connections”), but for more complex models and more chip logic,
you should run and diagnose just one test pattern at a time, as described on the next page.
View RTL
Simulation Results Summary

Log File: ./outDir_etv/verilog.log_tapbistv
Date = Mar 11 15:48
Number of Z Compare Events = 0
Number of 1/0 Compare Events = 255
Number of Compare Failures = 0
Log File: ./outDir_etv/verilog.log_serdesv_P1_CHIP_ULTRA_

Date = Mar 11 15:48
Log File: ./outDir_etv/verilog.log_serdesv_P2_I0_CH0_CHIP_ULTRA_

Date = Mar 11 15:48

Date = Mar 11 15:49

Date = Mar 11 15:49
The last Log File message shown (P4) is produced only for SerDes tests, not PLL tests.
View RTL
To check your RTL connections in the Tessent Visualizer schematic viewer, use the command:
make schematicView
In the GUI, you can find a desired instance in the Instance Browser tab, then right-click it to
display it in the Hierarchical Schematic tab. Please see the Tessent Visualizer chapter in the
Tessent Shell User's Manual for more details on using this GUI.
Simulate one pattern
Simulate one pattern

To simulate just one pattern (which is recommended to save time, and to permit you to achieve
success with each pattern before proceeding to the next pattern), first use the following
command to see the list of test patterns available:
make sim cmdOptions=”-list”
You will see the following list:
- tapbistv
- serdesv_P1_<chip>_ULTRA_
- serdesv_P2_I0_CH0_<chip>_ULTRA_
To run just the P1 pattern, for example, use the command:
make sim cmdOptions=”-select \

serdesv_P1_<chip>_ULTRA_”
To run just the P1 pattern and save the results in a file to view in a waveform viewer, use a
command that adds VCD, UTVCD, or debussy
make sim cmdOptions=”-select

\ serdesv_P1_<chip>_ULTRA_ +define+VCD”
The simulation results will be saved in a file with a name like:
verilog_serdesv_P1_<chip>_ULTRA_.dump.fast
In your simulator, observe the signals of TB/DUT_inst/<chip>
The applied clock signals will have _DUT suffix.
Some internal signals will be visible at this level with _INT suffix.
Note
If you make any changes to your design or to <chip>.etplan, you must re-run Steps 2.0 and
2.1 (make checkPlan, genLVWS ) with DFT as your current directory. Then, with DFT/
<chip>_LVWS/ETAssemble as your current directory, you can re-run steps 2.3~2.8 (make
embedded_test, designe, config_etSignOff, lvdb_preLayout, testbench, sim) with a single
command: make all
The following two pages describe what to look for in the simulation results to diagnose a failing
test.
Step 2.9 — Diagnose PLLTest SerdesTest simulations
Step 2.9 — Diagnose PLLTest SerdesTest

simulations
Here is the recommended diagnostic procedure. Each step must be successful before proceeding
to subsequent steps; skipping steps can cause frustration and waste time. For example, the
output summary file on the preceding page was for a chip whose SerDes serial output was
stuck-at-0 so the test never completed (DONE bit was 0) - the passing tests only involve the
reference clocks and SerdesTest. Jumping ahead to the P4 test before the preceding tests pass
would require you to diagnose simultaneously several potential problem areas (offset
frequency, RX lock time, bit order, bit inversion, setup/hold times, FIFO effects, etc.).
tapbistv and P1 patterns

For the tapbistv and P1 patterns (test TAP function), your SerDes is not involved, so just verify:
• TRST input to SerdesTest module is logic 1;

• TDI, TMS, and TCK pins and inputs to SerdesTest module toggle;
• TDO pin driver is enabled (active low) by SerdesTest;
• the TDO pin toggles;
• the test passes.
P2 pattern
For the P2 pattern (FrequencyOffset: frequency offset measurement with RxRef sampling
TxRef; 2 beat periods), verify:
• your SerDes is initialized to use the reference frequency and parallel port width stated in
<chip>.etplan;
• your simulation timing resolution is less than or equal to 0.1% of your serial UI (default
is 100 fs);
• this test only measures the frequency offset between the TX parallel-rate reference clock
and the RX parallel-rate reference clock; it does not involve the SerDes;
• if your TX obtains its clock from the ClockSource(Offset)pin, then the RX recovered
parallel-rate clock (connected to RXREC_CLK input of SerdesTest) has its nominal
period and is Clock2PinFrequencyRatio times the RX reference clock pin’s period, after
the declared LockTime;
• if your TX obtains its clock from the ClockSource(Reference)pin, then the RX
recovered parallel-rate clock (connected to RXREC_CLK input of SerdesTest) has a
P3 pattern
period that is 0.015% less than its nominal value and is Clock2PinFrequencyRatio times
the RX reference clock pin’s period, after the declared LockTime;
P3 pattern
For the P3 pattern (RmsJitter: on-chip RMS jitter measurement on the RxData[0]; 2 beat
periods, no jitter), verify:
• initialization, modes, and all clock periods are the same as specified above for P2;
• if your TX obtains its clock from the ClockSource(Offset)pin, then it transmits
10RRRR10RR, where R is randomly 0 or 1, with a bit interval 0.015% less than its
nominal value; if the bit interval is longer, this may indicate that the RX clock was used
instead, different than indicated in the .etplan file, which will cause this test to fail its
upper test limit;
• RXData[0] pulses each have a minimum duration of 3333+/-3 clock periods divided by
SerDesWordSize, after the declared LockTime;
P4 pattern
For the P4 pattern (tests most SerDes functions and SerdesTest timing, in function mode but
with offset reference clocks), verify:
• initialization and all clock periods are the same as for P2, except the RX is in normal
(lock-to-data) mode;
• the TX parallel PRBS7 data bits are serially transmitted in the correct sequence (e.g.,
LSB or MSB first);
• if your TX obtains its clock from the ClockSource(Offset)pin, then it transmits PRBS7
with a bit interval 0.015% less than its nominal value; the RX recovered parallel-rate
clock (connected to RXREC_CLK input of SerdesTest) has a period that is 0.015% less
than its nominal value, after the declared LockTime;
• if your TX obtains its clock from the ClockSource(Reference)pin, then it transmits
PRBS7 data with its nominal bit interval; the RX recovered parallel-rate clock
(connected to RXREC_CLK input of SerdesTest) period is nominal, after the declared
LockTime;
• the RX parallel bits correspond to serial data (e.g., LSB to MSB, for some byte
boundary), after the declared LockTime;
Step 2.10 — Synthesize logic gates
Step 2.10 — Synthesize logic gates

If you are embedding SerdesTest (or PLLTest) in a module to only the RTL level, and wish to
proceed directly to the top-level without synthesizing the module, you can skip this block-level
synthesis step, go directly to “Step 2.12 — Prepare for layout” on page 65, and then return to
“Step 1.0 — Create Working Directories” to perform DFT for the top-level design.
Use the command:
make synth
to synthesize your design's RTL into gate-level.
Read ETAssemble/outDir/SynthesisAndLayout.README to see how to use the two .sdc files

in that outDir directory for timing-driven synthesis and layout.
Step 2.11 — Static timing analysis

Before simulating at gate-level, you should perform static timing analysis (STA). You will find
notes for this task in the file:
DFT/<chip>_LVWS/ETAssemble/outDir/StaticTimingAnalysis.README
You will need to create a file that sets various tcl parameter values. The above README file
contains example lines for you to copy.
STA should be run in three modes, in this sequence:
• Functional mode, with all embedded test circuitry in reset mode

• Test logic only, with all paths to functional logic unchecked
• Normal, with function and test logic enabled
The Embedded Test methodology for STA is to remove all known false and multi-cycle paths
from the complete list of paths, and whatever is left must be single-cycle paths.
Within SerdesTest and PLLTest logic blocks, test data is loaded in and transferred between the
TAP and ULTRA block's TCK_REG at the TCK clock rate, then the tests are run at the parallel
or reference clock rate, and then the results are transferred back to the TAP controller at the
TCK rate. Transfers involving the TCK_REG register should be treated as false paths, because
once the parallel clock is involved, all TCK_REG outputs are constant values.
To accommodate different character mappings used by synthesis tools when flattening a design,
such as the hierarchy separator “/” replaced by “_”, square bracket indexes (“[n]”) replaced by
Step 2.12 — Prepare for layout
“_n_”, escaped names in paths, etc., you must find the following lines in the ETAssemble/
outDir/chip_etassemble.sta file and change the “[” and “_” characters appropriately:
proc LV_map_to_verilog {path} {

set path "[string map {"[" "_"} $path]"
set path "[string map {"]" "_"} $path]"
return $path
}
Also, set the Tcl variable “LV_hierarchy_separator” to be whatever character your synthesis
tool uses (“/” is the default character).
Use the command:
make sta
to run the static timing analysis tool using the automatically generated STA script.
Caution
You should check that flip-flops in the RPA/SAMPLER module are placed very close to
each other in final layout, and that no buffers are placed in the clock or data signal paths
between them. Any delays in these paths will be added to the measured value of the Mean
Sampling Instant, hence decrease (only) that measurement's accuracy.
Caution
For small ICs, especially test chips, I/O switching activity can affect the core logic power
rail voltage more significantly than for large ICs, which may cause excessive jitter in the
SAMPLER flip-flops. If the I/O switching is synchronous with a clock period that is an integer
multiple (2~8) of the ULTRA clock rates, then ULTRA can compensate. If not, then these
outputs should be disabled when ULTRA is testing, and circuitry might need to be added to do
this.
Go back to “Step 2.8 — Simulate” on page 59 and run make sim to re-run simulations, using
this gate-level version.
Step 2.12 — Prepare for layout

Use the command:
make concatenated_netlist
Step 2.13 — Prepare for sign-off
to create a single file named <chip>.v_postLV in the ETAssemble directory (your working
directory) containing the entire netlist to facilitate simpler hand-off to layout, along with the
.sdc file.
If you are embedding SerdesTest (or PLLTest) in a module (with a WTAP) to only the RTL
level, and wish to proceed directly to the top-level without synthesizing the module, then do the
following:
• Move the file <module>.vb_postLV to directory DFT/concatenated_netlists/

• In that directory, create a soft link using the command
ln -s <module>.vb_postLV <module>.netlist_prelayout
• Return to “Step 1.0 — Create Working Directories” to perform DFT for the top-level
design.
Caution
If you are working at the top level, and your SerdesTest (or PLLTest) is controlled
by a WTAP at a lower block-level, then do not proceed to the next step until all the
lower block-levels have been signed-off, i.e. completed at least to “Step 2.15 —
Generate final LVDB” on page 67.
Step 2.13 — Prepare for sign-off

After layout, place a soft link to your post-layout netlist in the directory:
DFT/concatenated_netlists/
using a soft link called <chip>.netlist_final i.e. use command:
ln -s <chip.postLayout> <chip>.netlist_final
Step 2.14 — Prepare for test pattern

generation
Set your current directory to DFT/<chip>_LVWS/ETSignOff/
Use the command:
make config_etManufacturing
to create a <chip>.etManufacturing file in your current directory with tests from

<chip>.etSignOff for generating ATE patterns.
Step 2.15 — Generate final LVDB
The SerdesTest (or PLLTest) patterns that you used for simulation are not transferred
automatically; you may copy these manually, or add later in SiliconInsight. If you are working
at the top level, and your SerdesTest (or PLLTest) is controlled by a WTAP at a lower block-
level, you do not need to do this because the patterns were already simulated via WTAP.
Note
This make command is only applicable at the top-level of a chip: if you are presently
completing a block with a WTAP, then this command does nothing.
Step 2.15 — Generate final LVDB

Use the command:
make lvdb_final
to generate the final LVDB directory, with all test information:
DFT/finalLVDB/<chip>.lvdb/
That directory will include <chip>.ETSignOff with your test descriptions.
Step 2.16 — Generate post-layout simulation

test bench
Use the following command:
make testbench
to create test benches (including SerdesTest/PLLTest-specific tests) from the following file:
finalLVDB/<chip>.lvdb/<chip>.ETSignOff
You may proceed to “Step 2.17 — Simulate post-layout”. If that simulation is successful, then
you should use SiliconInsight to create additional tests (with test limits) that are representative
of all those you intend to use on ATE and then simulate them.
To create more tests in SiliconInsight, while the ETSignOff directory is your current directory,
• If necessary, use the following command:

unsetenv TCLLIBPATH
• If necessary, include the SiliconInsight software directory that supports SerdesTest and
PLLTest in your search path, with a command like:
setenv PATH /wv/lvs_rls/prod/Tessent/ETAccess/bin:$PATH
Step 2.16 — Generate post-layout simulation test bench
• To start SiliconInsight, use the command:

sid -lvdb CHIP.lvdb_preLayout -sim
• Go to “Step 4.2 — Add a Test Step” and implement tests as described in Step 4 and Step
5 (without any hardware);
o Use values for Test Duration In Beat Cycles between 1 and 10 so that simulation
time is reasonably short (zero jitter will be measured).
o Always enable Use Async Clocks in Test Step Options.
o Always set ATE Vector Period (which sets TCK Period) to at least 4 times the
RXREF clock period.
• Click on File, then click on Export...
and set the file Selection to
DFT/finalLVDB/<chip>.lvdb/<chip>.etManufacturing
• Click on OK
• Click on File, then click on Save Config As...
and set the file Selection to
DFT/finalLVDB/<chip>.lvdb/<chip>.config_eta
• Click on OK
• Exit from SiliconInsight.
Note: Next time you enter SiliconInsight, use the normal configFile:
-configFile <chip>.lvdb/<chip>.config_eta
• Set your current directory to finalLVDB/<chip>.lvdb/

• Rename <chip>.etSignOff to <chip>.etSignOff.gen (for example).
• Rename <chip>.etManufacturing to <chip>.etSignOff so that it will be used instead.
• In the new <chip>.etSignOff file, comment out the line with LoadBoardInfoFile by
preceding it with “//” (if a WTAP is used, this line does not exist). This file is used to
provide loopback paths between boundary scanned pins and to designate connections for
pins that are not connected to the ATE - the serial data loopback will be automatically
made for SerdesTest controlled by a TAP, but not when a block containing an
SerdesTest and WTAP is instantiated.
Step 2.17 — Simulate post-layout
Step 2.17 — Simulate post-layout

Set your current directory to DFT/<chip>_LVWS/ETSignOff/
Use the command:
make <chip>_sim
to run post-layout simulations with full back-annotation (using soft link DFT/
concatenated_netlists/<chip>.netlist_final). You can use the same options you used for pre-
layout simulation in “Simulate one pattern” on page 61.
If these simulations run successfully for a module, you are ready to incorporate it within a chip,
and connect the WTAP to the chip’s TAP. To begin DFT for the top level, proceed to “Step 1.0
— Create Working Directories”.
If these simulations run successfully for a whole chip, you are ready for tape-out (you do not
need to re-run WTAP module tests, but you can by using the command make sim ).
Step 2.18 — Generate sample test patterns

Use the following command:
make patterns
to have ETVerify read <chip>.etManufacturing and create WGL files (or PatternType value in
.LVICTech file - see “Step 1.6 — Check Default Files”).
The generated files will include the jtagVerify test, the ‘P1, ‘P2, ‘P3, ‘P4 tests if you copied
them manually in “Step 2.14 — Prepare for test pattern generation”, and/or any other tests that
you added in “Step 2.16 — Generate post-layout simulation test bench”. These patterns can be
supplied as a minimal set of tests for ATE to check file format.
Note
Edit the pin-map template file, <chip>.pinmap_tpl, when you know specific tester channel
connections, and then rename it <chip>.pinmap - see “Step 3.4 — .pinmap File”.
• Return to using the latest software directory with a command like:

setenv PATH /wv/lvs_rls/prod/tessent/ETCreate/bin:$PATH

etv <chip> -configFile <chip>.etManufacturing \
-wgl on -tcmFile <chip>_lvdb_preLayout/<chip>.tcm
Step 2.19 — Archive Files
o Instead of wgl, you can specify any one of:

-stil,-svf, -verilog, -vhdl, -tstl
o Pattern files are generated in the current directory
Note
Presently, SVF patterns cannot be generated for the jtagVerify tests because the
tests end in intermediate TAP states. This limitation will be fixed in a future
version of etVerify. So you will need to comment these tests out of the
<chip>.etManufacturing file.
Step 2.19 — Archive Files

Set your current directory to DFT

make archive_config
to produce a file DFT/<chip>_LVWS/<chip>.archiveList that lists all files to be
archived from the LVWS directory.
make archive
to save all the listed files into a file DFT/<chip>_LVWS.tar.gz
make archive_etp
to produce a file DFT/<chip>_etp.tar.gz that contains <chip>.etplan,and files from the
DFT/outDir directory (techlib.CADEnv, techlib.ETDefault, ...).\
• Ensure that you save copies of all files listed in “Primary control files that you create”.
Go to “Step 3: Prepare a Board to Characterize Your IC”.
Chapter 4
Step 3: Prepare a Board to Characterize
Your IC
ULTRA has three requirements for accurate measurements: clean power, clean clocking, and
clean JTAG. The following Steps will help you to design ATE loadboards and/or stand-alone
characterization boards that meet these requirements.
Step 3.0 — Clocking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Step 3.1 — Loopback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Step 3.2 — JTAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Step 3.3 — Board Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Step 3.4 — .pinmap File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Step 3: Prepare a Board to Characterize Your IC
Step 3.0 — Clocking
Step 3.0 — Clocking

Choose a board clocking scheme. Here are considerations:
ATE Clocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
SRS CG635 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
LMK03000 PLL Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Si550 VCXO Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Power Supply Decoupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
ATE Clocks
Typical ATE clocks have >5 ps rms jitter and are not suitable for most SerDes reference clock
inputs, nor for use as a sampling clock when testing PLLs. Also, most digital ATE does not
have fine enough frequency resolution to provide ~150 ppm offset frequency. To measure LF
jitter, coherent sampling is necessary, and even though mixed-signal ATE supports coherent
sampling it usually does not have sufficiently low jitter.
SRS CG635
You may use bench-top equipment to generate the clocks. SiliconInsight can directly control a
Stanford Research Systems Model CG635 clock generator via a USB-to-GPIB cable. This
equipment is capable of generating clock frequencies up to 2 GHz, with millihertz frequency
resolution, so it is well-suited to testing SerDes with SerdesTest.
Caution
This equipment is not recommended for measuring PLL LF jitter because its absolute
frequency accuracy for some frequencies (for which it interpolates between phase-locked
frequencies) is about 100 millihertz, which introduces too much LF jitter to be usable. Sharing a
common 10 MHz back panel reference clock helps, but not sufficiently.
LMK03000 PLL Family

To generate low-jitter reference clocks on the board, Tessent SiliconInsight software can
automatically generate programming for National Semiconductor's LMK03000 family of PLL
Clock Conditioners. These 48-pin devices have four or more, differential PECL outputs with
<0.5 ps rms jitter (12 kHz~20 MHz bandwidth) depending on the specific device used, the
choice of loop filter, and the choice of phase-frequency detector (PFD) frequency inside the
PLL. Choose the PLL whose VCO frequency can be an integer multiple of your IC's reference
frequency. For example, if your chip's reference frequency is 225 MHz, you must choose the
LMK03002 because there is no integer multiple of 225 within the VCO range of the other PLLs.
LMK03000 PLL Family
Siemens EDA can provide you with a Tcl routine or Excel spreadsheet that enables you to
explore the frequency possibilities.
LMK03000C: 1185~1296 MHz VCO; max. fOUT = 640 MHz
LMK04000: 1185~1296 MHz VCO; max. fOUT = 640 MHz
PLL loop filter

The external loop filter connected to the PLL's CPout pin should be 1.8 kohm in series with 12
nF to ground, as shown in Figure 4-1 on page 74, and the PLL's loop filter should be National's
recommended values for their PLL evaluation board (R3 = 100 ohms, C3 = 100 pF, R4 = 100
ohms, C4 = 110 pF), which is the default setting used by SiliconInsight. The objective is to
minimize low frequency (LF) jitter, not high frequency (HF) jitter. HF jitter is most important
for accurate jitter measurements and is easily achieved with this device, whereas LF jitter is
most important for delay measurements but is less easily achieved. SiliconInsight will
automatically choose the highest suitable PFD frequency to get the lowest LF jitter.
LMK03000 PLL Family
Figure 4-1. Example connections to two LMK03000 PLLs
Clock Signal Connections

Any number of PLLs can be controlled by SiliconInsight, but a maximum of four can be
controlled via the USB interface. The LMK03000 outputs are PECL that require DC loads to
ground, and 100 ohm (typically) termination to prevent reflections, and possibly AC-coupling
to the chip inputs to ensure the common mode voltage is suitable, as shown in Figure 4-1.
Refer to http://www.national.com/ds/LM/LMK04000B.pdf pages 43~45 for examples of how

to connect LVPECL and LVDS outputs to your IC, with proper terminations for DC or AC
coupling.
Si550 VCXO Family
Master Reference Clock

To operate the board away from ATE, the board must contain a crystal oscillator or external
clock input that connects to the DUT or to the PLLs. One convenient reference frequency for
the PLLs is 10 MHz because it is a standard used (and sometimes generated) by bench-top
measurement equipment, but any reference frequency up to 200 MHz is permitted by the
LMK03000 PLLs. The input to the PLL can be differential or single-ended (3.3 volt maximum
swing, AC-coupled). The two sides of a differential signal can drive two PLLs single-endedly
(as shown in Figure 4-1), or a differential clock buffer can be used (especially if splitting to
more than two signals). If you use one PLL instead of two PLLs, choosing a PLL input
frequency above 80 MHz may limit your choice of sampling resolution (e.g., >0.5 ps).
Si550 VCXO Family

To generate a low-jitter reference clock without needing to program a PLL, you can use a
voltage-controlled crystal oscillator (VCXO). This may be a simpler and cheaper alternative for
in-system use for one or two ASICs, compared to a PLL. Off-the-shelf 6-pin VCXOs cannot
achieve >50 ppm offset across all conditions, so they are unsuitable because SerdesTest
typically needs 150 ppm offset and PLL testing may require an even larger offset. The Silicon
Labs Si550 family of VCXOs can achieve up to 300 ppm offset and <0.5 ps rms, in a 6-pin
hybrid device, but they have only one (differential) output and its frequency must be
programmed by the manufacturer, with a turn-around of a couple weeks. The control voltage for
the offset-frequency reference VCXO can be generated by your DUT using two counters and a
PFD, and conveyed to the VCXO via one pin and an RC filter, as shown in Fig. 12 - this
circuitry comprises a simple phase-locked loop.
Power Supply Decoupling

The power supply for each PLL or VCXO should be very well isolated from the power supply
for the other PLL or VCXO, and from the DUT.
Caution
To minimize coupling between PLL or VCXO clock generators, they should be placed as
far apart as possible on the circuit board, and one 100 pF (0402 SMD) ceramic capacitor
should be connected between each and every VCC pin and ground, within 2 mm of each VCC
pin. Larger capacitors (e.g., >20 mF) to ground, and series inductors (e.g., 1 mH) should also be
used.
ULTRA can measure (and compare to test limits) the frequency offset and clock jitter within
each DUT in typically <20 ms (depending on required repeatability), prior to measuring SerDes
or PLL performance.
Step 3.1 — Loopback
Step 3.1 — Loopback

For SerDes testing, choose a serial data loopback scheme. A loopback path is the differential
path from each SerDes TX to a corresponding RX (which may be in another transceiver). Here
are considerations:
Path Length in Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
AC vs. DC Coupling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
DC Test Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Path Length in Application

The loopback path may be representative of the intended application, but it does not need to be
longer than is practical in a production loadboard. A loopback path that is very short (e.g., <5
cm) will decrease the impact of different pre-emphasis or equalization settings, which increases
the phase measurement accuracy and test time needed to distinguish between the settings. The
path length needed depends on the serial bit rate: higher bit rates can use shorter loopback paths.
Attenuation for FR4 is typically ~7 dB/meter at 1 GHz (2 Gb/s), but ~25 dB/meter at 5 GHz (10
Gb/s). Similarly, the phase shift for minimum vs. maximum transition density depends on bit
rate. At 6 Gb/s, a 100 cm loopback path in FR4 wire trace can cause >200 ps phase shift across
different transition densities and equalization settings, whereas a 10 cm loopback path may
cause <20 ps difference across those same equalization settings.
For production testing, use a path length that causes at least 20 ps variation between minimum
and maximum transition density word patterns, for at least one equalization setting. For a
characterization-only board (i.e., not for production testing), the loopback should be provided
via connectors to an external path to permit a variety of path types and lengths.
AC vs. DC Coupling
If the SerDes is intended for only AC-coupled paths (e.g., RX and TX have different common-
mode voltages, or 8B10B coding is used), then capacitors must be included in the loopback path
- these are typically 10 nF surface-mounted components. For AC-coupled paths, resistor DC
access should be provided for both the RX and TX sides of the loopback path. SerdesTest can
test AC-coupled and DC-coupled paths, but DC-coupling prevents measurement of signal-eye
amplitude at the RX because the DC offset that can be injected is typically limited to less than
100 mV.
DC Test Access
DC Test Access
Resistive access to each wire of the loopback path is very useful to:
• check for continuity (i.e., verify that the device pins are contacted before testing is
started);
• measure common mode voltages of the TX and RX;
• measure signal amplitude at the TX pins (by measuring average TX voltage for different
duty-cycle bit patterns or steady-state 0 or 1);
• measure DC input resistance at the RX and TX pins;
• measure slew rate and signal amplitude at the RX pins (by injecting different DC offsets
and measuring resultant change in phase or pulse-width);
• avoid the need for ATE DC-access relays in the loopback path, which add loadboard
space and signal jitter.
The access resistors must be surface mount (SM) components with one end placed directly on
the differential wire path, as shown in Figure 4-2, to eliminate (or minimize) wire stubs that
cause signal reflections and jitter. The other end of the resistors does not have any stub length
restrictions. This scheme contributes <0.5 ps rms jitter, even suitable for serial data rates above
10 Gb/s. Without resistor access, SerdesTest cannot measure signal amplitude but can measure
20% to 80% transition time by altering the data's bit-wise duty cycle and measuring the
resulting impact on received pulse width.
Figure 4-2. Example Loadboard Layout for Differential Loopback with AC-
Coupling Capacitors and DC-Access Resistors
DC Test Access
Note
Inductors should not be used instead of resistors: the best high-frequency inductors have
acceptable properties up to 2 Gb/s but unacceptable above that rate because their impedance
decreases as frequency increases beyond their 1~2 GHz resonant frequency.
The choice of resistance value for these resistors is determined as follows:
Recommended TX access resistance: 10 kohm (= 200 × 50 ohms), with 0.1% tolerance or less.
• Reduces signal amplitude by 0.5%; this can be compensated by adjusting the test limits.
• A larger resistance increases the time to measure average voltage without significantly
reducing the resistance's impact on the loopback path jitter.
• A smaller resistance does not significantly reduce test time, but adds more jitter.
Recommended RX access resistance: 1~5 kohm (= 20~100 × 50 ohms), with 0.1% tolerance or
less.
• Reduces signal amplitude by 5~1%, respectively; this can be compensated by adjusting

the test limits.
• To obtain, say, 100 mV offset with 2 kohm resistors, 4V must be applied relative to the
common mode voltage (typically 1 V); a larger resistance increases the DC voltage that
must be applied for a given DC offset, which might not be possible for some tester's DC
PMUs and might cause damage to the IC if applied at the wrong time (before power-up,
or before on-chip termination is enabled).
• A smaller resistance does not significantly increase offset voltage range, but adds more
jitter.
• A larger tolerance significantly affects measurement accuracy.
Some SerDes designs include circuitry to permit DC-offset injection directly into the RX
comparators, either within the RX differential comparators or via on-chip common mode
voltage adjustment. For SerdesTest to measure slew rate and received amplitude, on-chip DC-
injection capability is necessary when the SerDes has on-chip AC-coupling.
Step 3.2 — JTAG
Step 3.2 — JTAG

Provide suitable 1149.1 TAP (JTAG) access for SiliconInsight's USB-to-JTAG module. The
module's output signal levels are the voltages connected to its GND and VCC pins. Note that the
Signalyzer is capable of connecting to JTAG signals and to the LMK03000 microWire
interfaces to program the PLLs' frequencies. Here is information about the USB-JTAG module:
USB-Signalyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
USB-Signalyzer
The Signalyzer module's minimum output logic 1 depends on the specific model, and it can
connect to two or four groups of signals, with user-assigned positions, and each group with its
own VCC. Generally the latest Signalyzer modules support a voltage swing of 3V - 5V, but
level translator accessories are available to extend the range to 1.15-5.5V. Refer to the Xverve
website at the following URL for details about the modules:
http://www.signalyzer.com
Additionally, see the Tessent SiliconInsight User’s Manual for the LV Flow for details about
supported models.
• Ensure that a resistive divider is provided if your IC's voltage levels are <1.2 V.
• The DUT's TRST pin should be assigned to a connector pin, but it may be separately
connected to VDD if not needed (all patterns generated by SiliconInsight include
synchronous reset after a TRST reset). If your DUT uses two TAP controllers, in a
master and slave configuration, and TRST is used to revert back to the master TAP, then
you should use the Signalyzer instead of the Amontex so that the TRST can be activated
when needed.
• If the Signalyzer will be used to control the LMK03000 frequencies as well as the JTAG
interface, one connector should be provided for controlling the JTAG pins, connected to
the A slot of the Signalyzer, and one should be provided for controlling the PLLs,
connected to the B slot, so that the DUT's VDD can be different than the PLLs' VDD. In
“Step 4.5 — Set global clock periods” you will indicate to SiliconInsight which of the
Signalyzer pins you connected to the PLL microWire interface.
• Each connector should be a standard IDC 26-pin header, 2 x 13 pins with 100 mil
spacing, and signals and power assigned as shown in Figure 4-3.
• The module can drive only high-impedance inputs having pull-ups >2k ohms and pull-
downs >10k ohm.
• Note that all Signalyzer GND pins are a single node and could short circuit your board’s
power supply if connected incorrectly.
Step 3.3 — Board Components
For more details, see http://www.signalyzer.com/sh-series/signalyzer-shaxx (Signalyzer

SHA40).
Figure 4-3. SignalyzerH4 USB-JTAG connector, and pin-out
Caution
For the SignalyzerH4 adaptor, Pin 2 (VEXT) and Pin 26 (VEXT) are 5.0V DC supply pins
from the USB port of the computer. These pins, in contrast to older Signalyzer models, are
not for VREF input and could damage the Signalyzer device if you use them as such.
Another module that is supported is described at https://www.olimex.com/Products/ARM/

JTAG/ARM-USB-OCD-H/ (Olimex ARM-USB-OCD-H).
Step 3.3 — Board Components

In this Step, create a list of the circuit elements that go on the circuit board and include the
following:
• DUT socket
• USB-to-JTAG socket: a standard 26-pin, as shown in Figure 4-3.
• Primary reference clock PLL (LMK03000/04000 series) - optional if clock provided
from a crystal or external source.
• Offset reference clock PLL (LMK03000/04000 series), if you are not using clock
generation.
• Offset reference clock PLL (LMK03000/04000 series), if you are not using on-chip
generation for this clock.
Step 3.4 — .pinmap File
• 10 MHz crystal - optional if PLLs' input reference clock is provided from a crystal or
external source.
• USB-to-microWire socket: a standard 26-pin header as shown in Figure 4-3.

In the <chip>.lvdb/ directory, copy the <chip>.pinmap_tpl to <chip>.pinmap and edit it to
indicate which of the Signalyzer's pins are connected to the TAP pins. Here is an example in
which the A0 to A4 pins of the Signalyzer are connected to the TAP pins (for ATE-driven test,
many more DUT pins would be connected). The Signalyzer has two groups of pins indicated in
Figure 4-3 as Channel A and Channel B, and the pins must be indicated in the file as A0~A7
and B0~B7 respectively. A0 corresponds to pin 3; A1 to pin 4; A2 to pin 5; etc.
PinMap (<module>) {
Pins {
// <design pin name> : <ATE channel name> <Tester channel type>;
TCK : A0 ctl; // control (in) pin
TDI : A1 ctl;
TDO : A2 obs; // observation (out) pin
TMS : A3 ctl;
TRST : A4 ctl;
otherChipPin : -; // unconnected but in .etplan file
TXBCLK : -;// clock pin not driven by ATE
RXBCLK : -;// clock pin not driven by ATE
}
Chapter 5
Step 4: Prepare SiliconInsight to
Characterize Your IC

Step 4.0 — Accessing SiliconInsight. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Step 4.1 — Power up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Creating a complete set of tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Step 4.0 — Accessing SiliconInsight

To access SiliconInsight Desktop (in Linux), create a shell script like the one below. Other
parameters and files may be specified in the command line or selected within the GUI. You will
need to specify the path to the directory that contains the SiliconInsight software and licenses -
your system administrator may need to assist you.
• Include the ETAccess software directory that supports SerdesTest in your search path,
with a command like: setenv PATH <install_path>/current/ETAccess/bin:$PATH
• Set your current directory to finalLVDB, which contains <chip>.lvdb/
• Use command unsetenv TCLLIBPATH
• Create a script that calls SiliconInsight Desktop:
sid \
-lvdb ./<chip>.lvdb \
-configfile ./<chip>.lvdb/my.config_eta \
-cable signalyzerH4 \
-pinmapfile ./<chip>.pinmap \
-outdir ./outDir
The lvdb and config files are produced by the make lvdb_final command, described earlier in
“Step 2.15 — Generate final LVDB”.
The cable option allows you to specify that you are using a SignalyzerH4 connector (Amontec
is default).
The pinmap file was created manually by you, as described earlier in “Step 3.4 — .pinmap
File”.
The outdir directory is your choice of directory for all datalog files and error messages.
Step 4: Prepare SiliconInsight to Characterize Your IC
Step 4.1 — Power up
You may add -sim to allow you to load the SiliconInsight software in simulation mode, which is
useful for checking that SID software loads correctly, for checking that all required files are
accessible and are error-free, or for adding new tests without the Signalyzer connected. Without
the sim option, SiliconInsight will give an error message if the Signalyzer is not detected
(because it's not connected or the USB port has not been properly identified).
You may add -lvtpExtraArgs “-t 120” to increase the time that the software will look for a
license to 120 seconds, but only if your system takes longer than a minute to find the license.

Check all TAP connections to the USB-JTAG cable, check all power connections, and, for
SerDes testing, ensure that you have a serial loopback path connected between at least one
transmitter and one receiver.
If you are running SiliconInsight Desktop, and it is connected to your DUT's TAP, then turn on
the power, and then start SiliconInsight by executing the script you created in the previous step.
Caution
SiliconInsight Desktop (SID) will not start if power to the Amontec module is missing, so
you can't use SID to enable the power delivery. However, it will start without power for the
Signalyzer.
If you have connected a GPIB-controlled power supply, or are running on ATE, the GUI will
show a Power button (red when power is off, green when it is on). Under the Tools menu, you
will also see Power Setup..., and Shmoo... as additional options.
Turn on power by clicking on the Power button: no tests will run when the button is red. The red
Power button should become green.
After the LVDB, configuration file, and pinmap file have been selected, the GUI will look like
the one in Figure 5-1 the first time that you open it, with possibly only one Test Group, named
jtagVerify. This test step tests only the TAP controller and connections to it, but is very useful
for verifying connections between the PC's USB port and the IC's TAP pins. You can run this
test immediately, if your desktop computer is connected to your IC via a USB-to-JTAG
interface cable (see the section, “Running a Test”), or first create a suite of tests off-line.
Figure 5-1. Example default SiliconInsight GUI
Creating a complete set of tests
Creating a complete set of tests

This next section shows how to add tests in SiliconInsight, in the recommended order for
efficient diagnosis.
Step 4.2 — Add a Test Step. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Step 4.3 — Choose a Test Controller (ULTRA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Step 4.4 — Choose test type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Step 4.5 — Set global clock periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Step 4.6 — Program loadboard PLL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Step 4.7 — Set clock periods for single Test Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Step 4.8 — Add Test Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Step 4.9 — Measure reference frequency offset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Choose Test Controller (ULTRA) options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Step 4.10 — Measure reference clock jitter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
JitterFromCDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Step 4.2 — Add a Test Step

A Test Group is a graphical convenience to group test steps together. A Test Step indicates what
test type is to be performed, the test's parameters, options, userDRBit settings, and initialization
patterns.
• Right click on the jtagVerify test group G icon, and then click Options.
• Type in a new Group Name of your choice (or preferably leave it as jtagVerify). The
new name must obey the naming rules and be unique among all Test Group names for
the device.
• Click on OK (or Cancel if you don't want to save the changes).
• Right click on the jtagVerify test group G icon, and then click on Add Steps.
• In the Add Steps pop-up window, click on the checkbox to left of Plugin Step.
• Click on OK. This will append a new test step, with default name “S0”.
Step 4.3 — Choose a Test Controller (ULTRA)

For each test, you must choose which ULTRA block(s) will be the Test Controllers for the test.
• Right click on the new test step: S0
Step 4.4 — Choose test type
• Click on Add Controller

• Click on one, or multiple controllers by holding down the Shift or Ctrl key while
clicking. If you have a ULTRA controllers for SerDes and for PLLs, then you must
select controllers for only one type in a test step.
• Click on OK.
• Right click on the Test Step, and replace S0 (or S1, S2, etc.) with the Test Step name of
your choice (use 'ultraBlock' for this example). The new name must obey the naming
rules and be unique among all Test Step names for the device.
Caution
If you change the Step Name, then you must click on Apply before changing any
other Test Step options (for example, Test or Pattern). Similarly, if you change a
Test Step option (including Edit as a Group), then you must click on Apply before
changing the Step name. Otherwise you may see a simple error message (click on its
OK), or the sub-menu may freeze with OK/Apply/Cancel greyed-out (click on File/Save
from main menu, then click on Yes to save your changes to configuration, then Exit,
then enter "pkill eta" to close the sub-menu).
• Click on OK.
Step 4.4 — Choose test type

For each test step, you must choose one from a list of test types to be performed.
• Right click on the new test step: S0 ('ultraBlock' for example).

• Click on Options. A new GUI window opens like the one in Figure 5-2.
• To test the ULTRA logic, click on the pull-down menu beside SerDes Test, and then
click on BasicTests in that menu. This test only verifies that data can be shifted into and
out of each ULTRA block, so you don't need to select any other options in the
Embedded SerDes Test Step Options window. (More complex test types will be
described later.)
Step 4.5 — Set global clock periods
Figure 5-2. Example test type selection within a Test Step

Async Clock Periods are the periods of clock generators that run independently of the ATE,
such as crystal oscillators.
A special type of Test Group can be created that sets the two asynchronous clock periods for all
Test Steps. It is possible to set the clock period within each Test Step, but the setting for
asynchronous clock periods will be overridden whenever this special Test Group is executed.
• Right click on the first test group (jtagVerify) or on the top-level chip icon.
• Click on Add Test Group
• Right click on the new test group, select Options, and enter a Group Name such as,
“SetClockPeriods”
• Click on the checkbox to right of Execute With Tcl Script.
• Enter this specific Script Name: LMK_Group.tcl
• Click on OK
Note
If you Execute this Test Group before adding any Test Steps to the Group, then it
will output documentation for this type of test step, similar to the following:
• Right click on the new Test Group's icon, and click on Add Steps...
• Click on the checkbox beside ATE Step, then click on OK
• Right click on the new Test Step, then click on Options
• In the ATE Step Options window, enter a new Name value (instead of the default S0)
and enter an Operation value of DefineVariables
• For each parameter in the following list, click on Add Parameter, and enter the
parameter Name (case sensitive) and then a value in the adjacent field. Do this for at
least the first three parameters listed below to assign a clock period to a pin, and at least
the first eight parameters if you plan to program an LMK0xxxx PLL to generate a clock,
then click on OK. One PLL can drive multiple pins at synchronously related
frequencies, but not both the reference clock and the undersampling clock.
OnlySetAsyncClocks — set value to 0 if an LMK PLL will be programmed and to set clock
periods for all Test Steps, or set to 1 if none is to be programmed but you still want to set clock
periods for all Test Steps.
OutputClockPeriod — Target output period for the LMK PLL. Specify a value in ns (without
'ns' suffix).
AsyncClockPins — List the chip's pins that are used as asynchronous clocks. You may list any
number of pins, each separated by a space.
CLKout_EN — Select outputs of the LMK that are to be enabled, from CLKout0_EN to
CLKout7_EN. You can enter more than one of these lines to enable more than one output.
modelNo — LMK0xxxx (3000 is default), where xxxx is one of 3000, 3001, 3002, 3033, 4000,
4001, 4002, 4010, 4011, 4031, or 4033.
OSCin_FREQ — Input frequency to the LMK device, in MHz.
Pins_CDE — A list to specify Clock, Data, and Enable pins of the device used to load the
LMK. Defaults to 'B0 B1 B2' for Clock, Data, and Enable pins, respectively.
ERROR_max_fs — Maximum acceptable error on OutputClockPeriod, in fs (defaults to 100).
The following four parameters can directly set the PLL’s dividers, unless OutputClockPeriod
is greater than 0 (in which case, these four parameter values will be ignored).
PLL_R — Main PLL input divider
VCO_DIV — Main PLL VCO output divider
PLL_N — Main PLL feedback divider
CLKoutX_DIV — Post divider (from output of VCO divider), applied to all outputs.
Table 5-1 below lists all supported parameters, their default values, and their range of allowed
values. Please refer to the device’s datasheet for a detailed description of each parameter.
Table 5-1. LMK030xx and LMK040xx Parameters, Default Values, and Ranges
LMK030xx LMK040xx
Parameter name Default Range Default Range Notes
OSCin_FREQ 10 [1..200] 100 [1..250] (1)
CLKoutX_DIV 2 [1,2,4,6..510] 2 [1,2,4,6..510] (3)
CLKout_DIV 2 [1,2,4,6..510] 2 [1,2,4,6..510] (3)
CLKout_DLY 0 [0,150,300..2250] 0 [0,150,300..2250] (6)
CLKout_EN 0 [0,1] 0 [0,1]
EN_CLKout_Global 1 [0,1] 1 [0,1]
EN_Fout 0 [0,1] 0 [0,1]
PLL_CP_GAIN 3 [0..3] 2 [0..3] (2)
PLL_MUX 0 [0..11] 0 [0..24] (5)
PLL_N 760 [1..262143] 4 [1..262143] (1)(2)
PLL_R 10 [1..4095] 1 [1..4095] (1)(2)
POWERDOWN 0 [0,1] 0 [0,1]
Vboost 0 [0,1] (n/a)
VCO_C3_C4_LF 10 [0..11] 10 [0..11] (2)(4)
VCO_DIV 2 [2,3,4..8] 5 [2,3,4..8] (1)(2)
VCO_R3_LF 0 [0..4] 0 [0..4] (2)(4)
VCO_R4_LF 0 [0..4] 0 [0..4] (2)(4)
CLKin_SEL (n/a) 0 [0..3]
CLKin0_BUFTYPE (n/a) 1 [0,1]
CLKin1_BUFTYPE (n/a) 1 [0,1]
CLKout_PECL_LVL (n/a) 0 [0,1]
CLKoutXA_STATE (n/a) 1 [0..3] (7)
CLKoutXB_STATE (n/a) 0 [0..3] (7)
Table 5-1. LMK030xx and LMK040xx Parameters, Default Values, and Ranges (cont.)
LMK030xx LMK040xx
Parameter name Default Range Default Range Notes
EN_PLL_REF2X (n/a) 0 [0,1] (2)
EN_PLL_XTAL (n/a) 0 [0,1] (2)
LOS_TYPE (n/a) 3 [1..3]
LOS_TIMEOUT (n/a) 1 [0..3]
PLL_CP_TRISTATE (n/a) 0 [0,1] (2)
PLL1_CP_GAIN (n/a) 6 [2..7]
PLL1_CP_POL (n/a) 1 [0,1]
PLL1_CP_TRISTATE (n/a) 0 [0,1]
PLL1_N (n/a) 4 [1..4095]
PLL1_R (n/a) 1 [1..4095]
RC_DLD1_Start (n/a) 0 [0,1] (8)
Table 5-1 Notes:
(n/a) — Not available for this device.
(1) — LMK040xx datasheet has a different default value. With the default values above, 100
MHz in produces 100 MHz out.
(2) — In the LMK04000 family, which has two PLLs, this parameter applies to the main PLL
(“PLL2”).
(3) — CLKoutX_DIV is the default value to be applied to each CLKout_DIV, where is
in the range of outputs supported by the device. Any CLKout_DIV will override the value of
CLKoutX_DIV. If the value is 1, the divider is bypassed.
(4) — A default value is not specified in the LMK040xx family, so the same default is used as
for the LMK030xx family.
(5) — For this parameter on LMK040xx, the “reserved” values cause an error: 8 10 12 13 16 17
18 19 21.
(6) — Delay is directly set in ps and must be a multiple of 150. When delay is set to 0, the delay
path is bypassed.
(7) — For the LMK040xx family, CLKoutXA_STATE and CLKoutXB_STATE apply only to
outputs 1, 2 and 3.
Step 4.6 — Program loadboard PLL
(8) — The default value is different than the spec sheet so that the auxiliary PLL (“PLL1”) is
not used.
To use an ATE Step as only a convenient way to set asynchronous clocks for all Test Steps,
without programming a PLL, you must define at least the following parameters:
OnlySetAsyncClocks — Set value to 1.
OutputClockPeriod — Set to value of the clock period (in ns).
AsyncClockPins — Set to list of clock pins affected.
• You may add a Test Step for each asynchronous clock connected to your chip for
SerdesTest or PLLTest, whether it comes from a crystal or LMK0xxxx.
If you have connected a GPIB-controlled clock generator, or are running on ATE, under the
Tools menu, you will see Clock Setup..., and Shmoo... as additional options.
Step 4.6 — Program loadboard PLL

Programming a LMK0xxxx PLL
In the following example, the independent reference frequency (from a crystal) is 156.25 MHz
with a 6.4 ns period, and the PLL is set to 6.4011 (ns) so that the basic sampling resolution,
which is always the difference between the two clock periods connected to ports, will be 1.1 ps,
assuming these two clocks are used as the parallel rate clocks (or PLL reference and sampling
clocks). If these frequencies are multiplied by N within the DUT (by another PLL), then the
resolution will be finer by a factor of N.
The example GUI window one the left side of Figure 5-3 is for a crystal or external input. It
shows two parameters, to let Tessent SiliconInsight automatically set for all test steps that use
that AsyncClockPins value. By setting OnlySetAsyncClocks to '1', SiliconInsight will not
attempt to program any PLL; it will only set the clock period in all test steps.
In the GUI window example on the right side of Figure 5-3, the input reference clock to the
PLL, OSCin_FREQ, is set to 39.0625 (MHz, and chosen to be equal to the crystal frequency
divided by 4). The LMK03000 and LMK03001 each have 8 differential outputs, labeled
CLKouti_EN, where i can be any digit from 0 to 7. The LMK03002 only has 4 outputs,
numbered 4 to 7. You can enter more than one of these parameters to enable more than one
output. ERROR_max_fs is the error in the period, in femtoseconds, that you will permit to
allow the algorithmic calculation to find an acceptable value. Sometimes, entering a larger value
of ERROR_max_fs will enable SiliconInsight to generate a clock period close enough to your
target value, and sometimes, entering a smaller value will help.
The B0, B1, and B2 pins of the Signalyzer are assumed to be connected to the microWire
interface Clock, Data, and latchEnable pins respectively. If you have chosen another pin
Step 4.7 — Set clock periods for single Test Steps
assignment, create a Pins_CDE parameter and then enter the Signalyzer pin names in the
corresponding order, e.g., B3 B2 B7.
When you click on this new Test Group's icon, then on the Execute icon, the PLL will be
programmed and Async clock periods in all Test Steps that have clocks with the same
AsyncClockPins names will be set to those values; the Console will indicate which Test Step's
values were changed (if any). Also, SVF patterns to program the LMK03000 are automatically
created (if OnlySetAsyncClocks=0) in the outDir directory, with filename <testStepName>.svf.
Figure 5-3. Setting clock periods that will be applied to all test steps, for
independent clock (left), an LMK03000 (middle), and for LMK04033 (right)
Step 4.7 — Set clock periods for single Test Steps

The ATE Vector Period is the ATE's reference clock period to which data patterns are
synchronized, including the TAP clock and data.
• If the displayed value is not what you want, click on ATE Vector Period and enter a new
value. This will be equal to the TCK period if the DUT's reference clock is derived from
an oscillator or PLL on the loadboard as is recommended for low-jitter testing (in which
case, the reference clock and TCK are asynchronous).
Step 4.8 — Add Test Group
• If this clock period is not the TCK period, then also select the TCK Ratio, which is the
ratio of TCK period to vector clock period.
• Click on OK, to apply the settings and exit the clock period window.
You can set Async Clock Periods for individual Test Steps (it is the period of a clock generator
that runs independently of the ATE).
• Click on Async Clock Periods and enter the reference clock periods.
• Click on OK. to apply the settings and exit the Async Clock Periods window.
• Click on OK to apply and exit the Test Step Options.
Caution
You should always use the procedure in “Step 4.5 — Set global clock periods” on
page 88 to set the Async Clock Period values, especially when the asynchronous
clocks are the two reference clocks coming from off-chip PLLs. This ensures that all
Test Steps use the same clock periods. Only set Async Clock Period for individual Test
Steps when you intend it to be different than other Test Steps; you will need to change
that Test Step's clock periods after every time you run the top-level clock period setting
function.
Caution
In some operating systems, if a sub-window opens where your cursor is located, you will
not be able to enter values - simply move the cursor out of the window and back in. And
sometimes sub-menus open in the top left corner and behind the main menu, so you may need to
move the main menu to the right to see it.
Step 4.8 — Add Test Group

Now that you have a “jtagVerify” Test Group that tests for opens, stuck-at, and setup/hold faults
in the TAP controller and ULTRA blocks, you can add tests that perform measurements using
the procedure described previously.
The first test steps should measure the quality of the reference clocks, so they should be grouped
in a new Test Group.
• Right click on the top-level chip icon.

• Click on Add Test Group to append a new Test Group.
• Right click on the new Test Group, select Options, and change the default Group Name
to something like, “ReferenceClocks”
• Click on OK.
Step 4.9 — Measure reference frequency offset

This typically first test measures the frequency offset between TX and RX word clocks (if
testing a PLL, these are the PLL reference clock and undersampling clock, respectively). Sign
and magnitude are measured in Diagnosis mode, but only magnitude is measured in Execute
(pass/fail) mode, therefore both test limits should be positive numbers. Magnitude measurement
does not involve the SerDes or PLL, but sign measurement does and thus requires a serial
loopback path for a SerDes. You don't need to choose a pattern for this test because, for a
SerDes, it is always PHalfWord in Execute mode and PHalfOne in Diagnosis mode,
regardless of user choice.
• In the “ReferenceClocks” Test Group, add a Test Step with at least one ULTRA
controller, and name the Test Step something like “FrequencyOffset”.
• Right click on the “ReferenceClocks” Test Group G icon, and then click on Add Steps.
• In the Add Steps pop-up window, click on the checkbox to left of Plugin Step.
• Click on OK. This will append a new test step, with default name “S0”.
• Right click on the new Test Step and select Options to get the Test Step Options window
of Figure 5-3 on page 93.
• Change the default name to something like “FrequencyOffset”.
• Click on the pull-down menu beside SerDes Test or PLL Test, and choose
OffsetFrequency to measure the frequency offset between the TX and RX parallel word
clocks (PLL reference clock and undersampling clock, respectively).
If necessary, set additional parameters.
Pause Time
Enter a value if you want a test sequence to pause just before a Test Step is run, for a time
interval that is independent of the clock period, e.g., to allow an tester's DC PMU to settle. This
should not be used for lock time because there is a separate LockTime parameter (in the .etplan
file that you created) and its delay will be automatically inserted after the BIST controller is
loaded (and SerDes TX pattern applied), just before measuring begins. You may use any time
units - the default is ms.
Initial Wait Cycles

(an alternative to Pause Time) - Enter a value if you want a test sequence to pause just before a
Test Step is run, for a time interval that is a specific number of TCK cycles - the actual time will
depend on the period set for TCK. This parameter has the same effect as Pause Time, but in
units of TCK periods - if both parameters are specified, only the Pause Time value will take
effect.

If you added a User-Defined Sequence in “Step 2.5 — Prepare for simulation”, then the Test
Step options panel shown in Figure 5-2 will have an additional area (see Figure 7-4 for an
example) that shows files for you to optionally select. You will be able to select whether the
sequence is applied Pre TAP Reset or Post TAP Reset. If the sequence was supplied in an SVF
file and is applied Pre TAP Reset, then the normal TAP reset will be skipped (to avoid
canceling the effects of the SVF pattern).
Pin Settings
Click on Pin Settings to drive steady-state logic values into the selected pins during the test, but
only if the pins are connected to the ATE or Signalyzer.
User Bits
Click on User Bits to set individual bit values in the TAP registers.
• IR bits - you should typically leave this as 0.

• IR Aliases - you should typically leave this blank
• DR Bits and DR Aliases:
• If you have bit aliases (functional names for bits within the User Bit register), defined in
your <CHIP>.etassemble file, you can click on single-bit aliases to set it to 1, or for
multi-bit aliases you can enter the bit values in RTL format.
• Do not click on the check boxes to set individual DR Bits--this might lock the sub-menu.
For this reason, “Step 2.2 — Specify TAP” specified that you should provide aliases for
all UserDRBits in your .etassemble file.
Caution
In some cases a logic 0 might enable (turn on) a function, depending on how you
have connected that User Bit.
• Show User Bits From TAP/WTAP - TAP refers to the 1149.1 TAP controller (if you
have a Master/Slave arrangement, then only one is active in SiliconInsight - the Slave
must be selected by a User-Defined Sequence). WTAP refers to the Wrapper TAP
connected to the selected SerdesTest (or PLLTest). If no user bits have been defined for
the TAP or WTAP, then it cannot be selected.
• After entering all the applicable values and settings in the User Bits window, click on
OK (or Cancel).
When you finish the preceding settings in the Test Step Options window,
Choose Test Controller (ULTRA) options
• Click on OK, then run the test by clicking on the Diagnose icon.

A Test Controller refers to an ULTRA module. JTAG instructions cause each ULTRA module
to initiate each test, select its sampled data source, analyze the sampled data, optionally after
further undersampling (e.g., only using every Nth sample so that a wider range of jitter can be
measured), and compare the measured value to test limits.
• Right click on one of the Test Controllers, e.g., BP0, then click on Options.
Alternatively, right click on one of the Test Steps, and in the pop-up menu, click on Edit
as a Group. This allows you to simultaneously edit the Test Controller options for all
controllers within a Test Step.
Caution
If any of the sub-menu settings are opened, such as the Channel Select or Under
Sampling Clock Ratio, then the values in these sub-menus will be applied to all Test
Controllers.
A new GUI window will open like the one in Figure 5-4. The window content will depend on
the chosen test type - the window shown here is for Frequency Offset.
Figure 5-4. Example test controller options
The following Test Controller Options are also applicable to other test types:
Test Duration in Beat Cycles

A “beat cycle” is one cycle of the aliased output signal (a greatly time-expanded version of the
signal that was sampled) from the receiver and contains one rising edge region and one falling
edge region (a region might have jitter and hence multiple edges). Testing more beat cycles
increases the test time but improves the test's repeatability.
The beat cycle period for a 11001100 pattern (or 2X frequency output for a PLL under test) is
twice as long as the beat period for a 1010 pattern (or 4X frequency output for a PLL under
test), unless you are measuring a delay, in which case only the reference beat period is relevant.
The “reference beat period” is equal to the reciprocal of the frequency offset between the TX
and RX parallel-rate reference frequencies (or PLL reference and undersampling clocks,
respectively).
Channel Select, or PLL to Test

Select a SerDes channel (or lane) or a PLL to be tested from those connected to that particular
ULTRA controller. For example, if channels 27 and 28 of a large chip are connected to this
ULTRA (as specified by the .etplan file), then channel 27 might be Channel 0 for that ULTRA
and channel 28 might be Channel 1.
Measurement Limits
Provide values for Measurement Lower / Upper Limit if you want a meaningful pass/fail test
result. The units will automatically be appropriate for the Test Type chosen for this Test Step:
kHz for offset frequency; ps for jitter and TDDD; % for duty cycle distortion; bit errors for
FunctionalLoopback (when Sanity Check is off). The value may be positive or zero, or (for
some delay tests) negative. A test will pass if the measured result is exactly equal to a Limit, or
between the Lower and Upper Limits.
Note
After running a Test Step, its icon becomes: Green if the Test Step was Executed and the
measurement was with test limits, or test limits were not applicable; Yellow if the Test Step
was Diagnosed and the test ran to completion, regardless of measured value; Red if the test
failed to complete (DoneStatus fails meaning Done bit = 0, or any other reason) or the
measurement was not within test limits, regardless of whether it was run in Execute or Diagnose
mode. The output text in the console window of SiliconInsight will indicate the reason for
failure.
Caution
During Execute mode, the frequency offset magnitude is estimated based on a phase delay
measurement (1 bit for a SerDes; one half cycle for a PLL), so it is not as accurate as in
Measurement mode. In production tests, only use the frequency offset test as a sanity check of
the clocks, with limits looser than +/-5% of nominal offset. In a future release, this test will be
made as accurate as in Measurement mode.
Test Time Multiplier

If the reference clock period, transmitted bit pattern, or word width are different in the hardware
than the values set for the test step in software (for example, if the serial data arrives from
another device), the Test Time Multiplier (TTM) can be changed so that a test result is expected
later (larger TTM) or sooner (smaller TTM, to save test time) than the time automatically
calculated.
Note
Each test runs until the required number of beat cycles has been analyzed, and then the
results are held within ULTRA logic on-chip until an instruction is received via the JTAG
port to shift the results out - no indication is transmitted out of the chip to indicate that the test is
complete, so a test pattern simply waits the expected number of TCK clock period and then
sends in the shift instruction. It is this wait time that is adjusted using the Test Time Multiplier.
The wait time with TTM=1 is 10% longer than the calculated theoretical wait time, to allow for
some indeterminacy.
Under Sampling Clock Ratio

If necessary, select a non-unity value for Under Sampling Clock Ratio (USCR). A value greater
than 1 is useful in the following cases:
• The peak-to-peak jitter value is larger than the sampling resolution multiplied by the
number of histogram bins (default value is 32 bins). A larger USCR value will increase
the jitter amplitude for which the entire histogram can be captured in 32 bins, which
improves the accuracy of the RMS calculation.
• There is significant synchronous noise at some integer multiple of the parallel clock
period, so it must be cancelled. Choosing a USCR value of 4 will effectively cancel any
noise at one quarter of the parallel-rate clock frequency.
• The sampling clock frequency is approximately 2~8 times higher than the sampled.
Choosing a USCR value of 6 will permit the sampling clock (e.g., Recovered clock) to
be 3 or 6 times higher than the sampled clock (e.g., RX reference clock).
Step 4.10 — Measure reference clock jitter
Caution
The time interval between consecutive jitter-free edges of the data signal must be
larger than twice the size of the sampling register (typically equal to the number of
histogram bins, which is 32 by default) multiplied by the sampling resolution (typically
equal to the difference between the two parallel-rate reference clock periods) multiplied
by the USCR. To allow for the maximum measurable peak-to-peak jitter, this time
interval between consecutive edges must be increased by 25%. If you set the USCR too
large for the pattern being tested, you will cause an error to be reported in the GUI
(“Error: For the test to work, the beat period must be greater than …”) because there will
be too few same-value samples between edges of the sampled signal for the edge
detection algorithm to detect the end of an edge region. In other words, the algorithm
cannot tell whether a rising edge that occurs too few samples after a falling edge is
outlier jitter from the preceding falling edge or from the next rising edge. If you get this
error message, then try reducing the USCR value, or choosing a test pattern that has
more bit intervals between the signal edges, e.g., try P1100 instead of P1010 (if testing a
PLL, try setting the PLL output frequency lower).
Measurement Edge
There are two choices: RISE or FALL. When measuring jitter for a clock or any clock-like data
pattern, the measurement results may be different for each edge due to differences in slew rate,
crosstalk (on-chip or off-chip), or inter-symbol interference (ISI). For frequency offset and most
other tests, use the default value (RISE) unless you are diagnosing whether there is interference
on only one edge, as can occur when on-chip switching is predominantly active after, say, the
rising edge.
Lock Time Pause

The lock time pause is applied after the BIST controller is loaded (and pattern applied to SerDes
TX), immediately before measuring begins (the actual pause applied accounts for the time to
shift in the pattern fragment that starts the measuring). If the value entered is 0ns (default), the
test will pause for the duration specified for LockTime in your <chip>.etplan file. You may
enter a different value for a test if, for example, a longer than normal lock time is needed due to
test conditions, a shorter than normal pause can be used to save test time when there is no
change in PLL/SerDes setting, or to diagnose lock time problems. Any time units may be used
(ns is default).
Step 4.10 — Measure reference clock jitter

Reference Clock Jitter
This test measures jitter in the on-chip reference clocks, independent of the SerDes or PLL
under test.
JitterFromCDF
• Within the “ReferenceClocks” Test Group, add another Test Step with at least one
ULTRA controller, and name the Test Step something like “ReferenceClockJitter”.
• Right click on the new Test Step and select Options to get the Test Step Options window
of Figure 5-2 on page 88.
• Click on the pull-down menu beside SerDes Test or PLL Test, and choose
JitterFromCDF to capture the jitter histogram, or Jitter to simply measure its RMS value
(assuming it is Gaussian).
• Click on OK, then right-click on one of the Test Controllers, and click on Options.
• Click on the pull-down menu beside Signal To Measure, and choose pllInputClk if it
is a PLL or TransmitterClock if it is a SerDes (the Data Bit Number will be ignored).
JitterFromCDF
ULTRA captures the CDF (cumulative distribution function, or cumulative histogram), and
outputs 32 bin-values of 12 bits each (by default - you can change this with the
CDFNumberOfBins parameter in the .etplan file). The differences between the CDF bins are
equal to the bin values of the histogram.
Note
If you would like nicer jitter histogram plots, suitable for reports, Create a file named
.lv_eta.config in your current directory, that has the following two lines (the first line is a
comment): # Create jitter histogram gnu plot files configure PDFPlotEnable 1 Formatted plot
files will be placed in the outdir directory.
Caution
For this test, no measurement limits are applied within the GUI - this must be done in a test
program, e.g., for the range or RMS value. For small ranges (fewer than 16 bins), the center
bin may be artificially high because the BIST algorithm uses a median-based algorithm instead
of the mean-based algorithm used for a true RMS calculation. Most SerDes clock-data-recovery
(CDR) circuits use a median-based eye-centering algorithm, so the BIST algorithm may be
more representative of their true performance.
Jitter
ULTRA estimates RMS value on-chip by finding the 25% and 75% points on the CDF and
compares to limits derived from an ideal Gaussian CDF. This test is best for production testing
because the ATE need only monitor the shifted-out pass/fail bits, however, the measured value
may be significantly less than the value calculated for a shifted-out CDF if the true RMS value
is very small (less than twice the sampling resolution).
Jitter
When testing SerDes reference clocks, the transmitted/received data pattern is not important
except to provide SerDes activity, and when testing PLLs it is not meaningful at all. Beside
Pattern, click on the pull-down menu and select P1010. This causes a 1010 serial data pattern to
be transmitted/received and will cause the least parallel-data-related noise on-chip, so that you
will measure primarily jitter in the reference clocks caused by the clock generation and the
clock paths. You can try other patterns to see their effect on the measurement result.
• Right click on one of the Test Controllers and then click on Options, or right click on
one of the Test Steps, and in the pop-up menu, click on Edit as a Group.
• Click on Signal To Measure and select Transmitter. This measures jitter in the
transmitter's parallel-rate clock (reference clock), as sampled in the core logic (RPA
block) by the RX reference clock (undersampling clock).
Caution
Any clock jitter test uses one clock to sample another clock, therefore, the measured
jitter histogram is actually the sum of jitter in each of the two signals involved, and
the measured RMS jitter is the RMS sum of jitter in the two signals, i.e., Jrms2 = J1rms2
+ J2rms2. For example, if the Signal To Measure is Transmitter, then the RX reference
clock (undersampling clock) samples the TX reference clock (reference clock), and the
result is the sum of the jitter in both clocks.
When testing SerDes, if your RX reference clock (undersampling clock) frequency is
not equal to the RX parallel rate frequency, SerdesTest does not presently account for
this, so you must scale the measured result appropriately. If RX reference clock is N
times lower than parallel rate, then measured values for jitter and mean sampling instant
must be multiplied by N to get the correct value. Only these two tests are affected.
Chapter 6
Step 5: Characterize your SerDes

Use SiliconInsight to Characterize Your SerDes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Use SiliconInsight to Characterize Your

SerDes
At this stage, if you have implemented all of the preceding instructions, you have added Test
Steps that test the entire JTAG and SerdesTest infrastructure, and these tests will typically take
less than 25 ms to run in a production test program. Next, tests for the SerDes will be described,
in the following order, which is recommended for easiest diagnosis:
Transmitter
• Clock input/output signal quality

o Measure non-deterministic jitter histograms
o Clock-like bit pattern - this corresponds to Random Jitter (RJ).
o Pseudo-random bit pattern - this corresponds to Total Jitter (TJ).
• Measure some deterministic jitter contributors
o Duty Cycle Distortion (DCD)
o Transition Density Dependent Delay (TDDD) vs. pre-emphasis setting.
• Measure waveshape
o Slew rate
o 20%~80% Transition time
• Measure voltages
o Common mode voltage
o Output logic levels
• Measure resistances
o Input/output resistance
Receiver
Step 5.0 — Optimize frequency offset
• Measure receiver tolerance contributors

o TDDD vs. equalization setting
o Mean Sampling Instant (MSI)
o Multi-Phase Sampling Error (MSPE)
o Jitter in the recovered clock.
Transmitter/Receiver
• Measure Bit Error Rate (BER) for a pseudo-random bit sequence (PRBS).
• Detect bit errors in a PRBS.
Step 5.0 — Optimize frequency offset

The sampling clock's frequency offset relative to sampled signal's frequency is very important.
It determines the basic sampling resolution (the minimum histogram bin width), in picoseconds,
and the low-frequency cut-off for measuring HF jitter. A higher frequency offset will result in
coarser sampling, and rejection of more LF jitter.
The choice of frequency offset is not arbitrary. The cut-off frequency, or golden-PLL loop-filter
corner frequency must be approximately equal to the serial data rate divided by 1667 or 2500
(the divisor depends on the SerDes standard). Using a frequency offset that is much too small
will include more LF jitter than necessary and may report a larger jitter value than is relevant
(and increase test time), considering that a SerDes receiver will track LF jitter. Using a
frequency offset that is much too large will exclude more HF jitter and hence report a jitter
value that is too small.
The frequency offset is defined as the difference between the TX parallel clock rate and RX
parallel clock rate, while the RX is in lock-to-reference mode. It is calculated as follows:
fOFFSET = 0.1 ? ? ? fPARALLEL / StdDivisor
For an example SerDes with 156.25 MHz parallel clock rate:
fOFFSET = 0.314 ? 156.25 ? 106 / 1667 = 29.4 kHz, or 188 ppm of the parallel clock rate.
or
fOFFSET = 0.314 ? 156.25 ? 106 / 2500 = 19.6 kHz, or 125 ppm of the parallel clock rate.
Any value between 75% and 100% of these values usually produces a measurement that
correlates with external equipment using a “golden PLL” to generate a recovered clock. The
default rate used for SerdesTest simulation test benches is 150 ppm.
Implementing SerDes Transmitter Tests
If the parallel clocks are generated by on-chip PLLs using an off-chip reference clocks, the ppm
offset is the same.
Implementing SerDes Transmitter Tests

Create a new Test Group, and named something like “TX”.
• Right click on the top-level chip icon.

• Click on Add Test Group to append a new test group.
• Right click on the new test group, select Options, and change the default Group Name to
something like, “TX”
Step 5.1 — Measure RJ

This test measures the total, high-frequency jitter (excluding DCD) in a received, clock-like bit
sequence signal.
• Create a new Test Group, and name it something like “TX” or “Transmitter”.
• In the “ReferenceClocks” Test Group, click on the Test Step named
“ReferenceClockJitter”, then press Ctrl C (Control key and 'C' key simultaneously, to
copy), then click on the “TX” Test Group and press Ctrl V (to paste). The Test Step will
be copied, with a new name equal to the old one appended with “__1”.
• Rename the Test Step to something like “RJ” or “RandomJitter”.
• Right click on the new Test Step and select Options to get the Test Step Options
window.
• Click on the pull-down menu beside SerDes Test, and choose JitterFromCDF (if it is not
already selected), or Jitter to measure its RMS value.
• Beside Pattern, click on the pull-down menu and select P1010 (if it is not already
selected) or any other clock-like bit pattern (e.g., P1100, PHalfOne, or PHalfWord).
Note
The results for this test may be affected by the transmitter's amplitude setting for
long loopback paths because lower amplitude signals have a lower slew rate which
makes them more sensitive to voltage noise. The results may also be affected by the
reference frequency offset because the measurement's low frequency cut-off is linearly
dependent on the frequency offset (as required to emulate a golden PLL response).
• Right click on one of the Test Controllers and select Options (or right click on one of
the Test Steps, and in the pop-up menu click on Edit as a Group).
Data Bit Number
• Click on Signal To Measure, and select DataBit. This measures jitter as sampled in the
receiver by the high-speed recovered clock in lock-to-reference mode. You can select a
Data Bit Number different than the default 0, but there is no need.
Data Bit Number

By default, all tests are performed on RXData[0] of the RX parallel output, but for many tests,
any output bit can be chosen. For a defect-free chip and no jitter, the results will be identical for
any output bit of a SerDes.
Step 5.2 — Measure TJ

This test measures the total, high-frequency jitter (excluding DCD) in a received, special
pseudo-random bit sequence signal.
In the “TX” Test Group, copy the “RJ” Test Step, paste it into the same Test Group, and rename
it something like “TJrms” or “TotalJitter”.
window. Click on the pull-down menu beside SerDes Test, and choose JitterFromCDF
(if it is not already selected), or Jitter to measure its RMS value.
• Beside Pattern, click on the pull-down menu and select P10J or P01J: these patterns
comprise a PRBS7 pseudo-random pattern, with some pairs of bits within each parallel
word set to constantly 10 or 01, respectively. The resulting pattern surrounds a rising or
falling edge transition, respectively, with pseudo-random bits, yet compliant with
8B10B coding rules (no more than 5 consecutive 1's or 0's).
Note
The results for this test are typically sensitive to pre-emphasis and equalization
setting for long loopback paths because of inter-symbol interference (ISI).
Step 5.3 — Measure DCD

This test measures error in pulse width for a user-chosen clock-like pattern relative to the ideal
value of 50%. Duty cycle distortion (DCD) for SerDes is formally defined as the percentage
error relative to 50% for a 1010 pattern. This test is also useful for other patterns when the serial
loopback is AC-coupled (e.g. TDDD, and Transition Time).
Step 5.4 — Measure ISI or TDDD
• In the “TX” Test Group, copy the “RJ” Test Step, paste it into the same Test Group, and
rename it something like “DCD”.
window.
• Click on the pull-down menu beside SerDes Test, and choose DutyCycleDistortion to
measure the duty cycle, relative to 50%.
• Beside Pattern, click on the pull-down menu and select P1010 (if it is not already
selected).
• DCD is reported after subtracting 50% from the measured duty cycle, but you must
provide test limits for the duty cycle without subtracting 50%.
The results for this test are typically sensitive to receiver input offset voltage.

Inter-symbol interference (ISI) is caused by reflections from incorrectly terminated
transmission lines, and by the signal path's bandwidth being significantly less than the signal
bandwidth. Pre-emphasis and equalization are intended to compensate for limited bandwidth.
The impact of limited bandwidth is transition density dependent delay (TDDD), and it is the
dominant source of jitter at serial speeds above 4 Gb/s. With external equipment, this is
measured as jitter that is correlated to data in a random pattern, or by generating a long sequence
of minimum transition density (e.g., 11111000001111100000, the minimum for an 8B10B
compliant pattern, which SerdesTest labels PHalfOne for brevity) followed by an instantaneous
switching to maximum transition density (101010…, which SerdesTest labels P1010) and
measuring the instantaneous phase error. SerdesTest measures the steady-state phase delay for
the PHalfOne pattern, and subtracts this from the phase delay for the user-selected pattern.
This test allows you to characterize pre-emphasis and equalization circuitry.
• In the “TX” and/or “RX” Test Group, copy the “RJ” Test Step, paste it into the chosen
Test Group, and rename it something like “TDDD” or “ISI”.
• Click on the pull-down menu beside SerDes Test and select
TransitionDensityDependentDelay. Then click OK.
• Beside Pattern, click on the pull-down menu and select P1010.
• Right click on one of the Test Controllers and select Options, or right click on one of the
Test Steps, and in the pop-up menu, click on Edit as a Group.
• Set the Test Duration in Beat Cycles value. Ensure that the number is an integer multiple
of your parallel word width. For example, if your word width is 20 or 40 bits, then 1000
beat cycles is good, but if your word width is 32, then you should choose 1024 beat
cycles. If an unsuitable number is used, you will get an error message when you try to
run the test.
An alternative way to measure ISI is to measure the DCD for a bit pattern which contains an
isolated logic 1 bit, relative to a similar but clock-like bit pattern. The PHalfIsoOne pattern is
similar to a PHalfOne pattern, and has 50% bit-wide duty cycle, but has an isolated '1' bit. The
pattern for a 10-bit word is 1111001000, and the pattern for a 20-bit word (or multiples of 20) is
11111111100000100000. The pattern for an 8-bit word is 11100100, and the pattern for a 16-bit
word (or multiples of 16) is 1111111000010000. This test is faster and more tolerant of on-chip
noise than measuring phase shift, but does not measure for P1100.
Note
Measuring TDDD via the DCD test presently requires the measurement results of two
separate test steps to be subtracted from each other. Implementation in a single test step is
planned for a future release of the software.
• In the “TX” Test Group, copy the “DCD” Test Step, paste it into the same Test Group,
and rename it something like “ISI_Iso1”.
window.
• Click on the pull-down menu beside SerDes Test, and select DutyCycleDistortion (if it
is not already selected). Then click on OK.
• Beside Pattern, click on the pull-down menu and select PHalfIsoOne.
• Copy the “ISI_Iso1” Test Step, paste it into the same Test Group, and rename it
something like “ISI_Ref”.
window.
• Beside Pattern, click on the pull-down menu and select PHalfOne. This pattern allows
measuring the inherent DCD in the path (including receiver offset voltage) with the
same scaling factor as for PHalfIsoOne.
For word widths of 10,
ISI =10 ? UI_in_ps ? (DCD_Iso1 - DCD_Ref)/100%
e.g., 10 ? 200ps ? ((+4%) - (-1%)) = 10 × 200ps ? 5% = 100 ps.
For word widths that are multiples of 20,
ISI = 20 ? UI_in_ps ? (DCD_Iso1 - DCD_Ref)/100%
Step 5.5 — Measure slew rate
For word widths of 8,
For word widths that are multiples of 16,

This test measures the difference in pulse width for a received clock-like waveform at two
different voltage offsets (injected on-chip or on the board), which is proportional to the average
of the rising and falling edge slew rates. The test requires a parametric measurement unit (PMU)
to be connected to the receiver pins that are to be tested, and a PMU in the ATE or a USB-to-
GPIB cable to a Keithley Model 2602/2612 SMU. The Keithley terminals shown in Figure 6-1
should be connected as follows:
Table 6-1. Keithley Terminals
Keithley pin Board connection
Channel A HI Access resistor to RX non-inverting input pin
Channel A LO Access resistor to RX inverting input pin
Channel A G Board ground
Channel B HI Access resistor to TX non-inverting output pin
Channel B LO Access resistor to TX inverting output pin
Channel B G Board ground
Figure 6-1. Rear panel connections to Keithley SourceMeter Unit
and rename it something like “SlewRate_150mV”.
window.
• Click on the pull-down menu beside SerDes Test, and select AverageSlewRate.
• Beside Pattern, click on the pull-down menu and select P1010.
• Right click on one of the Test Controllers and select Options.
• Click on the pull-down menu button beside Channel Select, and then select one of the
channels (that are connected to that particular ULTRA Test Controller).
• Next click on the button beside Force Voltages. In the resulting pop-up “Force Voltage
Settings/Pin” menu, you will see the two (differential) serial input pin names for the
receiver corresponding to the channel you selected.
• In the top left entry field, under Phase 1 enter the voltage to be applied by the ATE's DC
PMU that is connected to that pin via a loadboard access resistance (>1 kohm). The
differential voltage to be applied will be divided by 2 x RACCESS/100ohms (for nominal
termination resistance). For example, if VCOM + 0.75 volt is applied to the non-inverting
pin and VCOM - 0.75 volt is applied to the inverting pin, the voltage applied across the
100 ohm differential inputs resistance when each RACCESS is 1 kohm will be 1.5 volt
divided by 20, which is 75 mV.
• Under Phase 2 enter the same two voltages as for Phase 1, but interchanged. The slew
rate will be measured for one offset minus the other. To measure slew rate for a 150 mV
voltage difference (on the differential waveform), VCOM between 0.5V and 1 V, and 1
kohm access resistors, you can apply the voltages as shown in Figure 6-2.
• Then click on OK (for Force Voltage Settings/Pin), and OK (for Slew Rate options).
Step 5.6 — Measure 20%~80% transition time
Figure 6-2. Example Force Voltage values for Slew Rate tests
The measurement result reported (and compared against Measurement Limits) is the measured
change in pulse width. The differential slew rate (average of the rise and fall slew rates) is equal
to the differential offset voltage applied during Phase 1 at the RX pins divided by the measured
change in pulse width. If a 25 ps change in pulse width was measured for the preceding
example, the slew rate would be 3 mV/ps or 3 V/ns.
Note
The results for this test are sensitive to the receiver's gain and equalization setting, and more
so for longer loopback paths. You should choose sufficient equalization to compensate for
the transition time increase (slew rate decrease) caused by the loadboard's loopback path and the
receiver's pad capacitance.

This test measures the difference in pulse width (or received duty cycle, to be more precise), for
two transmitted duty cycles that differ by 20% in the number of logic ones contained; the result
is extrapolated to a 60% difference (i.e., the difference between 20% and 80%).
Note
Measuring the transition time presently requires the measurement results of two separate
test steps to be subtracted from each other. Implementation in a single test step is planned
for a future release
and rename it something like “TransitionTime60”.
window.
• Click on the pull-down menu beside SerDes Test, and select DutyCycleDistortion (if it
is not already selected).
• Beside Pattern, click on the pull-down menu and select PV60. This applies a bit pattern
that is 60% logic ones if the parallel word width is a multiple of 10 bits, or 62.5% if the
word width is a multiple of 8 bits. The measured value is usually a number between 5%
and15%.
• Copy the “TransitionTime60” Test Step, paste it into the same Test Group, and rename
it something like “TransitionTime40”.
window.
• Beside Pattern, click on the pull-down menu and select PV40. This applies a bit pattern
that is 40% logic ones if the parallel word width is a multiple of 10, or 37.5% if the word
width is a multiple of 8 bits. The measured value is usually a negative number between
-5% and -15%.
For word widths that are multiples of 10, the 20%~80% transition time is equal to
15 ? UI_in_ps ? (20% - DCD_PV60 + DCD_PV40)
e.g., 15 ? 200ps ? (20% - (+7%) + (-9%)) = 15 ? 200ps ? 4% = 120 ps.
For word widths that are multiples of 8, the 20%~80% transition time is equal to
12 ? UI_in_ps ? (25% - DCD_PV60 + DCD_PV40)
Note
The results for this test are sensitive to the receiver's gain and equalization setting, and more
so for longer loopback paths. You should choose sufficient equalization to compensate for
the transition time increase (slew rate decrease) caused by the loadboard's loopback path and the
receiver's pad capacitance.
Step 5.7 — Measure VCOM
Step 5.7 — Measure VCOM

To measure the common-mode voltages (for transmitter, or receiver if AC-coupled), this test
uses a DC PMU to measure the DC or average voltage at a SerDes serial data input or output
pin, via high-impedance access resistors, while the transmitter sends a 50% duty cycle, user-
chosen pattern. The test requires a DC PMU to be connected to the transmitter and receiver
pins that are to be tested, controlled via the ATE operating system or (when using a PC) via a
USB-to-GPIB cable to a Keithley PMU (see slew rate test for how to connect the Keithley
PMU). Note that SerdesTest only initiates the transmitter to send the user-chosen pattern. No
measurement limits are applied within the SiliconInsight GUI - this must be done in a test
program.
and rename it something like “MeasureCommonMode”.
window.
• Click on the pull-down menu beside SerDes Test, and select AverageVoltage.
• Beside Pattern, click on the pull-down menu and select a clock-like pattern with 50%
duty cycle (e.g. P1010, P1100, PHalfOne, or PHalfWord).
• Use the PMU to measure average voltage on each serial data pin.
Step 5.8 — Measure logic voltages

This test uses a DC PMU to measure the unloaded logic levels by measuring the change in
average voltage at the transmitter's serial output pins, when the transmitter sends two user-
chosen, non-50% duty-cycle patterns. (You could obtain the same result by transmitting a
steady-state logic 1, or logic 0.)
• In the “TX” Test Group, copy the “MeasureCommonMode” Test Step, paste it into the
same Test Group, and rename it something like “MeasureLogicVoltages_40”.
window.
• Click on the pull-down menu beside SerDes Test, and select AverageVoltage (if it is not
already selected). Beside Pattern, click on the pull-down menu and select PV40. Click
on OK.
• In the “TX” Test Group, copy the “MeasureLogicVoltages_40” Test Step, paste it into
the same Test Group, and rename it something like “MeasureLogicVoltages_60”.
• Beside Pattern, click on the pull-down menu and select PV60.
Step 5.9 — Measure input/output resistances
• Use the PMU to measure the average voltage difference between the inverting and non-
inverting transmitter serial data pins, for the PV40 and PV60 patterns. The change in
differential DC voltage is equal to 20% of the unloaded differential signal swing, hence
multiplying the measured voltage change by 5 will produce the unloaded output
voltages, which are typically double the loaded output voltage.
• Note that for this step, SiliconInsight does not control or read data from the PMU.
Step 5.9 — Measure input/output resistances

This test uses a DC PMU to measure the termination resistance by measuring the change in
average voltage at the transmitter's serial output pins, when applying a known current, while the
transmitter sends any pattern. (You could obtain the same result while transmitting a steady-
state logic 1, or logic 0.)
• In the “TX” Test Group, copy the “MeasureLogicVoltages_40” Test Step, paste it into
the same Test Group, and rename it something like “MeasureResistance.”
window.
• Click on the pull-down menu beside SerDes Test, and select AverageVoltage (if it is not
already selected). Beside Pattern, click on the pull-down menu and select P1010. Click
on OK.
• Use the PMU to apply 1 mA, for example, and simultaneously measure the average
voltage difference across the access resistances and termination resistances, all in series.
Compare this voltage to the average voltage measured while no current is applied. The
total series resistance is equal to the measured change in differential DC voltage divided
by the applied current (1 mA). Subtract the series resistance from this to obtain the
termination resistance (typically 100 ohms) for the transmitter or receiver, if they are
AC-coupled. If they are DC-coupled, the resistance measured will be the parallel
combination of transmitter and resistor resistances.
• Note that for this step, SiliconInsight does not control or read data from the PMU.
Implementing SerDes Receiver Tests

The following test steps pertain to the receiver, so they could be grouped in a new Test Group
labeled “RX”.
Step 5.10 — Measure mean sampling instant

This test measures the receiver's average or mean sampling instant (MSI) within the received
signal eye, relative to the leading (or left) edge of the signal eye, for bit 0 (arbitrarily designated
Step 5.11 — Measure systematic sampling error
as the serial bit corresponding to the parallel output RXData[0]). All other tests are measured
for this same bit, by default, except Systematic Receiver Sampling Error. The position relative
to leading edge of signal eye is reported in Diagnosis mode, but the position relative to the ideal
center of the eye is measured in Execute (pass/fail) mode. Typically, the Measurement Upper
Limit should be a positive number and the Measurement Lower Limit should be the same
number but negative. This test comprises two internal measurements, one while the receiver is
in lock-to-reference mode, and one while the receiver is in lock-to-data mode (therefore, a lock
time pause is always included).
• In the “TX” Test Group, copy the “DCD” Test Step, paste it into the “RX” Test Group,
and rename it something like “SamplingInstant”. The Pattern choice will be ignored
because PHalfWord is always used to ensure there is only one rising edge within each
received word.
• Click on the pull-down menu beside SerDes Test, and select MeanSamplingInstant.
• Right click on one of the Test Controllers and then select Options, or right click on one
of the Test Steps, and in the pop-up menu, click on Edit as a Group.
• Set the Test Duration in Beat Cycles value. Ensure that the number is an integer multiple
of your parallel word width.
Caution
If your RX reference clock (undersampling clock) frequency is not equal to the RX
parallel rate frequency, see the caution in Step 5.13 — Measure LF jitter.
Step 5.11 — Measure systematic sampling error

This test measures the non-random variation in the mean sampling instant for different bits
within the received serial words (the random variation is averaged out). More specifically, it
measures receiver sampling position error for consecutive bit positions in the serial data,
relative to the sampling position for bit 0. You can specify the number of bit positions to be
tested, starting from bit 1. The results are indicative of deterministic interference from nearby
circuitry in the receiver via the power rail or substrate, or indicative of the quality of the design's
sampling scheme. For example, if multiple phases of the sampling clock (e.g., the rising and
falling edges) are used to latch serial data bits, the multi-phase sampling error (MPSE) will
typically increase for every alternate bit and decrease for the other bits.
• Copy the “SamplingInstant” Test Step, paste it into the same Test Group, and rename it
something like “MPSE”. The Pattern choice will be ignored because PHalfWord is
always used to ensure there is only one rising edge within each received word.
• Click on the pull-down menu beside SerDes Test, and select MultiPhaseSamplingError.
Step 5.12 — Measure recovered clock jitter
• Click on Last Data Bit To Test and select the maximum bit number that is to be tested. If
you choose 15, for example, then 15 separate measurements will be performed
(RxData[1] to RxData[15])and all will be compared to the same test limits.
• Test time and pattern length may be long if you test more than 10 bits, but you can
usually reduce the Test Duration in Beat Cycles to 100 (instead of default 1000) because
the test is typically very repeatable.
Step 5.12 — Measure recovered clock jitter

This test measures jitter in the parallel-rate recovered clock. This clock is a divided-down
version of the serial-rate recovered clock, so some of its jitter will be correlated to serial clock.
The jitter is measured using a core logic flip-flop, so this test is more sensitive to the logic's
power rail noise than the RJ and TJ tests.
• Copy the “RJ” Test Step, paste it into the “RX” Test Group, and rename it something
like “RecoveredClockJitter”.
window.
• Click on the pull-down menu beside SerDes Test, and select JitterFromCDF (if it is not
already selected).
• Beside Pattern, click on the pull-down menu and select P1010 - this pattern typically
results in the lowest jitter for the recovered clock but you can choose any other bit
pattern (e.g., P1100, PHalfOne, PHalfWord, or P10J) except PRBS. If you choose a
non-50% duty cycle pattern (e.g., PV60 or PV40), then jitter will be measured at a
voltage that is offset from the mid-point. If you choose a pseudo-random pattern (P10J
or P01J), you can expect a larger jitter value, which may by caused by the clock
recovery alone or by increased parallel-port switching activity.
• Click on Signal To Measure and select Recovered.
Step 5.13 — Measure LF jitter

This test measures the wideband jitter or HF+LF jitter, but LF jitter usually dominates. Tests
that measure delay, such as the TDDD and MSI tests, are sensitive to low frequency (LF) jitter
in the reference clocks, so the LF jitter test is useful for diagnosing poor repeatability. Also, if
LF jitter in the recovered clock is less than LF jitter in the transmitted clock, then this indicates
that the RX CDR is not tracking quickly enough (like a golden PLL would).
Caution
This test is very sensitive to LF jitter in the reference and sampling clocks. One clock must
be derived from the other using a telecom-quality PLL, as described on the next page, since
almost all clock generators do not have the required absolute frequency resolution and accuracy
(10 millihertz).
• In your current directory, create a file with a name constructed as follows:

DLV_U_<testStepName>.lfjittercdf:
For example, use DLV_U_RecClkJitter_LF.lfjittercdf
The contents of the file are:

BasePeriod : <Tbase>us;
ClockPeriodsDividers {
<TXRefClkPin> : <txDivider>;
<RXRefClkPin> : <rxDivider>;
}
where,
• TBase is the period of the base reference frequency, which is the shortest period into
which fits exactly an integer number of RX Reference clock periods and an integer
number of TX Reference clock periods;
• TXRefClkPin is the name of the transmitter’s input reference ClockSource(Offset) pin,
as named in the .etplan file;
• txDivider is the integer number of TX Reference clock periods that exactly fits the
Tbase period;
• RXRefClkPin is the name of the receiver’s input reference ClockSource(Reference)
pin, as named in the .etplan file;
• rxDivider is the integer number of RX Reference clock periods that exactly fits the
Tbase period.
Note
To quickly find the correct ClockSource names, click on the Test Step in
SiliconInsight, then click on Async Clock Periods - you will see the two clock
names that are relevant.
The choices of Tbase and divider values must be exactly correct for this test, but they are easily
determined using LV_ClockGenerator.exe (the program is also available in Excel), which is
available by special request to your Siemens representative. The GUI calculates optimal values
for the clock frequencies that are input and output by LMK03000/1/2 PLLs or any other clock
generators. The three values required are highlighted in the bottom right corner of Figure 6-3.
Figure 6-3. GUI for calculating settings for LF jitter measurement
• In the “RX” Test Group, click on the Test Step named “RecoveredClockJitter”, then
copy it into the same Test Group. Rename the Test Step to something like
“RecoveredClockJitter_LF”.
window.
• Click on the pull-down menu beside SerDes Test, and choose JitterFromCDF (if it is
not already selected).
• Beside Pattern, click on the pull-down menu and select PHalfWord.
• Click on OK.
Implementing SerDes Lane Tests
• Right click on one of the Test Controllers and then select Options (or right click on one
of the Test Steps, and in the pop-up menu click on Edit as a Group).
• Click on Signal To Measure, and select Recovered (if it is not already selected). This
measures jitter as sampled by one of the RxData inputs to ULTRA.
Caution
You must use the JitterFromCDF test type to measure low frequency jitter, and the
PHalfWord pattern. For any other jitter measurement combination, the test will only
measure HF jitter.
You may edit this file while you are in SiliconInsight. The file will be used any time the test is
run (in Diagnose mode only).
Implementing SerDes Lane Tests

The following test steps pertain to a transmitter/receiver pair, so they could be grouped in a new
Test Group labeled “RXTX”.
Step 5.14 — Measure BER

This test measures the bit error rate (BER) by counting bit errors received in a serially
transmitted pseudo-random pattern, specifically the so-called PRBS7 pattern generated by a 7-
bit LFSR using the standard polynomial x6 +x5 +x0. The pattern can be looped-back,
transmitted to bench-top equipment, or received from bench-top equipment. Error detection
begins counting begins after two consecutive parallel words are correct, and stops when a JTAG
instruction is received to output the result. When this test is run in Execute mode, the bit error
count is compared to the Measurement Limits for the lane.
• Copy the “SamplingInstant” Test Step, paste it into the “BER” Test Group, and rename
it something like “BER”. The Pattern choice will be ignored because PRBS7 is always
used.
• Click on the pull-down menu beside SerDes Test, and select FunctionalLoopback.
• Ensure that the checkbox beside Sanity Test is empty, otherwise click on it. If this
checkbox is empty, bit errors are counted for any one lane per ULTRA Test Controller
(if the checkbox is checked, bit errors are only detected, not counted, for multiple lanes
simultaneously)
• Set the Test Duration in Beat Cycles value. Choose a number that is equal to the number
of bits to be sampled for errors, divided by your parallel word width. For example, if
Step 5.15 — Detect bit errors
your word width is 20 bits, and you wish to verify that 10 million bits are transmitted
error-free, set the number of (parallel-clock) cycles to 500,000.
• To choose which lanes connected to each ULTRA Test Controller are to be tested, click
on Channel Select and in the pop-up window, click on any or all of the channel buttons.
The Measurement Upper Limit and Measurement Lower Limit must be expressed in
terms of the number of received words with bit errors (typically zero).
• Click on OK to exit the Channels window, then OK to exit the Test Controller Options
Window
Note
Two versions of this test should be created: a quick test with error injection, and a
longer test without error injection. Error injection is invoked by clicking on Error
Injection in the Test Step Options window. One bit in every 127 words will be inverted,
therefore, the expected bit error count will be approximately equal to the Test Duration
in Beat Cycles divided by 127. Results may vary from lane to lane because of variation
in the time to access the results via JTAG - counting does not stop until the results are
accessed. The expected BER will be word length dependent, e.g., 3.9 ? 10-4 for 20 bit
words or 1.9 ? 10-4 for 40 bit words.

This test detects the presence of any bit errors (but does not count them) in a serially transmitted
PRBS7 pattern, for many lanes simultaneously to save test time relative to a BER test. The
pattern can be looped-back, transmitted to bench-top equipment, or received from bench-top
equipment. Error detection begins counting begins after two consecutive parallel words are
correct, and stops when a JTAG instruction is received to output the result. This test can only by
run in Execute mode (to deliver a pass/fail result); it cannot be run in Diagnose mode to count
bit errors.
• Copy the “BER” Test Step, paste it into the same Test Group, and rename it something
like “BitErrorDetect”. The Pattern choice will be ignored because PRBS7 must be used.
• Click on the pull-down menu beside SerDes Test, and select FunctionalLoopback (if it
is not already selected).
• If necessary, click on the checkbox beside Sanity Test. If the checkbox is checked, bit
errors are only detected, not counted, for any number of lanes simultaneously (if this
checkbox is empty, bit errors are counted for any one lane per ULTRA Test Controller).
of the Test Steps, and in the pop-up menu, click on Edit as a Group, then observe the
Test Duration in Beat Cycles value. Choose a number that is equal to the number of bits
to be transmitted, divided by your parallel word width. To choose which lane connected
to each ULTRA Test Controller is to be tested, click on Channels and in the pop-up
window, click on any one of the channel buttons.
• Click on OK to exit the Channels window, then OK to exit the Test Controller Options
Window
• Click on OK, then run the test by clicking on the Execute icon.
Note
If Error Injection is enabled and bit errors are detected during this test, the test will
pass; if no bit errors are detected, the test will fail.
Go to “Step 6: Diagnose and Characterize Tests”.
Chapter 7
Step 6: Diagnose and Characterize Tests

Step 6.0 — Diagnose Basic Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Step 6.1 — Diagnose Measurement Failures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Step 6.2 — Diagnose Jitter Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Step 6.3 — Check Lock Time Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Step 6.4 — Measure Repeatability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Step 6.5 — Calculate Test Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Step 6.6 — Optimize Test Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Step 6.7 — Characterize many devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Step 6.8 — Creating scripts for characterization and testing . . . . . . . . . . . . . . . . . . . . . 138
Step 6.0 — Diagnose Basic Connectivity

Run the “jtagVerify” Test Group a few times to test the JTAG connections to the TAP and
ULTRA.
If it passes, all connections to the IC's TAP are good, the TAP functions correctly, and it
communicates with each of the ULTRA Test Controllers that you have included in the Test Step
that runs the BasicTests pattern.
If it fails, click on the “+” symbol beside the G icon to see which Test Step failed. Here are
possible failures, their cause, and possible fixes:
• All Test Steps failed, with many miscompares reported in the Console window, and the
expected values were all '0' as shown in Figure 7-1 on page 124:
o open/shorted connection between Amontec/Signalyzer and some or all TAP pins;
o resistive loading on the TAP signal - check amplitude at IC pins;
o the USB-JTAG interface needs to be re-initialized by exiting SiliconInsight,
disconnecting the USB plug, and plugging it back in, and restarting SiliconInsight.
• Some Test Steps fail, with a few miscompares reported, some are expected '0' and some
are expected '1':
o a connection is intermittent or resistive;
Step 6.1 — Diagnose Measurement Failures
o the manufacturer's code is incorrect (wrong IC version?);

o TAP signals edges too slow, causing double-clocking as signal crosses through
switching point voltage;
o TCK clock edges too fast, causing reflections and double-clocking;
o resistive or capacitive loading on the TAP signal - check amplitude and rise times at
IC pins.
Figure 7-1. Example of failures reported when no connections to the TAP pins,
or TDO pin

Run all tests in Characterize/Diagnose mode first (stethoscope icon). This will show measured
values without indicating pass/fail due to Measurement Upper and Lower Limits. The console
window usually gives an explanation for the failure. Here are possible failures, their cause, and
possible fixes:
The measurement did not finish, as indicated by the DoneStatus failure at end of test (see
Figure 7-2) - this is usually caused by:
• the actual reference clock frequency or TCK clock frequency is different than expected;
• the frequency offset is less than expected;
• the sampling clock frequency is synchronous to the sampled frequency;
• the transmitted data pattern is inappropriate;
• excessive jitter is preventing detection of a signal edge (merges into next edge).
o use a shorter loopback path
o use different pre-emphasis or equalization settings.
Figure 7-2. Example failure due to test not completing
LVDB Directory: /home/siuser/Serdes_FPGA_ITC_demo/

EST_FPGA.lvdb
LVDB Name: EST_FPGA.lvdb
Test Config: serdes_ITCdemo
TestStep: CDF_RandomJitterRMS_P1010 (FAILED)
Execution Time Stamp: 01/18/09 21:11:30
UltraController "BP1" (RXBCLK, 6.4ns)
Port "DoneStatus" failed (DR_STATUS3=0).
================================================================
====
Try the following:
• increase the Test Time Multiplier for the Test Step;

• reduce or increase the Under Sampling Clock Ratio;
• for Jitter or JitterFromCDF tests (but not other tests), improve the output amplitude, pre-
emphasis, or equalization to ensure an open signal eye is received;
• ensure that the Pattern is appropriate
o use P1100 instead of P1010, to allow more time between jittery edges
o use a clock-like pattern instead of P10J / P01J, to eliminate data-dependent jitter.
The measured value was not between the Measurement Upper and Lower Limits (e.g. for Jitter)
- this is usually caused by:
• frequency offset measurement is correct in Diagnose mode, but Exec mode test fails
Lower Limit (by a factor of 3 for PLLTest, or N-1 for N-bit SerdesTest);
Step 6.2 — Diagnose Jitter Measurements
• insufficient samples for a repeatable result;

• faulty parametric performance;
• insufficient design margin.
• Try the following:
o check the periods of the two clocks relative to the values declared in SiliconInsight
for Async Clock Periods; if the period for the TestClock clock in etplan file is longer
than the period for pllReference clock, then the offset measured in Diagnosis mode
should be positive - if it is negative, then the clock connections might be reversed.
o increase the Test Duration in Beat Cycles, to make the result more repeatable;
o increase the Measurement Upper Limit for negative results, the Upper Limit must be
less negative than the result);
o decrease the Measurement Lower Limit (for negative results, the Lower Limit must
be more negative than the result);
o examine the shape of the jitter histogram— see “Step 6.2 — Diagnose Jitter
Measurements” on page 126
Step 6.2 — Diagnose Jitter Measurements

The JitterFromCDF test produces histogram CDF bin values, and does not compare these values
to any limits. The difference between adjacent pairs of CDF values is equal to the height of each
histogram bin, as documented later in this document. If sufficient samples have been captured
(Test Duration in Beat Cycles > 500), the shape of the histogram may reveal possible causes for
excess jitter, e.g., a double peak (bi-modal) shape indicates excess deterministic jitter.
Figure 7-3. Console display of jitter histogram
P10J, P01J
Note
The default number of CDF bins is 32, and the resulting number of histogram bins is 32, but
only 31 bins can be displayed. Also, the console omits leading and trailing zero-value bins
to save screen space.
The Jitter test produces an RMS value (derived on-chip from two points in the CDF curve) that
is often less than the RMS value for the CDF captured by the JitterFromCDF test, especially
when:
• the RMS value is less than 5 bins

• there are many outliers (the on-chip algorithm counts the number of outliers but not their
values)
• when the Test Duration in Beat Cycles value is too small (insufficient samples)
P10J, P01J
For P10J or P01J tests, if the last bin (instead of the middle bin) has the most hits, then the
algorithm is searching for the wrong edge type relative to the pattern actually received:
• for P10J, the Measurement Edge must be RISE, and for P01J, the Measurement Edge
must be FALL;
• if you have already chosen these settings, try running the test using the opposite edge
(e.g., FALL instead of RISE); if the histogram shape becomes centered around bin the
middle bin, then
o the received data might be inverted (check the loopback path connections),
o the clock frequency offset might be in the opposite direction than expected (run the
OffsetFrequency test in Diagnose mode and observe the sign),
o the LSB of the data applied to the transmitter’s parallel port might be transmitted
last, or
o the receiver’s output LSB might correspond to the last bit received within each
word.
Note
The P10J pattern name indicates that the parallel word transmitted contains ‘10’
surrounded random bits, but since the LSB is transmitted first, it results in a
rising edge (surrounded by random bits). If your SerDes is designed to transmit LSB
last, then you must indicate this in the <chip>.etplan file by listing the port
connection as <port>[LSB:MSB].
Getting Finer Resolution
In general, you can expect the following:
• Similar RMS values for different Test Duration in Beat Cycles, unless samples in first
and last bins do not approach zero;
• Sum of bin contents equals number of cycles;
• Some bin values may be negative, and more may be negative when fewer samples
collected (because each CDF bin is collected independently, and the histogram subtracts
adjacent CDF bins);
• Center bin is somewhat exaggerated due to the median-based algorithm (instead of
mean-based algorithm).
For a given level of RMS jitter, the ratio of the on-chip calculated RMS value during the Jitter
test and the off-chip calculated RMS value derived from the JitterFromCDF test will be constant
(correlated), if the Test Duration in Beat Cycles is sufficient. If the jitter histogram occupies
only a few bins, then its RMS value may be less repeatable. Increasing the Test Duration in Beat
Cycles will help.
Getting Finer Resolution

To obtain finer sampling resolution, you can decrease the frequency offset. This will cause the
histogram to occupy more bins, and possibly produce a more repeatable result, but will also
cause lower frequency jitter to be included and hence might measure a larger jitter value. This
lower frequency jitter might not be relevant if it is below a SerDes CDR's corner frequency. For
SerDes, you should not reduce the sampling interval more than, say, 20% below the golden-
PLL-based value, by reducing the offset frequency, because that will also reduce the high-pass
cut-off frequency and hence increase the included jitter.
Changing Under Sampling Clock Ratio does not change the measurement bandwidth - it only
changes the sampling resolution.
Note
The JitterFromCDF and AverageVoltage tests do not generate a pass/fail result and won't
run when you click on the Execute button - they can only be run in Diagnose mode. For
these tests, you can set auto-diagnose on (right click on the Test Step, and select "auto-
diagnosis") so that they will run when you click on the Execute button.
Reference Clock Jitter

Before measuring various delays and delay variation, it is important to establish or calibrate the
source of time. For ULTRA-based measurements, there are two sources of time:
• the frequency of a primary reference clock, which establishes absolute time,
Periodic Jitter
• the frequency offset of the sampling clock relative to the primary reference clock, which
establishes a time that is scaled relative to absolute time.
When measuring delay variation (jitter), the jitter in the sampling clock may affect the results
and should be measured.
HF jitter in reference clocks
• decreased by the PLL in SerDes

• increased by power rail noise (causes variation in single-ended buffer switching-point
voltage)
• increased by crosstalk
• affects Jitter and JitterFromCDF
LF jitter in reference clocks
• increased by lack of tracking between reference and sampling clock sources

• increased by long clock path delay (adds thermal variation)
• increased by power supply noise
• affects MeanSamplingInstant and TransitionDensityDependentDelay
Periodic Jitter
Periodic jitter at the clock or data frequency, or a sub-multiple (i.e. jitter with a period that is N
times the clock period or UI), the measured jitter histogram may have every Nth bin nearly zero
- if you change the Under Sampling Clock Ratio to equal N then the histogram will look more
Gaussian. This allows you to diagnose the existence of periodic jitter and still measure the
random jitter accurately. Note that the periodic jitter could be in the sampling clock or the
sampled signal.
Step 6.3 — Check Lock Time Impact

Sometimes, a SerDes or PLL will take longer to achieve phase lock than expected and longer
than the value previously entered in the .etplan file. You can increase or decrease the time
interval inserted for Lock Time to see whether it affects any measurements. To change the lock
time pause that is inserted for a specific test, so that it is different to the LockTime value in the
.etplan file (and LVDB), click on Tools at the top of the SiliconInsight GUI, select Command
Line …, then in the Command Line Dialog window,
Write GetProperty <TestStep> <Controller> LocktimePause
Step 6.4 — Measure Repeatability
then press Enter on keyboard.
The present value for LocktimePause will be displayed in the Console window (and confirm
that you entered valid text). Then,
Write SetProperty <TestStep> <Controller> LocktimePause 10ms
(if you want a 10 ms pause) then press Enter.

To measure a test's measurement repeatability, refer to Figure 7-4 on page 132, and perform the
following operations:
• Right-click on Test Step

• In the Repeatability Analysis area, click on the checkbox beside Enable/Disable
• Enter the number of times that you want to repeat the measurement (default is 10)
• This setting will result in a statistical summary output when Test Step is Diagnosed
• If you want to see every measurement (and the hex code for the actual output bits), then
also click on the checkbox beside Display All Measurements
• If you want to see a trend plot in the +/-3 sigma range (but without hex codes), then also
click on the checkbox beside Display Trend Plot
The Trend plot shows an asterisk for each data point, a vertical line for the lower and upper 3
sigma values, and “<” or “>” next to the vertical line if a data point is outside the ±3 sigma
range.
If you want to see a histogram for the measurements, click on Tools, select Command Line …,
then in the Command Line Dialog window,
write LV::configure RAHistogramEnable 1 ,
then press Enter.
Thereafter, whenever you run repeatability analysis, the histogram will be displayed. To stop
this display,
write LV::configure RAHistogramEnable 0 ,
then press Enter.
If you click on Execute for a test that has Repeatability Analysis enabled, the test will Execute
only once. If the test does not have an Execute mode (e.g., the JitterFromCDF test), and it has
“auto-diagnose” enabled, then the test will run once in Diagnose mode once (this is a
convenient way to quickly check the jitter histogram before running Repeatability Analysis).
You can set the Repeatability Analysis options for all Test Steps simultaneously as follows:
• Click on User, at the top of the SiliconInsight GUI

• Then click on Repeatability Analysis,
• Then click on Global_Repeatability_Analysis
• In the pop-up Global Repeatability Analysis window, click on any buttons under
Modify: to select which setting(s) you want to be applied to all Test Steps, and for each
such row, click on the setting value if necessary.
• Click on OK
If some setting was modified, the Console window will indicate the following:
Successfully updated …”
Step 6.5 — Calculate Test Times
Figure 7-4. Measuring Repeatability
Step 6.5 — Calculate Test Times

All test controllers (ULTRA) within a Test Step are run in parallel, therefore, test time is
calculated per Test Step. Approximately 400 bits are shifted out per ULTRA after each test (via
JTAG). Therefore, the time to shift out test results is <0.5 ms per ULTRA if the TCK clock
frequency is >1 MHz.
Some tests are repeated for multiple settings of pre-emphasis, equalization, and output
amplitude.
BasicTests
BasicTests
Test time = 100 bits / TCKFrequency(Hz)
Typical example
Test time = <0.1 ms
OffsetFrequency
Test time = Test Duration in Beat Cycles / FrequencyOffset(Hz)
Typical example
Test time = 500 / 25000 = 20 ms
Jitter, DutyCycleDistortion
Test time = RelativePatternLength ? Test Duration in Beat Cycles / FrequencyOffset(Hz)
SerdesTest: RelativePatternLength = PatternLength / SerDesWordSize
Pattern Lengths (in UI)
• P1010, P0101 : 2
• P1100, P0011 : 4
• PHalfOne, PHalfOneC : 10 if SerDesWordSize is a multiple of 10, else 8
• PV40, PV60, P01J, P10J : 10 if SerDesWordSize is a multiple of 10, else 8
• All others : SerDesWordSize
Typical examples for SerDesWordSize = 20
P10JTest time = (20/20) ? 500 / 25000 = 20 ms
P1010Test time = (2/20) ? 500 / 25000 = 2 ms
Typical examples for SerDesWordSize = 40
P10JTest time = (40/40) ? 500 / 25000 = 20 ms
P1010Test time = (2/40) ? 500 / 25000 = 1 ms
Jitter, DutyCycle
Jitter, DutyCycle
Test time = RelativePatternLength ? Test Duration in Beat Cycles / FrequencyOffset(Hz)
SerdesTest: RelativePatternLength = PatternLength / SerDesWordSize
JitterFromCDF
Test time = Test time for Jitter + histogram analysis time
MeanSamplingInstant,
TransitionDensityDependentDelay
Test time = 2 ? Test Duration in Beat Cycles / Frequency Offset (Hz)
Typical example
Test time = 500 / 25000 = 40 ms
MultiPhaseSamplingError
Test time = Last Data Bit To Test ? Test Duration in Beat Cycles / Frequency Offset (Hz)
Typical example
Test time = 10 ? 100 / 25000 = 40 ms
AverageSlewRate
Test time = 2 ? [ Test Duration in Beat Cycles / Frequency Offset (Hz) + DCPMUsettling(ms)
]
Typical example
Test time = 2 ? [ 500 / 25000 ] = 50 ms
FunctionalLoopback
SerDes test time = Loopback in Word Clock Cycles ? ClockPeriod(ns)
Typical example for 10M serial bits, SerDesWordSize = 20, 250 MHz parallel clock (at 5 Gb/s)
Step 6.6 — Optimize Test Time
Test time = 500000 ? 4 = 10 ms
Step 6.6 — Optimize Test Time

The quickest way to reduce test time is to reduce the Test Duration in Beat Cycles until the ±3
sigma repeatability becomes too large, relative to the margin between the average measured
value and one of the Measurement Limits, and significantly reduces the test yield. The average
value must be measured for a representative set of devices.
ULTRA-based measurement repeatability may be improved by doing any or all of the

following:
Reduce LF jitter in reference clock or sampling clock
• Optimize loop filter (internal and/or external) for LMK03000 PLLs

o The internal loop filter can be selected via the Test Step that programs the PLL
o The external filter's capacitance can be increased, or its resistance can be decreased,
by connecting passive components in parallel with existing passive components
• Optimize input and feedback counter values for LMK03000 PLLs
o Siemens EDA can provide software that helps you select optimal values
• Choose a larger frequency offset for all phase delay measurements
o Test time is proportional to the reciprocal of offset frequency.
o Whereas Jitter measurements require the correct LF cut-off frequency, phase delay
measurements have no such requirement.
o Re-programming the LMK03000 PLLs requires <20 ms to reacquire lock (depends
on frequency change), but all jitter tests may be run with one offset, and delay tests
(which are the longest tests) with a different offset.
• Choose a different master reference frequency for the LMK03000 PLL(s)
o LF jitter in the PLL output may be reduced if the master reference frequency is
significantly higher or lower (because it allows a better choice of PLL divider
values).
o It is possible to use the output from one LMK03000 PLL as a reference for the other
PLL, thus allowing a higher or lower input frequency for the second PLL; in some
cases this may reduce LF jitter.
• Use additional undersampling to cancel synchronous interference
Step 6.7 — Characterize many devices
o If switching noise from a nearby register or I/O pin is affecting a measurement,

using a different UnderSampling Clock Ratio may help, despite making sampling
coarser.
Use alternative tests that are more repeatable within a given time interval
• 20%~80% transition time, as measured by DutyCycleDistortion for PV60, may be more

repeatable than slew rate for a given Test Duration in Beat Cycles because it measures
duty cycle instead of phase delay, and does not require offset voltage injection by a DC
PMU. However, it presently is a two-step test that requires calculation in the ATE.
• Duty cycle distortion for PHalfIsoOne may be more repeatable than
TransitionDensityDependentDelay for a given Test Duration in Beat Cycles because it
measures duty cycle instead of phase delay. However, it presently is a two-step test that
requires calculation in the ATE
Reduce power rail noise
Another way to reduce test time is to eliminate Test Steps. Reasons for eliminating Test Steps
may include:
• Measurement is highly correlated to that of another Test Step;

• Parameter can be characterized;
• Measurement can be performed on every Nth device.
Step 6.7 — Characterize many devices

The next section shows how to run all tests in diagnosis mode on a large number of
representative devices to gather a statistical summary of parametric performance and determine
test limits that optimize quality and yield.
Saving Your Measurements

All text in the SiliconInsight Console window will be automatically saved in <outdir>/
bistaccess.log, but you cannot read the file until you exit from SiliconInsight. At any time you
can save the Console contents results so far in another file that you can read immediately.
• Click on Console at the top of the SiliconInsight GUI.

• Click on Save To File to define the filename and directory for the data log file; the
default filename is <outdir>/eta_console.log.
• Click on OK and the file will be created immediately.
Preparation
You can save a more concise listing by enabling Datalogging:
• Click on Datalog at the top of the SiliconInsight GUI, then

• click on Datalog File to define the filename and directory for the data log file; the default
filename is <outdir>/eta_results.log.
• Click on OK and datalogging will begin.
• Click on Datalog at the top of the SiliconInsight GUI.
• Click on the button beside To Screen to see a pop-up window that shows the datalog
text. Closing this window will not affect what is saved.
Enter a User Tag value (12 characters maximum), at the top of the Console section to record the
device identification number and/or a test condition. This value will be appear in the Datalog
file as the Output ID value and is very useful when you are characterizing many devices in
sequence.
Preparation
After each Test Step in SiliconInsight has been run successfully, with sufficiently repeatable
results for each measurement on one device or several devices, you can run all tests for one
device by clicking on the packaged device icon at the top of the Test Configuration window,
and then clicking on the Diagnose button. Before doing that,
• Delete all unnecessary Test Steps (click on Test Step, then Ctrl X)
• Disable Repeatability Analysis for all Test Steps (User / … /
Global_Repeatability_Analysis)
• Enter text into the User Tag window to indicate which device number you are testing,
e.g. “chip_001”
To test multiple devices, for each device:
• Insert device in test socket

• Enter the device's number in User Tag window
• Click on the device icon in Test Configuration window
• Wait 5~20 seconds while test runs
• Repeat above four steps for all devices.
• At the top of SiliconInsight GUI, click on Console, then Save To File… then enter a
name and directory.
You will need to write a script to extract the test results for statistical analysis.
Step 6.8 — Creating scripts for characterization and testing
The first time you run each test, it runs slowly and produces more text in the Console window as
it is compiled, but thereafter it runs much faster. In SiliconInsight, each Test Step typically
requires 100 ms and a suite of SerDes tests usually requires 5~20 seconds. Outside of
SiliconInsight, using the automatically generated test vectors for go/no-go production testing,
the same test vectors may run 10X faster. The next section will show you how to estimate
production test times.
Caution
When running a suite of tests, in Characterize or Execute mode, pass/fail repeatability is
generally poor on a PC due to USB-JTAG handling of large amounts of data. You should
use SiliconInsight on ATE for this procedure.
Step 6.8 — Creating scripts for

characterization and testing
When setting property or parameter values in Tessent SiliconInsight, the GUI automatically and
immediately checks the settings and provides feedback to the user if the setting is invalid for
any reason. However, this approach can be cumbersome for setting parameters when there are
many tests. There are several ways to more quickly create and run tests.
As described in “Step 7.0 — Generate Generic Pattern,” all test steps and their parameter
settings may be exported to an etManufacturing file. You can edit that file, and import the file as
a configuration file.
You can also create scripts in Tcl. To minimize the chance of error, you should only alter the
property values for the parameters that are shown for each test type in an exported
etManufacturing file. Other parameters are either irrelevant or only have one correct value.
1. Click on Tools at the top of the SiliconInsight GUI, select Command Line …,
2. In the Command Line Dialog window, enter the name of a Tcl file containing a
sequence of commands, as follows:
source <file.tcl>
or enter each command using the following syntax to get or set property values:
getProp <TestStepName> SerdesTest
setProp <TestStepName> SerdesTest <TestType>
getProp <TestStepName> Pattern
setProp <TestStepName> Pattern <PatternName>
getProp <TestStepName> RepeatabilityAnalysis
setProp <TestStepName> RepeatabilityAnalysis <OnOff>
getProp <TestStepName> RARepeatCount

setProp <TestStepName> RARepeatCount <integer>
For example:
setProp Step1 SerdesTest Delay
(Note that “SerdesTest” is used whether it is a SerDes or PLL, but you must use a
TestType that is applicable to the function.)
For all other parameters, use the following syntax:

getProp <TestStepName> <Controller> <hierProperty>
setProp <TestStepName> <Controller> <hierProperty> <value>
For example:
getProp Step1 BP0 LocktimePause
setProp Step1 BP0 LocktimePause LocktimePause 10ms
getProp S0 BP0 UnderSamplingClkRatio
setProp S0 BP0 UnderSamplingClkRatio 2
getProp S0 BP0 MeasurementLimits()::UpperLimit
setProp S0 BP0 MeasurementLimits()::UpperLimit 10
setProp S0 BP0 MeasurementLimits()::LowerLimit -10
3. To Execute or Diagnose a test step, use the following commands:

ExecuteStep <TestStepName>
DiagnoseStep <TestStepName>
For example:
ExecuteStep S0
DiagnoseStep S0
4. To select the TPG/RPA that will be enabled for a test, or to find out which will be
enabled, use the following commands in the Command Line Dialog window:
setProp TPGChannelEnable <TestStepName> <Controller> <listOfValues>
setProp RPAChannelEnable <TestStepName> <Controller> <listOfValues>
getProp TPGChannelEnable <TestStepName> <Controller>
getProp RPAChannelEnable <TestStepName> <Controller>
For example:
setProp TPGChannelEnable S0 BP0 {0 1 3}
setProp RPAChannelEnable S0 BP0 [list 0 1 3]
To find out about other possible commands, enter "help".
Note
One command is a little different for PLLTest and SerdesTest than for other types of BIST.
When entering clock periods with the SetAsyncClockData command, you must provide the
settings for both clocks in the same line, for example:
SetAsyncClockData Step1 RefClk:10ns USClk:10.001ns
Note
There are behavior differences between entering a parameter value with a click, and using
setProp. For the EST plugin, when a property is set using setProp in a test step and the
property is valid, the test step is usually marked as “dirty” and the pattern is usually regenerated
the next time Execute/Diagnose is performed. This is true even if the value of the property does
not change. However, the GUI is not updated (going from green/red back to gray), and
sometimes the pattern is not regenerated. To update the state of the GUI and to ensure that the
pattern is regenerated, the following commands can be added after a group of set commands:
dirtyStep <TestStepName> For example: dirtyStep Step1
Chapter 8
Step 7: Generate Production Tests
After characterization, and setting test limits that provide optimal quality and yield based on a
representative number of devices, you generate go/no-go test vectors that run on any ATE. Each
pattern has its own name, and is called by the test program that you write.
Generate an etverify output from SiliconInsight. From this file, you can generate test patterns in
generic formats (STIL, WGL, or SVF).
Step 7.0 — Generate Generic Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Step 7.1 — Generate WGL, SVF, STIL, Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Step 7.2 — Write Test Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Step 7.0 — Generate Generic Pattern

• In SiliconInsight, under the File menu, select Export...
• In the Export ETV Configuration File window, select the directory <chip>.lvdb/. and
select the file <chip>.etManufacturing
• Click on OK
• You can read the resulting plain text file - it contains all your tests organized in
serdesVerify wrappers. If necessary, you can edit this file, for example to duplicate test
steps so that the same User Bits setting is used for equalization.
• Import this file back into SiliconInsight to check that any changes you made are correct:
• In SiliconInsight, click on Configuration button, and select the <chip>.etManufacturing
file, then click OK.
• Check that any changes you made are correct, then Exit.
Step 7.1 — Generate WGL, SVF, STIL, Verilog

• Set your current directory to <chip>.lvdb
etv <chip> \
-configFile <chip>.etManufacturing \
-wgl on
Step 7.2 — Write Test Program
Instead of -wgl, you can specify any one of the following runtime options:
-stil, -svf, -verilog
This will produce a file <chip>.TestProgramSequencewhich lists all patterns that were created.
Each pattern is in a separate file with an appropriate suffix — .wgl, .stil, .svf, or .v .
Note
SVF patterns to program the National Semiconductor LMK03000 are produced
automatically by Tessent SiliconInsight whenever the clock generator programming test
step is run (and OnlySetAsyncClocks=0). The patterns are in the outDir directory, with the
filename <testStepName>.svf. The SVF pattern can be converted to WGL using software which
is available by special request to your Siemens representative.
Note
Some of the jtagVerify test steps cannot be performed with .svf because those tests end in
intermediate TAP states.
Step 7.2 — Write Test Program

Note the following for writing your Test Program:
Formula for RMS from CDF Data

Use this formula in your test program to compute the RMS jitter from the CDF data shifted out
by the JitterFromCDF test.
Assume the CDF bin values are cdfValue1, cdfValue2, …, cdfValue32.
Each is a 12-bit binary coded number, shifted out of the JTAG port.
histValue1 = cdfValue1 - 0
histValue2 = cdfValue2 - cdfValue1
histValue32 = cdfValue32 - cdfValue31
If the CDF is produced for a falling edge instead of a rising edge (possibly because frequency
offset is negative instead of positive), or if the jitter is very noisy due to too few samples, then
some or all of histValue1~histValue32 may be negative, so an 'absolute value' operation (ABS)
is needed to ensure a positive result.
For 32 bins, with values histValueN, where N=1 to 32, the RMS value is calculated as follows:
MeanDeviation = [(1 ? histValue1) + (2 ? histValue2) + … +
(32 ? histValue32)] / [cdfValue32]
MeanSquaredDev = ABS[(12 ? histValue1) + (22 ? histValue2)
+ … + (322 ? histValue32)] / [cdfValue32]
Variance = MeanSquaredDev - MeanDeviation2
RMSbins = squareroot(Variance)
psPerSample = fOFFSET / (fTXREF ? fRXREF)
psPerBin = psPerSample ? samplesPerBin
RMSpicoseconds = psPerBin ? RMSbins
Note
The value in your .etplan file for CDFNumberOfBins determines the number of counters
created in the RTL and the number of histogram bins. The default value of 32 is best, and
should not be increased for applications where the RMS jitter may exceed 0.1 UI, which
commonly occurs for SerDes with non-optimal equalization.
The maximum count within each bin is determined by CDFSamplesCounterSize and can be
increased safely beyond the default value of 12-bits (Test Duration in Beat Cycles up to 4095) if
necessary but it will increase gate count by 32 extra flip-flops for each extra bit.
Caution
If UnderSamplingClkRatio >1 for the JitterFromCDF test, then the first bin is skipped when
shifting out the CDF via the TAP, so the number of bins read out is actually
CDFNumberOfBins - 1 .
Appendix A
Getting Help
There are several ways to get help when setting up and using Tessent software tools. Depending
on your need, help is available from documentation, online command help, and your Siemens
representative.
The Tessent Documentation System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Global Customer Support and Success . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
The Tessent Documentation System

At the center of the documentation system is the InfoHub that supports both PDF and HTML
content. From the InfoHub, you can access all locally installed product documentation, system
administration documentation, videos, and tutorials. For users who want to use PDF, you have a
PDF bookcase file that provides access to all the installed PDF files.
For information on defining default HTML browsers, setting up browser options, and setting the
default PDF viewer, refer to the Siemens® Software and Mentor® Documentation System
manual.
You can access the documentation in the following ways:
• Shell Command — On Linux platforms, enter mgcdocs at the shell prompt or invoke a
Tessent tool with the -Manual invocation switch.
• File System — Access the Tessent InfoHub or PDF bookcase directly from your file
system, without invoking a Tessent tool. For example:
HTML:
firefox <software_release_tree>/doc/infohubs/index.html
PDF:
acroread <software_release_tree>/doc/pdfdocs/_tessent_pdf_qref.pdf
• Application Online Help — Get contextual online help within most Tessent tools by
using the “help -manual” tool command:
> help dofile -manual
This command opens the appropriate reference manual at the “dofile” command
description.
Getting Help
Global Customer Support and Success
Global Customer Support and Success

A support contract with Siemens EDA is a valuable investment in your organization’s success.
With a support contract, you have 24/7 access to the comprehensive and personalized Support
Center portal.
Support Center features an extensive knowledge base to quickly troubleshoot issues by product
and version. You can also download the latest releases, access the most up-to-date
documentation, and submit a support case through a streamlined process.
https://support.sw.siemens.com
If your site is under a current support contract, but you do not have a Support Center login,
register here:
https://support.sw.siemens.com/register
Appendix B
Commands and Control Files
Commands and control files.

Sequence of EDA commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Primary control files that you create . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Sequence of EDA commands

Current directory:ETCHECKER
Step 1.1: etchecker <chip> ... ==> <chip>.etchecker
Step 1.4: make <chip>.clockInfo
Step 1.5: make <chip>.ruleCheck
Current directory:DFT
Step 1.7: etplanner <chip> ... ==> <chip>.etplan
Step 2.0: make checkPlan
Step 2.1: make genLVWS ==> <chip>.etassemble
Current directory:DFT/<chip>_LVWS/ETAssemble
Step 2.3: make embedded_test --+
Step 2.4: make designe |
Step 2.5: make config_etSignOff | ==> <chip>.etSignOff
Step 2.6: make lvdb_preLayout +-- make all
Step 2.7: make testbench |
Step 2.8: make sim --+
Step 2.10: make synth
Step 2.13: make concatenated_netlist => <chip>.vb_postLV
Current directory:DFT/<chip>_LVWS/ETSignOff
Step 2.14: make config_etManufacturing
Step 2.15: make lvdb_final ==> <chip>.lvdb/
Step 2.16: make testbench
Step 2.17: make <chip>_sim
Step 2.18: make patterns
Step 2.19: make archive_config
Primary control files that you create

The following control files are described in the order they occur in this user guide.
Commands and Control Files
Primary control files that you create
<myEmbeddedTestDirectory>
+ ETCHECKER
+ DFT
ETCHECKER/<chip>.etchecker
• Indicates whether chip should be checked in anticipation of logic BIST, or memory

BIST
• Declares TAP pins
• Declares SerDes or PLL as a black box for DFT rule checking
ETCHECKER/Makefile
• The etcOptions you added indicate: top-level of design, chip design directory,
pad.library file, file extensions (e.g., .v, .vb)
DFT/<chip>.etplan
• Indicates CAD environment (location of simulators, etc.); IC technology files (cell

library, etc.); default chip parameter settings for embedded test.
• Indicates how SerdesTest (or PLLTest) is to be connected within IC
DFT/<chip>_LVWS/ETAssemble/<chip>.etassemble
• Sets TAP parameters (deviceIdCode, userDRBits and aliases, etc.)

• Indicates customObjects and connections to be made automatically after Embedded Test
logic is inserted in your IC design
DFT/<chip>_LVWS/ETAssemble/<chip>.etSignOff -> DFT/<chip>_LVWS/
ETSignOff/<chip>.lvdb_prelayout/<chip>.etSignOff
• High-level parameters describing the minimum suite of test patterns for simulation and
verifying basic operation of SerdesTest or PLLTest (with jitter-free signals)
• User Defined Sequences that precede each test pattern
Appendix C
Models
Overview of models.
Simplified SerDes model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Simplified SerDes model

To try the design flow described in this document using an example dual-clock, jitter-free
SerDes, you may use the following RTL model to quickly simulate (less than a minute) the test
bench automatically generated by the Make Testbench command.
`celldefine
`define WORDSIZE 20
`timescale 1 ns / 1 fs
module SERDES (
TXREFCLK, // Transmitter reference clock - from XTAL
TXREFCLK_OUT, // Transmitter reference clock - to SerdesTest
TXDATA, // Transmitter parallel data - input port
TXSD, // Serial data line to differential output pad
RXREFCLK, // Receiver reference clock - from XTAL
RXREFCLK_OUT, // Receiver reference clock - to SerdesTest
RXSD, // Serial data line from differential input pad
RXDATA, // Receiver parallel data - output port
RXRECCLK, // Receiver recovered clock
RXFORCE // Force the receiver to sample at RXREFCLK
);
input TXREFCLK;
Models
output TXREFCLK_OUT;
input [`WORDSIZE-1:0] TXDATA;
input RXSD;
output TXSD;
input RXREFCLK;
output RXREFCLK_OUT;
output [`WORDSIZE-1:0] RXDATA;
output RXRECCLK;
input RXFORCE;
wire [`WORDSIZE-1:0] TXDATA_I;
wire TXSD_INT, TXSD_clean;
wire RXREFCLK_INT, CLK_IN_SYNC_WITH_TXSD;
assign TXSD = TXSD_INT;
assign TXDATA_I = TXDATA;
RX SDRX ( .DIN(RXSD), .RX_REFCLK(RXREFCLK_INT), .RX_DOUT(RXDATA), .RX_RECCLK(RXRECCLK) );
TX SDTX ( .DIN(TXDATA_I), .CLK(TXREFCLK), .DOUT(TXSD_INT) );
// For sake of simplicity, the receiver channel model (RX) does not really recover the clock.
// This model assumes that the data received on the RXSD when RXFORCE=0 (functional mode) will have the
// edges aligned with TXREFCLK
// Consequently, if a delay is inserted on the serial data line, and this supplied RX model is used,
// the same delay must be inserted in the path of RXREFCLK_INT when RXFORCE=0 in order to mimic correct
// clock recovery in RX. If this delay is NOT inserted, this will result in a shift in the sampling position
// of the RX receiver model.
ìfdef CHANNEL_DELAY_PS
real chDelay_ns;
Models
initial begin
chDelay_ns = 1.0 * `CHANNEL_DELAY_PS / 1000.0;
end
assign #chDelay_ns CLK_IN_SYNC_WITH_TXSD = TXREFCLK;
èlse
assign CLK_IN_SYNC_WITH_TXSD = TXREFCLK;
èndif
assign TXREFCLK_OUT = TXREFCLK;
assign RXREFCLK_OUT = RXREFCLK;
assign RXREFCLK_INT = RXFORCE ? RXREFCLK : CLK_IN_SYNC_WITH_TXSD;
endmodule
èndcelldefine
// ------------------------------------------------------------------------------
`celldefine
module TX (DIN, CLK, DOUT);
input [`WORDSIZE-1:0] DIN;
input CLK;
output DOUT;
real edge1Time, halfperiod;
reg [`WORDSIZE-1:0] DIN_REG;
reg DOUT_INT, VCOON, VCO;
wire DOUT;
assign DOUT = VCOON & DOUT_INT;
integer KP, KS;
initial begin
Models
KP = -1;
KS = -1;
DIN_REG = 0;
DOUT_INT = 0;
edge1Time = 0.0;
VCOON = 0;
VCO = 0;
@ (negedge CLK);
@ (posedge CLK);
@ (posedge CLK);
@ (posedge CLK);
VCOON = 1;
end
always @(posedge CLK) begin
halfperiod = 0.5 * ($realtime - edge1Time) / `WORDSIZE;
edge1Time = $realtime;
if (VCOON) begin
VCO = 0;
DIN_REG = DIN;
for (KP=0; KP < 2*`WORDSIZE - 1; KP = KP+1) begin
#halfperiod VCO = ~VCO;
if (VCO) begin
KS = KP >> 1;
DOUT_INT = DIN_REG[KS];
end
Models
end
end
end
endmodule
èndcelldefine
// ------------------------------------------------------------------------------
`celldefine
// Parameters (tick)define for this module
// MSI_ERROR_PERCENT
// Error in the sampling instant, in percent of a UI
// Positive -> sampling instant is later,
// Negative -> sampling instant is sooner.
// Reasonable range to avoid errors + / - 20%
module RX (DIN, RX_REFCLK, RX_DOUT, RX_RECCLK);
input DIN, RX_REFCLK;
output RX_RECCLK;
output [`WORDSIZE-1:0] RX_DOUT;
real edge1Time;
real hperiod, hperiod0, hperiod1;
integer KP;
reg DIN_REG, VCO;
reg [`WORDSIZE-1:0] DOUT_REG, RX_DOUT;
reg CLK_int;
reg VCOON;
assign RX_RECCLK = CLK_int;
Models
initial begin
VCO = 0;
VCOON = 0;
CLK_int = 1;
edge1Time = 0.0;
hperiod = 0.0;
ìfdef MSI_ERROR_PERCENT
$display(":: MSI error = %.1f%% of a UI", `MSI_ERROR_PERCENT);
èndif
@(negedge RX_REFCLK);
@(posedge RX_REFCLK);
@(posedge RX_REFCLK) VCOON <= 1;
end
always @(posedge RX_REFCLK) begin
hperiod <= 0.5 * ($realtime - edge1Time) / `WORDSIZE;
edge1Time <= $realtime;
ìfdef MSI_ERROR_PERCENT
hperiod1 <= (1 + 0.02 * `MSI_ERROR_PERCENT) * hperiod;
hperiod0 <= (1 - 0.02 * `MSI_ERROR_PERCENT) * hperiod;
èlse
Models
hperiod1 <= hperiod;
hperiod0 <= hperiod;
èndif
end
always @(posedge RX_REFCLK) begin
if (VCOON) begin
VCO = ~VCO;
CLK_int = 1;
for (KP=1; KP<=`WORDSIZE; KP = KP+1) begin
if (VCO) begin
#(hperiod1) VCO = ~VCO;
end else begin
end
end
CLK_int = 0;
for (KP=1; KP<`WORDSIZE; KP = KP+1) begin
if (VCO) begin
end else begin
end
end
end
end
Models
always @ (negedge VCO) begin
DIN_REG <= DIN;
DOUT_REG <= {DIN_REG, DOUT_REG[`WORDSIZE-1:1]};
end
always @ (posedge CLK_int) begin
RX_DOUT <= DOUT_REG;
end
endmodule
èndcelldefine
Appendix D
Jitter Components and Frequencies
The following figure illustrates the source of and relationships between different jitter
components.
Figure D-1. Jitter Components
Figure D-2 illustrates the relationship between different jitter frequencies.
Jitter Components and Frequencies
Figure D-2. Jitter Frequencies
Appendix E
Document Updates
This is a living document. As improvements are found for the recommended practices
documented herein, they will be added.
Approximately in order of priority, highest at top of list.
• How to test Transmitter-only SerDes, by adding a sampling latch to its output so that it
becomes a transceiver - some tests are not applicable
• Improve STA step description
• Explain tool options:
o Session Setup...
o Debug Toolkit...
o Generate ATPG SVF Patterns - for logic BIST only
• How to adjust VDD via SiliconInsight when a power supply is connected via USB-
JTAG (or in ATE).
• Add a note somewhere that each test step presently generates a pattern, and each has its
own reset (and lock time).
Eventually, an option will be provided so that instead of each Test Step having a reset,
only each Test Group would have a reset, to save test time. This also means that Test
Step order would be more significant.
• Content for last chapter, on generating ATE-specific patterns.
Document Updates
Third-Party Information
Details on open source and third-party software that may be included with this product are available in the
<your_software_installation_location>/legal directory.

Etserdes User

Uploaded by

Copyright:

Available Formats

Etserdes User

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Etserdes User

Uploaded by

Copyright:

Available Formats

SIEMENS EDA

Support Center: support.sw.siemens.com

Tessent™ SerdesTest User’s Manual, v2021.2 and Later 3

Step 2.6 — Generate LVDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4 Tessent™ SerdesTest User’s Manual, v2021.2 and Later

Step 4.4 — Choose test type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Tessent™ SerdesTest User’s Manual, v2021.2 and Later 5

6 Tessent™ SerdesTest User’s Manual, v2021.2 and Later

Tessent™ SerdesTest User’s Manual, v2021.2 and Later 7

8 Tessent™ SerdesTest User’s Manual, v2021.2 and Later

Figure 2-1. Master/Slave TAP Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Tessent™ SerdesTest User’s Manual, v2021.2 and Later 9

10 Tessent™ SerdesTest User’s Manual, v2021.2 and Later

Tessent™ SerdesTest User’s Manual, v2021.2 and Later 11

12 Tessent™ SerdesTest User’s Manual, v2021.2 and Later

This chapter provides an overview.

Embed Test Circuitry in Your IC Design to Test

Characterize and Diagnose Silicon

Tessent™ SerdesTest User’s Manual, v2021.2 and Later 13

Generate Production Test Patterns for Your IC

14 Tessent™ SerdesTest User’s Manual, v2021.2 and Later

You must first prepare your design.

Tessent™ SerdesTest User’s Manual, v2021.2 and Later 15

2. RxRef — receiver reference clock at parallel rate or lower:

16 Tessent™ SerdesTest User’s Manual, v2021.2 and Later

General Implementation Strategy

Tessent™ SerdesTest User’s Manual, v2021.2 and Later 17

Step 1.0 — Create Working Directories

If necessary, add the directory to your UNIX path. For example:

Step 1.1 — ETChecker

• Set your current directory to ETCHECKER.

18 Tessent™ SerdesTest User’s Manual, v2021.2 and Later

Step 1.2 — Indicate TAP Pins

Tessent™ SerdesTest User’s Manual, v2021.2 and Later 19

lv.Target -type Block -notPhysicalRegion

Provide Connections for Second TAP, If Necessary

20 Tessent™ SerdesTest User’s Manual, v2021.2 and Later

Figure 2-1. Master/Slave TAP Connections

Step 1.3 — Indicate Design Files

Tessent™ SerdesTest User’s Manual, v2021.2 and Later 21

22 Tessent™ SerdesTest User’s Manual, v2021.2 and Later

If your cell library does not have a ClockGatingORCell or ClockGatingANDCell as defined in

Tessent™ SerdesTest User’s Manual, v2021.2 and Later 23

Step 1.4 — Check Clock Tree

• Use the command:

The errors and warnings are saved in an output file:

Step 1.5 — Check DFT Rules

• Use the command:

• Check the following output file for errors and warnings:

Step 1.6 — Check Default Files

• Set your current directory to DFT

24 Tessent™ SerdesTest User’s Manual, v2021.2 and Later

• LV_CADENV_FILE should point to a .CADSetup file which describes your CAD

Figure 2-2 shows an example of the content for a .CADSetup file.

Figure 2-2. Example .CADSetup File

Figure 2-3 shows an example of the content for a .LVICTech file.

Tessent™ SerdesTest User’s Manual, v2021.2 and Later 25

Figure 2-3. Example .LVICTech File

Figure 2-4 shows an example of the content for a .ETDefaults file.

Figure 2-4. Example .ETDefaults File