Tessent Plltest User'S Manual: Software Version 2014.1 March 2014

This manual is part of a fully-indexed Tessent documentation set.
To search across all Tessent manuals, click on the binocular icon

or press Shift-Ctrl-F. Note that this index is not available if you are
viewing this PDF in a web browser.
Tessent
PLLTest Users Manual

Software Version 2014.1
March 2014
2010-2014 Mentor Graphics Corporation
All rights reserved.
This document contains information that is proprietary to Mentor Graphics Corporation. The original recipient of this
document may duplicate this document in whole or in part for internal business purposes only, provided that this entire
notice appears in all copies. In duplicating any part of this document, the recipient agrees to make every reasonable
effort to prevent the unauthorized use and distribution of the proprietary information.
This document is for information and instruction purposes. Mentor Graphics reserves the right to make
changes in specifications and other information contained in this publication without prior notice, and the
reader should, in all cases, consult Mentor Graphics to determine whether any changes have been
made.
The terms and conditions governing the sale and licensing of Mentor Graphics products are set forth in
written agreements between Mentor Graphics and its customers. No representation or other affirmation
of fact contained in this publication shall be deemed to be a warranty or give rise to any liability of Mentor
Graphics whatsoever.
MENTOR GRAPHICS MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE.
MENTOR GRAPHICS SHALL NOT BE LIABLE FOR ANY INCIDENTAL, INDIRECT, SPECIAL, OR
CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT LIMITED TO LOST PROFITS)
ARISING OUT OF OR RELATED TO THIS PUBLICATION OR THE INFORMATION CONTAINED IN IT,
EVEN IF MENTOR GRAPHICS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
U.S. GOVERNMENT LICENSE RIGHTS: The software and documentation were developed entirely at
private expense and are commercial computer software and commercial computer software
documentation within the meaning of the applicable acquisition regulations. Accordingly, pursuant to
FAR 48 CFR 12.212 and DFARS 48 CFR 227.7202, use, duplication and disclosure by or for the U.S.
Government or a U.S. Government subcontractor is subject solely to the terms and conditions set forth
in the license agreement provided with the software, except for provisions which are contrary to
applicable mandatory federal laws.
TRADEMARKS: The trademarks, logos and service marks ("Marks") used herein are the property of
Mentor Graphics Corporation or other parties. No one is permitted to use these Marks without the prior
written consent of Mentor Graphics or the owner of the Mark, as applicable. The use herein of a third-
party Mark is not an attempt to indicate Mentor Graphics as a source of a product, but is intended to
indicate a product from, or associated with, a particular third party. A current list of Mentor Graphics
trademarks may be viewed at: www.mentor.com/trademarks.
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.
Mentor Graphics Corporation
8005 S.W. Boeckman Road, Wilsonville, Oregon 97070-7777
Telephone: 503.685.7000
Toll-Free Telephone: 800.592.2210
Website: www.mentor.com
SupportNet: supportnet.mentor.com/
Send Feedback on Documentation: supportnet.mentor.com/doc_feedback_form
Tessent PLLTest Users Manual, v2014.1 3
March 2014
Table of Contents
Chapter 1
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Embed Test Circuitry in Your IC Design to Test SerDes or PLLs . . . . . . . . . . . . . . . . . . . . 9
Characterize and Diagnose Silicon Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Generate Production Test Patterns for Your IC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Chapter 2
Step 1: Prepare Your Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
SerDes Suitability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
PLL/DLL Suitability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Stable Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
General Implementation Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Step 1.0 Create Working Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Step 1.1 ETChecker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Step 1.2 Indicate TAP Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Provide Connections for Second TAP, If Necessary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Step 1.3 Indicate Design Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Step 1.4 Check Clock Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Step 1.5 Check DFT Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Step 1.6 Check Default Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Step 1.7 ETPlanner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Step 1.8 Check Default Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Step 1.9 CUT Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Connections for PLLs and DLLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Step 1.10 Collect Design Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Step 1.11 Update .etplan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Step 1.12 PLL Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Step 1.13 On-chip sampling clock generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Using the PLLs reference clock. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Using another PLLs output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Chapter 3
Step 2: Embed Test Circuitry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Step 2.0 Check .etplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Step 2.1 Generate LVWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Step 2.2 Specify TAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Step 2.3 Generate & insert RTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Add muxes and userDRBit connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Custom Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Step 2.4 Check connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
File hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Step 2.5 Prepare for simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Table of Contents
4
March 2014
Tessent PLLTest Users Manual, v2014.1
User Defined Sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Verilog to SVF conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Step 2.6 Generate LVDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Step 2.7 Generate test bench. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Step 2.8 Simulate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
View RTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Simulate one pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Step 2.9 Diagnose PLLTest simulations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
tapbistv and P1 patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
P2 pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
P3 pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Step 2.10 Synthesize logic gates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Step 2.11 Static timing analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Step 2.12 Prepare for layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Step 2.13 Prepare for sign-off. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Step 2.14 Prepare for test pattern generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Step 2.15 Generate final LVDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Step 2.16 Generate post-layout simulation test bench . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Step 2.17 Simulate post-layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Step 2.18 Generate sample test patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Step 2.19 Archive Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Chapter 4
Step 3: Prepare a Board to Characterize Your IC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Step 3.0 Clocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
ATE Clocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
SRS CG635. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
LMK03000 PLL Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Si550 VCXO Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Power Supply Decoupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Step 3.1 Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Step 3.2 JTAG. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
USB-Amontec. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
USB-Signalyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Step 3.3 Board Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Step 3.4 .pinmap File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Chapter 5
Step 4: Prepare SiliconInsight to Characterize Your IC . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Step 4.0 Accessing SiliconInsight. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Step 4.1 Power up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Creating a complete set of tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Step 4.2 Add a Test Step. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Step 4.3 Choose a Test Controller (ULTRA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Step 4.4 Choose test type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Step 4.5 Set global clock periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Step 4.6 Program loadboard PLL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Step 4.7 Set clock periods for single Test Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Table of Contents
March 2014
Step 4.8 Add Test Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Step 4.9 Measure reference frequency offset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Choose Test Controller (ULTRA) options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Step 4.10 Measure reference clock jitter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
JitterFromCDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Jitter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Chapter 6
Step 5: Characterize your PLL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Use SiliconInsight to Characterize Your PLL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Step 5.0 Optimize frequency offset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Implementing PLL/DLL Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Step 5.1 Measure HF jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Data Bit Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Step 5.2 Measure LF jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Step 5.3 Measure duty cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Step 5.4 Measure clock frequency ratio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Step 5.5 Measure phase delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Step 5.6 Measure lock time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Step 5.7 Measure lock range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Chapter 7
Step 6: Diagnose and Characterize Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Step 6.0 Diagnose Basic Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Step 6.1 Diagnose Measurement Failures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Step 6.2 Diagnose Jitter Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Getting Finer Resolution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Reference Clock Jitter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Periodic Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Step 6.3 Check Lock Time Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Step 6.4 Measure Repeatability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Step 6.5 Calculate Test Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
BasicTests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
OffsetFrequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Jitter, DutyCycleDistortion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
JitterFromCDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
FunctionalLoopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Step 6.6 Optimize Test Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Step 6.7 Characterize many devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Saving Your Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Step 6.8 Creating scripts for characterization and testing. . . . . . . . . . . . . . . . . . . . . . . . . 113
Chapter 8
Step 7: Generate Production Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Step 7.0 Generate Generic Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Step 7.1 Generate WGL, SVF, STIL, Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Step 7.2 Write Test Program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Table of Contents
6
March 2014
Formula for RMS from CDF Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Appendix A
Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Mentor Graphics Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Appendix B
Commands and Control Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Sequence of EDA commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Primary control files that you create . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Appendix C
Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Simplified PLL model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Appendix D
Jitter Components and Frequencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Appendix E
Document Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Appendix F
Step 5: SerDes-Based Design Flow for PLLTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Using the SerDes-Based Design Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Step 5.0 Optimize frequency offset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Implementing PLL/DLL Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Step 5.1 Measure HF jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Step 5.2 Measure LF jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Step 5.3 Measure duty cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Step 5.4 Measure clock frequency ratio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Step 5.5 Measure phase delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Step 5.6 Measure lock time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Step 5.7 Measure lock range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Third-Party Information
End-User License Agreement
March 2014
List of Figures
Figure 2-1. Master/Slave TAP Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figure 2-2. Example .CADSetup File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figure 2-3. Example .LVICTech File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figure 2-4. Example .ETDefaults File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figure 2-5. Design Hierarchy for PLL (or DLL). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 2-6. Example PLL Interface Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figure 2-7. Controlling a PLL for Lock Time and Lock Range Measurement . . . . . . . . . . . 31
Figure 2-8. Example PLL, and connections when reference clock is the sampling clock . . 32
Figure 2-9. Architecture of LMK03000 PLL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Figure 3-1. File hierarchy for <chip> = CHIP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figure 4-1. Example connections to two LMK03000 PLLs . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figure 4-2. Amontec USB-JTAG connector, and pin-out . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Figure 4-3. SignalyzerH4 USB-JTAG connector, and pin-out . . . . . . . . . . . . . . . . . . . . . . . 69
Figure 5-1. Example default SiliconInsight GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Figure 5-2. Example test type selection within a Test Step. . . . . . . . . . . . . . . . . . . . . . . . . . 74
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). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Figure 5-4. Example test controller options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Figure 6-1. GUI for calculating settings for LF jitter measurement . . . . . . . . . . . . . . . . . . . 95
Figure 7-1. Example of failures reported when no connections to the TAP pins, or TDO pin 102
Figure 7-2. Example failure due to test not completing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Figure 7-3. Console display of jitter histogram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Figure 7-4. Measuring Repeatability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Figure D-1. Jitter Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Figure D-2. Jitter Frequencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Figure F-1. GUI for calculating settings for LF jitter measurement . . . . . . . . . . . . . . . . . . . 136
8
March 2014
List of Tables
Table 5-1. LMK030xx and LMK040xx Parameters, Default Values, and Ranges . . . . . . . 76
March 2014
Chapter 1
Introduction
Embed Test Circuitry in Your IC Design to Test
SerDes or PLLs
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 Mentor Graphics Database (LVDB) with all data necessary for automated test
generation
Characterize and Diagnose Silicon
Performance
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
Generate Production Test Patterns for Your IC
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,
Introduction
Generate Production Test Patterns for Your IC
March 2014
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 Users 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.
Note
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 Mentor Graphics Tessent-specific terms, refer to the Tessent Glossary.
March 2014
Chapter 2
Step 1: Prepare Your Design
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).
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:
PLL/DLL Suitability
March 2014
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 inputsthe 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.
PLL/DLL Suitability
To be tested by PLLTest, your PLL or DLL must have at least the following two ports and port
functionality (logic may be inserted manually or automatically to provide the required polarity
to the PLLTest ports):
1. ReferenceClock
The PLLs output is assumed to phase lock to the rising edge of this signal.
2. OutputClock(s)
The frequency of this output must be an integer ratio to the ReferenceClock frequency
during PLLTest testing, where the denominator is 8 or less. For example, 70/3, 5/8, and
72/9 (=8/1) are acceptable integer ratios, but 7/9 is not acceptable.
Other ports and functionality that might be connected to PLLTest to enable more test
capabilities:
LockDetect
PLLTest can measure lock time only if the PLL has a phase-lock indicator output.
DividerValue(s)
PLLTest can measure lock range and lock time if the PLLs divider values can be
changed.
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
General Implementation Strategy
March 2014
equalization (FFE), decision-feedback equalization (FFE), then these must be frozen or disabled
during testing.
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
In this Step, perform the following operations:
Step 1.1 ETChecker
March 2014
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
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
March 2014
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 ETChecker Reference 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.
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 Mentor Graphics TAP or WTAP, but you can
have a second TAP on your chip. For this step, the Mentor Graphics 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.
March 2014
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 Mentor Graphics TAP used by
SerdesTest (or PLLTest) is the secondary TAP, then a signalling 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 17. 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 17, after the Slave TAP is
selected, the Master TAPs 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 TAPs IR and DR registers, restores SelLV back to 0, and, thus, enables the Master
TAPs 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.
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.
Step 1.3 Indicate Design Files
March 2014
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 modules LVDB file, and to point to the
modules design directory:
-lvdbDir \
<path>/DFT/<module>_LVWS/ETSignOff/
<module>.lvdb_preLayout
or, if it exists
-lvdbDir <path>/DFT/finalLVDB/<module>.lvdb
March 2014
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) {
Step 1.4 Check Clock Tree
March 2014
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
Use the command:
make <chip>.clockInfo
Note
The make command parameters are case-sensitive.
If you do not use batch mode, the interactive ETChecker GUI will open.
Click on Run/Analysis or its arrow icon to run SpyGlass analysis of your design.
Check the ETChecker console for errors.
To view a block schematic version of your RTL, double-click on your top-level file in
the Design Files (left) sub-window, then click on Tools/ModularSchematic or its nand-
gate icon. Navigate around your design in the schematic viewer as follows:
To trace a wire visually, click on the wireit will be highlighted.
To view inside a block, double-click on the block. Any highlighted wire will
continue inside the block.
Step 1.5 Check DFT Rules
March 2014
Note
Any module with an internal WTAP (and the LVDB directory) will appear as an empty
shell so that no checks are done inside, since the module was checked before its LVDB
was created.
To zoom in, click in top-left corner of the window you want to zoom and drag the
cursor to bottom-right corner of the zoomed window.
To zoom out a little, click and drag cursor up to the right.
To zoom out completely, click and drag cursor to down to the left.
To go up in the hierarchy, click and drag cursor up to the right.
The errors and warnings are saved in an output file:
etCheckInfo/etchecker.rpt_clockInfo_<chip>
Step 1.5 Check DFT Rules
Use the command:
make <chip>.ruleCheck
If you are not using batch mode, the same ETChecker GUI will open again. Repeat the
GUI procedure from Step 1.4 Check Clock Tree.
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
Step 1.6 Check Default Files
March 2014
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.
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
Caution
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
Caution
- 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
March 2014
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.
}
}
Step 1.7 ETPlanner
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
modules pre-synthesis LVDB directory (omit this option if you have a post-synthesis or
Step 1.8 Check Default Parameters
March 2014
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.
The DFT/<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)
March 2014
// 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
Step 1.9 CUT Type
March 2014
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 lateryou 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
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 PLLs 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
Step 1.10 Collect Design Information
March 2014
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.
Figure 2-5. Design Hierarchy for PLL (or DLL)
To create an ETPlanner configuration fileDFT/<chip>.etplan) in Step 1.11 Update
.etplan, you will need to know 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 clocks 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
March 2014
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 PLLs 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(pllReference) IC pin(s), single-ended or differential, that is the source of each
PLLs reference clock; different pins may be listed for each PLL. You may list a default clock
that is to be used by all PLL modules, and you may list a different one for any individual PLL.
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 logics
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 PLLs input port for its reference clock. The PLLs 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 R
th
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 PLLs 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 PLLs 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
Step 1.11 Update .etplan
March 2014
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 (described in Step
5.6 Measure lock time).
VcoFrequencyMultiplier This parameter indicates the ratio between the PLLs internal
voltage-controlled oscillators frequency and the PLLs input reference clock frequency.
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 PLL. 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 is not operating. Typically, these signals control PLL division ratio, loop
filter, delay, etc.
Copy and edit the following example text into the EST wrapper of the DFT/<chip>.etplan file,
(which is for the design shown in Figure 2-5 on page 26):
Module (<chip>) {
EST (<prefixForULTRAs>) { // Repeated for every PLLTest group
ClockPeriod : 10.0; // PLLs nominal reference clock period (ns)
LockTime : 0.02ms; // PLLs 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 // PLLs 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) { // PLLs 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)
March 2014
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 86.
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
Step 1.12 PLL Interface
March 2014
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).
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-6. Use a module name and port names that are consistent with your
<chip>.etplan file.
Figure 2-6. 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
Step 1.13 On-chip sampling clock generation
March 2014
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-7. Controlling a PLL for Lock Time and Lock Range Measurement
After you add the interface module, run (again) Step 1.4 Check Clock Tree, and Step 1.5
Check DFT Rules
Proceed to Step 2: Embed Test Circuitry.
Step 1.13 On-chip sampling clock
generation
There are two ways to obtain a sampling clock on-chip without using a second clock input to the
IC:
Use a PLLs reference clock to sample the PLLs output clock;
Use the output clock of one on-chip PLL to sample the output of another PLLs output
clock.
March 2014
Using the PLLs reference clock is simplest but only allows sufficiently fine resolution when
the PLL has a ten or more bits in its feedback divider. This clocking also prevents PLLTest from
measuring input clock duty cycle, input-to-output phase delay, and separated input and output
jitter. Using a second on-chip PLL is more complex but allows finer measurement resolution for
the same number of bits, and allows measurement of input clock parameters. In either case,
when choosing the sampling clock frequency and the frequency to measure, note that:
A higher sampling frequency permits shorter test times: 2X higher reduces measurement
time by 4X.
A higher PLL output frequency permits finer sampling resolution: 2X higher permits 2X
finer resolution.
Using the PLLs reference clock
If you want to use your PLLs reference clock to sample that PLLs output clock, as shown in
Figure 2-8, then use the following procedure to find the smallest sampling resolution you can
easily choose a coarser resolution. Typically, the finest sampling resolution possible is
approximately equal to the PLLs output frequency divided by the PLLs largest possible
feedback divider. If the finest resolution is too coarse, then you will need to use a second on-
chip PLL to generate the sampling clock, as described later.
Figure 2-8. Example PLL, and connections when reference clock is the
sampling clock
As an example, assume the PLL-to-be-tested has the following specifications:
VCO range: 2.6~3.3 GHz
PFD input range: 1~20 MHz
Input divider range: 2~32 (5 bits)
Feedback divider range: 4~1024 (10 bits)
March 2014
Output divider range: 2~8 (3 bits)
f
OUT
= f
REF
feedbackDiv / (outputDiv inputDiv)
Procedure for calculating the finest sampling resolution possible when using the PLLs
reference clock to sample the PLLs output clock:
1. The objective is to find a reference frequency and dividers for the PLL so that the PLL
effectively multiplies the reference frequency by K(N-1)/N, where K is the nominal
integer ratio of the PLLs output to input frequency, and N is any integer. The PLLs
feedback divider will equal K(N-1).
2. Choose the PLL output frequency at which you wish to measure PLL performance.
e.g., f
OUTmin
= 500 MHz
3. Choose the largest possible output divider that keeps the VCO frequency in its range.
e.g., choose outputDiv
max
= 6; so that f
VCO
=3000 MHz
4. Choose the largest possible input divider.
e.g., choose inputDiv
max
= 32
5. Choose the highest practical reference frequency for test that is equal to f
OUTmin
divided
by an integer, f
REF
= f
OUTmin
/ K .
Choose a value that keeps the PFD input frequency within range.
e.g., choose 50 MHz and K=10;
f
REF
/ inputDiv
max
= 50 / 32 = 1.5 MHz, which is within the PFDs 1~20 MHz
range.
6. Calculate feedbackDiv
max
= outputDiv
max
inputDiv
max
K 1 .
e.g., feedbackDiv
max
= 6 32 10 1, e.g., 192 10 1 = 1919
7. If feedbackDiv
max
is too large for the divider, then choose a smaller input or output
divider so that the resulting feedback divider will be within its range and f
REF
/ inputDiv
will be within the PFDs range.
e.g., feedbackDiv
max
is too large by a factor of 2, so choose inputDiv
max
= 16,
50/16=3.1 MHz, which is within the 1~20 MHz range.
Recalculate feedbackDiv
max
.
e.g., feedbackDiv
max
= 6 16 10 1, eg. 96 10 1 = 959
8. Calculate the exact PLL output frequency to be used, and its period T
OUTexact
-
f
OUTexact
= f
REF
feedbackDiv
max
/ (outputDiv
max
inputDiv
max
)
e.g., f
OUTexact
= 50 959 / (6 16) = 499.479167 MHz; T
OUTexact
= 2.00208 ns
March 2014
9. Calculate the minimum sampling resolution: T
RESmin
= T
OUTexact
K 1/f
REF
e.g., T
RESmin
= 2.002008ns 10 1/(50MHz) = 20.0208ns 20ns = 20.8ps
10. If this is finer than you need, then choose a smaller inputDiv and recalculate
feedbackDiv.
To measure jitter, sampling resolution should be 1~0.3X the expected RMS value.
To measure phase delays or duty cycle, resolution should be 0.2~2% of the PLL
output period.
11. If you need finer sampling resolution, then:
a. Choose a higher PLL output frequency.
b. Choose a larger feedback divider (if it is external to PLL).
c. Choose a different PLL.
d. Use two PLLs, as shown in Figure 2-5, and described next.
Using another PLLs output
If you need to use a second PLL, you must find a reference frequency and dividers for the two
PLLs so that the ratio between the two PLL output frequencies is (N-1)/N and the PLL output
frequencies are close to your target values. For example, the finest sampling resolution that can
be obtained with two of the PLLs from the previous example is approximately 0.5 ps, with a
frequency ratio of 4016/4017, using the following dividers and frequencies:
PLL1: f
REF
=52 MHz, inputDiv=13, outputDiv=6, feedbackDiv=753, f
OUT
=502.0 MHz
PLL2: inputDiv=16, outputDiv=6, feedbackDiv=927, f
OUT
=502.13 MHz
To keep the sampling frequency low enough that timing closure can be easily achieved during
synthesis and layout of PLLTest (its circuitry operates at the sampling rate or at TCK rate), you
can divide one of the two PLL outputs by the smallest integer that produces a low enough
sampling frequency. This will also make the sampling resolution coarser by the same integer.
For example, if the maximum desired PLLTest clocking rate is 400 MHz, then for the above
example, f
SAMPLING
= f
OUT
/2 = 251.06 MHz, and the finest sampling resolution is T
RES
= 1 ps.
The LV_ClockGenerator GUI software (Figure 6-1) is used to find optimal divider values for
two off-chip PLLs (to generate f
REF
and f
SAMPLING
), specifically National Semiconductors
LMK03000 family of clock conditioners. That family of PLLs has the architecture shown in
Figure 2, which is different than the PLL architecture shown in Figure 1 and possibly different
than your PLL. The LV_ClockGenerator GUI can be used to find optimal settings for many
PLL architectures, as will be described.
March 2014
Figure 2-9. Architecture of LMK03000 PLL
Here is the heuristic procedure to find the finest sampling resolution possible when using one
PLLs reference clock to sample the output of another PLLs output clock. The procedure
requires the use of Mentors LV_ClockGenerator GUI software, which is available by special
request to your Mentor Technical Marketing Engineer. (The procedure is relatively complex so
it may be automated in a future release, but it usually needs to be performed only once per
design.)
1. Enter the target PLL reference input frequency (it will be used for both PLLs).
e.g., 50 MHz
2. Enter the target PLL output frequency as DUT input reference clock nominal
frequency (initially, well assume both PLLs will use approximately the same output
frequency).
e.g., 500 MHz
3. Enter a value of 1 for the DUT on-chip PLL frequency multiplier.
4. Use a value of 4, 8, 10, 16, or 20 for the Parallel word width it has no effect.
5. Use a value of 1667 or 2500 for the Golden PLL LF cutoff frequency it has no
effect.
6. Enter a target User-requested sampling resolution.
If the target PLL output frequency is too high as in input to PLLTest logic for you to
easily achieve timing closure of the PLLTest logic, then assume you will later use a
divider integer on the output of one of the PLLs, and divide your target resolution by
this integer to obtain the value to enter.
e.g., if f
MAX
=400MHz, and 1 ps resolution is required, then enter 0.5 ps
7. Select resolution as the Basis for Frequency offset.
8. Enter a Tolerable resolution error that is 100 fs less than your Target sampling
resolution.
March 2014
e.g. 400 fs (if resolution target is 0.5 ps)
9. Observe the Messages window of the GUI.
If it says Operating range error, then try selecting a different PLL Model
(LMK03000, etc.).
If it says The frequencies must be coherent to each other, then choose one of
the OSCin frequencies provided.
If no choice of PLL Model produces an error-free result, then choose a lower DUT
input reference clock frequency.
At any time, you can save the present values or load previous one by clicking on
File.
If you have made changes, when you exit from the GUI, a pop-up window will ask
you to:
o Save & Exit save the values you entered for the next time you open the GUI
(default filename for saved data is LV_ClockGenerator_LMK030xx.config)
o Exit exit without saving values, so next time it will use other saved values.
Caution
The values provided are for the LMK PLL architecture of Figure 2-9, so the equivalent
feedback divider of the PLL in Figure 2-8 equals the GUIs VCO output divider times
Feedback divider, N. The GUI always chooses values that keep the LMKs VCO in its
required range, but you will need to ensure that the result will be within your PLLs
range.
10. The Clock Generator #1 and #2 divider values (blue font) are acceptable for the chosen
input frequency when both Feedback divider N values are low enough for your PLLs
divider and VCO range, and they are locally optimal if the divider values are within 20%
of each other.
o e.g., The example PLLs VCO frequency is ~3 GHz but the LMK is ~1.5 GHz,
so the GUI-calculated feedback divider must be doubled to use it for the example
PLL. Therefore, the target feedback divider in the GUI will be 512.
Try each of the following iteratively to optimize the Clock Generator divider values.
Choose the OSCin = frequency, if acceptable, that maximizes the PFD input
frequencies
Increment the DUT input reference frequency to see if the Feedback divider
values continue to diverge; try decrementing too.
e.g., Example iterations for 50 MHz in, 500 MHz out, 0.5 ps target resolution, 400 fs
tolerance
March 2014
o Result: PLL#1 = 320/(231); PLL#2 = 33991/(39931); OSCin = 52
MHz
o PLL#2 numerator is >512, so optimize further by using the recommended
OSCin.
o Enter 52 MHz as new PLL reference input frequency
MHz
o PLL#2 numerator is >512, so optimize further by incrementing output
frequency.
o Enter 501 MHz as new DUT input reference clock
MHz
MHz
o Both numerators are >512, but both input dividers (26, 32) can be divided by 2
to get the 3 GHz VCO output, and both output dividers (3,3) can be multiplied by
2 to maintain same ratio. Resolution is 0.5 ps, but after dividing by 2 to get <400
MHz, it will be 1.0 ps. Try optimizing further by decrementing the output
frequency.
o Enter 499 MHz as new DUT input reference clock (with 52 MHz input)
o Result: PLL#1 = 3499/(5231); PLL#2 = 348/(531); OSCin = 62 MHz
MHz
o Enter 45 MHz as new PLL reference input frequency
MHz
o Both numerators are <512, and OSCin is optimal and low, but resolution is 0.86
ps, which is coarser than the 0.5 ps result.
11. When optimal Clock Generator #1 and #2 divider values have been found, calculate the
divider values that meet the requirements of your PLL (since the ClockGenerator
software chooses values for the LMK03000 architecture, not your PLL).
If your PLL uses the architecture of Figure 2-9, and has a similar VCO frequency
range and PFD input frequency range, then you can use the GUI-computed values.
March 2014
If your PLL architecture is different, you will need to calculate the equivalent
divider values, and ensure that the VCO frequency is within PLLs VCO range.
For the example PLL
o The VCO range is ~3 GHz, and the LMKs VCO range is ~1.5 GHz, so two
extra factors of 2 are needed that cancel each other, but drive the VCO to 3 GHz.
o The input divider is in the same position as the LMK, so the GUI value can be
used for the example PLL, after dividing by 2 to get the higher VCO frequency.
e.g., PLL1-inputDiv = 13; PLL2-inputDiv = 16
o There is only one feedback divider, but the LMK has two dividers in series
multiply the GUIs VCO output divider by the Feedback divider, N to
produce the feedback divider for the example PLL.
e.g., PLL1-feedbackDiv = 3 251 = 753; PLL2-feedbackDiv = 3 309 = 927
o The output divider is connected directly to the VCO output, but the LMK output
divider is connected to the VCO output divider multiply the GUIs VCO
output divider value by the Output-specific divider to produce the output
divider for the example PLL, and use a 2X larger output divider because of the
2X higher VCO frequency.
PLL1-outputDiv = 321 = 6; PLL2-outputDiv = 321 = 6
o PLL1 f
OUT
= 52 MHz 753/(136) = 502.00 MHz, T
OUT
= 1.9920 ns;
PLL2 f
OUT
= 52 MHz 927/(166) = 502.13 MHz, T
OUT
= 1.9915 ns; T
RES
=
0.5 ps
o Outside the PLL, add a divide-by two to obtain a sampling clock below 400
MHz. Therefore, the sampling clock would be 251.06 MHz and T
RES
= 1 ps.
March 2014
Chapter 3
Step 2: Embed Test Circuitry
Step 2.0 Check .etplan
Set your current directory to DFT .
Use the command:
make checkPlan
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
Use the command:
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.3 Generate & insert RTL
March 2014
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
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 .
March 2014
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 Mentor Graphics 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).
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
}
Step 2.4 Check connectivity
March 2014
ModuleName may refer to an RTL multiplexer module in your design directory, or to a specific
cell in the ICs 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 modules 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, 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.
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.
Your current directory should be DFT/<chip>_LVWS/ETAssemble
March 2014
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 blocks <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 44 (for initial
working directory named mydesign, and a chip named CHIP).
Step 2.5 Prepare for simulation
March 2014
Figure 3-1. File hierarchy for <chip> = CHIP
Set your current directory to DFT/<chip>_LVWS/ETAssemble
March 2014
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
...
serdesVerify(<chip>_<prefix>_P2) {
PatternName : serdesv_P2_<chip>_<prefix>;
...
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;
March 2014
...

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.
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.
<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.
User Defined Sequence
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-
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
March 2014
}
} // 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);
Verilog to SVF conversion
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, eg. 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
March 2014
Running the normal simulation with the extra SignalStrobe module will generate an output file
called Data.strobe which will look 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
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 will then look 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 that PIO patterns cannot be applied to TAP pins: you must use other SVF commands (like
RUNTEST) for TAP pins.
A UserDefinedSequence can be applied immediately before or after the Mentor Graphics TAP
is reset/accessed, as follows:
etv (<designName>) {
...
UserDefinedSequence (<sequenceName1>) {
...
}
...
...
PreTAPUserDefinedSequence : <sequenceName1>;
}
}
PreTAPUserDefinedSequence - applied immediately preceding the TRST pulse and
five consecutive 1s on TDI that resets the TAP at the beginning of each test pattern. If
you have a Master/Slave TAP, you will need this type of UDS.
PostTAPUserDefinedSequence - applied immediately following the TRST pulse
and five consecutive 1s 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
March 2014
Step 2.6 Generate LVDB
Use the command:
make lvdb_preLayout
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 58.
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. ModelSim, 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.
Step 2.8 Simulate
March 2014
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.
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 ETChecker schematic viewer, use the command:
make schematicView
If it runs without errors, then use the command:
etchecker <chip> -mode loadVdbFile
In the ETChecker GUI, click on the left-hand side Design tab.
Step 2.8 Simulate
March 2014
Double-click on the design entity that you want to look at,
for example, <chip>
Click on the Modular Schematic icon (nand-gate) at top of the GUI
See Step 1.4 Check Clock Tree for how to use the schematic viewer to explore
your design.
Exit the windows when finished.
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.
Step 2.8 Simulate
March 2014
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 simulations
March 2014
Here is the recommended diagnostic procedure. Each step must be successful before proceeding
to subsequent steps; skipping steps can cause frustration and waste time. Jumping ahead to the
P3 test before the preceding tests pass would require you to diagnose simultaneously several
potential problem areas (offset frequency, lock time, set-up and hold times, etc.).
tapbistv and P1 patterns
For the tapbistv and P1 patterns (test TAP function), your PLL is not involved, so just verify:
TRST input to SerdesTest module is logic 1;
TDI, TMS, and TCK pins and inputs to PLLTest module toggle;
TDO pin driver is enabled (active low) by PLLTest;
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 PLL is initialized;
your simulation timing resolution is less than or equal to 0.1% of your PLL output
period (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 PLL;
the clock period supplied to ULTRA is the same as the
ClockSource(testClock)pin and has the ClockPeriod stated in
<chip>.etplan.
the reference clock period supplied to your PLL from the
ClockSource(pllReference)pin has a period that is 0.1% less than the
ClockPeriod stated in <chip>.etplan;
the period of the signal from the A and B outputs of the
<EST_wrapper_Name>_LV_ULTRA_RPA is 2000 times the PLLs reference clock
period and have a 90-deg offset between them.
the clock provided to the PLLTest module's RXREF_CLK input is inverted relative to
its RXREC_CLK signal;
March 2014
the test passes.
P3 pattern
For the P3 pattern (RmsJitter: on-chip RMS jitter measurement on the first PLL output
identified in the ClockOutputs wrapper of the <chip>.etplan), verify:
your PLL initialization and all clock periods are the same as specified above for P2;
RxWord[2] pulses each have a duration of 500 +/-2 sampling clock periods, divided by
the PLL output to input frequency ratio, after the declared LockTime;
the frequency of the PLL output sampled to produce RxWord[2] is an integer multiple
of the PLL's reference clock frequency (if you chose a fractional ratio, then you must
insert a different sampling clock period for this test in the .etSignOff file).
the test passes.
Step 2.10 Synthesize logic gates
March 2014
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 56, 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.
Step 2.12 Prepare for layout
March 2014
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
_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
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 49 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
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.
Step 2.13 Prepare for sign-off
March 2014
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/concatentated_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 58.
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
March 2014
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.
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
Step 2.16 Generate post-layout simulation test bench
March 2014
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
To start SiliconInsight, use the command:
make eta_offline
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).
Step 2.17 Simulate post-layout
March 2014
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
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 section on page 51.
If these simulations run successfully for a module, you are ready to incorporate it within a chip,
and connect the WTAP to the chips 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.
Step 2.19 Archive Files
March 2014
Return to using the latest software directory with a command like:
setenv PATH /wv/lvs_rls/prod/tessent/ETCreate/bin:$PATH
Use the command:
etv <chip> -configFile <chip>.etManufacturing \
-wgl on -tcmFile <chip>_lvdb_preLayout/<chip>.tcm
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.
Set your current directory to DFT
Use the command:
make archive_config
to produce a file DFT/<chip>_LVWS/<chip>.archiveList that lists all files to
be archived from the LVWS directory.
Use the command:
make archive
to save all the listed files into a file DFT/<chip>_LVWS.tar.gz
Use the command:
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.
March 2014
March 2014
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
Choose a board clocking scheme. Here are considerations:
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 doesnt 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, 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
Step 3: Prepare a Board to Characterize Your IC
Step 3.0 Clocking
March 2014
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. Mentor can
provide to you a Tcl routine or Excel spreadsheet that allows you to explore the frequency
possibilities.
LMK03000C: 1185~1296 MHz VCO; max. f
OUT
= 640 MHz
LMK03001C: 1470~1570 MHz VCO; max. f
OUT
= 780 MHz
LMK03002C: 1566~1724 MHz VCO; max. f
OUT
= 860 MHz
LMK04000: 1185~1296 MHz VCO; max. f
OUT
= 640 MHz
LMK04010: 1185~1296 MHz VCO; max. f
OUT
= 640 MHz
LMK04001: 1430~1570 MHz VCO; max. f
OUT
= 780 MHz
LMK04011: 1430~1570 MHz VCO; max. f
OUT
= 780 MHz
LMK04031: 1430~1570 MHz VCO; max. f
OUT
= 780 MHz
LMK04002: 1600~1750 MHz VCO; max. f
OUT
= 860 MHz
LMK04033: 1840~2160 MHz VCO; max. f
OUT
= 1080 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 65, 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.
Step 3.0 Clocking
March 2014
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.
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
Step 3.0 Clocking
March 2014
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
March 2014
Step 3.1 Loopback
The step only applies to SerdesTest.
Step 3.2 JTAG
Provide suitable 1149.1 TAP (JTAG) access for SiliconInsight's USB-to-JTAG module
(Amontec or Signalyzer). The module's output signal levels are the voltages connected to its
GND and VCC pins. Note that only 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 two USB-JTAG modules:
USB-Amontec
The Amontec JTAGkey-Tiny module's minimum output logic 1 is 2.8 volts, its minimum
detected logic 1 is half that voltage, and it connects to only 4 signals (TCK, TMS, TDI, and
TDO) with specific positions.
Ensure that the DUT's TRST pin can be separately connected to VDD when the
Amontec module is connected.
Ensure that a resistive divider is provided if your IC's voltage levels are <2.8 V.
If your IC's voltage swing is <2 V, then you must use the Signalyzer so that TDO logic
values will be reliably detected.
The connector should be a standard 20-pin header, 2 x 10 pins with 100 mil spacing, and
signals and power assigned as shown in Figure 4-2 (use VDD of ICs TAP pins).
The module can drive only high-impedance inputs having pull-ups >2k ohms and pull-
downs >10k ohm.
Note that all Amontec GND pins are a single node and could short circuit your boards
power supply if connected incorrectly.
Step 3.2 JTAG
March 2014
Figure 4-2. Amontec USB-JTAG connector, and pin-out
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 Users 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.
Step 3.3 Board Components
March 2014
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 boards
power supply if connected incorrectly.
Figure 4-3. SignalyzerH4 USB-JTAG connector, and pin-out
Caution
For the SignalyzerH2 and SignalyzerH4 adaptors, 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.
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 as described in Step 1.13 On-chip sampling clock generation.
10 MHz crystal - optional if PLLs' input reference clock is provided from a crystal or
external source.
Step 3.4 .pinmap File
March 2014
USB-to-microWire socket: a standard 26-pin header as shown in Figure 4-3.
Step 3.4 .pinmap File
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
}
March 2014
Chapter 5
Step 4: Prepare SiliconInsight to
Characterize Your IC
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.
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).
Step 4: Prepare SiliconInsight to Characterize Your IC
Step 4.1 Power up
March 2014
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.
Step 4.1 Power up
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
March 2014
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
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
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.
Step 4.4 Choose test type
March 2014
Caution
If you change the Step Name, then you must click on Apply before changing any other
Test Step options (eg. 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 on page 74.
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.)
Figure 5-2. Example test type selection within a Test Step
Step 4.5 Set global clock periods
March 2014
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).
March 2014
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 PLLs 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 devices 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)
March 2014
Table 5-1 Notes:
(n/a) Not available for this device.
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)
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. LMK030xx and LMK040xx Parameters, Default Values, and Ranges
LMK030xx LMK040xx
Parameter name Default Range Default Range Notes
March 2014
(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.
(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
March 2014
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
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.
Step 4.7 Set clock periods for single Test Steps
March 2014
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).
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.
Step 4.8 Add Test Group
March 2014
Caution
You should always use the procedure in Step 4.5 Set global clock periods on
page 75 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 it is always
PHalfWord for a SerDes, regardless of user choice.
March 2014
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 80.
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.
User Defined Sequence
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
cancelling the effects of the SVF pattern).
March 2014
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 what 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.
If you click on Clear All, under DR Aliases, then all bit values are set to Off
(logic 0) and you can click on the individual bit numbers in the DR Bits area to set a
bit to 1. If you click on Clear All under DR Bits, then all bit values are set to logic 0
and you can edit the DR Aliases area values.
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,
Click on OK, then run the test by clicking on the Diagnose icon.
Choose Test Controller (ULTRA) options
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.
March 2014
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.
March 2014
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; % 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
March 2014
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
March 2014
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).
Reference Clock Jitter
This test measures jitter in the on-chip reference clocks, independent of the SerDes or PLL
under test.
March 2014
Within the ReferenceClocks Test Group, add another Test Step with at least one
ULTRA controller, and name the Test Step something like ReferenceClockJitter.
window of Figure 5-2 on page 74.
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
March 2014
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).
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., J
rms
2
= J
1rms
2
+
J
2rms
2
. 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.
Caution
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.
See Use SiliconInsight to Characterize Your PLL.
March 2014
March 2014
Chapter 6
Step 5: Characterize your PLL
Use SiliconInsight to Characterize Your PLL
At this stage, if you have implemented all of the preceding instructions, you have added Test
Steps that test the entire JTAG and PLLTest infrastructure, and these tests will typically take
less than 25 ms to run in a production test program. Next, tests for the PLL or DLL will be
described, in the following order, which is recommended for easiest diagnosis:
PLL output
Clock input to output delay
o HF jitter
o LF jitter
Measure waveform
o Duty cycle
o Frequency
Clock input to output delay
o Measure phase delay
o Phase error for each output vs. input
Phase locking
o Measure lock time
o Duty cycle of lock detector, for 1 beat period after PLL's divider altered
o Measure lock range
Caution
The rest of Step 5 describes how to use Silicon Insight if you used the PLL-based design
flow (ChannelType : PLL, in your .etplan file) to add BIST. If you used the SerDes-based
flow (ChannelType : Serdes, or no ChannelType statement at all), then refer to Appendix
F Step 5: SerDes-Based Design Flow for PLLTest for the rest of Step 5.
March 2014
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.
For PLLs, the choice of frequency is more determined by the desired sampling resolution,
remembering that finer resolution sampling will include more LF jitter.
For PLLTest, the sampling resolution is the difference between the sampling clock period and
the nearest frequency that is synchronous to the sampled clock frequency:
T
RESOLUTION
= | N T
PLLOUT
- T
SAMPLING
|
For an example PLL with 50 MHz input, 400 MHz output, and ~50 MHz sampling clock:
T
RESOLUTION
= | 8 2.5ns - 20.001ns | = 1 ps
Implementing PLL/DLL Tests
Create a new Test Group, and named something like PLLOutput.
Step 5.1 Measure HF jitter
This test measures the HF jitter in a clock signal. For a PLL, this jitter is mostly caused by VCO
input and power rail noise. If the PLLTest sampling rate is equal to the sampled signal's
frequency (minus an offset) or half this, then the test will be sensitive to cycle-to-cycle jitter; but
you will likely use a much lower sampling frequency. If the sampling rate is much less than the
sampled signal's frequency, then the test will only be sensitive to period jitter.
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 PLLOutput 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 OutputJitter_HF.
window.
Click on the pull-down menu beside PLL Test, and choose JitterFromCDF (if it is not
already selected), or Jitter to measure its RMS value.
March 2014
Note
The results for this test will be affected by the reference frequency offset because the low
frequency cut-off is linearly dependent on the frequency offset (and because the
measurement's resolution is also linearly dependent).
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).
If more than one PLL Sampler module is connected to the ULTRA, then click on the
number beside PLL to Test that corresponds to the PLL you want to test.
Click on Signal To Measure, and select pllOutput or pllInputClk. This measures jitter
as sampled by one of the inputs to ULTRA.
If you chose pllOutput, click on the number beside Data Bit Number and select the
input of your Sampler module that is connected to the PLL output of interest. Dont
select 0 or 1 because 0 samples the PLL input reference clock divided by two, and 1 re-
samples that value. (If you chose pllInputClk, the Data Bit Number is ignored.)
Caution
You must choose a PLL output-to-input frequency ratio that is appropriate for the
sampling resolution you choose. For maximum ppm offset permitted according to the
<chip>.etplan file, which is 1956, the maximum PLL out/in frequency ratio is 15. If the
ppm offset is reduced by half, to 1000 (or 0.1%) for example, then the PLL out/in ratio
can be increased to 30. This ensures sufficient samples per output clock period.
Data Bit Number
By default, all tests are performed on the DataBit[2] input to PLLTest, corresponding to the bit
0 of the PLLOUTPUTS bus. The other PLLTest inputs are connected to higher-numbered PLL
outputs, as shown in Figure 2-6, and any one of them can be chosen in the Data Bit Number
pull-down menu.
DataBit[0] is connected a sampled version of the PLL's reference clock input for use as a phase
reference. DataBit 1 is a resampled delayed version of the same clock. Only
DataBits 2~n-1 are sampled versions of outputs of the PLL that you connected in Step 1.12
PLL Interface section. The highest numbered Data Bit must be a sampled version of the PLLs
lock detector output (if there is one), so do not select it to measure jitter.
March 2014
Step 5.2 Measure LF jitter
This test measures the wideband jitter in a clock signal. For a PLL, this jitter is mostly affected
by loop filter bandwidth and PFD. This test actually measures HF+LF jitter, but LF jitter
usually dominates.
Caution
This test is very sensitive to LF jitter in the reference and sampling clocks. One clock
should be derived from the other using a telecom-quality PLL, as described on the next
page, since most clock generators do not have the required absolute frequency resolution
and accuracy (10 millihertz). Always compare LF jitter measured in your PLLs outputs
to that measured in the PLLs reference clock, since most PLLs track LF jitter and
transfer almost all input LF jitter to their outputs.
In your current directory, create a file with a name constructed as follows:
DLV_U_<testStepName>.lfjittercdf
For the example above, use
DLV_U_OutputJitter_LF.lfjitter
The contents of the file are:
BasePeriod : <Tbase>us;
ClockPeriodsDividers {
<RefClkPin> : <txDivider>;
<SamplingClockPin> : <rxDivider>;
}
where,
TBase is the period of the base reference frequency, which is the shortest period into
which fits exactly an integer number of Reference clock periods and an integer number
of Sampling clock periods;
RefClkPin is the name of the PLL input reference ClockSource(testClock) pin, as
named in the .etplan file;
txDivider is the integer number of Reference clock periods that exactly fits the Tbase
period;
SamplingClockPin is the name of the offset ClockSource(pllReference) pin, as named
in the .etplan file;
rxDivider is the integer number of Sampling clock periods that exactly fits the Tbase
period.
March 2014
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 Mentor Technical Marketing Engineer. 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-1.
Figure 6-1. GUI for calculating settings for LF jitter measurement
In the PLLOutput Test Group, click on the Test Step named OutJitter_HF, then
copy it into the same Test Group. Rename the Test Step to something like
OutputJitter_LF.
window.
March 2014
Click on the pull-down menu beside PLL Test, and choose JitterFromCDF (if it is not
already selected).
Click on OK.
of the Test Steps, and in the pop-up menu click on Edit as a Group).
Click on Signal To Measure, and select pllOutput. Then click on the pull-down menu
beside Data Bit Number and select a number corresponding to the PLL output of
interest. Alternatively, click on Signal to Measure and select pllInputClk.
Caution
You must use the JitterFromCDF test type to measure low frequency jitter. The Jitter
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).
Step 5.3 Measure duty cycle
This test measures duty cycle (or pulse width) for a clock signal.
In the PLLOutput Test Group, copy the OutputJitter_HF Test Step, paste it into the
same Test Group, and rename it something like OutputDutyCycle.
window.
Click on the pull-down menu beside PLL Test, and choose DutyCycleDistortion to
measure the duty cycle, relative to 50%.
Click on Signal To Measure, and select pllOutput. Then click on the pull-down menu
beside Data Bit Number and select a number corresponding to the PLL output of
interest. Alternatively, click on Signal to Measure and select pllInputClk.
DCD is reported after subtracting 50% from the measured duty cycle, but you must
provide test limits for the duty cycle without subtracting 50%.
Step 5.4 Measure clock frequency ratio
This test measures the PLL output frequency divided by the PLLs reference input frequency.
March 2014
More specifically, it counts the number of rising clock edges in the number of reference beat
periods that you indicate with Test Duration in Beat Cycles. If you set this value to 1, then the
measured result will simply be an integer. If you choose a larger number for Test Duration in
Beat Cycles, such as 10 or 100, then the measurement will show additional digits after the
decimal point. You must ensure that the frequency ratio multiplied by the USCR is equal to an
integer. For example, if the frequency ratio is known to be 6.25, choose USCR=4. Due to LF
jitter, the measurement always has some uncertainty, so measuring the number of edges in a
larger number of beat cycles will increase the accuracy.
same Test Group, and rename it something like FoutDividedByFin.
window.
Click on the pull-down menu beside PLL Test, and choose FrequencyMultiplier.
Click on OK.
of the Test Steps, and in the pop-up menu click on Edit as a Group),
Click on the pull-down menu beside Data Bit Number and select a number
corresponding to the PLL output of interest.
Step 5.5 Measure phase delay
This test measures the average phase delay, in picoseconds, from the PLL input reference clock
rising edge to any PLL output edge (rising or falling).
Create a new Test Group, and name it something like PLLInToOut.
PLLInToOut Test Group, and rename the Test Step something like PhaseDelay.
Click on the pull-down menu beside PLL Test, and select Delay.
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 the pull-down menu beside Data Bit Number, and select the number
corresponding to the PLL ouput of interest.
March 2014
Phase delays are measured in picoseconds, from minus one half of the PLLs reference clock
period, to plus one half of the period. Beyond that is ambiguous: for example, if the reference
clock period is 10 ns, an actual phase delay of +7 ns will be reported as -3 ns. Furthermore,
delay will be measured to the nearest edge in that range, so the maximum measurable delay for
a PLL output frequency that is higher than the input frequency is plus or minus one period of the
output frequency.
Step 5.6 Measure lock time
This test measures the total time that a PLL's lock detector output indicates that a PLL is not
locked, starting after the PLL is forced to lose lock (e.g., by altering its feedback divider value)
until the end of the measurement time, as set by Test Duration in Beat Cycles (number of
reference clock cycles). The beat period is the reciprocal of the frequency offset.
In Step 1.12 PLL Interface section and Connections for PLLs and DLLs section, you
connected a InterceptChangePLL signal to force the PLL to lose lock temporarily.
The InterceptChangePLL signal is inverted when ULTRA starts measuring input duty cycle,
and stays inverted for Test Duration in Beat Cycles (the beat period is the reciprocal of the
offset frequency).
The Step 1.12 PLL Interface connects the PLL's lock detector.
window.
Click on the pull-down menu beside PLL Test, and choose LockTime.
Click on OK.
Right click on the appropriate Test Controller and select Options.
Click on the pull-down menu beside Data Bit Number and select the number
corresponding to the lock detector output of your PLL it should be the highest
numbered input.
Enter a value for Test Duration in Beat Cycles that is greater than the largest expected
lock time divided by the period of the frequency offset. If the actual lock time is longer
than this duration, only the test duration will be reported.
For example, if your PLLs reference clock period is 100 MHz, and the frequency offset
is 1000 ppm (= 0.1%), then the offset is 100 kHz and its period is 10 s. If maximum
permitted lock time is, for example, 20 s, then you could set Test Duration in Beat
Cycles to twice that duration, which is 4 Beat Cycles.
March 2014
Optionally enter values for Test Limits, where the duration is in units of microseconds.
Test limits are in entered units of microseconds.
Step 5.7 Measure lock range
To measure lock range with PLLTest, you select a feedback divider value or input divider value
that causes the PLL to output the required minimum or maximum required frequency, and then
measure its output jitter (see Step 5.1 Measure HF jitter). Alternatively, you can measure
its lock time using the procedure in Step 5.6 Measure lock time, but ensuring that the new
divider value that is loaded into the PLL causes it to output its required highest or lowest
frequency. The advantage of measuring lock time is that any PLL output clock frequency can be
used, whereas jitter can be measured for only a subset of frequencies.
Go to Step 6: Diagnose and Characterize Tests.
March 2014
March 2014
Chapter 7
Step 6: Diagnose and Characterize Tests
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 102:
open/shorted connection between Amontec/Signalyzer and some or all TAP pins;
resistive loading on the TAP signal - check amplitude at IC pins;
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':
a connection is intermittent or resistive;
the manufacturer's code is incorrect (wrong IC version?);
TAP signals edges too slow, causing double-clocking as signal crosses through
switching point voltage;
TCK clock edges too fast, causing reflections and double-clocking;
resistive or capacitive loading on the TAP signal - check amplitude and rise times at
IC pins.
Step 6.1 Diagnose Measurement Failures
March 2014
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;
March 2014
the transmitted data pattern is inappropriate;
excessive jitter is preventing detection of a signal edge (merges into next edge).
use a shorter loopback path
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
use P1100 instead of P1010, to allow more time between jittery edges
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);
insufficient samples for a repeatable result;
faulty parametric performance;
insufficient design margin.
Try the following:
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.
increase the Test Duration in Beat Cycles, to make the result more repeatable;
Step 6.2 Diagnose Jitter Measurements
March 2014
increase the Measurement Upper Limit
for negative results, the Upper Limit must be less negative than the result);
decrease the Measurement Lower Limit
(for negative results, the Lower Limit must be more negative than the result);
examine the shape of the jitter histogram see 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
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:
March 2014
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)
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,
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
Step 6.3 Check Lock Time Impact
March 2014
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
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.
Step 6.4 Measure Repeatability
To measure a test's measurement repeatability, refer to Figure 7-4 on page 108, and perform the
following operations:
Right-click on Test Step
Step 6.4 Measure Repeatability
March 2014
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:
Step 6.5 Calculate Test Times
March 2014
Successfully updated
Figure 7-4. Measuring Repeatability
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
Test time = 100 bits / TCKFrequency(Hz)
March 2014
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
PLLTest: RelativePatternLength = PLLReferenceFrequency / MeasuredFrequency
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
JitterFromCDF
Test time = Test time for Jitter + histogram analysis time
Step 6.6 Optimize Test Time
March 2014
FunctionalLoopback
PLL test time = Test Duration in Beat Cycles / Frequency Offset(Hz)
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)
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
The internal loop filter can be selected via the Test Step that programs the PLL
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
Mentor Graphics can provide software that helps you select optimal values
Choose a larger frequency offset for all phase delay measurements
Test time is proportional to the reciprocal of offset frequency.
Whereas Jitter measurements require the correct LF cut-off frequency, phase delay
measurements have no such requirement.
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)
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).
Step 6.7 Characterize many devices
March 2014
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
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.
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.
March 2014
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.
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.
Step 6.8 Creating scripts for characterization and testing
March 2014
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.
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>
March 2014
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:
March 2014
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
March 2014
March 2014
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
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
If you are generating tests for PLL but you used the SerDes-based design flow (and the
SiliconInsight Desktop steps in Step 5: SerDes-Based Design Flow for PLLTest in
Appendix F), then use the command:
setenv LV_ET_PLL 1
Use the command:
etv <chip> \
-configFile <chip>.etManufacturing \
-wgl on
Step 7.2 Write Test Program
March 2014
Instead of -wgl, you can specify any one of the following runtime options:
-stil, -svf, -verilog
This will produce a file <chip>.TestProgramSequence
which 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 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 Mentor Technical Marketing Engineer.
Note
Some of the jtagVerify test steps cannot be performed with .svf because those tests end
in intermediate TAP states.
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
March 2014
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[(1
2
histValue1) + (2
2
histValue2)
+ + (32
2
histValue32)] / [cdfValue32]
Variance = MeanSquaredDev - MeanDeviation
2
RMS
bins
= squareroot(Variance)
psPerSample = f
OFFSET
/ (f
TXREF
f
RXREF
)
psPerBin = psPerSample samplesPerBin
RMS
picoseconds
= psPerBin RMS
bins
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 .
March 2014
March 2014
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 Mentor
Graphics Support.
Documentation
A comprehensive set of reference manuals, user guides, and release notes is available.
These manuals are provided in two formats:
HTML for searching and viewing online
PDF for searching, viewing online, and printing
The documentation is available in your installed Tessent tree and displayed by using the
help -manual command from within each Tessent product. Documentation is also available
on the Mentor Graphics SupportNet site:
http://supportnet.mentor.com
For more information about setting up and using Tessent documentation, refer to Using
Tessent Documentation in the Managing Mentor Graphics Tessent Software manual.
Mentor Graphics Support
Mentor Graphics software support includes software enhancements, access to comprehensive
online services with SupportNet, and the optional On-Site Mentoring service.
For details, refer to this page:
http://supportnet.mentor.com/about/
If you have questions about a software release, you can log in to SupportNet and search
thousands of technical solutions, view documentation, or open a Service Request online:
http://supportnet.mentor.com
If your site is under current support and you do not have a SupportNet login, you can register for
SupportNet by filling out a short form here:
http://supportnet.mentor.com/user/register.cfm
Getting Help
Mentor Graphics Support
March 2014
All customer support contact information is available here:
http://supportnet.mentor.com/contacts/supportcenters/index.cfm
March 2014
Appendix B
Commands and Control Files
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
Commands and Control Files
Primary control files that you create
March 2014
Primary control files that you create
The following control files are described in the order they occur in this user guide.
<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
March 2014
Appendix C
Models
Simplified PLL model
To try the design flow described in this document using an example jitter-free PLL, 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
`timescale 1 ns / 1 fs
// Parameters: Multiplier integer>0 (not checked); I/O delay (ns); Locktime (us), >1 cycle of
REF clock
// Input: REF -> reference clock to multiply
// Outputs
// CKM[3:0] -> { 270, 180, 90, 0 } deg multiplied output frequency
// I/O delay is applied modulo the full period of the output frequency. Within that modulo
delay,
// one CKM output is guaranteed to exhibit this modulo delay.
// LOCKED
// Goes to 1 when PLL has locked. Minimum is 2 full cycles of REF. Otherwise, elapsed time is
checked on
// every falling edge of REF and the PLL is then enabled. The LOCKED signal goes high on the
2nd rising
// edge of REF following the time when the specified locktime has elapsed. CKM outputs are
generated in
// the REF cycle that precedes the LOCKED signal being asserted.
module PLL ( REF, CKM, LOCKED );
input REF;
output [3:0] CKM;
output LOCKED;
parameter M = 5.0;
parameter IODELAY_NS = 1.0;
parameter LOCKTIME_US = 1.0;
ìfdef LV_scanmodel
èlse
reg VCO4, VCO4D;
reg EN, VCO_CPL, LOCKED;
real edge1Time, period, vcohp, iodelay, rem;
real firstEdgeTime, lockTime, refLockTime;
integer MM, MU;
reg [1:0] C0, C1, C2, C3;
reg [3:0] CKMD;
Models
March 2014
initial begin
MM = 0;
iodelay = 0.0;
edge1Time = 0.0;
firstEdgeTime = 0.0;
lockTime = 0.0;
refLockTime = 1000.0 * LOCKTIME_US;
VCO_CPL = 1'b0;
VCO4 = 1'b0;
EN = 1'b0;
@(posedge REF) firstEdgeTime = $realtime;
@(vcohp);
@(negedge REF);
@(posedge REF);
if (refLockTime <= 0.0) begin
EN = 1'b1;
lockTime = $realtime - firstEdgeTime;
end
end
always @ ( posedge REF ) begin
period = $realtime - edge1Time;
vcohp = 0.125 * period / M;
edge1Time = $realtime;
if (EN) begin
if (vcohp > 0.0) begin
MU = $rtoi(1.0 * IODELAY_NS / vcohp);
iodelay = IODELAY_NS - $itor(MU) * vcohp;
if ((MU % 2) == 0) begin
VCO_CPL = 1'b0;
end else begin
VCO_CPL = 1'b1;
end
end else begin
iodelay = 0.0;
end
VCO4 = 1'b1;
for (MM = 4*M - 1; MM > 0; MM = MM - 1) begin
#(vcohp) VCO4 = ~VCO4;
end
end else begin
VCO4 = 1'b0;
@(negedge REF);
if (refLockTime > 0.0) begin
Models
March 2014
lockTime = $realtime - firstEdgeTime;
if (lockTime - refLockTime > 0.0) begin
EN = 1'b1;
end
end
end
end
initial begin
C0 = 2'b11;
C1 = 2'b10;
C2 = 2'b01;
C3 = 2'b00;
CKMD = 4'b0000;
LOCKED = 1'b0;
end
always @(posedge C3[1]) CKMD[3] = EN;
always @(posedge REF) LOCKED <= CKMD[3];
assign CKM = { CKMD[3] & C3[1], CKMD[2] & C2[1], CKMD[1] & C1[1], CKMD[0] & C0[1] };
always @(VCO4 or VCO_CPL) begin
#(iodelay) VCO4D = EN & (VCO4 ^ VCO_CPL);
end
always @(posedge VCO4D) begin
C0 <= C0 - 2'b01;
C1 <= C1 - 2'b01;
C2 <= C2 - 2'b01;
C3 <= C3 - 2'b01;
end
èndif
endmodule
èndcelldefin
Models
March 2014
March 2014
Appendix D
Jitter Components and Frequencies
Figure D-1 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
March 2014
Figure D-2. Jitter Frequencies
March 2014
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
March 2014
March 2014
Appendix F
Step 5: SerDes-Based Design Flow for
PLLTest
Using the SerDes-Based Design Flow
Set the environmental variable LV_ET_PLL to indicate that you used the LV Flow from
Tessent Release v8.2009_5.10 or later.
setenv LV_ET_PLL 1
This will affect the following tests:
MultiPhaseSamplingError measures output phase delays.
JitterFromCDF LF jitter measured if .lfjittercdf file exists.
DutyCycleDistortion lock time measured if PRBS pattern.
FunctionalLoopback measures PLL out/in frequency ratio.
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.
For PLLs, the choice of frequency is more determined by the desired sampling resolution,
remembering that finer resolution sampling will include more LF jitter.
For PLLTest, the sampling resolution is the difference between the sampling clock period and
the nearest frequency that is synchronous to the sampled clock frequency:
T
RESOLUTION
= | N T
PLLOUT
- T
SAMPLING
|
For an example PLL with 50 MHz input, 400 MHz output, and ~50 MHz sampling clock:
T
RESOLUTION
= | 8 2.5ns - 20.001ns | = 1 ps
For best jitter measurement accuracy, you should choose an effective resolution
(= T
RESOLUTION
x USCR) that is 0.4~0.8 times the expected RMS jitter.
Step 5: SerDes-Based Design Flow for PLLTest
March 2014
Implementing PLL/DLL Tests
Create a new Test Group, and name it something like PLLOutput.
Step 5.1 Measure HF jitter
This test measures the HF jitter in a clock signal. For a PLL, this jitter is mostly caused by VCO
input and power rail noise. If the PLLTest sampling rate is equal to the sampled signal's
frequency (minus an offset) or half this, then the test will be sensitive to cycle-to-cycle jitter. If
the sampling rate is much less than the sampled signal's frequency, then the test will be sensitive
to period jitter.
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 PLLOutput 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 OutputJitter_HF.
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.
Note
The results for this test will be affected by the reference frequency offset because the low
frequency cut-off is linearly dependent on the frequency offset (and because the
measurement's resolution is also linearly dependent).
Click on Signal To Measure, and select DataBit. This measures jitter as sampled by
one of the RxData inputs to ULTRA.
Click on OK, then run the test by clicking on the Diagnose icon. The delay before
shifting out test results will be automatically optimized for a PLL output to input
frequency ratio of 4. If the ratio is not 4, then use the test time multiplier (TTM) to adjust
the test time: EnteredTTM = 4 / ratio .
Caution
You must choose a PLL output-to-input frequency ratio that is appropriate for the
sampling resolution you choose. For maximum ppm offset permitted according to the
<chip>.etplan file, which is 1956, the maximum PLL out/in frequency ratio is 15. If
the ppm offset is reduced by half, to 1000 (or 0.1%) for example, then the PLL out/in
ratio can be increased to 30. This ensures sufficient samples per output clock period.
March 2014
Data Bit Number
By default, all tests are performed on the '0' bit input to PLLTest, corresponding to the PLL's
reference clock input. The other PLLTest inputs are connected to PLL outputs, and any one of
them can be chosen in the Data Bit Number pull-down menu.
The '0' bit must be connected to the PLL's reference clock input so that it can be used as a phase
reference. Bit 1 is the same clock inverted, and bits 2~6 are other outputs of the PLL that you
connected in Step 1.12 PLL Interface section on page 30.
Step 5.2 Measure LF jitter
This test measures the wideband jitter in a clock signal. For a PLL, this jitter is mostly affected
by loop filter bandwidth and PFD. This test actually measures HF+LF jitter, but LF jitter
usually dominates.
Caution
This test is very sensitive to LF jitter in the reference and sampling clocks. One clock
should be derived from the other using a telecom-quality PLL, as described on the next
page, since most clock generators do not have the required absolute frequency resolution
and accuracy (10 millihertz). Always compare LF jitter measured in your PLLs outputs
to that measured in the PLLs reference clock, since most PLLs track LF jitter and
transfer almost all input LF jitter to their outputs.
In your current directory, create a file with a name constructed as follows:
DLV_U_<testStepName>.lfjittercdf
For the example above, use DLV_U_OutputJitter_LF.lfjitter
The contents of the file are:
BasePeriod : <Tbase>us;
ClockPeriodsDividers {
<RefClkPin> : <txDivider>;
<SamplingClockPin> : <rxDivider>;
}
where,
TBase is the period of the base reference frequency, which is the shortest period into which fits
exactly an integer number of Reference clock periods and an integer number of Sampling clock
periods;
RefClkPin is the name of the PLL input reference ClockSource(testClock) pin, as named in
the .etplan file;
txDivider is the integer number of Reference clock periods that exactly fits the Tbase period;
March 2014
SamplingClockPin is the name of the offset ClockSource(pllReference) pin, as named in the
.etplan file;
rxDivider is the integer number of Sampling 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 Mentor Technical Marketing Engineer. 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 F-1.
Figure F-1. GUI for calculating settings for LF jitter measurement
March 2014
In the PLLOutput Test Group, click on the Test Step named OutJitter_HF, then
copy it into the same Test Group. Rename the Test Step to something like
OutputJitter_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.
Click on Signal To Measure, and select DataBit that corresponds to the PLL output
whose frequency ratio you want to measure.
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).
Step 5.3 Measure duty cycle
This test measures error in duty cycle (or pulse width) for clock signal relative to the ideal value
of 50%.
same Test Group, and rename it something like OutputDutyCycle.
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.
DCD is reported after subtracting 50% from the measured duty cycle, but you must
provide test limits for the duty cycle without subtracting 50%.
March 2014
The test limits will be automatically scaled for a PLL output to input frequency ratio of
4. If the ratio is not 4, then EnteredLimit = TrueLimit 4 / ratio .
Step 5.4 Measure clock frequency ratio
This test measures the PLL output frequency divided by the PLLs reference input frequency.
More specifically, it counts the number of rising clock edges in the number of reference beat
periods that you indicate with LoopbackDurationInWordClockCycles. If you set this value to
1, then the measured result will simply be an integer. If you choose a larger number for
LoopbackDurationInWordClockCycles, such as 10 or 100, then the measurement will show
additional digits after the decimal point. You must ensure that the frequency ratio multiplied by
the USCR is equal to an integer. For example, if the frequency ratio is known to be 6.25, choose
USCR=4. Due to LF jitter, the measurement always has some uncertainty, so measuring the
number of edges in a larger number of beat cycles will increase the accuracy.
same Test Group, and rename it something like FoutDividedByFin.
window.
Click on the pull-down menu beside SerDes Test, and choose FunctionalLoopback
(the pattern is irrelevant since no pattern is used). Ensure that the SanityCheck box is
unchecked.
Beside Pattern, click on the pull-down menu and select PRBS.
Click on OK.
Click on Signal To Measure, and select DataBit that corresponds to the PLL output
whose frequency ratio you want to measure.
Step 5.5 Measure phase delay
This test measures the average phase delay, in picoseconds, from the PLL input reference clock
rising edge (or whatever signal is connected to the RXData[0] input) to any PLL output edge
(rising or falling).
Create a new Test Group, and name it something like PLLInToOut. In the
PLLOutput Test Group, copy the OutputJitter_HF Test Step, paste it into the
PLLInToOut Test Group, and rename the Test Step something like PhaseDelay.
March 2014
Click on the pull-down menu beside SerDes Test, and select
MultiPhaseSamplingError.
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 Last Data Bit To Test and select the input port bit number that is to be tested.
If you choose 3 for example, then the phase of the signal on RXData[3] will be tested.
Phase delays are measured in picoseconds, from minus one half of the PLLs reference clock
period, to plus one half of the period. Beyond that is ambiguous: for example, if the reference
clock period is 10 ns, an actual phase delay of +7 ns will be reported as -3 ns. Furthermore,
delay will be measured to the nearest edge in that range, so the maximum measurable delay for
a PLL output frequency that is higher than the input frequency is plus or minus one period of the
output frequency.
Step 5.6 Measure lock time
This test measures the total time that a PLL's lock detector output indicates that a PLL is not
locked, starting after the PLL is forced to lose lock (e.g., by altering its feedback divider value)
until the end of the measurement time, as set by Test Duration in Beat Cycles (number of
reference clock cycles). The beat period is the reciprocal of the frequency offset.
In Step 1.12 PLL Interface section on page 30 and Connections for PLLs and DLLs
section on page 25, you connected a ChangePLL signal to force the PLL to lose lock
temporarily.
The ChangePLL signal rises when ULTRA starts measuring input duty cycle, and stays high for
Test Duration in Beat Cycles.
The Step 1.12 PLL Interface section on page 30 connects the PLL's lock detector.
window.
Click on the pull-down menu beside SerDes Test, and choose DutyCycleDistortion.
Beside Pattern, click on the pull-down menu and select PRBS.
Note
If PRBS cannot be selected - you need the latest release of the software.
Click on OK.
Right click on the appropriate Test Controller and select Options.
March 2014
Click on the number beside Data Bit Number and select 7.
Enter a value for Test Duration in Beat Cycles that is greater than the largest expected
lock time divided by the period of the frequency offset.
For example, if your PLLs reference clock period is 100 MHz, and the frequency
offset is 1000 ppm (= 0.1%), then the offset is 100 kHz and its period is 10 s. If
maximum permitted lock time is 20 s, then you could set Test Duration in Beat
Cycles to twice that duration, which is 4 Beat Cycles.
Enter values for Test Limits that are equal to the true limits in microseconds multiplied
by the sampling resolution, then divided by the product of Test Duration in Beat
Cycles and the sampling clock period in picoseconds.
For example, if effective sampling resolution is 10 ps, Test Duration in Beat
Cycles is 4, and sampling clock period is 10000ps, then EnteredLimit =
TrueLimit_us 10 / (4 10000)
Note
This test reuses the DutyCycleDistortion entry fields in the GUI to measure Locktime. A
dedicated set of entry fields in the GUI is provided in release v9.3 of the software.
Step 5.7 Measure lock range
To measure lock range with PLLTest, you select a feedback divider value or input divider value
that causes the PLL to output the required minimum or maximum required frequency, and then
measure its output jitter (see Step 5.1 Measure HF jitter section on page 134).
Alternatively, you can measure its lock time using the procedure in Step 5.6 Measure lock
time section on page 139, but ensuring that the new divider value that is loaded into the PLL
causes it to output its required highest or lowest frequency.
Go to Step 6: Diagnose and Characterize Tests section on page 101.
Third-Party Information
For information about third-party software included with this release of Tessent products, refer to the Third-Party Software for
Tessent Products.
End-User License Agreement
The latest version of the End-User License Agreement is available on-line at:
www.mentor.com/eula
END-USER LICENSE AGREEMENT (Agreement)
This is a legal agreement concerning the use of Software (as defined in Section 2) and hardware (collectively Products)
between the company acquiring the Products (Customer), and the Mentor Graphics entity that issued the corresponding
quotation or, if no quotation was issued, the applicable local Mentor Graphics entity (Mentor Graphics). Except for license
agreements related to the subject matter of this license agreement which are physically signed by Customer and an authorized
representative of Mentor Graphics, this Agreement and the applicable quotation contain the parties entire understanding
relating to the subject matter and supersede all prior or contemporaneous agreements. If Customer does not agree to these
terms and conditions, promptly return or, in the case of Software received electronically, certify destruction of Software and all
accompanying items within five days after receipt of Software and receive a full refund of any license fee paid.
1. ORDERS, FEES AND PAYMENT.
1.1. To the extent Customer (or if agreed by Mentor Graphics, Customers appointed third party buying agent) places and Mentor
Graphics accepts purchase orders pursuant to this Agreement (each an Order), each Order will constitute a contract between
Customer and Mentor Graphics, which shall be governed solely and exclusively by the terms and conditions of this Agreement,
any applicable addenda and the applicable quotation, whether or not those documents are referenced on the Order. Any additional
or conflicting terms and conditions appearing on an Order or presented in any electronic portal or automated order management
system, whether or not required to be electronically accepted, will not be effective unless agreed in writing and physically signed
by an authorized representative of Customer and Mentor Graphics.
1.2. Amounts invoiced will be paid, in the currency specified on the applicable invoice, within 30 days from the date of such invoice.
Any past due invoices will be subject to the imposition of interest charges in the amount of one and one-half percent per month or
the applicable legal rate currently in effect, whichever is lower. Prices do not include freight, insurance, customs duties, taxes or
other similar charges, which Mentor Graphics will state separately in the applicable invoice. Unless timely provided with a valid
certificate of exemption or other evidence that items are not taxable, Mentor Graphics will invoice Customer for all applicable
taxes including, but not limited to, VAT, GST, sales tax, consumption tax and service tax. Customer will make all payments free
and clear of, and without reduction for, any withholding or other taxes; any such taxes imposed on payments by Customer
hereunder will be Customers sole responsibility. If Customer appoints a third party to place purchase orders and/or make
payments on Customers behalf, Customer shall be liable for payment under Orders placed by such third party in the event of
default.
1.3. All Products are delivered FCA factory (Incoterms 2010), freight prepaid and invoiced to Customer, except Software delivered
electronically, which shall be deemed delivered when made available to Customer for download. Mentor Graphics retains a
security interest in all Products delivered under this Agreement, to secure payment of the purchase price of such Products, and
Customer agrees to sign any documents that Mentor Graphics determines to be necessary or convenient for use in filing or
perfecting such security interest. Mentor Graphics delivery of Software by electronic means is subject to Customers provision of
both a primary and an alternate e-mail address.
2. GRANT OF LICENSE. The software installed, downloaded, or otherwise acquired by Customer under this Agreement, including any
updates, modifications, revisions, copies, documentation and design data (Software) are copyrighted, trade secret and confidential
information of Mentor Graphics or its licensors, who maintain exclusive title to all Software and retain all rights not expressly granted
by this Agreement. Mentor Graphics grants to Customer, subject to payment of applicable license fees, a nontransferable, nonexclusive
license to use Software solely: (a) in machine-readable, object-code form (except as provided in Subsection 5.2); (b) for Customers
internal business purposes; (c) for the term of the license; and (d) on the computer hardware and at the site authorized by Mentor
Graphics. A site is restricted to a one-half mile (800 meter) radius. Customer may have Software temporarily used by an employee for
telecommuting purposes from locations other than a Customer office, such as the employees residence, an airport or hotel, provided
that such employees primary place of employment is the site where the Software is authorized for use. Mentor Graphics standard
policies and programs, which vary depending on Software, license fees paid or services purchased, apply to the following: (a)
relocation of Software; (b) use of Software, which may be limited, for example, to execution of a single session by a single user on the
authorized hardware or for a restricted period of time (such limitations may be technically implemented through the use of
authorization codes or similar devices); and (c) support services provided, including eligibility to receive telephone support, updates,
modifications, and revisions. For the avoidance of doubt, if Customer provides any feedback or requests any change or enhancement to
Products, whether in the course of receiving support or consulting services, evaluating Products, performing beta testing or otherwise,
any inventions, product improvements, modifications or developments made by Mentor Graphics (at Mentor Graphics sole discretion)
will be the exclusive property of Mentor Graphics.
3. ESC SOFTWARE. If Customer purchases a license to use development or prototyping tools of Mentor Graphics Embedded Software
Channel (ESC), Mentor Graphics grants to Customer a nontransferable, nonexclusive license to reproduce and distribute executable
files created using ESC compilers, including the ESC run-time libraries distributed with ESC C and C++ compiler Software that are
IMPORTANT INFORMATION
USE OF ALL SOFTWARE IS SUBJECT TO LICENSE RESTRICTIONS. CAREFULLY READ THIS LICENSE
AGREEMENT BEFORE USING THE PRODUCTS. USE OF SOFTWARE INDICATES CUSTOMERS COMPLETE
AND UNCONDITIONAL ACCEPTANCE OF THE TERMS AND CONDITIONS SET FORTH IN THIS AGREEMENT.
ANY ADDITIONAL OR DIFFERENT PURCHASE ORDER TERMS AND CONDITIONS SHALL NOT APPLY.
linked into a composite program as an integral part of Customers compiled computer program, provided that Customer distributes
these files only in conjunction with Customers compiled computer program. Mentor Graphics does NOT grant Customer any right to
duplicate, incorporate or embed copies of Mentor Graphics real-time operating systems or other embedded software products into
Customers products or applications without first signing or otherwise agreeing to a separate agreement with Mentor Graphics for such
purpose.
4. BETA CODE.
4.1. Portions or all of certain Software may contain code for experimental testing and evaluation (which may be either alpha or beta,
collectively Beta Code), which may not be used without Mentor Graphics explicit authorization. Upon Mentor Graphics
authorization, Mentor Graphics grants to Customer a temporary, nontransferable, nonexclusive license for experimental use to test
and evaluate the Beta Code without charge for a limited period of time specified by Mentor Graphics. Mentor Graphics may
choose, at its sole discretion, not to release Beta Code commercially in any form.
4.2. If Mentor Graphics authorizes Customer to use the Beta Code, Customer agrees to evaluate and test the Beta Code under normal
conditions as directed by Mentor Graphics. Customer will contact Mentor Graphics periodically during Customers use of the
Beta Code to discuss any malfunctions or suggested improvements. Upon completion of Customers evaluation and testing,
Customer will send to Mentor Graphics a written evaluation of the Beta Code, including its strengths, weaknesses and
recommended improvements.
4.3. Customer agrees to maintain Beta Code in confidence and shall restrict access to the Beta Code, including the methods and
concepts utilized therein, solely to those employees and Customer location(s) authorized by Mentor Graphics to perform beta
testing. Customer agrees that any written evaluations and all inventions, product improvements, modifications or developments
that Mentor Graphics conceived or made during or subsequent to this Agreement, including those based partly or wholly on
Customers feedback, will be the exclusive property of Mentor Graphics. Mentor Graphics will have exclusive rights, title and
interest in all such property. The provisions of this Subsection 4.3 shall survive termination of this Agreement.
5. RESTRICTIONS ON USE.
5.1. Customer may copy Software only as reasonably necessary to support the authorized use. Each copy must include all notices and
legends embedded in Software and affixed to its medium and container as received from Mentor Graphics. All copies shall remain
the property of Mentor Graphics or its licensors. Customer shall maintain a record of the number and primary location of all
copies of Software, including copies merged with other software, and shall make those records available to Mentor Graphics upon
request. Customer shall not make Products available in any form to any person other than Customers employees and on-site
contractors, excluding Mentor Graphics competitors, whose job performance requires access and who are under obligations of
confidentiality. Customer shall take appropriate action to protect the confidentiality of Products and ensure that any person
permitted access does not disclose or use Products except as permitted by this Agreement. Customer shall give Mentor Graphics
written notice of any unauthorized disclosure or use of the Products as soon as Customer becomes aware of such unauthorized
disclosure or use. Except as otherwise permitted for purposes of interoperability as specified by applicable and mandatory local
law, Customer shall not reverse-assemble, reverse-compile, reverse-engineer or in any way derive any source code from Software.
Log files, data files, rule files and script files generated by or for the Software (collectively Files), including without limitation
files containing Standard Verification Rule Format (SVRF) and Tcl Verification Format (TVF) which are Mentor Graphics
trade secret and proprietary syntaxes for expressing process rules, constitute or include confidential information of Mentor
Graphics. Customer may share Files with third parties, excluding Mentor Graphics competitors, provided that the confidentiality
of such Files is protected by written agreement at least as well as Customer protects other information of a similar nature or
importance, but in any case with at least reasonable care. Customer may use Files containing SVRF or TVF only with Mentor
Graphics products. Under no circumstances shall Customer use Products or Files or allow their use for the purpose of developing,
enhancing or marketing any product that is in any way competitive with Products, or disclose to any third party the results of, or
information pertaining to, any benchmark.
5.2. If any Software or portions thereof are provided in source code form, Customer will use the source code only to correct software
errors and enhance or modify the Software for the authorized use. Customer shall not disclose or permit disclosure of source code,
in whole or in part, including any of its methods or concepts, to anyone except Customers employees or on-site contractors,
excluding Mentor Graphics competitors, with a need to know. Customer shall not copy or compile source code in any manner
except to support this authorized use.
5.3. Customer may not assign this Agreement or the rights and duties under it, or relocate, sublicense, or otherwise transfer the
Products, whether by operation of law or otherwise (Attempted Transfer), without Mentor Graphics prior written consent and
payment of Mentor Graphics then-current applicable relocation and/or transfer fees. Any Attempted Transfer without Mentor
Graphics prior written consent shall be a material breach of this Agreement and may, at Mentor Graphics option, result in the
immediate termination of the Agreement and/or the licenses granted under this Agreement. The terms of this Agreement,
including without limitation the licensing and assignment provisions, shall be binding upon Customers permitted successors in
interest and assigns.
5.4. The provisions of this Section 5 shall survive the termination of this Agreement.
6. SUPPORT SERVICES. To the extent Customer purchases support services, Mentor Graphics will provide Customer with updates and
technical support for the Products, at the Customer site(s) for which support is purchased, in accordance with Mentor Graphics then
current End-User Support Terms located at http://supportnet.mentor.com/supportterms.
7. LIMITED WARRANTY.
7.1. Mentor Graphics warrants that during the warranty period its standard, generally supported Products, when properly installed, will
substantially conform to the functional specifications set forth in the applicable user manual. Mentor Graphics does not warrant
that Products will meet Customers requirements or that operation of Products will be uninterrupted or error free. The warranty
period is 90 days starting on the 15th day after delivery or upon installation, whichever first occurs. Customer must notify Mentor
Graphics in writing of any nonconformity within the warranty period. For the avoidance of doubt, this warranty applies only to the
initial shipment of Software under an Order and does not renew or reset, for example, with the delivery of (a) Software updates or
(b) authorization codes or alternate Software under a transaction involving Software re-mix. This warranty shall not be valid if
Products have been subject to misuse, unauthorized modification, improper installation or Customer is not in compliance with this
Agreement. MENTOR GRAPHICS ENTIRE LIABILITY AND CUSTOMERS EXCLUSIVE REMEDY SHALL BE, AT
MENTOR GRAPHICS OPTION, EITHER (A) REFUND OF THE PRICE PAID UPON RETURN OF THE PRODUCTS TO
MENTOR GRAPHICS OR (B) MODIFICATION OR REPLACEMENT OF THE PRODUCTS THAT DO NOT MEET THIS
LIMITED WARRANTY. MENTOR GRAPHICS MAKES NO WARRANTIES WITH RESPECT TO: (A) SERVICES; (B)
PRODUCTS PROVIDED AT NO CHARGE; OR (C) BETA CODE; ALL OF WHICH ARE PROVIDED AS IS.
7.2. THE WARRANTIES SET FORTH IN THIS SECTION 7 ARE EXCLUSIVE. NEITHER MENTOR GRAPHICS NOR ITS
LICENSORS MAKE ANY OTHER WARRANTIES EXPRESS, IMPLIED OR STATUTORY, WITH RESPECT TO
PRODUCTS PROVIDED UNDER THIS AGREEMENT. MENTOR GRAPHICS AND ITS LICENSORS SPECIFICALLY
DISCLAIM ALL IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NON-INFRINGEMENT OF INTELLECTUAL PROPERTY.
8. LIMITATION OF LIABILITY. EXCEPT WHERE THIS EXCLUSION OR RESTRICTION OF LIABILITY WOULD BE VOID
OR INEFFECTIVE UNDER APPLICABLE LAW, IN NO EVENT SHALL MENTOR GRAPHICS OR ITS LICENSORS BE
LIABLE FOR INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES (INCLUDING LOST PROFITS OR
SAVINGS) WHETHER BASED ON CONTRACT, TORT OR ANY OTHER LEGAL THEORY, EVEN IF MENTOR GRAPHICS
OR ITS LICENSORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. IN NO EVENT SHALL MENTOR
GRAPHICS OR ITS LICENSORS LIABILITY UNDER THIS AGREEMENT EXCEED THE AMOUNT RECEIVED FROM
CUSTOMER FOR THE HARDWARE, SOFTWARE LICENSE OR SERVICE GIVING RISE TO THE CLAIM. IN THE CASE
WHERE NO AMOUNT WAS PAID, MENTOR GRAPHICS AND ITS LICENSORS SHALL HAVE NO LIABILITY FOR ANY
DAMAGES WHATSOEVER. THE PROVISIONS OF THIS SECTION 8 SHALL SURVIVE THE TERMINATION OF THIS
AGREEMENT.
9. HAZARDOUS APPLICATIONS. CUSTOMER ACKNOWLEDGES IT IS SOLELY RESPONSIBLE FOR TESTING ITS
PRODUCTS USED IN APPLICATIONS WHERE THE FAILURE OR INACCURACY OF ITS PRODUCTS MIGHT RESULT IN
DEATH OR PERSONAL INJURY (HAZARDOUS APPLICATIONS). EXCEPT TO THE EXTENT THIS EXCLUSION OR
RESTRICTION OF LIABILITY WOULD BE VOID OR INEFFECTIVE UNDER APPLICABLE LAW, IN NO EVENT SHALL
MENTOR GRAPHICS OR ITS LICENSORS BE LIABLE FOR ANY DAMAGES RESULTING FROM OR IN CONNECTION
WITH THE USE OF MENTOR GRAPHICS PRODUCTS IN OR FOR HAZARDOUS APPLICATIONS. THE PROVISIONS OF
THIS SECTION 9 SHALL SURVIVE THE TERMINATION OF THIS AGREEMENT.
10. INDEMNIFICATION. CUSTOMER AGREES TO INDEMNIFY AND HOLD HARMLESS MENTOR GRAPHICS AND ITS
LICENSORS FROM ANY CLAIMS, LOSS, COST, DAMAGE, EXPENSE OR LIABILITY, INCLUDING ATTORNEYS FEES,
ARISING OUT OF OR IN CONNECTION WITH THE USE OF MENTOR GRAPHICS PRODUCTS IN OR FOR HAZARDOUS
APPLICATIONS. THE PROVISIONS OF THIS SECTION 10 SHALL SURVIVE THE TERMINATION OF THIS AGREEMENT.
11. INFRINGEMENT.
11.1. Mentor Graphics will defend or settle, at its option and expense, any action brought against Customer in the United States,
Canada, Japan, or member state of the European Union which alleges that any standard, generally supported Product acquired by
Customer hereunder infringes a patent or copyright or misappropriates a trade secret in such jurisdiction. Mentor Graphics will
pay costs and damages finally awarded against Customer that are attributable to such action. Customer understands and agrees
that as conditions to Mentor Graphics obligations under this section Customer must: (a) notify Mentor Graphics promptly in
writing of the action; (b) provide Mentor Graphics all reasonable information and assistance to settle or defend the action; and (c)
grant Mentor Graphics sole authority and control of the defense or settlement of the action.
11.2. If a claim is made under Subsection 11.1 Mentor Graphics may, at its option and expense: (a) replace or modify the Product so
that it becomes noninfringing; (b) procure for Customer the right to continue using the Product; or (c) require the return of the
Product and refund to Customer any purchase price or license fee paid, less a reasonable allowance for use.
11.3. Mentor Graphics has no liability to Customer if the action is based upon: (a) the combination of Software or hardware with any
product not furnished by Mentor Graphics; (b) the modification of the Product other than by Mentor Graphics; (c) the use of other
than a current unaltered release of Software; (d) the use of the Product as part of an infringing process; (e) a product that Customer
makes, uses, or sells; (f) any Beta Code or Product provided at no charge; (g) any software provided by Mentor Graphics
licensors who do not provide such indemnification to Mentor Graphics customers; or (h) infringement by Customer that is
deemed willful. In the case of (h), Customer shall reimburse Mentor Graphics for its reasonable attorney fees and other costs
related to the action.
11.4. THIS SECTION 11 IS SUBJECT TO SECTION 8 ABOVE AND STATES THE ENTIRE LIABILITY OF MENTOR
GRAPHICS AND ITS LICENSORS, AND CUSTOMERS SOLE AND EXCLUSIVE REMEDY, FOR DEFENSE,
SETTLEMENT AND DAMAGES, WITH RESPECT TO ANY ALLEGED PATENT OR COPYRIGHT INFRINGEMENT OR
TRADE SECRET MISAPPROPRIATION BY ANY PRODUCT PROVIDED UNDER THIS AGREEMENT.
12. TERMINATION AND EFFECT OF TERMINATION.
12.1. If a Software license was provided for limited term use, such license will automatically terminate at the end of the authorized
term. Mentor Graphics may terminate this Agreement and/or any license granted under this Agreement immediately upon written
notice if Customer: (a) exceeds the scope of the license or otherwise fails to comply with the licensing or confidentiality
provisions of this Agreement, or (b) becomes insolvent, files a bankruptcy petition, institutes proceedings for liquidation or
winding up or enters into an agreement to assign its assets for the benefit of creditors. For any other material breach of any
provision of this Agreement, Mentor Graphics may terminate this Agreement and/or any license granted under this Agreement
upon 30 days written notice if Customer fails to cure the breach within the 30 day notice period. Termination of this Agreement or
any license granted hereunder will not affect Customers obligation to pay for Products shipped or licenses granted prior to the
termination, which amounts shall be payable immediately upon the date of termination.
12.2. Upon termination of this Agreement, the rights and obligations of the parties shall cease except as expressly set forth in this
Agreement. Upon termination, Customer shall ensure that all use of the affected Products ceases, and shall return hardware and
either return to Mentor Graphics or destroy Software in Customers possession, including all copies and documentation, and
certify in writing to Mentor Graphics within ten business days of the termination date that Customer no longer possesses any of
the affected Products or copies of Software in any form.
13. EXPORT. The Products provided hereunder are subject to regulation by local laws and United States (U.S.) government agencies,
which prohibit export, re-export or diversion of certain products, information about the products, and direct or indirect products thereof,
to certain countries and certain persons. Customer agrees that it will not export or re-export Products in any manner without first
obtaining all necessary approval from appropriate local and U.S. government agencies. If Customer wishes to disclose any information
to Mentor Graphics that is subject to any U.S. or other applicable export restrictions, including without limitation the U.S. International
Traffic in Arms Regulations (ITAR) or special controls under the Export Administration Regulations (EAR), Customer will notify
Mentor Graphics personnel, in advance of each instance of disclosure, that such information is subject to such export restrictions.
14. U.S. GOVERNMENT LICENSE RIGHTS. Software was developed entirely at private expense. The parties agree that all Software is
commercial computer software within the meaning of the applicable acquisition regulations. Accordingly, pursuant to U.S. FAR 48
CFR 12.212 and DFAR 48 CFR 227.7202, use, duplication and disclosure of the Software by or for the U.S. government or a U.S.
government subcontractor is subject solely to the terms and conditions set forth in this Agreement, which shall supersede any
conflicting terms or conditions in any government order document, except for provisions which are contrary to applicable mandatory
federal laws.
15. THIRD PARTY BENEFICIARY. Mentor Graphics Corporation, Mentor Graphics (Ireland) Limited, Microsoft Corporation and
other licensors may be third party beneficiaries of this Agreement with the right to enforce the obligations set forth herein.
16. REVIEW OF LICENSE USAGE. Customer will monitor the access to and use of Software. With prior written notice and during
Customers normal business hours, Mentor Graphics may engage an internationally recognized accounting firm to review Customers
software monitoring system and records deemed relevant by the internationally recognized accounting firm to confirm Customers
compliance with the terms of this Agreement or U.S. or other local export laws. Such review may include FlexNet (or successor
product) report log files that Customer shall capture and provide at Mentor Graphics request. Customer shall make records available in
electronic format and shall fully cooperate with data gathering to support the license review. Mentor Graphics shall bear the expense of
any such review unless a material non-compliance is revealed. Mentor Graphics shall treat as confidential information all information
gained as a result of any request or review and shall only use or disclose such information as required by law or to enforce its rights
under this Agreement. The provisions of this Section 16 shall survive the termination of this Agreement.
17. CONTROLLING LAW, JURISDICTION AND DISPUTE RESOLUTION. The owners of certain Mentor Graphics intellectual
property licensed under this Agreement are located in Ireland and the U.S. To promote consistency around the world, disputes shall be
resolved as follows: excluding conflict of laws rules, this Agreement shall be governed by and construed under the laws of the State of
Oregon, U.S., if Customer is located in North or South America, and the laws of Ireland if Customer is located outside of North or
South America. All disputes arising out of or in relation to this Agreement shall be submitted to the exclusive jurisdiction of the courts
of Portland, Oregon when the laws of Oregon apply, or Dublin, Ireland when the laws of Ireland apply. Notwithstanding the foregoing,
all disputes in Asia arising out of or in relation to this Agreement shall be resolved by arbitration in Singapore before a single arbitrator
to be appointed by the chairman of the Singapore International Arbitration Centre (SIAC) to be conducted in the English language, in
accordance with the Arbitration Rules of the SIAC in effect at the time of the dispute, which rules are deemed to be incorporated by
reference in this section. Nothing in this section shall restrict Mentor Graphics right to bring an action (including for example a motion
for injunctive relief) against Customer in the jurisdiction where Customers place of business is located. The United Nations
Convention on Contracts for the International Sale of Goods does not apply to this Agreement.
18. SEVERABILITY. If any provision of this Agreement is held by a court of competent jurisdiction to be void, invalid, unenforceable or
illegal, such provision shall be severed from this Agreement and the remaining provisions will remain in full force and effect.
19. MISCELLANEOUS. This Agreement contains the parties entire understanding relating to its subject matter and supersedes all prior
or contemporaneous agreements. Some Software may contain code distributed under a third party license agreement that may provide
additional rights to Customer. Please see the applicable Software documentation for details. This Agreement may only be modified in
writing, signed by an authorized representative of each party. Waiver of terms or excuse of breach must be in writing and shall not
constitute subsequent consent, waiver or excuse.
Rev. 140201, Part No. 258976

Tessent Plltest User'S Manual: Software Version 2014.1 March 2014

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tessent Plltest User'S Manual: Software Version 2014.1 March 2014

Uploaded by

Copyright:

Available Formats

This manual is part of a fully-indexed Tessent documentation set.

To search across all Tessent manuals, click on the binocular icon

PLLTest Users Manual

is used pursuant to a sublicense from LMI, the exclusive licensee of

histValue32 = cdfValue32 - cdfValue31

You might also like