IMS Pattern Conversion Manual Apt

IMS Vanguard™
Pattern Conversion Manual

Version V1.6c, PN: 0900-0154-005
Credence Systems Corporation

215 Fourier Avenue
Fremont, CA 94539
Tele: (510) 657-7400
Fax: (510) 623-2560
Customer Service Center

(503) 466-7678 (North America and International)
(800) 328-7045 (Toll-free within the United States)
call_center@credence.com (Internet email)
(503) 466-7814 (Fax)
No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or
translated into any language or computer language, in any form or by any means – electronic, mechanical,
magnetic, optical, chemical, manual or otherwise – without the prior written permission of Credence
Systems Corporation, 215 Fourier Ave., Fremont, CA 94539.
Credence Systems Corporation makes no representations or warranties with respect to the contents hereof
and specifically disclaims any implied warranties of merchantability or fitness for any particular purpose.
Furthermore, Credence Systems reserves the right to revise this publication and to make changes from
time to time in the content hereof without obligation of Credence Systems to notify any person of such
revision or changes.
Restricted Rights Legend
Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph
(c)(1)(ii) of the rights in Technical Data and Computer Software Clause at DFARS 252.227-7013 or in
subparagraph (c)(2) of the Commercial Computer Software – Restricted Rights Clause at FAR 52.227-19,
as applicable.
Printed in September 2003 in the U.S.A. All rights reserved.

Copyright © 2003 Credence Systems Corporation
Notices:
Credence is a registered trademark, and Credence Systems is a trademark of Credence Systems Corporation.
IMS Vanguard is a trademark of Credence Systems Corporation.
Product and company names listed are trademarks of their respective companies.
The IMS Vanguard series of test stations meet the following classifications under European Standard EN 55011,
titled “Limits and Methods of Measurement of Radio Disturbance Characteristics of Industrial, Scientific and
Medical (ISM) Radio-Frequency Equipment”:
Group 1 Equipment ISM Equipment: Equipment which utilizes radio-frequency energy for internal
functioning of the equipment itself.
Group A Equipment Equipment radio-frequency emissions comply with Class A limits.
TABLE OF CONTENTS
1 - Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Vanguard Pattern Conversion Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
How DPT Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
How to Start DPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
DPT Command Line Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2 - Planning Your Data Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Creating Your Test Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Knowing Your Data Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Evaluating Your VCD Source Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Evaluating Your Generic Source Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Generic Source File Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Elements of a Generic Source File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 - Creating Your DPT Run File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

About the DPT Run File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Required Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Conditionally Required Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Optional Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Run File Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
DPT Run File Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
VCD Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Generic Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Converting an APT Run File to a DPT Run File . . . . . . . . . . . . . . . . . . . . . 36
4 - Creating the Waveform Order File . . . . . . . . . . . . . . . . . . . . . . . . 37

What is a Waveform Order File? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Elements of a Waveform Order File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
About Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Syntax of the Macro List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
How Macros are Expanded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
About the Waveform List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
IMS Vanguard Pattern Conversion Manual 3

Table of Contents
Waveform List Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

How Waveforms are Applied to Pattern Sequences. . . . . . . . . . . . . . . 45
Timestamps vs. Repeat Counts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
APT Waveform Order File Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5 - DPT Run File Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Bidir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Breakup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
CompressTarget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Fill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
GenericComment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
GenericSignals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
IgnoreInstructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
LineContinue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
MatchSignals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4 IMS Vanguard Pattern Conversion Manual

Table of Contents
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
NoTimestamps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
ReferenceDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
SourceFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
SourceFormat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Substitute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
TargetDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
TargetFormat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Table of Contents
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
TargetSetup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
TestPlan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
TimeUnits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Tristate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
UpdateTestPlan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
VCDSignals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
WaveformOrder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6 - Using APT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
How APT Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
How APT Differs from DPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
APT Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Planning Your APT Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
About the APT Run File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Structure of an APT Run File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Standard Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
When Your Source is VCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Table of Contents
When Your Source is Generic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Other Conversion Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Merging Patterns with APT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Using Multiple Source Sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Using the Concatenate Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
How to Start APT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
APT Command Line Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
APT Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7 - APT Run File Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Source Section Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Active_input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Asserted_ouput ....................................... 117
Bidir ................................................. 119
Comment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Concatenate .......................................... 125
Cyclized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Device ............................................... 131
End_time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
External_resistor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Include . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
NoTimestamp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Retain_halts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Setup ................................................ 147
Start_time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Substitute ............................................ 152
Timebase ............................................ 156
Zero_delay ........................................... 158
Target Section Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
BidirCombine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
CycleDuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Device ............................................... 164

Table of Contents
FixtureMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Include . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Map_Tristate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
NoSequenceNumbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
VanguardInstructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
VanguardTiming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
WaveformMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
WaveformOrder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Zero_delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Conversion Section Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Include . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Logfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Translate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
8 - Learning Through Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Using These Examples with DPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
VCD Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Looking at the Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Running SURF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Looking at Signals in the Waves Window . . . . . . . . . . . . . . . . . . . . . . 194
Looking at the APT Run File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Running APT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Running ims_pat_cvt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
VCD Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Looking at the VCD Data File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Looking at the SURF Run File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Looking at Signals in the Waves Window . . . . . . . . . . . . . . . . . . . . . . 200
Looking at the APT Groups File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Looking at the APT Run File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Running APT and ims_pat_cvt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Generic Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Looking at the Generic Data File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Looking at the SURF Run File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Viewing Signals Using the Waves Window . . . . . . . . . . . . . . . . . . . . . 205
Looking at the APT Run File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Generic Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

Table of Contents

Generic Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
A - AVI-Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Starting AVI-Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Supported and Unsupported ATS Features . . . . . . . . . . . . . . . . . . . . . . . 221
Other Planning Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Removing Separated Pins from Your Setup . . . . . . . . . . . . . . . . . . . . 222
Modifying Invalid Pairings of Bidirectional Pin Groups . . . . . . . . . . . . 222
Using an Existing Test Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Conserving Tester Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Changing Timing Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Mapping Your Device to the Vanguard Fixture . . . . . . . . . . . . . . . . . . . . . 225
Editing a Fixture Map File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Translating an ATS Setup to a Vanguard Test Plan . . . . . . . . . . . . . . . . . . 228
Setup to Test Plan Conversion Issues . . . . . . . . . . . . . . . . . . . . . . . . . 229
Creating APT Run Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Run File #1 for ATS / XTS to IMSVF Translation . . . . . . . . . . . . . . . . . 230
Run File #2 for IMSVF to VanguardASCII Translation . . . . . . . . . . . . . 231
Translating ATS Pattern Files to Vanguard Pattern Setups . . . . . . . . . . . . 234
Automating the Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
B - Viewing Data as Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Overview of SURF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Planning Your Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Identifying the Data Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Identifying Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Identifying the Vectors to Convert . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Table of Contents
Writing a SURF Run File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

Required Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Data Dependent Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Optional Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Run File Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Running SURF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
SURF Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Bidir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Comment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
CycleLength . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Depth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
LineContinue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
NoTimestamp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
SourceFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
SourceFormat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
StartTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Substitute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
TargetFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
TesterType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
TimeUnits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
C - Batch Pattern Imports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

Command Line Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Pattern File Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Example 1: Default Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Example 2: Adding a Local Pattern to a Test Plan . . . . . . . . . . . . . . . 279
Example 3: Converting to Independent Pattern Files . . . . . . . . . . . . . 280
Example 4: Adding a Reference Pattern to a Test Plan . . . . . . . . . . . 281
Example 5: Overwriting a Reference Pattern in a Test Plan . . . . . . . . 282
Example 6: Converting a Pattern with a Named Timing Setup . . . . . 283
Example 7: Converting an ASCII Pattern Piped in from DPT . . . . . . . 283
Example 8: Concatenating Pattern Files . . . . . . . . . . . . . . . . . . . . . . 284
Example 9: Converting a Binary Setup to ASCII . . . . . . . . . . . . . . . . . 284
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

1
OVERVIEW
Overview
This chapter provids an overview of pattern conversion for the
Vanguard. It covers these topics:
• Vanguard Pattern Conversion Tools
• How DPT Works
• How to Start DPT
• DPT Command Line Syntax
Overview
Overview
Overview

1 - Overview
Vanguard Pattern Conversion Tools

IMS provides the following software applications for Vanguard
pattern conversion:
• DPT
• APT
• AVI-Link
• SURF
• ims_pat_cvt
DPT converts simulator data files to Vanguard pattern setups. In
general, this manual assumes you are using DPT to convert your
simulator data to Vanguard format. DPT has simpler syntax and
faster execution than APT.
APT is a general-purpose pattern conversion application for use with
most IMS testers. Although you can use APT to convert simulator
data files into Vanguard pattern setups, we recommend you use DPT
instead.
AVI-Link is a special-purpose application that takes both setups and
pattern files that were designed for use with the ATS, XTS and
Electra, and helps you to convert them for use on a Vanguard. It is
documented in the appendix, AVI-Link.
The SURF utility is used to convert simulation data files into a file
that can be loaded into the IMS Tools Waves window. This permits
you to see your simulation data as graphical waveforms. It is
documented in the appendix, Viewing Data as Waveforms.
The Vanguard software CD also contains a pre-processing utility,
ims_pat_cvt, you may use to convert a pattern setup from the
Vanguard ASCII format to the binary format used by Vanguard. It is
documented in the appendix, Batch Pattern Imports. The same
ASCII to binary conversion also takes place when you perform a File
> Import operation on an ASCII pattern setup, using IMS Tools.
All the Vanguard pattern conversion tools are command line tools,
rather than interactive.

How DPT Works
How DPT Works

DPT uses a set of files you supply to convert pattern data from a
simulator output file to a Vanguard pattern setup.
To perform a typical simulator to Vanguard conversion, DPT uses or
Overview
creates the files shown in Figure 1.
Figure 1. Files used by DPT, or created by DPT during a

conversion from simulator data to a Vanguard pattern setup.
Test Plan
Simulator
Overview
Data File
Pattern
DPT Setup
Run File
Waveform
Order File
(Optional)
Overview
DPT reads your Vanguard test plan and your simulator data file. The
test plan provides information about your device, such as pin names
and types, timing characteristics and DC levels. To learn more about
creating a test plan consult the manual, Getting Started with
Vanguard.
DPT reads the directives in a Run file you create and uses them to
map resources as it creates the final Vanguard pattern setup. DPT
Run files are described in the chapter, Creating Your DPT Run File.
Overview
If your pattern setup requires more than one waveform you must
create a Waveform Order file for DPT to read. This is described in the
chapter, Creating the Waveform Order File.

1 - Overview
How to Start DPT

DPT is a command line application. All the information DPT needs to
complete your conversion should be contained in your input files
(such as the Run file, the test plan, and the Waveform Order file),
and command line options.
Assuming DPT is in your path and your Run file gives the complete
information needed for your conversion, the simplest DPT command
is:
ims_dpt -r <run_file_name>
For example, if your Run file were in the directory /home/dave and
were named 544A.run.DPT, then you would enter the following at
the command line:
ims_dpt -r /home/dave/544A.run.DPT

DPT Command Line Syntax
DPT Command Line Syntax

The complete syntax of the DPT command line is:
ims_dpt -r <run_file> {-config <filename>}
{-convert <filename>}{-help}{-project <filename>}
Overview
{-verbose}{-version}
where optional parameters are shown in curly braces, and user-
supplied elements are shown in angle brackets (<>).
Table 1: Command line parameters for DPT
Parameter Description
-config <file> (Optional) Specifies the name of the config

file you want to use.
Overview
-convert <file> (Optional) Converts the APT Run file you
specify into a DPT Run file.
-help (Optional) Displays the DPT command line
options and exit.
-r <run_file> (Required) Specifies the name of the DPT
Run file you want to use.
-project <file> (Optional) Specifies the name of the project
Overview
file you want to use.
-verbose (Optional) Instructs DPT to expand the
amount of information it displays.
-version (Optional) Instructs DPT to return the version
of DPT you’re using and exit.
Overview

1 - Overview

2
PLANNING YOUR DATA CONVERSION
This chapter discusses what you should know as you get ready to
convert your simulator vectors into a Vanguard pattern setup.
Although this chapter assumes you are using DPT, it also applies to
conversions using APT.
It covers these topics:
Planning Your Data

Planning Your Data
• Creating Your Test Plan
Conversion
Conversion
• Knowing Your Data Format
• Evaluating Your VCD Source File
• Evaluating Your Generic Source File
Planning Your Data

Conversion
Planning Your Data
Conversion

2 - Planning Your Data Conversion
Creating Your Test Plan

Before you convert your simulation data to Vanguard format, you
need to create a Vanguard test plan for your device. Do this with IMS
Tools or the ims_table_import utility.
At a minimum, your test plan must contain a valid Device setup, a
valid Timing setup, and a TestPlan.ims file. The timing
characteristics described in the Timing setup must match the timing
characteristics of the simulator data you plan to convert.
Information on creating a test plan can be found in the manuals:
• Getting Started with Vanguard
• Vanguard User’s Manual

Knowing Your Data Format
Knowing Your Data Format

To convert a simulator data file, you must know its source format.
DPT accepts one of two possible source formats:
• VCD
• Generic
The VCD (Verilog Change Dump) format is commonly output by
Verilog simulators.
If your file is in a format other than VCD, it is likely to be in a tabular
data format. DPT considers all tabular data files to be generic. To
convert a generic source file, you must determine how your simulator
Planning Your Data

Planning Your Data
represents various kinds of data and then convey this information to
DPT through the use of directives in the Run file. In some cases, you
Conversion
Conversion
may need to alter your file slightly to conform to the requirements of
the DPT Generic device driver.
Planning Your Data

Conversion
Planning Your Data
Conversion

Evaluating Your VCD Source Data

If your source file is VCD, you do not have to teach DPT about its
syntax. The major task involved in your data conversion will be to
identify the signal names and convey them to DPT. To accomplish
this, you must examine the VCD file header.
The VCD file header contains information about various modules in
your simulation. Each new module is set apart by an initial $scope
keyword and terminated by an $upscope keyword. Within each
module there may be further nested modules, set apart with $scope
and $upscope keywords. Individual signals within the final nested
module are set apart on lines starting with the $var keyword and
terminated by the $end keyword.
Here is a simple example of a VCD file header, without nested
modules:
$scope module Test_74LS646 $end

$var wire 1 A G_ $end
$var wire 1 B DIR $end
.
.
.
$var wire 1 O B7 $end
$upscope $end
To convert this data with DPT you must identify each $var keyword
in the header and the $scope keyword of every level of nested
module it appears in. You use these keywords to construct the signal
name you will pass to DPT in the Run file. For example, the $var
named G_ in the $scope named Test_74LS646 would form the
signal name: Test_74LS646.G_.

Evaluating Your Generic Source Data

If your source file is generic, you must understand how your
simulator file represents various kinds of data and what conventions
it uses. This information will be needed when you create your Run
file.
Your generic source file may:
• be in “on-change” or “transition” format (data shown only if a
particular signal changes)
• use steps (data shown at regular intervals, with or without
timestamps)
Planning Your Data

Planning Your Data
• have data columns arranged in any order (group or pin order
does not need to match the order in the IMS setup)
Conversion
Conversion
• use a terminating or separating character on each line (e.g.,
colon, semicolon), or not
• include bidirectional pins (either as columns of bidirectional data
and a control group, or as special symbols in one column)
Most simulators express functional, waveform and edge placement
information in a condensed format of time-stamped, tabular data.
Planning Your Data

Usually this output is in transition format: all the data is shown at
each point where any signal changes, and the time-stamp identifies
Conversion
that point in time. By contrast, the Vanguard requires pattern data at
fixed intervals corresponding to the clock rate of the tester.
Therefore, converting simulator data is composed of two major tasks:
mapping simulator signal names to the correct pin names, and
resolving timing differences between the simulation and tester.
Planning Your Data

Conversion

Generic Source File Example

Your tabular format (generic) data file may resemble this example:
/* These lines are commented out:

/* p r
/* h e
/* a s
/* s e
/* e t
/* - - -------- - - - -------- - - - ---- --- -- --- --
0.25 0 3FFFFFFF 0 1 0 FFFFFFFF 1 0 0 1111 011 00 001 000
.
.
.
Elements of a Generic Source File

You will need to identify and evaluate the following elements of your
generic source file as you plan your data conversion:
• Timestamps
• Signal names and data column order
• Radices
• Data characters
• Data values
• Comment delimiters
• Line continuation
Timestamps
Simulators may represent timing information as timestamps in the
Source data file, or they may have regularly stepped data that does
not use timestamps. You must know how your simulator file
represents the time at which events occur.

If present, timestamps must be at the beginning of the line (preceded

only by whitespace characters, if any). If there are no timestamps in
your data, you must use the Notimestamps and Step directives.
Timestamps can be either integer or floating point numbers (no
exponentials) followed by whitespace. Timestamps may optionally
have unit labels, such as ns. Timestamp values can be real clock
values or multipliers for a base time unit. Refer to the DPT TimeUnits
directive for more information. To use APT, consult the Timebase
directive.
Sometimes your simulator data may be timestamped, but you want
DPT to generate different timestamps for the conversion. For
sources that have timestamps that you don’t want, use the Step
Planning Your Data

Planning Your Data
directive to let DPT know the timing for your source. When you use
the Step directive, DPT ignores the timestamp.
Conversion
Conversion
Signal names and data column order
To write your Run file, you must understand how the signal names in
your simulation map to the columns of data in your generic source
file. You must also understand how the columns of data in your
source file map to the pin names in your Vanguard Device setup.
Planning Your Data

In a DPT Run file, the order in which the columns of data appear in
your source file must match the order of the signal names listed in
Conversion
the GenericSignals directive. If you choose to list your simulation
signal names in the GenericSignals directive, instead of the pin
names in your Device setup, then you must also map your simulation
names to your pin names in a separate MatchSignals directive.
In an APT Run file, the order of signal names in the Groups directive
must match the order in which columns of data appear in the source.
Radices Planning Your Data

Conversion
You must know the radix used to display the data in your generic
source file.
DPT can accept generic source data in a binary, octal or
hexadecimal radix. It cannot accept data in decimal radix. You can
use mixed radices.

If you are using APT, your source data can appear in binary, octal,
decimal, and hexadecimal radices. You can use mixed radices (by
pin group), however, you must use care to separate data using
whitespace or be certain that the number of digits in the data
matches the width of the group. For example, if you have a 5 bit
group using decimal radix with a data value of 6, you must specify
"06" or separate the group’s data using whitespace. Failure to use
the leading 0 causes APT to misinterpret the data and report a data
width mismatch.
Data characters
You must know what characters your simulator uses to represent
various data states. DPT understands the following default character
usage without the need for further interpretation:
0 - Drive Low
1 - Drive High
Z - High Impedance (terminate or driver off)
0 - Expect Low
1 - Expect High
L - Expect Low
H - Expect High
Y - Expect Tristate
X - Mask (no comparison)
If your data uses other characters, use the Substitute directive to
associate these characters with the default characters shown above.
APT uses a Substitute directive for the same purpose.
Your simulator may use any of these ASCII characters to represent
data: 0-9, A-F, a-f, X, x, Z and z. Dashes ( - ) and dollar signs ( $ ) are
not allowed to represent data.

Data values
Each line of data in your source file must have the same number of
columns and each column must contain data on every line, even if
the data will be ignored. If the state of a pin does not change from
one vector to the next, the vector should simply repeat the previous
state character. For example, if you have both 1x and 2x pins, you
must have source data values on the "half-cycle" for the 1x pins.
Comment delimiters
Comments can be anywhere in your generic source data, but they
must be delimited by specific characters. Comment delimiters are
Planning Your Data

Planning Your Data
defined by the GenericComment directive in the DPT Run file.
Comments defined in this way are stripped out as DPT reads the file.
Conversion
Conversion
APT uses the Comment directive for the same purpose.
Line continuation
You must know how your generic source file handles long lines of
data. It may extend the number of data columns indefinitely to the
right or break long lines by wrapping them to the next physical line.
Planning Your Data

The default LineContinue character is a single backslash ( \ ). To use
a different LineContinue character, consult the LineContinue
Conversion
directive. To use APT, use the Options directive in the Source section
of the Run file.
Planning Your Data

Conversion


3
CREATING YOUR DPT RUN FILE
This chapter provides information about creating your DPT Run file.
It covers the following topics:
• About the DPT Run File
• DPT Run File Examples
Creating Your DPT Run Creating Your DPT Run Creating Your DPT Run
• Converting an APT Run File to a DPT Run File
File
Creating Your DPT Run
File
File File

3 - Creating Your DPT Run File
About the DPT Run File

The Run file is a critical part of the DPT conversion process. It tells
DPT how you want the conversion process to proceed and conveys
information that DPT needs to know about your source data file.
These are accomplished through DPT Run file directives.
A DPT Run file consists of:
• Required Directives
• Conditionally Required Directives
• Optional Directives
You may create your DPT Run file using any text editor capable of
producing an ASCII format file. Directives may appear in the Run file
in any order. All directives and their arguments are case sensitive.
For the complete syntax of all the directives you can use in your DPT
Run file and examples of their use, see the chapter, DPT Run File
Directives.
Required Directives
These directives are required in every DPT Run file:
TestPlan - specifies the test plan directory where DPT will locate
required information about your device.
SourceFile - specifies the source of the data you want DPT to
convert, usually a file.
SourceFormat - specifies the format of the source data.
TargetSetup - specifies the setup name to assign to the pattern
setup DPT creates.
TargetFormat - specifies the format for DPT to use when writing
your pattern setups.
Additionally, every DPT Run file requires either a GenericSignals or a
VCDSignals directive, as indicated in Table 2.

Conditionally Required Directives

Some DPT directives are required when your source data meets
particular criteria. Those conditionally required directives and the
conditions associated with them are listed in Table 2.
Table 2: Conditionally Required Directives.
This directive: Is required when:
Bidir Your device has bidirectional pins and the

state characters in your source data do not
clearly specify the direction of each vector.
For more information, consult the Bidir
reference in the chapter, DPT Run FIle
Directives.
File
GenericComment Your SourceFormat is Generic and your
source data contains comments.
GenericSignals Your SourceFormat is Generic.
IgnoreInstructions Your SourceFormat is Generic and your

source data appends pattern instructions
beyond the final column of pattern data.
LineContinue Your SourceFormat is Generic and it uses a
File
File
backslash character to denote line
continuation.
MatchSignals Your source data’s signal names differ from
the pin names in your Device setup.
NoTimestamps Your SourceFormat is Generic and your
source data contains no timestamps.
Step Your SourceFormat is Generic and your
source data contains no timestamps. If your
File
source data contains timestamps, the Step

directive overrides them.
TimeUnits Your SourceFormat is Generic and the
timestamps include no time units.

Table 2: Conditionally Required Directives.
This directive: Is required when:
VCDSignals Your SourceFormat is VCD.

WaveformOrder You TargetSetup requires a waveform other
than Default.
Optional Directives
Some directives perform valuable functions in certain conversions,
but are not required. The following directives are optional:
• Breakup - directs DPT to limit the number of pattern sequences
in any one pattern setup it creates and to make multiple setups
when the limit is exceeded.
• CompressTarget - instructs DPT to compress contiguous blocks
of identical pattern vectors in the source by converting the block
to a single sequence in the target setup with a Repeat N Times
pattern instruction appended.
• Fill - specifies a state character to apply to all sequences for a
particular pin in the pattern setup.
• Monitor - directs DPT to display its progress during the
processing of your source data.
• ReferenceDirectory - directs DPT to write the TargetSetup to the
indicated directory and to include it in the test plan named in the
TestPlan directive as a reference pattern.
• Substitute - specifies a character in your source data you want to
replace with another character during conversion.
• TargetDirectory - specifies the directory where you want DPT to
write its output pattern setup.
• Tristate - instructs DPT to emit a Z (the Vanguard tristate
character) in the pattern setup in each instance where the source
data indicates either an X or a Z for a pin that may be tristated.

• UpdateTestPlan - instructs DPT to write your pattern setup in the

directory named in the TestPlan directive and to include it in that
test plan.
Run File Comments

To place a comment in a DPT Run file, use this convention:
// this is the text of the comment
Comments may occur anywhere in a DPT Run file. When DPT

encounters the comment delimiter characters, //, it ignores the
remainder of the line. If your comments span multiple lines, you must
place the comment delimiter characters on each line, before the
comment text.
File
File
File File

DPT Run File Examples

This section contains two examples of DPT Run files: a VCD
example, and a Generic example.
VCD Example
In this example:
• The Vanguard test plan for your device is named
/home/my_device.
• The source data you want to convert is in a VCD file named

my_device.dump.
• The Vanguard pattern setup DPT creates will be in binary format

and will be named functional.
• You want the pattern setup, functional, included in the test
plan, /home/my_device.
The header of the VCD source file, my_device.dump, defines the
following four signals:

$var wire 1 A CTL $end
$var wire 1 C B1 $end
$var wire 1 D B2 $end
$upscope $end
Of these four signals, two are bidirectional: B1 and B2. They are
controlled by the signal CTL. The Device setup in the test plan,
/home/my_device , defines the pin names of the four signals as:
• ctrl
• dir
• Bdr1
• Bdr2
As a result, the minimum DPT Run file for this conversion would be
the following:

// DPT always requires the following five directives:
TestPlan /home/my_device;
SourceFile my_device.dump;
SourceFormat VCD;
TargetSetup functional;
TargetFormat Binary;
// VCD source requires a VCDSignals directive:

VCDSignals
// name type
Test_74LS646.CTL Input
Test_74LS646.DIR Input
Test_74LS646.B1 Bidirectional
Test_74LS646.B2 Bidirectional
;
// Bidirectional signals require Bidir directives:
Bidir Test_74LS646.B1 Control Test_74LS646.CTL;
File
Bidir Test_74LS646.B2 Control Test_74LS646.CTL;
// Different pin names in the Device setup requires a

// MatchSignals directive:
MatchSignals
// target source

ctrl Test_74LS646.CTL
dir Test_74LS646.DIR
Bdr1 Test_74LS646.B1
Bdr2 Test_74LS646.B2
File
File
;
// This puts the pattern setup into the test plan:
UpdateTestPlan;
Generic Example
In this example:
• The Vanguard test plan for the device is named
/home/my_device.
File
• The source data to convert is in a Generic tabular file named

my_device.pattern.
• The Vanguard pattern setup DPT creates will be in binary format

and will be named functional.

• You want the pattern setup, functional, included in the test

plan, /home/my_device.
The Generic source file, my_device.pattern, defines data for four
signals as follows:
$ Begin Header
$
$ C D
$ T I B B
$ L R 1 2
$ -----------------------------------
0.50 0 0 1 1
1.00 0 0 1 1
1.50 0 0 0 0
2.00 1 1 L L
2.50 1 0 L H
.
.
.
The Device setup in the test plan, /home/my_device, defines the pin
names of these four signals as:
• ctrl
• dir
• Bdr1
• Bdr2
Of the four signals defined, two are bidirectional, labelled as B1 and
B2 in the comment header. They are controlled by the signal labeled
CTL in the comment header. Because DPT does not recognize the
signal names in the comment header, you may identify the signals by
whatever name you desire in the GenericSignals directive. However,
if the names of signals in the GenericSignals directive differ from the
pin names in the Device setup, you must use a MatchSignals
directive. The Device setup pin names are used in this example,
avoiding the need for MatchSignals.
The comment delimiter in the source data is the dollar sign character
($). The source data includes timestamps, but no time units are
assigned to them.

As a result, the minimum DPT Run file for this conversion would be
the following:
// DPT always requires the following five directives:
TestPlan /home/my_device;
SourceFile my_device.pattern;
SourceFormat Generic;
// Generic source requires a GenericSignals directive:

GenericSignals
// name width radix type
ctrl 1 binary Input
dir 1 binary Input
Bdr1 1 binary Bidirectional
Bdr2 1 binary Bidirectional
File
;
// Bidirectional signals require Bidir directives:
Bidir Bdr1 Control ctrl;
Bidir Bdr2 Control ctrl;
// These directives are required to define two elements

// used in the source data:
TimeUnits ns;
Comment $;
File
File
// This puts the pattern setup into the test plan:
UpdateTestPlan;
File

Converting an APT Run File to a DPT Run File

If you have an existing APT Run file that was written for a target
device of VanguardASCII, you may automatically convert it to a DPT
Run file.
To convert an APT Run file to a DPT Run file, use the following
command:
ims_dpt -convert runfilename
where runfilename is the name of the APT Run file you want to
convert. Optionally, runfilename may include an absolute or a relative
path name.
DPT automatically converts as much of the APT Run file as it can
and writes the results to a file named: dpt_basename.ims, where
basename is the runfilename with any extension removed.
For example, if you enter this command:
ims_dpt -convert /home/steve/runfile.apt
then DPT creates a file named dpt_runfile.ims in the directory
/home/steve
Because of the differences between APT and DPT Run file syntax,
the converted file may differ in some details from the original.

4
CREATING THE WAVEFORM ORDER FILE
When your source data will be converted to a pattern setup using

waveforms other than the Default waveform, you must supply a
Waveform Order file.
This chapter discusses the following topics:
Waveform Creating the Waveform Creating the Waveform

• What is a Waveform Order File?
• Elements of a Waveform Order File
Order File
• About Macros
• About the Waveform List
• APT Waveform Order File Syntax
Order File
Waveform
File
File
Creating the
Creating the
Order
Order

4 - Creating the Waveform Order File
What is a Waveform Order File?

A Waveform Order file specifies the waveforms you want to apply to
each sequence of pattern data. It is optional. If you do not use a
Waveform Order file, DPT applies the Default waveform from your
test plan to all the pattern data in your source file. If your pattern
requires a waveform other than the Default, then you must create a
Waveform Order file. You must also add a WaveformOrder directive
to the Target section of your Run file.
The Waveform Order file consists of two major components: a list
that assigns a waveform to every sequence in your pattern data (as
divided by timing partition), and an optional set of macros to use in
that list. You may create your Waveform Order file using any text
editor.
This chapter assumes you are using DPT. To use APT, consult the
section at the end of this chapter, APT Waveform Order File Syntax.

Elements of a Waveform Order File

Table 3 describes the elements that may appear in a Waveform
Order file.
Table 3: Elements of a Waveform Order file.
Element Description
Header (Required.) This must be the first line of the

Waveform Order file. It must consist of the
word ImsSetupFile.

WaveformMacros (Optional.) Consists of the word
block WaveformMacros, followed by a set of left
and right curly braces that define the start
Order File
and end of the block. The WaveformMacros
block, if one is used, must precede the
WaveformOrder block.
WaveformOrder (Required.) Consists of the word
block WaveformOrder, followed by a set of left and
right curly braces that define the start and
end of the block.
Partition block (Required.) Must fall within the curly braces
that define either a WaveformOrder block or
Order File
a WaveformMacros block. Consists of the
name of a Timing Partition enclosed in
quote marks, followed by a set of left and
right curly braces that define the start and
end of the block. Even if the Default partition
is your only partition, you must create a
partition block named Default.
Waveform
Macro block (Optional.) Must fall within the curly braces
that define both a WaveformMacros block
File
File
and a Parition block. It consists of a macro

block name enclosed in quote marks,
Creating the
Creating the
Order
Order
followed by a set of left and right curly

braces that define the start and end of the
block.

Element Description
Macro list (Optional.) Must fall within the curly braces

that define a Macro block. Each entry in the
list ends with a semi-colon. Each entry may
consist of the following:
waveform name <, repeat count>;
Optional elements are shown in angle

brackets. There may be one or more entries
in a Macro list. The order in which these
entries appear defines how the waveforms
are applied to each pattern vector in a
Timing Partition when the macro is
expanded.
Waveform list (Required.) Must fall within the curly braces
that define both a WaveformOrder block and
a Partition block. Each entry in the list ends
with a semi-colon. Each entry may appear in
one of these two forms:
<timestamp> waveform name <repeat

count>;
“macro block name” <repeat count>;
Optional elements are shown in angle

brackets. There may be one or more entries
in a Waveform List. The order in which these
entries appear defines how waveforms or
macros are applied to each pattern vector in
a Timing Partition.

Element Description
Comment (Optional.) Comments can appear

anywhere in the file following the Header.
The comment delimiter is a pair of slashes.
All characters following the comment
delimiter are ignored to the end of the line
(the next carriage return charcter). Multi-line
comments require a delimiter preceding
each line.

Here is an example of a simple DPT Waveform Order file, showing all
the elements listed in Table 3:
Order File
ImsSetupFile
WaveformMacros
{
//macros used in waveform order for Default partition:
“Default”
{
“macro1”
{
w3, 10; //apply w3 to 10 sequences
Order File
}
}
}
WaveformOrder
{
// Waveform order for Default partition Waveform
“Default”
{
File
File
0ns - w1, 20; //apply w1 to first 20 sequences
w2,100; //apply w2 to next 100 sequences
Creating the
Creating the
Order
Order
“macro1”; //apply macro1 to next 20 sequences

w1; //apply w1 to remaining sequences
}
}

About Macros
Macros allow you to describe a series of waveforms you want to
apply repetitively to your pattern sequences.Macros are optional.
Suppose that, after the first 80 lines of pattern your pattern alternates
two waveforms for 10,000 lines of pattern data. Without using a
macro, your waveform list would need one entry for each of those
10,000 vectors. Using a macro, you could describe the alternation
using two lines in a macro, and then apply that macro 5,000 times,
using only one line of your waveform list.
Macros are defined for and applied to each separate timing partition
in your test plan. Even if idential macros are applied in two different
partitions, you must create two partition blocks in your Waveform
Macros block, and define the identical macros in each partition block.
Syntax of the Macro List

The syntax for a waveform entry in the Macro list, with optional
elements shown in angle brackets, is as follows:
waveform name <, repeat count>;
A waveform name is required. This is the name of the waveform to
apply. It must match a waveform defined in the Timing Setup that is
specified in the Target section of the Run file.
A repeat count is optional. This is an integer representing the
number of consecutive sequences to which the waveform in the
entry is applied. A comma must appear between the waveform
name and the repeat count.
IMPORTANT — Every entry in a Macro list must terminate with a

i semi-colon character.
How Macros are Expanded

Each macro you define in a Macros block is expanded where its
name appears in a Waveform list, as if the contents of the Macro list
were pasted in the Waveform list at that point. If you provide a repeat
count, the macro is expanded as if the Macro list were pasted into
the Waveform list repeatedly.

About Macros
Once they are expanded, the waveforms in the Macro list are applied
to sequences in your pattern using the exact same rules as other
waveforms in the Waveform list. If a macro block name appears as
the last entry in a Waveform list, the final waveform entry in the
Macro block continues to be applied to any remaining sequences.

Order File Order File
Waveform
File
File
Creating the
Creating the
Order
Order

About the Waveform List

The Waveform list describes how to apply a set of waveforms from
your test plan to every sequence of pattern data that appears in a
particular timing partition. Entries in the Waveform list may consist of
either waveform names or macro block names.
Waveform List Syntax

Here is the syntax for one waveform name entry in the Waveform list,
with optional elements shown in angle brackets:
<timestamp - > waveform name <, repeat count>;
A timestamp is optional. The timestamp must coincide with a
waveform boundary. For a single cycle waveform this also coincides
with the cycle boundary.
The timestamp is expressed as numeric value with a suffix to specify
the timing resolution. It is followed by a hyphen character. The
accepted suffixes are:
picoseconds: ps
nanoseconds: ns
microseconds: us
milliseconds: ms
seconds: sec
A waveform name is required. This is the name of the waveform to
apply. It must match a waveform defined in the Timing Setup that is
specified in the Target section of the Run file.
number of consecutive sequences to which the waveform in the
entry is applied. A comma must appear between the waveform
name and the repeat count.
Here is the syntax for a macro block name entry in the Waveform list,
with optional elements shown in angle brackets:
“macro block name” <, repeat count>;

About the Waveform List
A macro block name is required. This is the name of the macro block
you want to apply. It must match a Macro block name defined in a
Partition block of the same name as the Partition block in which the
Waveform list appears. It must be enclosed in quote marks.
number of consecutive times the macro block is expanded and
applied. A comma must appear between the macro block name and
the repeat count.
IMPORTANT — Every entry in a Waveform list must terminate with

i a semi-colon character.

How Waveforms are Applied to Pattern Sequences.
Waveforms in a Waveform list, or expanded from macros in a
Order File
Waveform list, are only applied to sequences in a particular partition.
DPT starts at the first entry in the Waveform list and moves through
the list sequentially, one entry at a time, applying the waveforms to
sequences in that partition. The waveform in each entry is applied
only to consecutive sequences. When a Waveform list is properly
constructed then, after the macros are expanded, there is one
waveform entry for each sequence in a partition that has a different
waveform than the prior sequence.
You must correctly specify the number of consecutive sequences
Order File
each entry is applied to, by using timestamps and repeat counts.
IMPORTANT — Timestamps must always coincide with a

i waveform boundary.
Timestamps vs. Repeat Counts

Waveform
In general, you will find it easier to use either timestamps or repeat
counts, but not both together. However, you may mix these methods
File
File
freely. DPT interprets the timestamps and repeat counts in your
Waveform list according to the following set of rules:
Creating the
Creating the
Order
Order
1. If an entry has no explicit timestamp or repeat count, it has an

implicit repeat count of one.

2. If an entry has a timestamp, the waveform from the previous

entry continues to be applied until the sequence specified by that
timestamp. This remains true, even when the previous entry has
a repeat count.
IMPORTANT — If the repeat count in one entry applies it to

i sequences past the timestamp in the next entry, the conflict
generates a fatal error.
3. If the first entry in the Waveform List has a timestamp that does
not coincide with the first sequence in the partition, then the
default waveform is applied up to the sequence specified by that
timestamp.
4. The last entry in the Waveform List continues to apply to any
remaining sequences. Also, when the last sequence is reached,
any remaining entries in the Waveform List are ignored.

APT Waveform Order File Syntax
APT Waveform Order File Syntax

The syntax of a Wavform Order file for APT is nearly identical to the
syntax for DPT. A listing of all the syntax differences follows:
• Partition names are not enclosed in quote marks.
• Macro block names are not enclosed in quote marks.
Here is an example of a simple APT Waveform Order file, showing all
the elements listed in Table 3 on page 39:
ImsSetupFile

WaveformMacros
{
Order File
//macros used in waveform order for Default partition:
Default
{
macro1
{
}
}
}
Order File
WaveformOrder
{
// Waveform order for Default partition
Default
{
0ns - w1, 20; //apply w1 to first 20 sequences
w2,100; //apply w2 to next 100 sequences
macro1; //apply macro1 to next 20 sequences
w1; //apply w1 to remaining sequences Waveform
}
}
File
File
Creating the
Creating the
Order
Order


5
DPT RUN FILE DIRECTIVES
DPT Run File

Directives
This chapter provides a complete description of each directive that
you may use in a DPT Run file. It covers the following directives:
• Bidir
• Breakup
• CompressTarget
DPT Run File

• Fill
Directives
• GenericComment
• GenericSignals
• IgnoreInstructions
• LineContinue
• MatchSignals
• Monitor
DPT Run File

Directives
• NoTimestamps
• ReferenceDirectory
• SourceFile
• SourceFormat
• Step
• Substitute
DPT Run File
Directives
• TargetDirectory
• TargetFormat
• TargetSetup
• TestPlan
• TimeUnits

5 - DPT Run File Directives
• Tristate
• UpdateTestPlan
• VCDSignals
• WaveformOrder
All DPT Run file directives and their arguments are case sensitive.
General syntactical rules for creating a DPT Run file are given in the
chapter, Creating A DPT Run File.

Bidir
Bidir
The Bidir directive names one bidirectional signal in your source data
and specifies how to determine when it is acting as an input or
output, when that information is not conveyed by the state
DPT Run File

Directives
characters.
Format
Bidir bsig Control csig [:polarity] [Enable esig [:polarity]];
where:
bsig specifies the name of one bidirectional signal. If the
DPT Run File

Directives
SourceFormat is Generic, bsig may consist of more than one pin.
csig specifies the name of the Control signal for bsig.
esig optionally specifies the name of the Enable signal for bsig. If
esig is omitted, bsig is assumed to be enabled at all times.
polarity optionally specifies whether the Control and Enable
signals are active when high (positive) or low (negative). If
polarity is omitted for either signal, a positive polarity is assumed
for that signal. Valid selections are:
DPT Run File

Directives
• Positive
• Negative
Examples
Assuming a bidirectional signal named pinA, using a control signal
named ctl with a positive polarity (active when high), and no enable
signal, the following line should appear in your Run file:
DPT Run File
Directives
Bidir pinA Control ctl;

Assuming a bidirectional signal named pinA, using a control signal

named ctl and an enable signal named enabl, each having a
negative polarity (active when low), the following line should appear
in your Run file:
Bidir pinA Control ctl:Negative Enable enabl:Negative;
Usage
One Bidir directive is required for each signal in your VCDSignals or
GenericSignals directive that has a type of Bidirectional, unless
directional information is contained in the source data state
characters. The names of each signal you list in a Bidir must match
the name used in the VCDSignals or GenericSignals directive.
For example, if your SourceFormat is Generic and your source data
uses the characters 1 and 0 when the pin is acting as an input pin
and the characters H and L when the pin is acting as an output pin,
then Bidir is not required. By contrast, if the characters 1 and 0 are
used for both input and output, Bidir directives are required for each
bidirectional signal.
If your SourceFormat is VCD, you may omit Bidir directives if your
data conforms to the enhanced VCD (eVCD) format specifications,
as that specification includes directional information for each signal.
Earlier VCD specifications did not preserve directional information in
the source data for each bidirectional pin, so Bidir is required for
signals in those VCD formats.
See also
GenericSignals, VCDSignals

Breakup
Breakup
The Breakup directive directs DPT to limit the number of pattern
sequences in any one pattern setup it creates. If your source data
exceeds the sequence limit you set, DPT converts your source data
DPT Run File

Directives
to multiple pattern setups.
For example, assume your source data would convert to 1058576
pattern sequences. Using the Breakup directive, you direct DPT to
limit each setup to a maximum of 524288 sequences. As a result,
DPT would create three setups: two containing 524288 sequences
and a third containing 10000 sequences.
Format
DPT Run File

Directives
Breakup max_size;
where:
max_size specifies the maximum number of sequences into which to
break the target pattern setups. Valid values consist of any integer
that is an even multiple of 16384 (16K).
Example
DPT Run File

Directives
Assuming you want your source data converted to a series of pattern
setups containing a maximum of 524288 (0.5 M) of pattern
sequences each, place the following line in your DPT Run file:
Breakup 524288;
Usage
The Breakup directive is optional. When you use the Breakup
DPT Run File
directive, the names of the pattern setups are based on the name
Directives
specified in the TargetSetup directive. Assuming your TargetSetup

directive specifies the name, functional, and your TargetFormat is
Binary, then the first and subsequent setups created by DPT would
be named according to this pattern:
• functional_0.bin

This naming pattern is applied any time the Breakup directive
appears in your DPT Run file. This includes cases where only one
pattern setup is created. In which case the one setup created would
have _0.bin appended to the TargetSetup name.
See also
TargetSetup, TargetFormat

CompressTarget
CompressTarget
The CompressTarget directive instructs DPT to compress the target
setup by taking any contiguous blocks of identical pattern vectors
from the source data and converting the block to a single sequence
DPT Run File

Directives
in the target pattern setup with a Repeat N Times pattern instruction.
Format
CompressTarget;
The directive takes no arguments.
Example
DPT Run File

Directives
Assuming that contiguous blocks of identical vectors appear in your
source data that you want to compress in your target pattern setup,
you would add this line to your DPT Run file:
CompressTarget;
Usage
DPT Run File

The CompressTarget directive is optional. If your source data file
Directives
contains a block of identical vectors, such as this one:
200 1, 1, 0, 0, 0, 1, 0
300 1, 1, 0, 0, 0, 1, 0
400 1, 1, 0, 0, 0, 1, 0
500 1, 1, 0, 0, 0, 1, 0
600 1, 1, 0, 0, 0, 1, 0
700 1, 1, 0, 0, 0, 1, 0
800 1, 1, 0, 0, 0, 1, 0
900 1, 1, 0, 0, 0, 1, 0
DPT Run File
Directives
DPT converts this source data to one sequence in the pattern setup:
1100010 Repeat 8 Times

Fill
The Fill directive specifies a repeating pattern of state characters to
apply to all sequences for a particular pin or group. If source data
exists for the pin or group you specify in a Fill directive, DPT
overrides the source data with the Fill directive’s repeating character.
This directive is useful when your source data either has different
pattern data from what you want to apply to a pin or no pattern data.
Format
Fill pin_name pattern_string;
where:
pin_name is the name of a pin or a group, as it appears in the Device
setup of the test plan named in the TestPlan directive.
pattern_string is a string of one or more legal source pattern
characters. The set of legal characters depends on the pin type of
pin_name. For example, if pin_name specifies an input pin, legal
characters would include 1,0,or X, but not H or L.
Example
Assuming you have a pin named clk_1 that you want to fill with the
repeating pattern 1010..., you would place the following line in your
DPT Run file:
Fill clk_1 10;
Usage
This directive is optional. You should be careful, when filling multiple
pin groups, to determine if the groups share pins in common.

GenericComment
GenericComment
The GenericComment directive identifies the comment delimiter, if
any, that appears in your generic tabular format source data.
DPT Run File

Directives
Format
GenericComment string;
where:
string specifies one or more characters used as a comment
delimiter in your source data. If string is more than one character,
all the characters together comprise a single comment delimiter.
DPT Run File

Directives
Example
If the comment delimiter in your source data is an ampersand
character, you would include the following line in your DPT Run file:
GenericComment & ;
Usage
DPT Run File

Directives
A GenericComment directive is required only if comments appear in
the source data file. If the GenericComment directive appears in the
Run file, DPT ignores any text or source data that appears to the
right of the delimiter on the same line of text. If you omit the
GenericComment directive from your Run file, the entire contents of
the source data file are considered as data. Multiple
GenericComment directives may appear in your Run file.
The GenericComment directive is not supported when the
SourceFormat is VCD.
DPT Run File
Directives

GenericSignals
The GenericSignals directive identifies all the signals in your generic
tabular format source data.
Format
GenericSignals
// embedded_comment
name1 width radix type // embedded_comment
name2 width radix type
.
.
.
nameN width radix type
;
where:
embedded_comment optionally is any string of characters appearing
on the same line as and following the comment delimiter characters:
//. More than one embedded_comment may appear. Each comment
may occupy its own line or follow the final meaningful element on a
line.
name1, name2... nameN are unique signal names in your source
data, named in the order they appear in your source data, from left to
right.
width specifies the width of the signal in name. This corresponds to
the number of adjacent columns the signal occupies in the source
data file.
radix specifies the radix in which the data for the named signal
appears. Valid selections are:
• binary
• octal
• hex
type specifies the type of the signal. Valid selections are:
• Input

GenericSignals
• Output
• Clock
• Bidirectional
DPT Run File

Directives
Example
Assume your source file is in generic tabular format and has eight
signals in binary radix. In the Device setup, they are given the pin
names pinA to pinH. Your GenericSignals directive might resemble
this:
GenericSignals
// Name Width Radix Type
DPT Run File

pinA 1 binary Input
Directives
pinB 1 binary Input
pinC 1 binary Input
pinD 1 binary Output
pinE 1 binary Output
pinF 1 binary Output
pinG 1 binary Input
pinH 1 binary Output
;
DPT Run File

Usage
Directives
The GenericSignals directive is required when your SourceFormat is
Generic. The signal names are not required to match the pin names
in your Device setup. If your signal names do not match pin names in
your Device setup, you must use a MatchSignals directive.
Bidirectional signals may require Bidir directives.
This directive is not supported when the SourceFormat is VCD.
DPT Run File
See also
Directives
Bidir, MatchSignals, SourceFormat, VCDSignals

IgnoreInstructions
The IgnoreInstructions directive directs DPT to ignore any source
data appearing beyond the final column of your generic tabular
pattern data, if it is delimited by a colon. Such source data is usually
an embedded pattern instruction.
Format
IgnoreInstructions;
Example
Assuming your source data contains embedded pattern instructions
that appear beyond the final column of pattern data delimited by a
colon, and you want to ignore these instructions, you would add the
following line to your DPT Run file:
IgnoreInstructions;
Usage
This directive is optional. If you omit this directive and DPT
encounters data beyond the final column of your source data, DPT
issues an error and stops processing your data.
See also
GenericComment

LineContinue
LineContinue
The LineContinue directive directs DPT to treat a backward slash
character ( \ ) at the end of a line as a line continuation character.
When such a line continuation character is detected at the end of the
DPT Run File

Directives
current line, DPT will process the next line as a continuation of the
current line.
Format
LineContinue;
Example
DPT Run File

Directives
Assuming your source data uses a backward slash ( \ ) as a line
continuation character, you would add the following line to your DPT
Run file:
LineContinue;
Usage
This directive is only required if your generic source data continues
DPT Run File

one line of data over multiple lines in the source data, using a
Directives
backslash character to indicate line continuation.
DPT Run File

Directives

MatchSignals
The MatchSignals directive specifies a one-to-one mapping of signal
names in your source data to a list of pin names in your Device
setup. DPT refers to the Device setup included in the test plan
specified by your TestPlan directive.
Format
MatchSignals;
// embedded_comment
target_name1 source_name1 // embedded_comment
target_name2 source_name2
.
.
.
target_nameN source_nameN
;
where:
embedded_comment optionally is any string of characters appearing
on the same line as and following the comment delimiter characters:
//. More than one embedded_comment may appear. Each comment
may occupy its own line or follow the final meaningful element on a
line.
target_name1, target_name2... target_nameN is a set of pin names
defined in the Vanguard Device setup. Each target_name must
correspond to a signal name in the source data.
source_name1, source_name2... source_nameN is a set of signal
names defined in the source data. Each source_name must
correspond to a pin name listed in the Device setup.
Example
Assuming you have used different names for signals in your VCD
source data and the corresponding pins in your Device setup, the
MatchSignals directive in your DPT Run file should resemble the
following:
MatchSignals;

MatchSignals
//Vanguard Name VCD Name

//============= ========
CAB Top.ClockAB
SAB Top.SAB
DIR Top.DIR
DPT Run File

A8 Top.A8
Directives
A7 Top.A7
A6 Top.A6
A5 Top.A5
A4 Top.A4
A3 Top.A3
A2 Top.A2
A1 Top.A1
;
DPT Run File

Usage
Directives
If the pin names in your Device setup differ from the names for the
corresponding signals in your GenericSignals or VCDSignals
directives, you must use the MatchSignals directive. If all the pin
names in your Device setup are identical to the corresponding
signals names in your GenericSignals or VCDSignals directives,
then this directive is not required.
See also
DPT Run File

Directives
GenericSignals, VCDSignals
DPT Run File

Directives

Monitor
The Monitor directive directs DPT to display its progress during the
processing of your source data. The progress is displayed to the
stdout device. Normally this is your screen, but the stdout device is
redirectable.
Format
Monitor;
This directive takes no arguments.
Example
Assuming you want DPT to display its progress, you would include
the following line in your DPT Run file:
Monitor;
Usage
This directive is optional.

NoTimestamps
NoTimestamps
The NoTimestamps directive is required when your generic tabular
source data has no timestamps.
DPT Run File

Directives
Format
NoTimestamps;
This directive takes no arguments.
Example
If your generic tabular source data contains no timestamps, you
DPT Run File

Directives
would include the following line in your Run file:
NoTimestamps;
Usage
The NoTimestamps directive is required when your source data is in
generic tabular format and does not include timestamps. If the
NoTimestamps directive appears in your Run file, the Step directive
DPT Run File

must also appear.
Directives
See Also
Step
DPT Run File

Directives

ReferenceDirectory
The ReferenceDirectory directive specifies a directory where you
want your pattern setup written and instructs DPT to include it as a
reference pattern in the test plan named in the TestPlan directive.
Format
ReferenceDirectory dir_name;
where:
dir_name specifies the name of the directory where you want DPT to
write the pattern setup it creates.
Example
If you want DPT to write your pattern setup to the directory
/my_device/patterns
and to update the test plan to include it as a reference pattern, you
would include the following line in your DPT Run file:
ReferenceDirectory /my_device/patterns;
Usage
Use this directive to create your TargetSetup as a reference pattern
setup. Normally, all setups in a test plan must reside in the test plan
directory. The only exceptions to this rule are reference pattern
setups.
When you use the ReferenceDirectory directive:
• DPT writes the TargetSetup files to the specified
ReferenceDirectory, and
• DPT updates the TestPlan to include TargetSetup as a reference
pattern.

ReferenceDirectory
When DPT updates your TestPlan, it includes the specified

ReferenceDirectory as an absolute path to your TargetSetup. As a
result, if you move the setup to another directory, the test plan will not
be able to locate it.
DPT Run File

If you include the ReferenceDirectory directive in your Run file, do
Directives
not include the TargetDirectory directive. When ReferenceDirectory
and UpdateTestPlan are both present, the effect is the same as
omitting the UpdateTestPlan directive.
If you do not specify a target directory using TargetDirectory,
ReferenceDIrectory, or UpdateTestPlan, then DPT writes the
TargetSetup to the current working directory.
See Also
DPT Run File

Directives
TargetDirectory, TestPlan, UpdateTestPlan
DPT Run File

Directives
DPT Run File
Directives

SourceFile
The SourceFile directive specifies the source of the data you want
DPT to convert. The source of the data may be either a data file or
the stdin device.
Format
SourceFile [filename];
where:
filename optionally is the name of the source data file. It may include
a full path name or a relative path name. If filename is omitted, DPT
reads your source data from the stdin device.
Example
Assuming your source data is in a file named in.generic and the
file is located in the current directory, then you would place this line in
your DPT Run file:
SourceFile in.generic;
Usage
The SourceFile directive is required. To specify a file, you include the
file name as an argument to the directive. If you omit the file name
argument, DPT expects input through the stdin device. This allows
you to redirect your source data into DPT from the command line.
See also
SourceFormat, TargetFile

SourceFormat
SourceFormat
The SourceFormat directive specifies the format of the source data.
DPT Run File

Format
Directives
SourceFormat data_format;
where:
data_format specifies the format of the source data. Valid values for
data_format are:
• Generic
• VCD
DPT Run File

Directives
Example
Assuming your source data is in Verilog Change Dump format, you
SourceFormat VCD;
Assuming your source data is in generic tabular format, you would
include the following line in your DPT Run file:
DPT Run File

Directives
Usage
The SourceFormat directive is required.
DPT Run File

Directives

Step
The Step directive specifies a time value for DPT to apply as the
implicit elapsed time interval between each line of source data. It is
intended for use with generic tabular source data that has no
timestamps.
Format
Step time_value;
where:
time_value is a floating point number followed by a valid time unit
indicator, for example 10.00ns. Valid time unit indicators are:
Table 4. Valid time unit indicators.
For this time unit: Use this indicator:
seconds s (or: sec)

milliseconds ms
microseconds us
nanoseconds ns
picoseconds ps
femtoseconds fs
Example
Assuming your source data has no timestamps and you want to
apply a timestep of 22.50ns between each line of source data, you
Step 22.50ns;

Step
Usage
This directive is required when the SourceFormat is Generic and the
source data has no timestamps. In this case, the NoTimestamps
directive is also required. If your source data does have timestamps,
DPT Run File

Directives
and the Run file includes a Step directive, the embedded timestamp
data is ignored and the Step value is applied in its place.
See also
NoTimestamps, SourceFormat
DPT Run File

Directives
DPT Run File
Directives
DPT Run File
Directives

Substitute
The Substitute directive specifies a character in your source data you
want to replace with another character during conversion. It is
intended for use when the characters used in your source data do
not match the characters used by Vanguard for the same purpose.
For example, if your source data uses U and D characters to indicate
high and low output, you could use this directive to replace them with
the Vanguard state characters, H and L.
Format
Substitute old_char new_char;
where:
old_char is the character you want replaced by new_char.
new_char is the character you want to replace old_char with.
Example
Assuming your source data uses the character T to denote tristated
data and you want to replace that character with the Vanguard
tristate character, Z, you would include the following line in your DPT
Run file:
Substitute T Z;
Usage
This directive is optional.

TargetDirectory
TargetDirectory
The TargetDirectory directive specifies the directory where you want
DPT to write its output pattern setup files. The resulting setup will not
be included in the test plan named in the TestPlan directive.
DPT Run File

Directives
Format
TargetDirectory dir_name;
where:
dir_name is the name of the directory where you want DPT to write
the pattern setups it creates.
DPT Run File

Directives
Example
Assuming you want DPT to write your pattern setup to the directory:
/DXV23_device/pattern
you would include the following line in your DPT Run file:
TargetDirectory /DXV23_device/pattern;
DPT Run File

Usage
Directives
This directive is optional. Using TargetDirectory, you may place your
TargetSetup files in any directory. The resulting setup will not be
included in the test plan named in the TestPlan directive.
If you include the TargetDirectory directive in your DPT Run file, you
may not include either the UpdateTestPlan directive or the
ReferenceDirectory directive.
If you do not specify a target directory using TargetDirectory,
DPT Run File
Directives
ReferenceDIrectory, or UpdateTestPlan, then DPT writes the
See also
ReferenceDirectory, TargetSetup, TestPlan, UpdateTestPlan

TargetFormat
The TargetFormat directive specifies the format for DPT to use when
writing your pattern setups.
Format
TargetFormat format_name;
where:
format_name specifies the name of a Vanguard pattern format. Valid
values for format_name are:
• ASCII
• Binary
Example
Assuming you want your pattern setups written in Vanguard binary
format, you would include the following line in your DPT Run file:
Assuming you want your pattern setups written in Vanguard ASCII
format, you would include the following line in your DPT Run file:
TargetFormat ASCII;
Usage
The TargetFormat directive is required. Setups written in ASCII
format generate one setup file. Setups written in Binary format
generate two files that, taken together, comprise the entire setup.

TargetSetup
TargetSetup
The TargetSetup directive specifies the setup name to assign to the
pattern setup DPT creates. DPT also uses the setup name as the
base name for its output files.
DPT Run File

Directives
Format
TargetSetup setup_name;
where:
setup_name is the name of the pattern setup DPT creates from your
source data. DPT also uses setup_name as the base name for its
output files.
DPT Run File

Directives
Example
Assuming you want your source data written to a pattern setup
named functional, you would include the following line in your DPT
Run file:
DPT Run File

Usage
Directives
The TargetSetup directive is required. If you do not specify a target
directory using TargetDirectory, ReferenceDIrectory, or
UpdateTestPlan, then DPT writes the output files for your
See also
Breakup, ReferenceDirectory, TargetDirectory, TargetFormat,
DPT Run File
Directives
TestPlan, UpdateTestPlan

TestPlan
The TestPlan directive specifies the test plan directory where DPT
will find a set of required information about your device.
Format
TestPlan dir_name;
where:
dir_name is the path and name of a valid Vanguard test plan
directory. The path may be relative or absolute.
Example
Assuming the test plan for your device is in the directory
/test/device_42
TestPlan /test/device_42;
Usage
The TestPlan directive is required. If your DPT Run file includes a
ReferenceDirectory directive or an UpdateTestPlan directive, the test
plan named in the TestPlan directive is updated to include the
TargetSetup.
See also
ReferenceDirectory, TargetDirectory, TargetSetup, UpdateTestPlan

TimeUnits
TimeUnits
The TimeUnits directive specifies the time units denoted by the
timestamps in your generic tabular source data. It is intended for use
when your source data includes a numeric timestamp, but no time
DPT Run File

Directives
unit indicator.
Source data that includes timestamps without time units might
resemble this example:

1.75 0 3FFFFFFF 0 1 1 6600041E 1 1 1 0000 100 00 001 110
In contrast, source data that includes time units might resemble this
DPT Run File

example, where the time unit is ns:
Directives
0.25ns 0 3FFFFFFF 0 1 0 FFFFFFFF 1 0 0 1111 011 00 001
000
000
000
1.75ns 0 3FFFFFFF 0 1 1 6600041E 1 1 1 0000 100 00 001
110
DPT Run File

Directives
Format
TimeUnits unit;
where:
unit indicates the time unit used by the timestamps in your source
data. Valid time unit indicators are:

DPT Run File
Directives
seconds s (or: sec)

milliseconds ms
microseconds us

nanoseconds ns
picoseconds ps
femtoseconds fs
Example
Assuming your source data is in a generic tabular format that
includes timestamps but omits time unit information, and you want to
use a time unit of us, you would include the following line in your DPT
Run file:
TimeUnits us;
Usage
By default, when DPT encounters timestamps without an indicated
time unit, it assumes a time unit of ns. If there is no explicit time unit
and the implicit time unit is not ns, this directive is required.
If your source data does indicate time units and you include a
TimeUnits directive indicating a different time unit, DPT will use the
units indicated in the source data, excpet for vectors (if any) where
no time unit is given.
The TimeUnits directive is not supported when the SourceFormat is
VCD.
See also
SourceFormat

Tristate
Tristate
The Tristate directive instructs DPT to emit a Z (the Vanguard tristate
character) in the pattern setup in each instance where the source
data indicates either an X or a Z for a pin that may be tristated. DPT
DPT Run File

Directives
determines if the pin can be tristated by examining the Device setup
of the test plan indicated by the TestPlan directive.
Format
Tristate;
DPT Run File

Directives
Example
Assuming you want tristate information from your source data
preserved in your pattern setup, you would include the following line
in your DPT Run file:
Tristate;
Usage
DPT Run File

Directives
The Tristate directive is optional. If you omit this directive, each X or
Z in the source data is converted to an X in the pattern setup.
DPT Run File

Directives

UpdateTestPlan
The UpdateTestPlan directive instructs DPT to write your pattern
setup into the directory named in the TestPlan directive and to
update that test plan to include it in the list of available pattern
setups.
Format
UpdateTestPlan;
Example
Assuming you want your TargetSetup files written to the TestPlan
directory and you want the setup to appear as part of your test plan,
UpdateTestPlan;
Usage
The UpdateTestPlan directive is optional. It instructs DPT to write the
TargetSetup files to the TestPlan directory and include the setup in
the test plan. All setups are normally written to the test plan directory.
If you include the UpdateTestPlan directive in your DPT Run file, you
may not include the TargetDirectory directive. When
ReferenceDirectory and UpdateTestPlan are both present, the effect
is the same as omitting the UpdateTestPlan directive.
See also
ReferenceDirectory, TargetDirectory, TestPlan

VCDSignals
VCDSignals
The VCDSignals directive identifies all the signals in your VCD
source data.
DPT Run File

Directives
Format
VCDSignals
// embedded_comment
name1 type
name2 type
.
.
.
DPT Run File

nameN type
Directives
;
where:
embedded_comment is any string of characters, appearing on the
same line as and following the comment delimiter characters: //.
name1, name2... nameN represent a list of signal names, separated
by whitespace characters. Each signal name must be in the format:
modulename[.sub_modulename.sub_modulename].signalname
DPT Run File

Directives
type specifies the type of the signal. Valid selections are:
• Input
• Output
• Clock
• Bidirectional
Example
DPT Run File
Directives
Assuming you want to convert source data in VCD format that has
three signals named pinA, pinB and pinC, and these three signals
are in a module named BusY, then a VCDSignals list similar to this
one should appear in your DPT Run file:

VCDSignals
// Name Type
BusY.pinA Input
BusY.pinB Input
BusY.pinC Output
;
Usage
The VCDSignals directive is required if your SourceFormat is VCD.
All signals whose type is Bidirectional should also appear in a Bidir
directive.
The signal names should appear exactly as they appear in your
source data.
To match these signal names to pin names in your Device setup, use
MatchSignals.
This directive is not supported when the SourceFormat is Generic.
See also
Bidir, GenericSignals, MatchSignals, SourceFormat

WaveformOrder
WaveformOrder
The WaveformOrder directive specifies a Waveform Order file to
apply to your pattern setup. A Waveform Order file describes how to
apply the waveforms defined in your test plan to every sequence
DPT Run File

Directives
created from your source data and written to your pattern setup.
The syntax for a Waveform Order file is described in the chapter,
Creating the Waveform Order File.
Format
WaveformOrder file_name;
where:
DPT Run File

Directives
file_name is the name of a valid Waveform Order file. file_name may
include a relative or absolute path name.
Example
Assuming you have created a Waveform Order file in the current
directory, named waveorder, and you want to apply it to your pattern
setup, you would include the following line in your DPT Run file:
DPT Run File

Directives
WaveformOrder waveorder;
Usage
The WaveformOrder directive is optional. If you omit this directive,
the Default waveform is applied to every sequence in the pattern
setup.
DPT Run File
Directives


6
USING APT
This chapter provids an overview of pattern conversion for the

Vanguard using APT, a general-purpose pattern conversion
application. Many of APT’s features are inapplicable unless you own
an ATS, XTS or Electra test station. Those features are not covered
in this manual.
This chapter covers these topics:
• How APT Works
Using APT
Using APT
• How APT Differs from DPT
• APT Limitations
• Planning Your APT Conversion
• About the APT Run File
• Structure of an APT Run File
• When Your Source is VCD
Using APT
• When Your Source is Generic
• Other Conversion Issues
• Merging Patterns with APT
• How to Start APT
• APT Command Line Syntax
• APT Environment Variables Using APT

6 - Using APT
How APT Works

APT converts data from a simulator output file to a Vanguard pattern
setup in ASCII format. This pattern setup may be imported into your
test plan directly or by reference, or it may be converted to binary
format prior to importing it, using the ims_pat_cvt utility.
To perform a typical simulator to Vanguard conversion, APT uses or
creates the files shown in Figure 2:
Figure 2. Files used by APT, or created by APT during a

conversion from simulator data to a Vanguard pattern setup.
Test Plan
Simulator
Data File
Pattern
Setup
Run File APT

Log File
(Optional)
Waveform
Order File
(Optional) Temporary
Files
APT reads your Vanguard test plan, specifically the Device setup
and the Timing setup, and your simulator data file. If your pattern
setup requires more than one waveform you must create a Waveform
Order file for APT to read.
APT reads the directives in a Run file you supply and uses them to
map resources as it creates the final Vanguard pattern setup. The
optional Log file contains summary information about the conversion
process. Temporary files are automatically removed after
conversion.

How APT Differs from DPT
How APT Differs from DPT

APT and DPT perform very similar tasks in very similar ways.
However, for the Vanguard user, APT differs from DPT in several
important respects:
• DPT is faster than APT.
• DPT can convert larger patterns than APT.
• DPT Run file syntax is much simpler than APT Run file syntax.
• DPT can produce Vanguard pattern setups in both binary and
ASCII format. APT produces Vanguard setups in ASCII format
only.
• Support for Vanguard pattern conversion using APT will be
Using APT
Using APT
withdrawn in the future. Support for DPT will continue. Contact
your IMS representative for details.
• APT can convert simulator files into ATS, XTS and Electra
pattern formats, while DPT cannot.
Using APT
Using APT

6 - Using APT
APT Limitations
APT has some limitations when converting pattern for a Vanguard.
APT does not support serial scan data for the Vanguard. If your
source data file contains serial scan data, APT will issue a warning
and ignore the data.
A limited set of pattern instructions may be preserved, using the
VanguardInstructions target directive. Also, any pattern instructions
in your source data may be converted to comments in the target
data, using the Option Instructions source directive. Otherwise, they
are ignored.

Planning Your APT Conversion
Planning Your APT Conversion

Planning a conversion with APT is almost identical to planning a
conversion with DPT. You must:
• Identify the test plan your pattern setup will be used with. If no
test plan exists, you must create one.
• Select your source device: VCD or Generic, based on the
characteristics of your source data.
• Know the details of your source data, especially if it is in a
generic tabular format.
Consult the chapter, Planning Your Data Conversion, for more
information.
Using APT
Using APT
Using APT
Using APT

6 - Using APT
About the APT Run File

The Run file is a critical part of the APT conversion process. It tells
APT details about how you want the conversion process to proceed,
and conveys information that APT needs to know about your
simulator data file.
An APT Run file consists of three sections:
• Source section
• Target section
• Conversion section
The Source section contains directives that tell APT how to parse the
incoming data file, how to recognize embedded comments, and how
to substitute characters the Vanguard test station recognizes for
other characters output by the simulator. For more information about
the specific directives used in the Source section, see the chapter
Source Directives.
The Target section contains directives about how to format the final
data. For more information about the specific directives used in the
Target section, see the chapter Target Directives.
The Conversion section contains directives that tell APT how to map
incoming data streams to the appropriate IMS groups/channels.For
more information about the specific directives used in the Conversion
section, see the chapter Conversion Directives.

Structure of an APT Run File

An APT Run file must be constructed according to a regular set of
rules. Using an ill-formed Run file may cause your conversion to fail.
This section discusses the rules for creating a well-formed APT Run
file.
Standard Elements
The Run file requires at least one conversion segment, which begins
with the Segment keyword and a unique text string that names the
conversion section. A Run file may have more than one conversion
section. The contents of each conversion segment are set apart by a
pair of opening and closing curly braces.
Using APT
Using APT
Segment “segment_name”
{
}
Segment names must meet Unix filename conventions. Additionally,
they cannot include whitespace. APT uses the Segment name as
the basis for temporary files that APT creates.
Within each conversion segment there must be at least one Source
section. Multiple source sections are allowed. All source sections
must appear before any other sections in the conversion segment.
Using APT
Within each conversion segment there must be one, and only one,
Target section. The Target section must appear after the final Source
section and before any Conversion section.
Within each conversion segment there may be one Conversion
section. The Conversion section is optional. If one appears, it must
follow the Target section.
Using APT

6 - Using APT
The contents of all sections within a conversion segment are

enclosed by a pair of opening and closing curly braces, as in this
example:
Segment “segment_name”
{
Source
{
}
Target
{
}
Conversion
{
}
}
End of line delimiters

The semi-colon is used as a an end of line delimiter in APT. One
logical line may be split across more than one physical line in the
Run file. Not every line requires an end of line delimiter. Consult the
examples and the directive descriptions to see where they are
required.
Comments in a Run File

In many situations, you will find it useful to put comments in the Run
file. All comments in the Run file must be in the following form:
/* text of the comment .......*/

Comments must be delimited at the beginning and the end of the
comment line. Comments may start and end at an arbitrary place
within a line. If your comments need to span a line, you must begin
each commented line with the begin comment characters (/*) and
end the line with the close comment characters (*/).
For information about comments in your source data file, see the
Comment Source section directive in the chapter, APT Run File
Directives.

Source sections
A Source section is required in every conversion segment. The
Source section is used to define characteristics of the source data for
your conversion.
A Device directive must appear in each Source section as the first
directive in that section. It is used to specify the driver APT uses to
parse your source data.
When a Setup directive is used in a Source section it must be the
second directive in that section, following the Device directive. The
Setup directive may be used to specify a file that contains a Groups
directive, as an alternative to placing a Groups directive directly in
your Source section.
When a Data directive is used in a Source section it must either be
Using APT
Using APT
the second directive (when no Setup directive is given), or the third
directive (when Setup is used). The Data directive may be used to
specify your simulator data file. If the Data directive is omitted, and
the -s <filename> command line parameter is not used, APT
defaults to reading source data from stdin.
Each Source section in your Run file may only contain valid Source
section directives. All valid Source section directives are listed in the
chapter Source Directives.
Using APT
Here is an example of a simple Source section:
Source
{
Device "Generic";
Data "in.generic.data";
Groups
{
"in1" : 1 : Bin : Input;
"out1" : 1 : Bin : Output;
};
Using APT
APT allows you to use multiple source sections that output to the
same target data file. This allows you to input Source data that is in
different source files. These files must use the same timing. If they
do not, use the Timebase or Step directive to correct the timing. For

6 - Using APT
more information on the various ways you can combine multiple

sections of source pattern data using APT, see the chapter Merging
Multiple Source Files.
Target section
A Target section is required in every conversion segment. It is used
to specify characteristics of APT’s output data.
A Device directive must appear in each Target section as the first
directive in that section. It is used to specify the driver APT uses to
create your pattern data. For a conversion to Vanguard, the device is
VanguardASCII.
The Setup directive must be the second directive in the Target
section, following the Device directive. The Setup directive is used to
specify the testplan your pattern setup will be imported to.
The Data directive must be the third directive to appear in the Target
section when it is given. The Data directive specifies the name of the
pattern setup APT will create. If the Data directive is omitted, and the
-t <filename> command line parameter is not used, APT defaults
to outputting data to stdout.
A Target section may only contain valid Target section directives. All
valid Target section directives are listed in the chapter Target
Directives.
Here is an example of a simple Target section:
Target
{
Device "VanguardASCII";
Setup "testplan_name";
Data "out.VanASCII.data";
}
Conversion section
A Conversion section is optional in any conversion segment. It is
used to specify a log file, if one is desired. It also may contain a
Translate directive.

Here is an example of a Conversion section:

Conversion
{
Logfile “conversion_stats";
Translate
{
“DATA-IN" { DataBus" };
“DATA-OUT" { DataBus" };
};
}
Using APT
Using APT
Using APT
Using APT

6 - Using APT
When Your Source is VCD

You may use APT to translate source data files in the Verilog VCD
format. To facilitate these translations, your Run file must conform to
a strict set of conventions, described in this section.
The Device directive in the Source section of your Run file must
specify "VCD". The Source section must contain a Groups directive,
either directly in the text of the Run file, or indirectly as part of an
Include directive or Setup directive. The Groups directive lists all the
signals from the VCD file that are of interest during the conversion. In
most cases, the signals of interest will consist of all signals that
correspond to one device pin and only those signals.
Each signal must appear as a group name listed in the Groups
directive. The group name for each signal must be derived from the
VCD module and signal names, as described below.
Example of a VCD file header, without nested modules:

.
.
.
$upscope $end
When your source device is VCD, the group names in your Groups
Source section directive must follow this convention:

When Your Source is VCD
For example, the first two signals in the example VCD file shown
above are contained in a single module named Test_74LS646. So
those two signals would be identified in your Groups directive as:
Test_74LS646.G_
Test_74LS646.DIR
IMPORTANT — The case used in signal names in the Run file must
i agree with the case used in the VCD file.
Assuming these two signals correspond to bidirectional pins on your
device, the Source section of your Run file might appear as in this
example:
Source
{
Device "VCD";
Using APT
Using APT
Data "/opt/ims/2000_Q2/APT/examples/74646/74646.vcd";
Groups
{
"Test_74LS646.G_" :Bin :1 :Bidir;
"Test_74LS646.DIR" :Bin :1 :Bidir;
.
.
.
}
}
Using APT
IMPORTANT — If your Groups directive includes bidirectional pins
i you will also need to define a control pin for each bidriectional
pin, using the Bidir directive.
In addition to this Groups directive in the Source section, your Run
file will almost certainly contain a Translate directive in a Conversion
section. The purpose of this Translate directive is to create pin
groups that contain more than one signal.
Using APT

6 - Using APT
For example, if the two signals shown in the Groups directive above
were to be grouped with some other pins into one pin group named
Ctl_A, you would place the following Translate directive in a
Conversion section in your Run file:
Conversion
{
Translate
{
"Ctl_A"
{
"Test_74LS646.G_"
"Test_74LS646.DIR"
.
.[add other pins to the group here]
.
};
};
};
Supported Source directives with VCD device

The following APT Run file source directives must be used with a
VCD source device:
• Device (must be “VCD”)
• Groups
The following APT Run file source directives may be used with a
VCD source device:
• Data
• Include
• Setup (the setup file may only contain a Groups directive)
• Bidir
The APT Source directives not listed here may not be used when the
source device is VCD.

When Your Source is Generic
When Your Source is Generic

There are some issues to take under consideration when planning
your conversion from a source file you plan on converting with the
Generic device driver.
For example, the Vanguard has per-pin timing resources. If your
source data groups pins together and assigns timing and pattern on
a per-group basis, you will need to instruct APT how to divide your
groups into individual pins. The names you give to each pin must
correspond to the names they have in the Device Setup.
Here is a fragmentary example of how this can be done in the Run
file, with a Translate directive in the Conversion section:
Source
Using APT
Using APT
{
Device "Generic";
Data "in.generic";
Groups
{
"inbin" : 1 : Bin : Input;
"inoctal" : 3 : Oct : Input;
}
}
.
.[Target section not shown]
Using APT
.
.
.[Conversion section next page]
.
.
Using APT

6 - Using APT
Conversion
{
Translate
{
"ib1" {
"inbin"
};
"io1" {
"inoctal" :2
};
"io2" {
"inoctal" :1
};
"io3" {
"inoctal" :0
};
}
}

Other Conversion Issues

Vanguard requires certain characteristics in its pattern that your
simulator data may not conform to.
For example, Vanguard requires that the sequence where a Halt
instruction occurs must coincide with the boundary of a waveform
and also fall on a pattern instruction boundary. Beyond the pattern
instruction boundary where the Halt instruction occurs there should
be eight more vectors of Keep alive data. APT may add sequences
as needed to bring your pattern data into compliance with these
Vanguard requirements.
If the last sequence of the pattern data you supply does not fall at the
boundary of a waveform, APT generates enough sequences to
complete the waveform, by repeating the last vector of pattern data
Using APT
Using APT
and assigning that waveform to each sequence it generated.
Normally, APT inserts a Halt pattern instruction on the final
sequence of pattern data. If the last sequence of pattern data does
not fall on a pattern instruction boundary, APT generates enough
sequences to complete a pattern instruction block of eight
sequences. In generating these sequences, APT normally repeats
the last vector of your pattern data and applies the default waveform
to them. Next, APT places the Halt instruction at the pattern
instruction boundary.
Using APT
By default, APT also creates eight vectors of Keep Alive data for you
and appends these following the sequence where it places the Halt
instruction.
A simple example of this behavior would be a conversion where all
waveforms are one cycle long, and the last vector of source pattern
data occured on the sixth sequence of an eight-sequence pattern
instruction block. As APT reaches the last vector of source data the
final few sequences of its output, prior to padding out the required
sequences, might look like this:
Using APT
"wave1", 000010110000TTTTLLLL , "; a user comment" ;"

"wave1", 10000000XXXXLHLLXXXX ;
"wave1", 0000XXXX0000LHLHXXXX ;
"wave1", 100000001111LHHLXXXX ;
"wave1", 0000XXXX0000LHHHXXXX ;
"wave1", 100011100101HLLLLLLH , "; Last cycle source data" ;

6 - Using APT
In order to create a valid Vanguard ASCII pattern file, APT completes

the pattern instruction block, adds a Halt instruction and eight
vectors of Keep Alive. After APT completes these activities, the final
sequences look like this:
"wave1", 100000001111LHHLXXXX ;
"Default", 100011100101XXXXXXXX , "; Padding - generated by APT" ;
"Default", 100011100101XXXXXXXX , "HALT; Padding -generated by APT";
"Default", 100011100101XXXXXXXX , "; KeepAlive - generated by APT" ;
A more complex example of this behavior is a conversion where both

these conditions are true:
• The final waveform is five cycles long and the last vector of
source data occurs in the second cycle of the waveform.
• The last vector of source pattern data occurs on the sixth
sequence of an eight-sequence pattern instruction block.
As APT reaches the last vector of source data the final few
sequences of its output, prior to padding out the required sequences,
might look like this:
"wave1", 100000001111LHHLXXXX ;

In this case, as APT completes the waveform by adding three more

sequences, that action also completes the pattern instruction block,
and creates the first vector of Keep Alive data. The Halt instruction is
added at the pattern instruction boundary at the fourth sequence of
the waveform, so that the final sequences would look like this:

"wave1", 100000001111LHHLXXXX ;
"wave5", 100011100101XXXXXXXX , "; Padding - generated by APT" ;
"wave5", 100011100101XXXXXXXX , "HALT; Padding -generated by APT" ;
"wave5", 100011100101XXXXXXXX , "; KeepAlive - generated by APT" ;
Using APT
Using APT
Using APT
Using APT

6 - Using APT
Merging Patterns with APT

You may merge multiple Vanguard pattern setups using the File >
Import feature of IMS Tools. This feature is covered in the Vanguard
User’s Manual. To accomplish this, you could use APT to convert
your source data into pattern setups and then merge those setups
using IMS Tools. Alternatively, you may also merge multiple source
data files directly into one Vanguard pattern setup with APT:
• using muliple source sections, and
• using the Concatentate directive.
IMPORTANT — The methods given in this section do not work

i with VCD files.
Using Multiple Source Sections

You may use multiple source sections to merge several source data
files, or to specify sections from one file and merge them selectively.
This method works only if you are using the Generic device.

Here’s a simple example of a Run file with multiple Source sections

that merges two separate sections from one source file:
Source
{
Device “Generic";
Data “tabfile.gen";
Setup “my_Groups";
Start_time 50ns;
End_time 150ns;
}
Source
{
Device “Generic";
Data “tabfile.gen";
Setup “my_Groups";
Start_time 250ns;
Using APT
Using APT
End_time 450ns;
}
Target
{
Device “VanguardASCII";
Setup “testplan_name";
Data “out.VanASCII.data";
}
This example uses the timestamp information found in the source
Using APT
data files to decide where to put the pattern.
With the Generic device, you can use the manual append method to
allow you to merge force and compare vectors from separate force
and compare data files generated by your simulator. You must be
certain that the separate force and compare data files do not conflict
in timestamp information, pin group names, parallel data, serial data,
pattern instructions, and timeset order, or APT may produce
unexpected results.
For example, if you have a Force pin group named p1 and a
Using APT
Compare pin group also named p1, the APT run may result in the
Compare data for p1 overwriting the Force data for the pin of the
same name. To avoid this, make sure to use unique pin group names
for all pin groups.

6 - Using APT
Similarly, if you have a Force group named f1 in one Generic source

file, and a Compare group named c1 in another Generic source file, if
you want both force and compare data to align on the same pattern
vector after the APT run, pattern data in each source file must use
the same timestamps.
Example
Here is an example of merging four (very simple) simulator data files
using the Generic device. Each file contains data for one pin group of
two pins. Two of the groups are input pins and two groups are output
pins. The files are timestamped and all the timestamps align.
Assume all of the signal names in the four files are unique.
File f1.gen contents:
0 01
100 00
200 01
300 00
400 01
500 00
File f2.gen contents:
0 11
100 00
200 11
300 00
400 11
500 00
File c1.gen contents:
0 01
100 10
200 01
300 10
400 01
500 10
File c2.gen contents:
0 11
100 10
200 11
300 10
400 11

500 10
To merge these signals into one output file, use the following APT
Run file:
Segment "source_1"
{
Source
{
Device "Generic";
Groups { "f1":2:Bin:Input; };
Data "f1.gen";
}
Source
{
Device "Generic";
Using APT
Using APT
Groups { "f2":2:Bin:Input; };
Data "f2.gen";
}
Source
{
Device "Generic";
Groups { "c1":2:Bin:Output; };
Data "c1.gen";
}
Using APT
Source
{
Device "Generic";
Groups { "c2":2:Bin:Output; };
Data "c2.gen";
}
Target
{
Using APT
Setup "testplan_name";
Data "test.out";
}

6 - Using APT
The resulting merged pattern will have these characteristics

(although not this exact format):
TS f1 f2 c1 c2
0 01 11 01 11
100 00 00 10 10
200 01 11 01 11
300 00 00 10 10
400 01 11 01 11
500 00 00 10 10
Using the Concatenate Directive

You may combine the use of multiple Source sections of the APT
Run file with the Concatenate directive to automatically manage the
timestamps in the source data files that are merged. Using
Concatenate with Generic source data also requires you to use an
additional APT directive (Cyclized, Step, or Timebase) to supply
information about the tester cycle length.
Generic source data files contain only timestamps or sequentially
numbered vectors, with no notion of tester cycles included in the
data. When you want to append data from one Generic source file to
another, there is no information contained in any of the source data
files that indicates what the timestamp of the first vector of the
second file, and all subsequent files, should be. Each of the
additional directives treats the problem of determining the timestamp
differently.

How to Start APT
How to Start APT

APT is a command line application. All the information APT needs to
complete your conversion should be contained in your input files
(such as the Run file, the test plan, and the Waveform Order file),
command line options, and environment variables.
Assuming APT is in your path and your Run file gives the complete
information needed for your conversion, the simplest APT command
line is:
APT -r <run_file_name>
For example, if your Run file were in the directory /home/dave and
were named 544A.run.APT, then you would enter the following at
the command line:
Using APT
Using APT
APT -r /home/dave/544A.run.APT
Using APT
Using APT

6 - Using APT
APT Command Line Syntax

The complete syntax of the APT command line is:
APT -r <run_file> {-s <source_file>} {-sopt <option>}
{-t <target_file>} {-topt <option>} {-v} {-version}
{-queue} {-core} {-help}
where optional parameters are shown in curly braces, and user-
supplied elements are shown in angle brackets (<>).
Table 6: Command line parameters for APT
-core (Optional) Prevents APT from trapping

signals that create a core dump file.
-help (Optional) Display the APT command line
options and exit.
-queue (Optional) Instructs APT to wait for a software
license to become free and then run, rather
than exiting when no license is available.
-r <run_file> (Required) The name of the Run file you want
to use.
-s <source file> (Optional) The name of the input data file.
If this parameter is omitted and no Data
directive specified in the source section of
Run File, input defaults to stdin.
-sopt <option> (Optional) name of a Run File Source section
Option directive to apply.
-t <target_file> (Optional) The name of the output data file.
If this parameter is omitted and no Data
directive specified in the target section of Run
File, output defaults to stdout.
-topt <option> (Optional) The name of a Run File Target
section Option directive to apply.
-v (Optional) A request for verbose operations.

APT Command Line Syntax
Table 6: Command line parameters for APT
-version (Optional) Instructs APT to return the version

of APT you’re using and exit.
Using APT
Using APT
Using APT
Using APT

6 - Using APT
APT Environment Variables

You can further modify the way APT runs by changing one
environment variable associated exclusively with APT.
APT_EDIT_MAX environment variable. The APT_EDIT_MAX
environment variable lets you control the size of system memory
resources that APT uses when your run file contains many
directives, for example, when converting VCD source files.
The default setting (in effect even if you do not add the
APT_EDIT_MAX variable to your environment) is 512KB. This
should be sufficient for most conversions. You must increase the
default size, if APT gives you the following error message:
Out of memory used for run file/generic directives,
such as Group or Substitute. Recommend you increase
the size above the default 512K by explicitly setting
it via environ variable APT_EDIT_MAX.
If your run file contains only a single source section, you can
increase this limit to any meaningful size limit (e.g., 2048 [2MB]).
However, if your run files typically have multiple source sections, you
can increase the memory size limit to a maximum of 1024 (1MB).
To increase the value of APT_EDIT_MAX (for example, to 2MB), add
the following line to your .cshrc file:
setenv APT_EDIT_MAX 2048

7
APT RUN FILE DIRECTIVES
This chapter provides a complete description of each directive that

you may use in an APT Run file. General syntactical rules for
creating an APT Run file are given in the chapter Using APT.
This chapter contains the following sections:
• Source Section Directives
• Target Section Directives
APT Run File

Directives
• Conversion Section Directives
Although some directives may be used in more than one section of
an APT Run file, there may be some small differences in the syntax
for a directive, its purpose, or its usage from one section to another.
For example, to use the Setup directive in the Source section,
consult the description of the Setup directive that occurs in Source
Section Directives.
APT Run File

APT Run File
Directives
Directives
APT Run File
Directives

7 - APT Run File Directives
Source Section Directives

All valid Source section directives for a Vanguard target device are
listed in this section in alphabetical order:
• Active_Input
• Asserted_output
• Bidir
• Comment
• Concatenate
• Cyclized
• Data
• Device
• End_time
• External_resistor
• Groups
• Include
• NoTimestamp
• Option
• Retain_halts
• Setup
• Start_time
• Step
• Substitute
• Timebase
• Zero_delay

Active_input
The Active_input Source section directive specifies whether the
source input group is active. If the enable group is positive, the data
is active. If the enable group is negative, the data is set to Z. The
default is that the enable group is positive.
This directive is not supported when the source device is VCD.
Format
Active_input "source_grp" [Enable "enable_grp"
[:polarity][:bit] ];
where:
APT Run File

Directives
source_grp is the name of the source group. The group name must
be within quotation marks.
enable_grp is the name of the enable group. The group name must
polarity is an optional qualifier for enable_grp. If specified, polarity is
either Positive (default) or Negative.
bit optionally specifies one bit in the enable group that determines
whether the input group is active. You need to specify the bit only
APT Run File

APT Run File
Directives
Directives
when the enable group is more than one bit wide.
Example
Source
{
Active_input "Data1" Enable "EN1":Negative:3;
}
APT Run File
Directives

Usage
The following table shows the states for this directive.
Table 7. State table for Active_input directive.
Source Enable group Polarity Source group result
1 positive Data 0 or 1 (Enable line is

a separate group)
0 positive Z
0 negative Data 0 or 1 (Enable line is
a separate group)
1 negative Z
See also
Asserted_output, Bidir

Asserted_ouput
The Asserted_output Source section directive specifies whether the
source output group is asserted. If the enable group is positive, the
data is asserted. If the enable group is negative, the data is set to X.
The default is that the enable group is positive.
Format
Asserted_output "source_grp" [Enable "enable_grp"
[:polarity][:bit]];
APT Run File

Directives
where:
source_grp is the name of the source group. The group name must
enable_grp is the name of the enable group. The group name must
be within quotation marks. The default is that the enable group is
positive. The polarity is optional.
polarity is an optional qualifier for enable_grp. If specified, polarity is
either Positive (default) or Negative.
APT Run File

APT Run File
Directives
Directives
bit optionally specifies one bit in the enable group that determines
whether the output group is asserted. You only need to specify the
bit when the enable group is more than one bit wide.
Example
Source
{
Asserted_output"Data1"Enable"EN1":Negative:4;
APT Run File
}
Directives

Usage
The following table shows the states for this directive. .
Table 8. State table for Asserted_ouput directive.
Source Enable group Polarity Source group result
1 positive Data 0 or 1 (Enable line is

a separate group)
0 positive X
0 negative Data 0 or 1 (Enable line is
a separate group)
1 negative X
See also
Active_input, Bidir

Bidir
Use the Bidir Source section to control the direction of bidirectional
pins, according to the state of the control and enable groups.
Typically, if your conversion requires the Bidir directive, you'll also
need to use the Translate directive.
Format
Bidir "src_grp" Control "cntrl_grp" [[:polarity] |
[:bit]]; | Enable "enbl_grp" [[:polarity] | [:bit]];
| Control "cntrl_grp" [[:polarity] | [:bit]] Enable
"enbl_grp" [[:polarity] | [:bit]];
APT Run File

Directives
where:
src_grp is the name of the bidirectional source group.
cntrl_grp is the name of the control group for the bidirectional source
group named in src_grp. By default, the polarity of the control group
is positive.
enbl_grp is the name of the enable group for the bidirectional source
group. By default, the polarity of the enable group is positive.
APT Run File

APT Run File
polarity is an optional qualifier for cntrl_grp or enbl_grp that specifies
Directives
Directives
their polarity. It may be either Positive (default) or Negative
bit is an optional qualifier for cntrl_grp or enbl_grp that specifies one
bit in the control or enable group that directs the bidirectional group.
By default all bits in the control or enable group determine the result.
Example
APT Run File
Directives
Source
{
Bidir"Data1"Control"Cnt1":Positive:7Enable"EN1":Negative:5;
}

Usage
The bidirectional pin is active whenever the enable group is positive.
The bidirectional pin is input when the control group is positive,
otherwise it is output. Table 9 shows the bidirectional states.
Table 9. Bidirectional signal states
When the ...and its ...and the ...and its ...then the
Control Polarity Enable Polarity Bidir Source
group is: is: group is: is: group is:
1 positive 1 positive input

0 positive 1 positive output
0 negative 1 positive input
1 negative 1 positive output
1 positive 0 positive inactive input (Z)
0 positive 0 positive inactive output
(X)
0 negative 0 positive inactive input (Z)
1 negative 0 positive inactive output
(X)
1 positive 0 negative input
0 positive 0 negative output
0 negative 0 negative input
1 negative 0 negative output
1 positive 1 negative inactive input (Z)
0 positive 1 negative inactive output
(X)
0 negative 1 negative inactive input (Z)
1 negative 1 negative inactive output
(X)

You may compare for tri-state by using a Z in the pattern data. For
most conversions, the bidirectional pin is controlled by a control
group. For those conversions, you do not need to change the state
character in the source data file.
However, if you have a bidirectional pin that is not controlled by a
control pin and you want to expect a Compare Z, you must use a Y in
the source data file. For both the Force and Compare data for the
pin, APT outputs a Z.
Table 10 shows how APT translates the bidirectional Source data for
the different target data.
Table 10. How source data is translated for bidirectional pins

without a control group or pin.
APT Run File

Directives
Bidir Source Data Target Data: Input Target Data: Output
0 0 X
1 1 X
H Z 1
L Z 0
X Z X
APT Run File

APT Run File
Directives
Directives
Y Z Z
Z Z Z
See also
Active_input, Asserted_output
APT Run File
Directives

Comment
The Comment Source section directive tells APT which characters
start a comment and, optionally, which characters end a comment.
When translating a Generic format source file, this directive is often
required to enable APT to recognize embedded comments.
You may use any number of Comment directives in a Source section.
Be aware, however, that APT processes the directives in the order
you specify.
Format
Comment "start_string" ["end_string"];
where:
start_string is the regular expression that indicates that a comment
follows.
end_string is an optional regular expression that defines the end of a
comment. If you do not specify an end_string, the comment
automatically extends to the end of the physical text line. If you do
specify an end_string, every instance of the start_string must be
paired with an end_string, and each end_string must occur on the
same physical line as the start_string.

Example
In this example, the Source data contains comment lines that begin
with an ampersand (&). Your Source Data file might look like this:
& PAGE #0001
& TR3320 68HC05J1 CPU PATTERN
& AAAAAAAA DDDDDDDD NNAAAELR IROONNNN
& 76543210 76543210 AA198 IW RSSSAAAA
& 120 RN QTCC3456
& B BB12
&
& >>>>>>> START HERE IF YOU WANT 4064 POWER ON RESET CYCLES
<<<<<<
0 XXXX0001 00000000 XX000000 X01XXXXX
10 XXXX0010 00000000 XX000000 X01XXXXX
APT Run File

20 XXXX0100 00000000 XX000000 X01XXXXX
Directives
& ALLOW TIME FOR IRQ TO BE PULLED TO 9V:
& KEEP RSTB LOW TO STAY IN RESET
30 XXXX0101 00000000 XX000000 X01XXXXX
40 XXXX0110 00000000 XX000000 X01XXXXX
.
.
.
To let APT know which lines are comments, use the Comment
APT Run File

APT Run File
directive in the Source section of the Run file, as shown below:
Directives
Directives
Source
{
.
.
.
Comment "&";
.
.
.
APT Run File
}
Directives
Usage
The Comment directive uses regular expressions for pattern
matching. As a result, you must precede the following special
characters with a backslash to remove their special meaning:

.^$[]*
For example, if your Source data uses a slash followed by an asterisk
(/*) to introduce comments, be sure to interject a backslash when
using the Comment directive, as shown:
Comment "/\*"
For information on how to use regular expressions, see that section
in your host's User's manual. On a Unix system, enter man ed at the
command prompt to see the manual page for regular expressions.

Concatenate
The Concatenate Source section directive tells APT to append one
Source data file to another to create one large Target data file. The
Concatenate directive ensures that, as each file is appended to the
previous file, it starts with the correct sequence number.
The Concatenate directive works with Source data files that are in
the Generic format. This directive is not supported when the source
device is VCD.
To concatenate many Source data files, you must make one Source
section for each of the files that you want to append together. You
must use the Data directive in each of these Source sections to
APT Run File

specify the file to be concatentated. The Concatenate directive must
Directives
appear in each of these Source sections and you can use only one
Concatenate directive per Source section. The Concatenate directive
cannot appear before the Data directive in any Source section.
In order to supply further information needed for the translation, you
must use one of the following Source directives as well:
• Cyclized. Use Cyclized to retain the relative timing supplied by
the timestamps in the Generic source data file.
APT Run File

APT Run File
• Step. Use Step to impose entirely new timing on the Generic
Directives
Directives
source data, ignoring existing timestamp information.
• Timebase. Use Timebase to calculate multiples of the source
clock, to be used in place of the existing timestamps.
See the chapter, Merging Multiple Source Files, for examples of how
to use these additional directives.
It is not necessary that the same setup file be named in each of the
Source sections. However, the Clock group rates and the pin count APT Run File
for each pin group must be the same in each setup file. Directives
Format
Concatenate;

Example
Source
{
Device "Generic";
Setup “groups_list";
Data "data1.gen";
Cyclized;
Concatenate;
}
Source
{
Device "Generic";
Setup “groups_list";
Data "data2.gen";
Cyclized;
Concatenate;
}
Target
{
Setup "Test_plan_2";
Data "all_data.vanAscii";
}
In the example, the first Source section names data1.gen as the
initial Source data file and uses the Concatenate directive; the
second Source section repeats all of the information that was in the
first Source section, but names a new data file, data2.gen, and uses
the Concatenate directive to cause APT to adjust the sequence
number for the first sequence in data2.dat to conform to an ordinal
sequence that continues after the last sequence of data1.gen.
The Concatenate directive causes APT to remove the normal Halt
instruction that occurs at the end of a data file for all but the last data
file in a series of files to be concatenated. APT generates an
informational message each time that a Halt instruction is removed.
You are limited to no more than one source section per shared
memory segment.
See also
Cyclized, Data, Device, Setup, Step, Retain_halts Timebase

Cyclized
The Cyclized Source section directive tells APT to calculate and
apply a timestamp for the first vector of a successively concatenated
Generic source file. The cycle time is determined by the time
difference difference between the last two source parallel vectors of
the Generic source file to which data from another Generic source
file is to be appended.
When you want to append data from one Generic source file (source
B) to the end of another (source A), there is no information contained
in either source file that indicates what the timestamp of the first
vector in source B should be. You must supply this information using
the Cyclized, Step or Timebase directives.
APT Run File

Directives
Use the Cyclized directive when you want to preserve the relative
times between vectors in the source data files.
You can use the Cyclized directive only in conjunction with the
Concatenate directive, and only with source files in Generic device
format. You may use Cyclized in multiple Source sections, just as you
would use the Concatenate directive. If used, Cyclized must be
included in each Source section.
APT Run File

APT Run File
Directives
Directives
Format
Cyclized;
Example
Source
{
APT Run File
Device "Generic";
Directives
Groups { "force":2:Bin:Input; };
Data "source_A.gen";
Cyclized;
Concatenate;
}
Source

{
Device "Generic";
Groups { "force":2:Bin:Input; };
Data "source_B.gen";
Cyclized;
Concatenate;
}
Target
{
Setup "Test_plan_2”;
Data "target_AB.pat";
}
Usage
Cyclized directs APT to calculate the difference between the
timestamp of the last two vectors in the first source file
(source_A.gen) and use the result of that calculation as the cycle
time for the first vector of the second source file (source_B.gen) for
the pattern translation.
The calculation can be expressed as:
(UltimateTimestamp - PenultimateTimestamp) +
UltimateTimestamp = FirstTimestamp
where:
UltimateTimestamp is the timestamp of the last pattern vector in
source_A.gen.
PenultimateTimestamp is the timestamp of the next-to-the-last

pattern vector in source_B.gen.
FirstTimestamp is the timestamp to will be used for the first vector of
source_B.gen, when the two files are concatenated during the APT
run.
For example, if the last two sequences in source_A.gen are at
400ns and 500ns, then the first sequence of source_B.gen would be
calculated:
(500ns - 400ns) + 500ns = 600ns

The remaining timing between vectors is derived from the existing

timestamps in source_B.gen.
See also
Concatenate, Step, Timebase
APT Run File

Directives
APT Run File
APT Run File
Directives
Directives
APT Run File
Directives

Data
When used in the Source section, the Data directive specifies the
source data file. The Data directive must not appear before the
Device and Setup directives. The Data directive in a Source section
may be overridden by the -s filename command line option.
If you don't include a Source section Data directive and do not use
the -s filename command line option, then APT inputs the data
from the standard input device (stdin).
For information on using this directive in the Target section, see
Target Section Directives.
Format
Data "filename";
where:
filename is the name of the file that contains the data you want
converted. The filename must be within quotation marks.
Example
Source
{
Device "Generic";
Setup "tabfile.dat";
Data "tabfile.dat";
}
See also
Device, Setup

Device
When used in the Source section, the Device directive specifies the
Source device. The Device directive is required in every Source
section and must be the first directive to appear in any Source
section.
For information on using the Device directive in the Target section,
see Target Section Directives.
Format
Device "format_name";
where:
APT Run File

Directives
format_name is the name of the device that produced the data you
want converted. The name must be within quotation marks, and
must be one of the following:
• Generic
• VCD
Example
APT Run File

APT Run File
Directives
Directives
Source
{
Device "Generic";
Data "tabfile.dat";
}
See also
Data, Setup
APT Run File
Directives

End_time
The End_time Source section directive specifies the time of the last
event in the Source data file to be converted. If you do not specify the
End_time directive, APT stops converting at the last timestamp in the
Source data file.
Format
End_time number;
where:
number is any timestamp number followed by one of the following
suffixes, representing the time unit:
• ps for picoseconds
• ns for nanoseconds
• us for microseconds
• ms for milliseconds
• s for seconds
The maximum resolution is 1ps. APT accepts space between the
number and the suffix (for example:, 500ns or 500 ns).
Example
Source
{
.
.
.
End_time 800ns;
.
.
.
}

Using this example, if the data file is:

400 /1,1,1,0,1,1,1,0,L,L,L,L;
500 /0,1,1,1,1,1,1,0,L,L,L,L;
600 /1,0,1,1,1,1,1,0,L,L,L,L;
700 /1,1,1,1,0,0,1,0,L,L,L,L;
800 /1,0,1,1,1,1,1,0,L,L,L,L;
900 /0,1,1,1,1,1,1,0,L,L,L,L;
then the last data line that will be converted is at timestamp 800.
Usage
This directive is particularly useful when you're converting multiple
Source sections. You can specify the particular vectors you want
APT Run File

from each source data file.
Directives
See also
Start_time
APT Run File

APT Run File
Directives
Directives
APT Run File
Directives

External_resistor
The External_resistor Source section directive specifies the action to
take if you are using pull-up or pull-down resistor on the socket card.
This directive defines what the Compare (Expect) data is when the
Force data is tri-stated (Z). This directive can also be used if the user
has bidirectional or output pins with receiver termination enabled (fly-
by pins).
Format
External_resistor "group" resistor_type;
where:
group is the name of the group that will provide data for the device.
The name must appear within quotation marks.
resistor_type specifies the type of resistor. It may be either Pullup or
Pulldown.
Example
Source
{
External_resistor "Compare1" Pulldown;
}
Usage
When the pin is outputting and there is a Z in the source output data
(and therefore an X in the Compare (Expect) data), this directive
controls whether the X should be interpreted as a 1 (pulled up) or 0
(pulled down).

The following table shows how pull-up and pull-down resistors are
interpreted.
Table 11. How pullup and pulldown resistors are interpreted.
Data Before Resistor type Data After
Z Pullup 1
X Pullup H
Z Pulldown 0
X Pulldown L
See also
APT Run File

Directives
Substitute
APT Run File

APT Run File
Directives
Directives
APT Run File
Directives

Groups
The Groups Source section directive provides information about how
to map simulator signals into pin groups. The Groups directive is
typically a multi-line directive.
When converting a Generic source file, the top to bottom order of the
group entries should match the left to right order of the columns in
the generic file.
For information about how the Groups directive is used in the Target
section, see Target Section Directives.
Format
Groups
{
"group_name" [:bit_width] [:radix]
[:format [time1] [time2]] [:direction];
.
.
.
};
where:
group_name is the name of the pin group. The group name must be
within quotation marks.
bit_width is an optional parameter that specifies the number of bits in
the group.
radix is an optional parameter that specifies the radix in which the
source data is expressed. These radices are case sensitive and
must begin with an upper case letter. Use one of the following:
• Hex (for hexadecimal)
• Oct (for octal)
• Bin (for binary)
• Dec (for decimal)

format is an optional parameter that specifies the format of the

source data. The default is the format used on the Target side. Use
one of the following:
• RZ
• DNRZ
• R1
time1 is the delay time. All formats require that you specify the delay
time.
time2 is the width. All formats, except DNRZ, require that you specify
a width.
direction specifies the signal direction. This may be Input, Output or
APT Run File

Bidir. These indicate that the source group you are describing is an
Directives
input group, output group or bidirectional group, respectively. If the
group is bidirectional, use the Bidir directive or special state
characters and the binary radix.
For Generic formats you must specify the group_name, bit_width,
radix, format (and times, as required), and the group_type.
Source
{
Device "Generic";
APT Run File

APT Run File
Data "input.dat";
Directives
Directives
Timebase 1ns;
Groups
{
"A":7:Bin:Input;
"B":6:Bin:Input;
};
}
Usage
APT Run File
Directives
The arguments are all optional and may be in any order. For
example, this directive:
Groups
{
"A":3:Bin:Input;
"B":2:Bin:Input;

};
is equivalent to this directive:
Groups
{
"A":Bin:3:Input;
"B":Bin:2:Input;
};
If your are translating a VCD file, the form of the the Groups directive
must conform to several specific requirements, as explained in the
chapter Creating the Run File, in the section, When Your Source is
VCD.
If your source data is in Generic format you must specify the group
names in order when you use the Groups directive.
On input, non-binary radix groups are limited to 32 bits. You can use
any number of bits for binary radix groups.
You must specify the bit_width field if the data does not have
separators between the groups. For example, if your data looks like:
111010011
You identify the groups using the Groups directive:
Groups
{
"A":3:Bin:Input;
"B":2:Bin:Input;
"C":1:Bin:Input;
"D":3:Bin:Input;
};
You can use the same Groups directive as shown above if your data
incorporates white space (for example, 11101 0011). You must be
careful, however, that a group doesn't extend across the white space
( example, Group "A" and "B" cannot both be three bits wide).
You can use the Groups directive to override a data format .
Alternatively, you can change the setup file. To override a data format
specified in the setup file with a 2x format, you must specify the
group_clock and the data format.

Group_clock. The group_clock parameter specifies the cycle time

for the group. For example, if the cycle time is 10ns and you have a
group with a 2x format, the cycle time for that group is 5ns. Typically,
you will not need to specify the group_clock in the Run file. The only
time you'll need to specify the group_clock in the Run file is when
you override a data format specified in the setup file with a 2x format.
For example, to override the group's NRZ format with 2xDNRZ and
the ATS setup file specifies a cycle time of 10ns, the Groups directive
would be:
Groups
{
"A":5ns:DNRZ;
};
APT Run File

Directives
See also
Translate
APT Run File

APT Run File
Directives
Directives
APT Run File
Directives

Include
The Include Source section directive lets you specify that the
contents of a separate file be read into the run file at the point the
Include directive is used. This lets you keep portions of the Run file
directives in separate files, where they can be more easily
maintained, stored, or accessed.
The Include directive will generate an error message if:
• the content of the file named by the Include directive does not
contain legal grammar for that portion of the run file where the
directive occurs.
• the file named by the Include directive cannot be accessed.
• the included file contains more than 50 levels of Include
statements.
Format
Include "filename";
where:
filename is an existing ASCII file containing grammatically legal Run
file directives, located in the current directory or identified by relative
path name or by absolute path name to the current directory. The
name must be enclosed in quotation marks. The file you name must
contain only directives that are grammatically correct at the location
where the directive is used.
Example
Source
{
Device"Generic";/* generic simulator device type*/
Setup"test1.set";/* source setup file */
Data "test1.pat";/* source pattern file */
Include"rules.def";
}
Assume the contents of rules.def is:

/* rules.def */
/* defines substitute and comment mapping */
Comment ";";
Substitute "" "-g";
Usage
Files named by the Include directive can themselves contain the
Include directive. Nesting of included files may be up to fifty levels
deep.
The Include directive is particularly useful in the Source section for
specifying files that contain logically related Run file directives, for
example a separate file for defining Groups, a separate file for
defining Options, and so on.
APT Run File

Directives
See Also:
Comment, Option, Substitute
APT Run File

APT Run File
Directives
Directives
APT Run File
Directives

NoTimestamp
The NoTimestampNoTimestamp Source section directive tells APT
that there are no timestamps in the Source data. You normally use
this directive in conjunction with the Step directive.
Format
NoTimestamp;
Example
Source
{
.
.
.
NoTimestamp;
Step 2ns;
.
.
.
}
The following Source file has no timestamps and therefore requires
that you use the NoTimestamp and Step directives.
1,1,1,1,1,1,1,0,L,L,L,L;
1,1,0,1,1,1,1,0,L,L,L,L;
0,1,1,1,1,1,1,0,L,L,L,L;
1,0,1,1,1,1,1,0,L,L,L,L;
1,1,1,1,0,0,1,0,L,L,L,L;
1,0,1,1,1,1,1,0,L,L,L,L;
0,1,1,1,1,1,1,0,L,L,L,L;
1,1,0,1,1,0,1,0,L,L,L,L;

Usage
The NoTimestamp directive should typically be used with the Step
directive. If you specify NoTimestamp and do not specify the Step
directive, APT uses either 1ns or the value specified by Timebase as
the Step time value. In some cases, this may result in the translation
of only one vector.
See also
Step, Timebase
APT Run File

Directives
APT Run File
APT Run File
Directives
Directives
APT Run File
Directives

Option
The Option Source section directive tells APT to enable or disable
the specified options. Any of the options that may be enabled or
disabled from the Run file using the Option directive may also be
enabled or disabled using the command line option -sopt keyword.
If the command line conflicts with the Run file directive, the Run file
directive is overridden.
Only the Monitor keyword is supported when the source device is
VCD. No other keywords are supported with VCD.
Format
Option "keyword";
where:
keyword specifies the option you want to enable/disable. The
keyword should be enclosed in quotation marks. Valid keywords for
this directive in the Source section are:
• Instructions. Use this keyword to enable the passing of
instructions from Generic input to the VanguardASCII target file.
• NoInstructions. Use this keyword to explicitly disable the
passing of instructions from Generic input. By default,
instructions are not passed from Generic input to the
VanguardASCII target file.
• LineContinue. Use this keyword to enable the continuation of a
line onto the next line. The default line continuation character is
the backslash.
• Monitor. Use this keyword to enable the reporting of %complete
information to the standard output device, stdout.

Example
Source
{
.
.
.
Option "NoInstructions";
.
.
.
}
Usage
APT Run File

Directives
Use the Option to enable line continuation. To use a line continuation
character other than backslash, specify it with an equal sign (Option
"LineContinue=\\";).
You can specify the Option directive in the Source section of the Run
file, as follows:
Option "LineContinue";
Comment "!";
APT Run File

APT Run File
LineContinue characters need to be escaped with a backslash under
Directives
Directives
two conditions. These are when using a double quote or backslash,
as shown below:
Option "LineContinue=\"";
Option "LineContinue=\\";
APT processes Comment and Substitute directives before
processing the Option “LineContinue” directive.
APT Run File
Directives

Retain_halts
Use the Retain_halts Source section to select whether, when there
are multiple Source sections, APT automatically suppresses or
retains the Halt pattern instructions it finds in the source data file
listed in each Source section.
By default, APT retains only those Halt instructions that occur in the
final Source section, and it supresses all Halt instructions in data
files from all other Source sections. By placing this directive in a
Source section, all Halt instructions from that Source section are
retained, even when it is not the final Source section.
The supression of Halt instructions is normally accomplished by
converting them into comments.
Format
Retain_halts;
Example
Source
{
.
.
.
Retain_halts;
.
.
.
}

Setup
In the Source section, the Setup directive specifies the Source setup
file. It is optional. When used, the Setup directive must be the
second directive in any Source section, before the Data directive and
after the Device directive.
For information on using the Setup directive in the Target section,
see Target Section Directives.
Format
Setup "filename";
APT Run File

Directives
where:
filename is the name of the Source setup file. When the source data
is Generic, this file must be the same as the file named in the Data
directive. When the source data is VCD, this file may only contain a
Groups directive.
Example
APT Run File

APT Run File
Source
Directives
Directives
{
Device "Generic";
Data "tabfile.dat";
}
If you are using a Generic format, you can create your own Source
setup file by placing setup directives (for example, Groups or
Substitute) in a file rather than specify the directives in the Run file.
APT Run File
See also
Directives
Data, Device

Start_time
The Start_time Source section directive specifies the time of the first
event in the Source data file to be converted. If you do not specify the
Start_time directive, APT starts converting at the first timestamp in
the Source data file.
Format
Start_time number;
where:
number is any timestamp number followed by one of the following
suffixes, representing the time unit:
• s for seconds
Example
Source
{
.
.
.
Start_time 600ns;
.
.
.
}

Using this example, if the data file is:

400 /1,1,1,0,1,1,1,0,L,L,L,L;
500 /0,1,1,1,1,1,1,0,L,L,L,L;
600 /1,0,1,1,1,1,1,0,L,L,L,L;
700 /1,1,1,1,0,0,1,0,L,L,L,L;
800 /1,0,1,1,1,1,1,0,L,L,L,L;
900 /0,1,1,1,1,1,1,0,L,L,L,L;
then the first data line that will be converted is at timestamp 600.
Usage
This directive is particularly useful when you're converting multiple
Source sections. You can specify the particular vectors you want
APT Run File

from each source data file.
Directives
See also
End_time
APT Run File

APT Run File
Directives
Directives
APT Run File
Directives

Step
Use the Step Source section to specify a regular time increment
between the incoming source vectors. When you use the Step
directive, APT will ignore any timestamps present in the source data
and apply the interval you specify, instead. Since this directive
instructs APT to ignore timestamps, you cannot use this directive
with the Timebase directive in the Source section.
You can use the Step directive in multiple Source sections when
appending one Generic source file to another using the Concatenate
directive. To retain the relative timestamp values in the Generic
source file, use the Cyclized directive, instead.
Format
Step time;
where:
time is the cycle time. It may be any integer or floating point number
followed by one of these units:
• s for seconds
Example
Source
{
.
.

.
Step 10ns;
.
.
.
}
See also
NoTimestamp, Timebase, Cyclized
APT Run File

Directives
APT Run File
APT Run File
Directives
Directives
APT Run File
Directives

Substitute
Use the Substitute Source section to replace one set of characters
with another.
For example, your source data may use a unique set of characters to
symbolize the state a signal is in. Substitute allows you to replace
them with the set of characters that have a similar meaning to APT.
For example, if your data symbolizes an unknown output signal as
“U”, APT cannot understand what this character means. However,
you may use Substitute to replace “U” with the character “X”, which
APT does recognize as symbolizing an unknown output state.
Formats
The Substitute directive has three formats:
Format 1
Substitute "old_pattern" "new_pattern";
Format 2
Substitute "group" "old_pattern" "new_pattern";
Format 3
Substitute group_type "old_pattern" "new_pattern";
where:
old_pattern is the pattern you want changed. For example, "A" .
new_pattern is the pattern to which you want the old pattern
changed. For example, "B".
group is the name of a specific group within which you want to
change the pattern. Use the name of a Source group. To substitute
within multiple groups, use multiple Substitute directives.

group_type specifies a group within which you want to change the

pattern by specifying its group type. The first directive in this format
changes the first group of the specified type that is encountered
when reading the data from left to right. The second directive in this
format changes the second group of the specified type, and so on.
Specify one of the following two group types:
• Input (changes the pattern for all Input groups)
• Output (changes the pattern for all Output groups)
Example
The following are examples of each of the three formats:
1. Substitute "A" "B";
APT Run File

Directives
2. Substitute "DATA_IN" "0000" "1101";
3. Substitute Input "111" "101";
Usage
The Substitute directive is executed on one physical line at a time. If
line continuation characters are used, so that the pattern to be
substituted is divided across one or more physical lines, the pattern
is not recognized, or substituted.
APT Run File

APT Run File
Directives
Directives
The Substitute directive, like the Comment directive and the
External_resistor directive, is order dependent. The rules for
applying Substitute directives are:
• Directives in Format 1 are always executed before directives in
Formats 2 and 3, in the order they are encountered.
• Directives in Formats 2 and 3 are executed in the order they are
encountered.
This means you have to be careful when issuing several directives
APT Run File
Directives
involving the same "old_pattern" parameter. For example, the
following sequence of directives would not give the desired results:
Substitute "Group_1" "A" "Y";

Substitute "A" "B";

All of the "A's" in Group_1, above, would end up as "B" rather than
"Y," because the second directive is in Format 1, which is always
executed first. To get the desired result in the above example, you
would need to issue a separate directive for each of your groups:
Substitute "Group_1" "A" "Y";

Substitute "Group_2" "A" "B";
Substitute "Group_3" "A" "B";
...
Substitute "Group_X" "A" "B";
You can also use this directive to create white space after the
timestamp. This is particularly useful for Generic formats that
separate the timestamp and the data using a character, rather than a
blank column. APT requires white space (a blank column) after the
timestamp.
For example, if your data looks like:
10/000,111,00
with the backslash indicating the separation of the timestamp (10)
from the data, use the following Substitute directive:
Substitute "/" " " ;

The data becomes:
10 000,111,00
When substituting data on a group_type basis (Format 3), you can
only specify one group's data at a time. For example, you must use
two Substitute directives to substitute the data for group_type Input
from "0000 1010" to "0101 0001." One Substitute directive converts
the first group's data from "0000" to "0101" and another Substitute
directive converts the next group's data from "1010" to "0001".
Different simulator formats use a variety of characters to represent
different signal states, such as a high or low ouput state. APT cannot
recognize the state symbolized by a character unless the character
is:
• already a character APT already recognizes (see Table 12), or

• you use a Substitute directive to replace the unknown character

with the character APT recognizes as meaning the appropriate
state.
The following table shows the mapping between the common signal
states and the characters APT is able to recognize.
Table 12. Signal states mapped to the state characters APT

recognizes.
State APT Characters
Input states:
Tristate Z
APT Run File

1 1
Directives
0 0
Unknown Z
Output states:
Don't care X
1 H or 1
APT Run File

APT Run File
0 L or 0
Directives
Directives
Unknown X
The Substitute directive uses regular expressions for pattern

matching. As a result, you must precede the following special
characters with a backslash to remove their special meaning:
.^$[]*
For information on how to use regular expressions, see that section APT Run File
in your host's User's manual. Enter man ed at the command prompt
Directives
to see the manual page for regular expressions.
See also
Comment, Groups

Timebase
The Timebase Source section directive specifies the timestamp
multiplier to use for your source data. Using Timebase causes APT
to interpret existing timestamps in the source file as multiples of the
time value you specify. If you do not use an explicit Timebase
directive, a default Timebase of 1ns is applied.
You can use the Timebase directive in multiple Source sections
when appending one Generic source file to another using the
Concatenate directive. To retain the relative timestamp values in the
Generic source file, use the Cyclized directive, instead.
For information on using the Timebase directive in the Target
section, see the chapter Target Section Directives.
Format
Timebase number;
where:
number is the base time to be multiplied by the source clock. The
number is followed by one of these units:
• s for seconds
Example
Source
{
.
.

.
Timebase 2ns;
.
.
.
}
If you specified Timebase 2ns in the Source section of the Run file,
the source timestamp and the source time would be as shown below:
Table 13. Source timing when using a Timebase of 2ns.
This source timestamp... Becomes this event time:
0 0ns
APT Run File

5 10ns
Directives
10 20ns
15 30ns
20 40ns
25 50ns
30 60ns
APT Run File

APT Run File
Directives
Directives
See also
NoTimestamp, Step, Cyclized
APT Run File

Directives

Zero_delay
The Zero_delay Source section directive instructs APT to assume all
delay and sample time settings in the source data are equal to zero.
This directive has the same effect when used in either the Source
section or the Target section. For information on using the
Zero_delay directive in the Target section, see the chapter Target
Section Directives.
Format
Zero_delay;
Example
Source
{
.
.
.
Zero_delay;
.
.
.
}
See also
Groups

Target Section Directives

All valid Target section directives for a Vanguard target device are
listed in this section in alphabetical order:
• BidirCombine
• CycleDuration
• Data
• Device
• FixtureMap
• Include
• Map_Tristate
APT Run File

Directives
• NoSequenceNumbers
• Setup
• VanguardInstructions
• VanguardTiming
• WaveformMap
• WaveformOrder
APT Run File

APT Run File
Directives
Directives
• Zero_delay
APT Run File

Directives

BidirCombine
The BidirCombine Target section directive specifies two signals in a
simulation source file (one input and one output) that you want to
combine into a single bidirectional pin in the target pattern setup.
When this directive is used, the target Device must be
VanguardASCII.
Format
BidirCombine "src_grp_1" “src_grp_2”;
where:
src_grp_1 specifies the name of the input bidirectional source group.
It must match the name of a Bidir pin in the Vanguard test plan,
which in turn must map to the name of an Input group in the Source
section Groups directive. The group name must be written within
quote marks.
src_grp_2 specifies the name of the output bidirectional source
group. It must match the name of a Bidir pin in the Vanguard test
plan, which in turn must map to the name of an Output group in the
Source section Groups directive. The group name must be written
within quote marks.

Example
Segment "segname"
{
Source
{
Device "Generic";
Data "in.generic";
Groups
{
"inPin" : 1 : Bin : Input;
"outPin" : 1 : Bin : Output;
};
}
Target
{
APT Run File

Directives
Setup "testplan";
Data "out.VanguardASCII";
BidirCombine "IOpin" "outPin";
}
Conversion
{
Translate
{
"IOpin" { "inPin" };
APT Run File

APT Run File
};
Directives
Directives
}
}
See also
Bidir, Device, Groups
APT Run File

Directives

CycleDuration
The CycleDuration Target section directive forces APT to use a
particular cycle duration value. The value given overrides the cycle
duration specified in the target test plan’s Timing setup.
Format
CycleDuration value;
where:
value specifies a floating point number followed by a time unit
specifier. Valid time unit specifiers are:
• s for seconds
Example
CycleDuration 15.001ns;

Data
When used in the Target section, the Data directive specifies the
target data file. The Data directive must not appear before the Device
and Setup directives. The Data directive in a Target section may be
overridden by the -t filename command line option.
If you don't include a Data directive in your Target section and do not
use the -t filename command line option, then APT outputs the
data to the standard output device (stdout). This will allow you to
pipe the generated VangaurdASCII memory file directly into the
ims_pat_cvt program to be compiled into a binary file.
For information on using this directive in the Source section, see
APT Run File

Source Section Directives.
Directives
Format
Data "filename";
where:
filename is the name of the file to which you want the converted data
written. The filename must be within quotation marks.
APT Run File

APT Run File
Directives
Directives
Example
Target
{
Setup "test_plan_2";
Data "pat_setup_3";
}
APT Run File
See also
Directives
Device, Setup

Device
When used in the Target section, the Device directive specifies the
target device. The Device directive is required in every Target section
and must be the first directive to appear in any Target section.
For information on using the Device directive in the Source section,
see Source Section Directives.
Format
Device "format_name";
where:
format_name is the name of the device into which you want your
pattern data converted. The name must be within quotation marks. It
must be one of the following devices:
• VanguardASCII
• IMSVF (only available with AVI-Link)
Example
Target
{
Data "pat_setup_3";
}
See also
Data, Setup

FixtureMap
The FixtureMap directive specifies a fixture map file created by AVI-
Link. It is only available with AVI-Link, and only used when the Target
device is IMSVF.
For more information on the FixtureMap directive, see the appendix
AVI-Link.
Format
FixtureMap "filename"
where:
APT Run File

Directives
filename is the name of a valid fixture map file created by AVI-Link.
Example
Target
{
.
.
.
APT Run File

APT Run File
FixtureMap "fixmap_filename"
Directives
Directives
.
.
.
Include
The Include directive lets you specify that the contents of a separate
APT Run File
file be read into the run file at the point the Include directive is used.
Directives
This lets you keep portions of the Run file directives in separate files,
where they can be more easily maintained, stored, or accessed.

directive occurs.
statements.
Format
Include "filename";
where:
filename is an ASCII file containing grammatically legal Run file
directives, located in the current directory or identified by relative
where the directive is used.
Example
Target
{
Data "pat_setup_3";
Include "target.directives"
}
Assume the contents of target.directives is:
/* target.directives */
NoSequenceNumbers;
WaveformOrder "wave_order_2";
Usage
deep.

Map_Tristate
The Map_Tristate Target section directive directs APT to preserve
tristate information from the source file in the target setup. By default,
when APT encounters a pattern character in the source file that
indicates tristate, the data is converted to an upper case X. Using
this directive, you may instruct APT to convert tristate data from the
source file into the Vanguard tristate character: Z.
To determine if a pin may be tristated, APT consults the test plan
designated by the Setup directive. The Fixture setup in that test plan
must identify the pin as having these characteristics:
• a pin type of Input in the Pins setup, and
• a connection type of Single Wire/Z in the Fixture setup, and
APT Run File

Directives
• a termination mode of Tristate in the DC Levels setup.
This directive is only valid when the target device is VanguardASCII.
Format
Map_Tristate “char”;
where:
APT Run File

APT Run File
char is a single alphabetic character used in the traget file to
Directives
Directives
designate tristate, enclosed within quote marks. For example, to
preserve tristate data in the target file, use “Z”. This directive is case
sensitive.
Example
Target
{
Map_Tristate “Z”;
APT Run File
}
Directives

NoSequenceNumbers
The NoSequenceNumbers Target section directive eliminates the
automatically generated comments inserted into Vanguard ASCII
formatted pattern files. The default behavior followed by APT is to
include comments in the Vangaurd ASCII pattern file it creates, at
every eighth sequence for DM500 pattern and every sixteenth
sequence for DM1000 pattern. For example:
"Default", 0000LL1 , "; Sequence 0" ;

"Default", 0001LH0 ;
"Default", 0010HH0 ;
"Default", 0011HL0 ;
"Default", 0100LHH ;
"wf1", 0101HHL ;
"wf1", 0110HLL ;
"wf1", 0111HL1 ;
"wf1", 1000HL0 , "; Sequence 8" ;
"wf1", 1001LL0 ;
Using the NoSequenceNumbers directive eliminates these

comments, making the resulting file smaller.
Format
NoSequenceNumbers;
Example
Target
{
.
.
.
NoSequenceNumbers;
.
.
.
}

Setup
In the Target section, the Setup directive specifies the Target setup
file. In most cases the target setup file is the test plan in which your
pattern setup will be used. The Setup directive must be the second
directive in the Target section, before the Data directive and after the
Device directive.
For information on using the Setup directive in the Source section,
see Source Section Directives.
Format
Setup "filename";
APT Run File

where:
Directives
filename is the name of the Target setup file. If your target device is
VanguardASCII, this is the name of a test plan. If you are using AVI-
Link and your target device is IMSVF, then this is the name of an
ATS/XTS setup file.
Example
Target
APT Run File

APT Run File
{
Directives
Directives
Data "pat_setup_3";
}
See also
Data, Device, VanguardTiming
APT Run File
Directives

VanguardInstructions
The VanguardInstructions Target section directive converts a limited
set of ATS/XTS pattern instructions into VanguardASCII pattern
instructions. Instructions not recognized in this set are converted to
comments in the target file. This directive is only used with AVI-Link.
Additionally, pattern instructions on the Vanguard must conform to a
different set of rules than pattern instructions on the ATS/XTS. APT
checks to see if the rules for creating Vanguard pattern instructions
and the usage of pattern instructions in the source file are in conflict.
In cases where more than one instruction in the source file can be
applied to the same target cycle, APT applies the first instruction,
converts each subsequent instruction to a comment, and issues a
notification message.
ATS/XTS pattern instructions are converted according to the
following table.
Table 14. Conversion of ATS pattern instructions to Vanguard

instructions.
ATS/XTS
Description of Conversion
Instructions
loop These remain unchanged in the target file.

repeat
comment
begin acquisition
begin test
clear errors
end acquisition
goto <target> These remain unchanged in the target file.
if error goto Additionally, the following warnings are
if any errors goto issued:
if no error goto
if no errors goto Keep Alive vectors are required.
No target label is defined.

Table 14. Conversion of ATS pattern instructions to Vanguard

instructions.
ATS/XTS
Description of Conversion
Instructions
halt These remain unchanged in the target file.

end loop Additionally, the following warning is issued:
Keep Alive vectors are required.
All other Converted to a comment in the target file.

instructions Notification message issued.
Format
APT Run File

Directives
VanguardInstructions;
Example
Target
{
.
.
.
APT Run File

APT Run File
Directives
Directives
VanguardInstructions;
.
.
.
}
See also
Option APT Run File
Directives

VanguardTiming
The VanguardTiming Target section directive is used to specify the
Timing setup you want to use when converting source data to
Vanguard ASCII format. If you do not specify a Timing setup with this
directive, APT uses the current Timing setup from the test plan
named in the Setup directive.
The timing specified in the timing setup you name using this directive
is used to determine the data extraction from the source file, when
this not specified in the source section Groups directive. Care should
be taken to have the correct cycle time and delay values for input and
output pins in this setup as these form the ’sample’ times for the
source data. It might be more convenient to have a separate setup
for simulation extraction if the timing is different from the desired
testing setup.
Format
VanguardTiming "setupname";
where:
setupname is the name of a Timing setup in a test plan directory. The
name must appear in quotation marks.
Example
Target
{
.
.
.
VanguardTiming "Timing_3";
.
.
}
Usage
This directive explicitly names the Timing setup you want to use
when converting to VanguardASCII. This avoids any potential
problems if the current Timing setup in the test plan changes.

See also
Setup
IMS Vanguard Pattern Conversion Manual

173
APT Run File

APT Run File APT Run File APT Run File
Directives
Directives Directives Directives
WaveformMap
The WaveformMap Target section directive specifies the name and
path of the waveform map file. This directive is only used during
conversions where the target device is IMSVF. It is only useful when
using AVI-Link. For details, see the appendix, AVI-Link.
Format
WaveformMap "filename";
where:
filename is the name of a Waveform Map file created by AVI-Link.
Example
Target
{
.
.
.
WaveformMap "wave_map_t3";
.
.
.
}

WaveformOrder
The WaveformOrder directive specifies a waveform order file to use
when converting source data to VanguardASCII format. This file is
required for any conversion that uses a waveform other than the
Default waveform. The format for the contents of the waveform order
file is described in the chapter, Creating the Waveform Order File.
Format
WaveformOrder "filename";
where:
APT Run File

Directives
filename is the name of a waveform order file you create.
Example
Target
{
.
.
.
WaveformOrder "wave_order_t3";
APT Run File

APT Run File
Directives
Directives
.
.
.
}
See also
Groups
APT Run File
Directives

Zero_delay
The Zero_delay directive instructs APT to assume all delay and
sample time settings in either the current Timing setup in the test
plan or the Timing setup indicated by the VanguardTiming directive
are equal to zero.
For information on using this directive in the Source section, see
Source Section Directives.
Format
Zero_delay;
Example
Target
{
.
.
.
Zero_delay;
.
.
.
}
Usage
Specify this directive in the Target section if your source data is not
formatted as on-change data with timestamps.
See also
Groups

Conversion Section Directives

All valid Conversion section directives for a Vanguard target device
are listed in this section in alphabetical order:
• Include
• Logfile
• Translate
APT Run File

Directives
APT Run File
APT Run File
Directives
Directives
APT Run File
Directives

Include
The Include directive lets you specify that the contents of a separate
file be read into the run file at the point the Include directive is used.
This lets you keep portions of the run file directives in separate files,
where they can be more easily maintained, stored, or accessed.
directive occurs.
statements.
Format
Include "filename";
where:
filename is an existing ASCII file containing grammatically legal run
file directives, located in the current directory or identified by relative
in the run file where the directive is used.
Example
Conversion
{
Logfile "test1.log";
Include "test1.trans";
};
In this example, the contents of test1.trans are:
/* test1.trans */
/* defines source group to IMS tester group mapping */

/* */
Translate
{
"A-hi" {"A":3:2};
"SumI" {"B":3:0};
};

deep. For example, the file, test1.trans, might contain an
additional line:
Include "test1.trans_single_bits";
The file named by the nested Include directive
APT Run File

(test1.trans_single_bits) might contain:
Directives
/* test1.trans_single_bits*/
/* defines source group to IMS tester group mapping*/
/* for single-bit translations*/
/* */
Translate
{
"In_hi" {"D":2 ‘1’};
"In_low {"D":4 ‘0’};
};
APT Run File

APT Run File
Directives
Directives
Usage
While it is possible for the Include directive to reference any existing
file with grammatically correct APT directives, the Include directive is
most useful in the Conversion section for specifying files containing
Translate directives.
See Also: APT Run File
Translate
Directives

Logfile
The Logfile Conversion section directive specifies the file to which
you want to send the conversion statistics. You must always use the
Logfile directive if you want conversion statistics. When the directive
is used and no file is specified, the statistics are sent to the standard
output device (stdout).
Format
Logfile "file_name";
where:
file_name is the name ofa file where you want the conversion
statistics sent. The name must be enclosed in quotation marks. A
set of quotation marks enclosing a null name results in the statistics
being sent to stdout.
Example
Conversion
{
Logfile "my_stats";
}
To send the statistics to stdout, specify:
Logfile " ";
Usage
The number of vectors converted, as displayed in the Log file, refers
to the number of internal APT vectors. This number may be larger
than the number of vectors in your source data file.

Translate
You use the Translate directive to map source groups to Target
groups. Using this directive you may assemble the data for your
target groups from any locations in your source data and in any order
of occurance in the source data. For most Vanguard applications,
there will be a simple one to one mapping of signal names.
Formats
The Translate directive has three formats.
Format 1:
Translate
APT Run File

Directives
{
"IMS_name" {"source_name" [:msb: lsb] [‘pattern’]};
.
.
.
};
Format 2:
Translate
APT Run File

APT Run File
{
Directives
Directives
"IMS_name" {"source_name"[ :lsb: msb] [‘pattern’]};
.
.
.
};
Format 3:
Translate
{ APT Run File
"IMS_name" {"source_name": bit [‘pattern‘]}; Directives
.
.
.
};
where:

IMS_name is the name of the Target pin group. The name must be
in quotation marks.
source_name is the name of the source group or frame that maps to
the LM group or frame. The name must be in quotation marks.
msb:lsb specifies the order of the bits that make up the simulator
group from the most significant (msb) bit to the least significant bit
(lsb). If you leave out the msb and lsb specification, APT uses all the
bits in the group.
lsb:msb denotes the order of the bits that make up the simulator
group, as proceeding left to right from the least significant bit (lsb) to
the most significant bit (msb). The default is msb:lsb.
bit specifies the single bit position that APT will map to the Target pin
group.
pattern specifies the pattern you want for part or all of the target
group.
Example
The Translate directive is typically a multi-line directive.
Conversion
{
Translate
{
"A_hi" { "A":3:2};
"SumI" { "B":3:0};
};
}
This example gives these results:
Table 15. Results of example.
This source group: maps to this Vanguard group:
A bits 3 and 2 A_hi

B bits 3, 2, 1, 0 SumI

You can map the bits that comprise one Target group from more than
one simulator group. For example, you have three simulator groups,
A, B and C, each with four bits 0 - 3. The columns of data appear in
the source file in order from msb to lsb. The column headers might
look like this, naming each signal in each group:
A3 A2 A1 A0 B3 B2 B1 B0 C3 C2 C1 C0
If you wanted to map some of the bits from these simulator groups to
the Target group SumO, the Translate directive might be as follows:
Conversion
{
Translate
{
"SumO" { "A":2:1 "B":3 "C":3:0};
APT Run File

};
Directives
}
This directive maps seven (7) bits from the simulator groups A, B,
and C to the Target group Sum0 so that Sum0 is comprised of the
data coming under these headers in the source data:
A2 A1 B3 C3 C2 C1 C0
Usage
APT Run File

APT Run File
Directives
Directives
The usage for the different formats is described in this section.
Format 1
Format 1 maps source groups to Target groups. The optional
msb:lsb parameter specifies the number of the bits in the group, but
not which bits. If you do not specify the msb:lsb, APT maps the
entire Source group to the IMS group. For example,
Translate
APT Run File
{
Directives
"Force_A" {"data":3:0};
"Comp_A" {"comp":0:0};
};
If you specify a pattern, APT uses that pattern for all or part of the
Target group, depending on the bits you specify. For example,
Translate

{
"Force_A" {"data":5:0 ’zzz’};
};
translates the data for the first five bits for an eight bit group from the
Source group "data" and tri-states the remaining bits. You can also
tell APT to use pattern for the entire group, such as a clock, as
follows:
Translate
{
"Clk" {’1’};
};
Format 2
You can reorder the bits using this directive. For example, if the bits
are:
You reverse the order of the msb and lsb by using the Translate
directive, as follows:
Translate
{
"Force_A" {"data":0:5}
}
Format 3
This format allows you to map one bit from the Source group to the
target Vanguard group.
Renaming groups. To convert simulator data, APT requires that all
simulator groups be uniquely named. For any groups that are not
uniquely named, APT will rename subsequent occurrences of a
group name. To show you that the group or pin has been renamed,
APT displays a warning message and appends _number to the
group name (for example, the second occurrence of group dbus1
would be renamed dbus1_1; the third occurrence would be renamed
dbus1_2, etc.).

Duplicate pin names. APT prefers that pins be uniquely named;

however, this is not always the case in reality. If a pin name is used
more than once, you must refer to it using a pathname. Typically,
you need to use pathnames when a pin name is identical to a group
name.
See also
Groups
APT Run File

Directives
APT Run File
APT Run File
Directives
Directives
APT Run File
Directives


8
LEARNING THROUGH EXAMPLES
This chapter uses a set of example files to illustrate how to use APT
and other IMS pattern conversion software. It covers these topics:
• Getting Started
• VCD Example 1
• VCD Example 2
Learning Through
• Generic Example 1
Examples
Learning Through
Examples
Learning Through
Learning Through
Examples
Examples

8 - Learning Through Examples
Getting Started
As you work with these examples, you may find it convenient to have
IMS Tools running. The examples discussed in this chapter are
normally installed in:
/opt/ims/apt/version/examples/Vanguard/
where version is the version of APT most recently installed.To find
out the version of APT you are running, use this command:
apt -version
Before reading this chapter, you should be familiar with the
fundamental Vanguard concepts and software covered in the
manual, Getting Started with Vanguard.

Using These Examples with DPT
Using These Examples with DPT

To convert the APT Run files provided with these examples into DPT
Run files, use the following command:
ims_dpt -convert runfilename
where runfilename is the name of the APT Run file you want to
convert. Optionally, runfilename may include an absolute or a relative
path name.
DPT automatically converts as much of the APT Run file as it can
and writes the results to a file named: dpt_basename.ims, where
basename is the runfilename with any extension removed.
Learning Through
For example, if you enter this command:
ims_dpt -convert /home/steve/runfile.apt
Examples
then DPT creates a file named dpt_runfile.ims in the directory
/home/steve.
Because of the differences between APT and DPT Run file syntax,
the converted file may differ in some details from the original.
With DPT, you may omit the steps of using ims_pat_cvt to convert
the pattern setups into Vanguard binary format and adding it to the
Learning Through
test plan, by adding these directives to the DPT Run file:
Examples
UpdateTestPlan;
Learning Through
Learning Through
Examples
Examples

VCD Example 1
The first example shows the following conversion steps:
SURF
1. Run file Waves Waves
SURF
file Tool
Simulation file
APT APT
2. Run file
Pattern
setup
(ASCII)
Pattern
3. ims_pat_cvt setup
(binary)
Test plan
All the examples in this chapter repeat these basic steps.

The first example resides in the directory, VCD_Example_1:
Table 16. Elements of VCD_Example_1
Name Description
verilog_example_1.dump A VCD data file.

VCD Example 1
Table 16. Elements of VCD_Example_1
Name Description
Surf_16646.ims A SURF Run file to be used for

converting the VCD data file into
waves format.
Waves_16646.ims A Waves format file converted from
the VCD data file.
AptRunFile_16646.ims An APT Run file for converting the
VCD data file into a Vanguard ASCII
pattern setup.
Learning Through
AptGroups_16646.ims A Groups directive to be included in
the APT Run file, using the Include
Examples
directive.
Pattern_16646.ims A Vanguard ASCII pattern setup to be
imported into the test plan.
TestPlan_16646 A minimal test plan into which you may
import Pattern_16646.ims.
Learning Through
All the other examples in this chapter use a similar set of elements,
with each successive example containing new or different material to
Examples
illustrate additional specifications.
Looking at the Files

First, look at some of the more important features of these files.
Looking at the VCD Data File Learning Through

Learning Through
For this example, the most important feature of the VCD example file
Examples
Examples
verilog_example_1.dump is the $scope/$upscope block. The
signal names are defined in this block. All the signals are in a module
named Top.
Here is the $scope/$upscope block:
$scope module Top $end

$var wire 1 A ClockAB $end

$var wire 1 B SAB $end

$var wire 1 C DIR $end
$var wire 1 D A8 $end
$var wire 1 E A7 $end
$var wire 1 F A6 $end
$var wire 1 G A5 $end
$var wire 1 H A4 $end
$var wire 1 I A3 $end
$var wire 1 J A2 $end
$var wire 1 K A1 $end
$var wire 1 L B8 $end
$var wire 1 M B7 $end
$var wire 1 N B6 $end
$var wire 1 P B4 $end
$var wire 1 Q B3 $end
$var wire 1 R B2 $end
$var wire 1 S B1 $end
$var wire 1 T OutputEnable_ $end
$var wire 1 U SBA $end
$var wire 1 V ClockBA $end
$upscope $end
This block is followed by the keyword $dumpvars. Everything below
$dumpvars represents pattern vector data.
Looking at the SURF Run File

Here is the SURF Run file Surf_16646.ims:
SourceFile verilog_example_1.dump;
TargetFile Waves_16646.ims;
TesterType Vanguard;
CycleLength 20ns;
Depth 32;
SourceFormat VCD;
Signals
Top.ClockAB
Top.SAB
Top.DIR
Top.A8
Top.A7
Top.A6
Top.A5
Top.A4

VCD Example 1
Top.A3
Top.A2
Top.A1
Top.B8
Top.B7
Top.B6
Top.B5
Top.B4
Top.B3
Top.B2
Top.B1
Top.OutputEnable_
Top.SBA
Top.ClockBA
;
Learning Through
Several directives in this Run file deserve closer examination. All the
Examples
SURF directives are described in the appendix, Converting Data for
the Waves Window.
SURF Signals Directive

Signals
Top.ClockAB
Top.SAB
Learning Through
[... continued...]
Examples
This signal information was derived from the VCD file header. The
format for signal names is:
modulename.signalname
where:
modulename is the name of the module containing a signal (for
example: Top). If the signals are in nested modules, then all modules
must be included, with the top level module listed first, followed by
Learning Through
Learning Through
the name of each nested module, separated by periods, on the
Examples
Examples
model: modulename.modulename.signalname.
signalname is one signal listed in the $scope/$upscope block of the
VCD file header (for example: ClockBA).

SURF Depth Directive

Depth 32;
This directs SURF to convert 32 cycles of data. No more than 2048
cycles can be converted each time you run SURF. The default is to
start converting at cycle 0. To specify a set of cycles starting beyond
cycle 0, use the StartTime directive.
SURF CycleLength Directive

CycleLength 20ns;
The correct cycle length cannot be learned from looking at the VCD
file header. If this information is not available from a data sheet or
other source, you may specify an arbitrary cycle length and readjust
it after examining the vectors in the Waves Window.
Running SURF
This step assumes that SURF is available through your PATH, and
that you are currently in the directory, VCD_Example_1.
To run SURF on this example, use this command line:
surf -r Surf_16646.ims
Invoking this command creates a file identical to Waves_16646.ims,

a file that is already supplied.
Looking at Signals in the Waves Window

To view the simulation data in Waves_16646.ims:
1. Start IMS Tools from the command line:
ims_tools
2. From the Toolbox, open the Waves window by clicking on the
Waves icon.
3. Load Waves_16646.ims into Waves Window, using File > Open.
NOTE — When you are prompted to open a layout, select no.

i

VCD Example 1
After loading the file, your Waveform Display window shows the
waveforms defined in the VCD simulation data. It places vertical
cycle boundaries at 20ns intervals.
Learning Through
Examples
If the cycle boundaries seem misplaced in relation to your signal
transitions (edges), measure the placement of the signal transitions
and reconvert your simulation data with a different cycle duration.
Information on measuring edge placement in the Waves Window is
given in the online Help. Select Help > Help on this Window and read
Learning Through
the topic Measuring Delta Time between State Transitions.
Examples
If you are not familiar with the Waves Window, consult the chapter
Using Waves in the User’s Manual, Vol. 1, and the online Help.
Looking at the APT Run File

After you determine the characteristics of your simulation data by
viewing it in the Waves Window, you may convert the simulation data
to a pattern setup using APT.
Learning Through
Learning Through
To use APT, you must write a Run file such as

Examples
Examples
AptRunFile_16646.ims:
Segment "VCD_2_Vanguard"
{
Source
{
Device "VCD";

Data "verilog_example_1.dump";
Include "AptGroups_16646.ims";
Option "Monitor";
}
Target
{
Setup "TestPlan_16646/";
Data "Pattern_16646.ims";
}
Conversion
{
Translate
{
/* Vanguard Name VCD Name */
/* ============= ======== */
"CAB" { "Top.ClockAB"};
"SAB" { "Top.SAB" };
"DIR" { "Top.DIR" };
"A8" { "Top.A8" };
"A7" { "Top.A7" };
"A6" { "Top.A6" };
"A5" { "Top.A5" };
"A4" { "Top.A4" };
"A3" { "Top.A3" };
"A2" { "Top.A2" };
"A1" { "Top.A1" };
"B8" { "Top.B8" };
"B7" { "Top.B7" };
"B6" { "Top.B6" };
"B5" { "Top.B5" };
"B4" { "Top.B4" };
"B3" { "Top.B3" };
"B2" { "Top.B2" };
"B1" { "Top.B1" };
"OE_" { "Top.OutputEnable_"
};
"SBA" { "Top.SBA" };
"CBA" { "Top.ClockBA"};
};
}
}

VCD Example 1
All of the APT directives are discussed elsewhere in this manual.

Several of the APT directives in this Run file are discussed briefly,
below.
APT Include directive

The Include directive includes another file from the into the APT Run
file at the position where it appears. The contents of
AptGroups_16646.ims is an APT Groups directive.
APT Groups directive

The Groups directive in the included file lists every signal from the
Learning Through
file, verilog_example_1.dump, using the same naming convention
as the Signals directive in the SURF Run file, along with some
Examples
additional syntax to identify its radix, the width of the data and the
signal direction:
Groups
{
"Top.ClockAB" :Bin :1 :Input;
"Top.SAB" :Bin :1 :Input;
.
.
Learning Through
.
Examples
APT Translate Directive
The Translate directive maps the signal names used in the Groups
directive to the pin names used in the Device Pins setup in the
example test plan, TestPlan_16646.
Running APT Learning Through

Learning Through
This step assumes that APT is available through your PATH, and that
Examples
Examples
you are currently in the directory, VCD_Example_1.

To run APT on these examples, use this command line:
apt -r AptRunFile_16646.ims
This creates an ASCII pattern setup identical to

Pattern_16646.ims.

Running ims_pat_cvt
This step assumes ims_pat_cvt is available through your PATH,
and that you are currently in the directory, VCD_Example_1.
To run ims_pat_cvt on this example:
1. Change to the directory, TestPlan_16646:
cd TestPlan_16646
2. Enter this command:
ims_pat_cvt -updateTestplan \
-pattern 16646_example \
< ../Pattern_16646.ims
This converts Pattern_16646.ims to binary format, imports it into
TestPlan_16646, and adds it to the list of available pattern setups.
When viewed in the Pattern window of IMS Tools, this setup will
appear as 16646_example.

VCD Example 2
VCD Example 2
This example demonstrates how to convert a VCD source that has
bidirectional pins. The conversion steps described in VCD Example 1
remain the same. This section uses the example files contained in
the directory VCD_Example_2.
Looking at the VCD Data File

The file verilog_example_2.dump is similar to the first example file,
but adds a second $scope/$upscope block. This new block contains
signals in a module named OutputControl, shown here:
Learning Through
$scope module OutputControl $end
$var wire 1 W ClockAB_oc $end
Examples
$var wire 1 X SAB_oc $end
$var wire 1 Y DIR_oc $end
$var wire 1 Z A8_oc $end
$var wire 1 1 A7_oc $end
Learning Through
$var wire 1 8 B8_oc $end
Examples
$var wire 1 ! B5_oc $end
$var wire 1 @ B4_oc $end
$var wire 1 # B3_oc $end
$var wire 1 $ B2_oc $end
$var wire 1 % B1_oc $end
$var wire 1 ^ OutputEnable__oc $end Learning Through
$var wire 1 & SBA_oc $end Learning Through
$var wire 1 * ClockBA_oc $end
Examples
Examples
$upscope $end

The SURF Run file, Surf_16646.ims has acquired a new set of
signal names in its Signals list, shown here:

Signals
[...]
OutputControl.ClockAB_oc
OutputControl.SAB_oc
OutputControl.DIR_oc
OutputControl.A8_oc
OutputControl.A7_oc
OutputControl.A6_oc
OutputControl.A5_oc
OutputControl.A4_oc
OutputControl.A3_oc
OutputControl.A2_oc
OutputControl.A1_oc
OutputControl.B8_oc
OutputControl.B7_oc
OutputControl.B6_oc
OutputControl.B5_oc
OutputControl.B4_oc
OutputControl.B3_oc
OutputControl.B2_oc
OutputControl.B1_oc
OutputControl.OutputEnable__oc
OutputControl.SBA_oc
OutputControl.ClockBA_oc
;
Looking at Signals in the Waves Window

Because the file Waves_16646.ims is already supplied, you do not
need to run SURF to create it. If you prefer to create the file, the
steps for running SURF are identical to those given in VCD Example
1, although you are assumed to be in the directory VCD_Example_2.

VCD Example 2
Load Waves_16646.ims into the Waves Window, using File > Open.
Learning Through
Examples
The new OutputControl signals are displayed.
Looking at the APT Groups File

The file AptGroupsFile_16646.ims has changed to reflect the
presence of bidirectional pins.The additional OutputControl signals
Learning Through
from the VCD data file have been added, and all the signals are now
bidirectional signals.
Examples
Here are a few lines to show how the Groups directive changed:
"Top.SBA” :Bin :1 :Bidir;

"Top.ClockBA” :Bin :1 :Bidir;
"OutputControl.ClockAB_oc" :Bin :1 :Bidir;
"OutputControl.SAB_oc" :Bin :1 :Bidir;

Learning Through
Learning Through
Examples
Examples
The most significant change in AptRunFile_16646.ims is the
addition of a block of Bidir directives. Here are some examples:
Bidir "Top.A8" Control "OutputControl.A8_oc" :Negative;


APT Bidir directive

The Bidir directive is used to identify characteristics of bidirectional
pins, such as the name of the signal that controls whether the pin is
functioning as an input or output, and how to interpret the control
signal when it is high or low. This directive is covered in more detail in
the chapter, Source Section Directives.
Running APT and ims_pat_cvt

Because Pattern_16646.ims is already supplied, you do not need
to run APT to create it. If you prefer to create the file, the steps for
running APT are identical to those given in VCD Example 1,
assuming you are located in the directory, VCD_Example_2.
To import Pattern_16646.ims into the example test plan so you
may view it in the Pattern window of IMS Tools, use the same
commands described in VCD Example 1, but start from the directory,
VCD_Example_2.

Generic Example 1
Generic Example 1
This example demonstrates how to convert a Generic tabular source
file with bidirectional signals, where the signal direction is indicated
by state characters. The conversion steps described in VCD
Example 1 remain the same in this example.
This section uses the example files contained in the directory,
Generic_Example_1.
Looking at the Generic Data File

Here are samples from simulation_646_generic_1.ascii,
Learning Through
showing two ranges of data:
Examples
0 NNNXXXXXXXXXXXXXXXXNNN : ; Start:
20 NNNXXXXXXXXNNNNNNNNNNN : ; B to A transfer
29 NNNLLLLLLLLNNNNNNNNNNN
40 NNNLLLLLLLLNNNNNNNPNNN
49 NNNLLLLLLLHNNNNNNNPNNN
60 NNNLLLLLLLHNNNNNNPNNNN
69 NNNLLLLLLHLNNNNNNPNNNN
.
.
Learning Through
.
820 NNPNNNNPNNNLLLLLHHHNPN
Examples
829 NNPNNNNPNNNLLLLHLLLNPN
840 NNPPPPPPPPPXXXXXXXXNPN
869 NNPPPPPPPPPHHHHHHHHNPN
880 NNPNPPPPPPPHHHHHHHHNPN
889 NNPNPPPPPPPLHHHHHHHNPN
900 NNPNNPPPPPPLHHHHHHHNPN
909 NNPNNPPPPPPLLHHHHHHNPN
920 NNPNNNPPPPPLLHHHHHHNPN
.
Learning Through
Learning Through
.
.
Examples
Examples
Each row begins with a timestamp. Each column beyond the

timestamp represents the state of one pin at that timestamp.
This file uses state characters to distinguish input from output on the
same pin. P and N are used to indicate input to the device. H and L
are used to indicate output.

Most of the pins on the 16646 device are grouped as two buses. In
this file the buses change direction beyond 640ns.

Here is the SURF Run file SURF_16646.ims:
SourceFile simulation_646_generic_1.ascii;
CycleLength 20ns;
Substitute P 1;
Substitute N 0;
Depth 64;
Signals
// Name Width Dir Visible
ClockAB 1 I Y
SAB 1 I Y
DIR 1 I Y
A8 1 IO Y
A7 1 IO Y
A6 1 IO Y
A5 1 IO Y
A4 1 IO Y
A3 1 IO Y
A2 1 IO Y
A1 1 IO Y
B8 1 IO Y
B7 1 IO Y
B6 1 IO Y
B5 1 IO Y
B4 1 IO Y
B3 1 IO Y
B2 1 IO Y
B1 1 IO Y
OutputEnable_ 1 I Y
SBA 1 I Y
ClockBA 1 I Y
;
Comment : ; // To ignore pattern instructions/comments .

Generic Example 1
Substitute Directive
This file uses the Substitute directive to replace the two state
characters P and N with two state characters that SURF recognizes
and understands: 1 and 0.
Signals Directive
The format of the Signals directive depends on whether the
simulation file format is VCD or a generic tabular format. This Run
file specifies the SourceFormat as Generic and uses the
corresponding Signals format. These Signals formats are explained
in the chapter Preparing Data for the Waves Window.
Learning Through
Comment Directive
Examples
The source data file has comments. The Comment directive is used
to instruct SURF where comments begin, so they will not be
mistaken for data.
Viewing Signals Using the Waves Window

Learning Through
Examples
Learning Through
Learning Through
Examples
Examples

Input signals are shown in green and output signals in magenta. By

entering 20, 40 in the Jump To Vectors field, you can examine the
signals on Bus A and Bus B switching direction.

Here is AptRunFile_16646.ims:
Segment "Generic_2_Vanguard"
{
Source
{
Device"Generic";
Data "simulation_646_generic_1.ascii";
Include"AptGroups_16646.ims";
Substitute "P" "1";
Substitute "N" "0";
Comment "#";
Option"Instructions";
Option"Monitor";
}
Target
{
Setup "TestPlan_16646";
WaveformOrder"WaveFormOrder_16646.ims";
}
Conversion
{
Translate
{
/* Vanguard Name Generic Name */
/* ============= ============ */
"CAB" { "ClockAB" };
"CBA" { "ClockBA" };
"OE_" { "OutputEnable_" };
};
}
}

Generic Example 1
Substitute and Comment Directives

The APT Run file uses Substitute and Comment directives for the
same purpose as the Substitute and Comment directives in the
SURF Run file. But the APT syntax is different, in that the specified
characters must appear within quote marks.
WaveformOrder directive
The WaveformOrder directive specifies the file
WaveFormOrder_16646.ims. This file is included in the
Generic_Example_1 directory. A waveform order file is required
when the pattern setup created from your source data uses more
than one Vanguard waveform. In this case, the file
Learning Through
WaveFormOrder_16646.ims is not strictly required, since it applies
Examples
the Default waveform to every sequence.

The file Pattern_16646.ims is already supplied, so you do not need
assuming you are located in the directory, Generic_Example_1.
Learning Through
Examples
Generic_Example_1.
Learning Through
Learning Through
Examples
Examples

Generic Example 2
This example demonstrates how to convert a Generic source where
the device has bidirectional pins but the source data does not use
state characters to define the direction of the signal. Instead the input
and output data for one pin are listed in two columns.
Generic_Example_2.

Here are two ranges of source data from
simulation_646_generic_2.ascii:
0 0 0 0 0 0 0 zzzzzzzz zzzzzzzz xxxxxxxx xxxxxxxx : ; Start:

20 0 0 0 0 0 0 zzzzzzzz 00000000 xxxxxxxx xxxxxxxx : ; B to A
29 0 0 0 0 0 0 zzzzzzzz 00000000 00000000 xxxxxxxx
.
.
.
640 0 0 1 0 1 0 zzzzzzzz zzzzzzzz xxxxxxxx xxxxxxxx
660 0 0 1 0 1 0 00000000 zzzzzzzz xxxxxxxx xxxxxxxx
669 0 0 1 0 1 0 00000000 zzzzzzzz xxxxxxxx 00000000
.
.
.
The first column contains timestamps. The next six columns contain
data for six control pins. The next eight columns contain data for the
A bus pins during input cycles. The next eight columns show the B

Generic Example 2
bus pin data during input cycles. These are followed by 16 columns
of output data for the A and B buses. Once again, the data buses
change direction beyond 640ns.

The greatest change in SURF_16646.ims from the last example is
the Signals list, where each column of data is given an unique name
and identified with one signal direction.

Learning Through
Examples
The significant changes to the file AptRunFile_16646.ims are in the
Target and Conversion sections, shown here:
Target
{
Learning Through
Setup "TestPlan_16646";
Examples
WaveformOrder "WaveFormOrder_16646.ims";
BidirCombine "A8i" "A8o";
BidirCombine "A1i" "A1o"; Learning Through
Learning Through
BidirCombine "B8i" "B8o";
Examples
Examples

}

Conversion
{
Translate
{
/* Vanguard Name Generic Name */
/* ============= ============ */
"OE_" { "OutputEnable_" };
"CAB" { "ClockAB" };
"CBA" { "ClockBA" };
"A8" { "A8i" };
"A7" { "A7i" };
"A6" { "A6i" };
"A5" { "A5i" };
"A4" { "A4i" };
"A3" { "A3i" };
"A2" { "A2i" };
"A1" { "A1i" };
"B8" { "B8i" };
"B7" { "B7i" };
"B6" { "B6i" };
"B5" { "B5i" };
"B4" { "B4i" };
"B3" { "B3i" };
"B2" { "B2i" };
"B1" { "B1i" };
};
}
}
BidirCombine Directive
The BidirCombine directive is required when input data and output
data for the same pin are divided into two separate columns of
source data.
To understand how the BidirCombine directive is being used here,
you must look at the Groups directive in AptGroups_16646.ims. An
excerpt is shown here:
.
.
.
"A6i" :Bin :1 :Input;

Generic Example 2

"B8i" :Bin :1 :Input;
"A8o" :Bin :1 :Output;
Learning Through
Examples
.
.
.
This Groups directive identifies the column containing input data for
the pin A4 as A4i and the output column as A4o. The BidirCombine
directive combines the A4i and A4o columns of data to create data
for one bidirectional pin: A4i.
Learning Through
Translate Directive
Examples
Because the pin name in the device pins setup is A4, rather than A4i,
the Translate directive maps the combined data in A4i to the name
A4.

Learning Through
Learning Through
Examples
Examples
Generic_Example_2.

Generic Example 3
This example demonstrates how to convert a Generic source that
has no timestamps and the state characters do not specify the signal
direction for bidirectional pins. The basic set of steps described in
VCD Example 1 remain the same.
Generic_Example_3.

Here is an excerpt from simulation_646_generic_3.ascii:
000XXXXXXXXXXXXXXXX000: ; Start:
0000000000000000000000: ; B to A transfer
0001000000010000000000
0000100000001000000000
0001100000011000000000
0000010000000100000000
0001010000010100000000
0000110000001100000000
0001110000011100000000
0000001000000010000000
000XXXXXXXX11111111000
0001111111111111111000
0001111111011111110000
0001111110011111100000
This source data has no timestamps and the state characters do not
indicate the signal direction for bidirectional pins. Unlike the previous
example, the data for each bidirectional pin occupies one column
rather than two.

When a generic tabular source file has no timestamps, the SURF
Run file requires the directives NoTimestamp and Step. Here is an
excerpt from SURF_16646.ims showing those directives:
SourceFile simulation_646_generic_3.ascii;

Generic Example 3
CycleLength 20ns;
Depth 64;
NoTimestamp;
Step 20ns;
.
.
.
The NoTimestamp directive instructs SURF that the first column of
the source file contains source data rather than a timestamp. The
Step directive specifies the elapsed time between rows of data.
Learning Through
Examples
Here is the Source section from AptRunFile_16646.ims:
Source
{
Device "Generic";
Learning Through
Data "simulation_646_generic_3.ascii";
Include "AptGroups_16646.ims";
Examples
Option "Instructions";
/* Option "Monitor"; */
NoTimestamp;
Step 20ns;
Bidir "A8" Control "DIR";
Learning Through
Learning Through
Examples
Examples
Bidir "B8" Control "DIR" :Negative;


}
SImilarly to the SURF Run file, the Source section includes a
NoTimestamp directive and a Step directive. Again, the APT syntax
requires the step value to be enclosed in quote marks. These
directives accomplish the same tasks in APT as in SURF.

Generic_Example_3.

A
AVI-LINK
AVI-Link
Use AVI-Link to translate ATS/XTS Series test patterns and setups
for use with Vanguard. AVI-Link does not support translation of
Vanguard test plans to ATS/XTS Series test station. AVI-Link
requires V4.2e APT (or higher).
This appendix discusses how to use AVI-Link. It includes these
topics:
• Overview
AVI-Link
• Starting AVI-Link
• Supported and Unsupported ATS Features
• Planning Considerations
• Mapping Your Device to the Vanguard Fixture
• Translating Your ATS Setup to a Vanguard Test Plan
• Translating ATS Pattern Files to Vanguard Pattern Setups
AVI-Link
• Automating the Process
AVI-Link

A - AVI-Link
Overview
To moving your data from an ATS/XTS Series test station to
Vanguard using AVI-Link you must:
1. Identify unsupported features in your ATS setup file and modify
them if possible.
2. Translate your ATS setup file into a valid Vanguard test plan.
3. Translate your ATS pattern files into Vanguard pattern setups.
These tasks are performed in the order in which they are listed.
AVI-Link must map your device from the ATS-style fixture to the
Vanguard fixture. It creates a Fixture Map file that lists all the pins in
your device and their type. You edit this file to map each pin to the
channel on the Vanguard fixture. You may also choose to have AVI-
Link assign Vanguard channels to your pins, but the channels it
selects may not match your fixture and will probably need to be
corrected at some later time.
During translation AVI-Link creates a Vanguard test plan based on
the ATS setup you supply. Not all ATS features are supported by
Vanguard. When AVI-Link encounters unsupported features in your
ATS setup file, its behavior varies depending on the nature of the
feature. AVI-Link may:
• convert the unsupported feature to a similar, but supported
feature, or
• not convert the feature, issue a warning, and continue, or
• issue an error message and halt.
The standard process for getting your ATS setup and pattern ready
for pattern translation is represented by the following diagram:

Overview
Do your
Can you
AVI-Link
ATS Setup and
change or remove Contact your IMS
Pattern files contain only NO NO
the unsupported representative.
AVI-Link-supported
features?
features?
YES YES
Use AVI-Link to Edit out the

create a template for unsupported
the Fixture Map file. features.
AVI-Link
Do you
want AVI-Link to Edit Fixture Map
NO file to specify
assign channels
to pins? channels for each
device pin.
YES
AVI-Link
Use AVI-Link to create a
test plan and a Waveform
Map file.
Is the test
Make any needed
plan NO
changes to the test
correct?
plan.
AVI-Link
YES
Make your
APT run
Ready for pattern

A - AVI-Link
Once you have a correct test plan, Waveform Map file, and Run files
you may translate your pattern files. This is a multi-step process,
where the pattern data is first translated into an uncyclized format,
called IMSVF. The data is then translated back into a cyclized format,
called Vanguard ASCII format.
From Vanguard ASCII format, you may use either of these two
methods to bring your patterns into your test plan:
• Use the Vanguard utility called ims_pat_cvt to simultaneously
convert your ASCII format pattern files into Vanguard binary
format and insert them into your test plan.
• Use the File > Import feature of IMS Tools to import your
Vanguard ASCII pattern files directly into your test plan.
Using ims_pat_cvt is the recommended method when translating
more than one or two pattern files, as it is faster and more flexible
than importing ASCII patterns directly.
The standard process of translating your ATS pattern files into
Vanguard Pattern setups is represented by the following diagram:

Overview
Use APT to
translate your ATS
pattern file into the NO
uncyclized IMSVF
AVI-Link
Use APT to translate Is this
your IMSVF file to Done. YES your final pattern
VanguardASCII translation?
format
AVI-Link
Is this Optionally, use
your initial pattern ims_pat_cvt to
NO
translation? translate your
VanguardASCII file
YES
Open IMS Tools, load

the test plan and import
AVI-Link
the pattern. Evaluate
for correctness.
AVI-Link

A - AVI-Link
Starting AVI-Link
You start AVI-Link from the command prompt of a UNIX terminal.
Assuming that AVI-Link is in your path, the syntax of the AVI-Link
command line is:
avi_link -s file {-b} {-c filename} {-f filename} {-h}
{-o} {-t testplan} {-version} {-w filename}
where optional parameters are shown in curly braces. The command

line options are described below:
-b (Optional.) Make all Vanguard data pins

bidirectional.
-c filename (Optional.) Create a template for a Fixture Map
file, named filename. Must be used together with
the option -s filename and no others.
-f filename (Optional.) Use the Fixture Map file named
filename. Must be used together with the options
-s filename, -t testplan, -w filename.
-h (Optional.) Display help and exit. Overrides other
options when present.
-o (Optional.) Specifies that, if the outputs defined
by the options -c, -f, -t, or -w exist, AVI-Link
should overwrite them rather than warn you.
-s filename (Required.) Use the ATS setup file named
filename. Required with all options, except the -h
or -version options.
-t testplan (Optional.) Create a Vanguard test plan directory
named testplan. Must be used together with the
options -s filename, -t testplan, -w filename.
-version (Optional.) Display version information and exit.
Overrides other options when present.
-w filename (Optional.) Create a waveform order file named
filename. Must be used together with the options
-s filename, -t testplan, -w filename.

Supported and Unsupported ATS Features
Supported and Unsupported ATS Features

IMS Vanguard differs architecturally from ATS or XTS Series test
stations. This places some limitations on your setup files and pattern
files. Those limitations are:
AVI-Link
Supported Force Formats: DNRZ and NRZ in 1x, 2x and 4x
formats. RZ and R1 in 1x and 2x formats. You may freely mix these
supported formats. RZI formats are supported, but cannot have two
edges within the same subcycle.
Unsupported Force Formats: SBC, SBI, and RI formats. All
formats with two edges transitions in a single tester cycle are
assigned to Vanguard clock pins, rather than data pins.
Supported Compare Formats: Edge compare and 2x split
compare.
AVI-Link
Supported Compare Formats: window compare. When AVI-Link
encounters a window compare it warns you and converts the window
compare to an edge compare, placing the strobe at the leading edge
of the window.
Scan. AVI-Link does not support serial scan data.
Pattern Instructions. ATS pattern instructions are converted to
comments in the Vanguard pattern setup.
AVI-Link
Fast Clock Multipliers. AVI-Link supports FT Series fast clock
multipliers of 1, 2 and 4 only. Other multipliers are unsupported.
Formulas. ATS formulas are not supported by AVI-Link. AVI-Link
replaces a setting controlled by a formula by the value obtained from
the formula at the time the setup was last saved.
Pin Names. AVI-Link creates Vanguard pin names for you.
AVI-Link

A - AVI-Link
Other Planning Considerations

This section describes some of the issues you may need to consider
after you have identified and eliminated any unsupported features
from your setup, but before you start your translation.
• Removing separated pins from your setup
• Modifying invalid pairings of bidirectional pin groups
• Using an existing test plan
• Conserving tester resources
• Changing timing characteristics
Removing Separated Pins from Your Setup

AVI-Link cannot correctly parse an ATS setup that contains pins that
have been separated from their group. Remove any separated pins
from your setup before using AVI-Link. One possible solution is to
place each separated pin into a group that contains just that pin.
Modifying Invalid Pairings of Bidirectional Pin Groups

AVI-Link cannot translate setups where bidirectional pins are
members of similar, but not identical, Force and Compare groups.
ATS Force and Compare groups that have identical pin lists, MUXes,
and opposite direction comprise a valid pairing. Such pairs map to a
single Vanguard Bidirectional group named after the ATS force
group. When AVI-Link encounters an invalid bidirectional pairing, it
issues a message similar to this:
FATAL: ATS groups "compare_1x" and "dnrz_1x" have some
common pins but do not comprise a valid Bidir pair.
If the Force half of a valid ATS bidirectional pairing has a double-

edge format (requiring conversion to a Vanguard clock) it can’t map
to a Vanguard Bidirectional group. This situation generates a
message similar to the following:

Other Planning Considerations
FATAL: Unable to convert ATS Group "rz_1x" with format

"FmtRZ" to a Vanguard clock pin because it is part of a
Bidirectional group pair.
Using an Existing Test Plan
AVI-Link
You should always use AVI-Link to create a new test plan, which you
may modify by importing setups, editing, or cutting-and-pasting. You
may export the following setups from an existing test plan and import
them into a test plan created by AVI-Link:
• DC Levels
• DC Parameters
• AC Parameters
AVI-Link
• Defaults
• Device Tests
These setups should require a minimum of modification. If you plan
to utilize data from other setups, your existing test plan should
closely follow the conventions used in test plans created by AVI-Link.
For example, the pin names in your test plan should follow the
naming conventions used by AVI-Link.
AVI-Link
Conserving Tester Resources
Edge settings are the Vanguard resource that AVI-Link is most likely
to exhaust during a translation. ATS setups that do not utilize FT
timing features are not likely to cause this problem, but setups that
move edges by many small increments, such cycle-stretch-and-
shrink operations, may quickly exhaust this resource.
When AVI-Link runs out of available edge settings, it issues a
warning and applies edge setting 0 (zero). This edge setting will not
replicate the edge placement from the original setup. The warning
AVI-Link
you receive is similar to this:

WARNING: Out of available force edges for Vanguard group
"rz_group1" while translating timeset "t1". Edgesets
for this group will not be correct for waveforms mapped
from this timeset.

A - AVI-Link
AVI-Link also translates many ATS constructs by creating multiple

waveforms. Vanguard has a limit of 32 waveforms. You may calculate
the number of waveforms required to translate your setup by
multiplying the highest format or clock multiplier in use by the number
of timesets in your setup. For example, if your setup includes 6
timesets and each timeset includes a clock pin with a multiplier of 4,
a total of 24 waveforms are used.
AVI-Link translates all pins that require two data transitions (edges)
within a single tester cycle as Vanguard clock pins, whether or not
these pins were designated as clock pins in the ATS setup. One
Vanguard clock module may connect up to 8 clock pins. If the test
plan created by AVI-Link contains more than 8 clock pins, the
Vanguard test station must contain more than one clock module.
Changing Timing Characteristics

To change the timing characteristics of your device, you should do
this in IMS Screens prior to initiating your conversion, or in IMS Tools
after the pattern conversion is complete and all pattern setups have
been incorporated into your Vanguard test plan.

Mapping Your Device to the Vanguard Fixture

To create a valid Vanguard test plan, AVI-Link must map your device
pins to their corresponding Vanguard tester channels.
Use any of three ways to map your device pins to your Vanguard
AVI-Link
fixture:
• Use AVI-Link to create a template of the Fixture Map file and edit
the template to include Vanguard channels for each device pin.
This method is recommended.
• Use AVI-Link to create a template of the Fixture Map file and let
AVI-Link automatically assign Vanguard channels to each device
pin.
• Use AVI-Link to create a template of the Fixture Map file and use
AVI-Link
AVI-Link to create a test plan. Import a Fixture setup from an
existing test plan and make it current. This method requires all
pin names in the imported Fixture setup to match the names in
the Pins setup created by AVI-Link.
To create a Fixture Map file template, use this command line:
avi_link -s setupname -c fixmapname
where setupname specifies the name and path of your ATS setup
file, and fixmapname specifies the name and path for the output file
AVI-Link
that will contain a template for the Fixture Map.
ATS Setup Fixture Map

File AVI-Link
File template
AVI-Link

A - AVI-Link
The resulting template of the Fixture Map file contains seven

columns. The first two retain ATS signal identification information.
The remaining columns contain Vanguard signal identification
information. Of these, the Pin Name and Pin Type columns are filled
in and the other columns are blank:
// Fixture Map File for ATS Setup "set.2xbidir1x4x"

//
// Created by AVI-Link Thu Jun 14 15:33:42 2001
//
//
// ATS Vanguard
// -------------------- ---------------------------------------------
// Override
// Group Channel Pin Pin Channel Pin
// Name ID Name Type ID Name Tristate
// ------------------------------------------------------------------
dnrz_1x 2 pin_1x data - - -
.
.
.
Editing a Fixture Map File

If you choose to edit the Fixture Map file, follow these rules:
1. Individual lines cannot exceed 1023 characters in length.
2. White space characters at the start or the end of a line count
against the character total, but are otherwise ignored.
3. Lines whose first two non-white-space characters are "//" are
treated as full-line comments and the remainder of the line is
ignored.
4. Each non-comment line is parsed into a series of character
blocks. These character blocks conform to the following
conventions:
• Character blocks are separated by one or more white space
characters. For that reason, a character block may not contain
any white space characters.

• The first character block is the ATS pin group name. This is
supplied in the template file. Do not edit this block.
• The second character block is the ATS channel ID. This is
• The third character block is a valid Vanguard pin name. This is
AVI-Link
• The fourth character block is a valid Vanguard pin type: data or
clock. This is supplied in the template file. Do not edit this block.
• The fifth character block, if present, is the Vanguard channel
assigned to the pin. You may edit this field to supply a channel ID.
If you choose not to supply a channel, do not remove the hyphen.
• The sixth character block, if present, is the Vanguard pin name
you want assigned to the pin, overriding the Pin Name in
AVI-Link
character block 3. You may edit this field to supply a pin name. If
you choose not to supply a pin name, do not remove the hyphen.
• The seventh character block, if present, indicates whether the pin
may be tristated. You may edit this field to replace the hyphen
with a Y, if the pin may be tristated.
• Additional character blocks are ignored.
Example of an edited Fixture Map file:
AVI-Link
// Fixture Map File for ATS Setup "set.1x2x4xDNRZ"
//
// Created by AVI-Link Thu Jun 14 15:33:42 2001
//
//
// ATS Vanguard
// -------------------- ---------------------------------------------
// Override
// Group Channel Pin Pin Channel Pin
AVI-Link
// Name ID Name Type ID Name Tristate

// ------------------------------------------------------------------
dnrz_2x 2 pin_2x data 3A0 - Y
dnrz_4x 3 pin_4x data 3A1 - Y
dnrz_1x 7 pin_1x data 8A0 - -

A - AVI-Link
Translating an ATS Setup to a Vanguard Test

Plan
After creating the Fixture Map file, use AVI-Link to create a Vanguard
test plan, using the information contained in your ATS setup file. At
the same time, AVI-Link creates a Waveform Map file to be used by
APT during the translation of your pattern data to IMSVF format.
ATS Setup File Vanguard

Test Plan
AVI-Link
Fixture Map File Waveform
Map File
This task is accomplished using the following command:

avi_link -s setup -f fixmap -t testplan -w wavemap
where setup is the name of the ATS setup file, fixmap is the name of
the Fixture map file to use, testplan is the name of the test plan
directory to create and populate with setups, and wavemap is the
name of the Waveform Map file to create.
If your Fixture Map file does not assign a Vanguard channel to each
pin, AVI-Link automatically assigns a channel to each pin left
unassigned, and generates a message similar to this one:
WARNING [myfixture.map]: One or more pins have no
channel assigned in the fixture map file. Channels have
been auto-assigned for each.
When you open the test plan created by AVI-Link you will find that
the following setups contain data derived from your ATS setup and
your Fixture Map file:
• Device Pins
• Device Fixture
• AC Timing
The following setups in the test plan created by AVI-Link contain no
data or only default data:
• Pattern

Translating an ATS Setup to a Vanguard Test Plan
• DC Levels
• DC Parameters
• AC Parameters
• Defaults
AVI-Link
• Device Test
You may want to modify some aspects of this test plan before
continuing.
Setup to Test Plan Conversion Issues

You should always pay close attention to the messages issued by
AVI-Link during a translation. They contain important information. For
AVI-Link
example, when translating your ATS setup into a Vanguard test plan,
AVI-Link may issue a warning similar to the following:
WARNING: Cycle duration for waveform "t1_0" has been
rounded by the Vanguard server. Edge placements in this
waveform are suspect.
This may indicate that the Master Clock cycle time in the Vanguard
test plan that AVI-Link created does not match the system cycle time
specified in your ATS setup. You may need to load the test plan in
IMS Tools and reset the master clock cycle. The master clock cycle
AVI-Link
is discussed in the User’s Manual for the Vanguard.
AVI-Link

A - AVI-Link
Creating APT Run Files

To translate ATS pattern files to Vanguard Pattern setups you must
create the appropriate Run files for use with APT. You will need two
Run files: one to use when translating your ATS pattern to IMSVF
format, and the other to use when translating your IMSVF pattern file
to Vanguard ASCII format.
Run File #1 for ATS / XTS to IMSVF Translation

You must create a separate Run file for your translation from ATS
Memory or Binary format to IMSVF format. The Source and Target
sections must contain certain required directives.
NOTE — Do not use any additional directives not listed here.

i Required Source section directives. Use the following Source
section directives in the Run file for your translation to IMSVF:
Device List the appropriate Source device name: ATSmem,

ATSbin, ATSFTmem, ATSFTbin, XTSmem, XTSbin,
XTSFTmem, or XTSFTbin.
Setup List the name of the ATS setup file.
Data List the name of the ATS pattern file.
Required Target section directives. Use the following Target

section directives in the Run file for your translation to IMSVF:
Device Use IMSVF as the Target device.

Setup List the name of the ATS setup file.
Data List the name of the IMSVF format pattern file
you want APT to output.

WaveformMap List the name of a Waveform Map file created

by AVI-Link at the same time as it created a test
plan from your setup.
FixtureMap List the name of a Fixture Map file created by
AVI-Link at the same time as it created a test
AVI-Link
plan from your setup.
Example of Run file #1. The following example shows an extremely

simple Run file, with the syntax for all the required directives.
Segment "ATSXTS_2_IMSVF"
{
Source
{
Device"ATSmem";
AVI-Link
Setup"646.set";
Data "646.mem";
}
Target
{
Device"IMSVF";
Setup"646.set";
Data "646.imsvf";
WaveformMap "646.map";
FixtureMap "646.fix";
AVI-Link
}
}
Run File #2 for IMSVF to VanguardASCII Translation

You must create a separate Run file for your translation from IMSVF
to VanguardASCII. The Source and Target sections must contain
certain required directives, and may contain other optional directives.
Required Source section directives. Use the following Source
section directives in the Run file for your translation to
AVI-Link
VanguardASCII:
Device Use IMSVF as the Source device.

A - AVI-Link
Data List the name of the IMSVF file.

Groups Lists the names of all groups in the IMSVF file. This
directive may be supplied by using an Include
directive that references the Pins List (.pins) file
created by APT as it creates the IMSVF file. See the
example Run file #2, below.
Required Target section directives. Use the following Target

section directives in the Run file for your translation to
VanguardASCII:
Device Use VanguardASCII as the Target device.

Data List the name of the Vanguard ASCII pattern
file you want APT to output.
Setup List the name of the Vanguard test plan
directory created by AVI-Link.
WaveformOrder List the name of a Waveform Order file
created by APT at the same time as the
IMSVF file.
Optional directives. A complete list of the optional directives

appears in the appendix, Converting Data to Vanguard Format, in the
section, Optional and Unsupported APT Directives.

Example of Run file #2. The following example shows an extremely

simple Run file, with the syntax for all the required directives. It also
contains two optional directives: the Option Instructions directive and
the Repeat directive.
Segment "IMSVF_2_Vanguard"
AVI-Link
{
Source
{
Device "Generic";
Data "646.imsvf";
Include "646.pins";
Option "Instructions";
}
Target
{
AVI-Link
Setup "646.testplan";
Data "646.Vmem";
Repeat;
WaveformOrder "646.imsvf.wfo";
}
}
AVI-Link
AVI-Link

A - AVI-Link
Translating ATS Pattern Files to Vanguard

Pattern Setups
Ideally, the first pattern you translate should be a small file designed
to demonstrate that AVI-Link creates a correct and usable Vanguard
Pattern setup from your ATS pattern file. This pattern should then be
imported into IMS Tools and examined for conversion errors. Once
this Pattern setup is confirmed as correct, you may proceed to
convert all your ATS pattern files.
Translating an ATS pattern file to a Vanguard Pattern setup is a multi-
step process:
1. Use APT to translate the ATS pattern file to IMSVF format. This
step also creates two other files: a Pins List file and a Waveform
Order file. The Pins List can be Included as the Groups directive
in your APT Run file for the next step in the process. The
Waveform Order file is also needed in the next step.
ATS Setup File IMSVF

Run File #1 Format File
APT Pins List

ATS Pattern File
File
Waveform Map
Waveform
Fixture Map File Order File

Translating ATS Pattern Files to Vanguard Pattern Setups
2. Use APT to translate the IMSVF pattern file to Vanguard ASCII

format.
Test Plan
AVI-Link
Run File #2
IMSVF File APT Vanguard ASCII

Format File
Waveform
Order File
3. Optional.) Use ims_pat_cvt to translate the Vanguard ASCII
AVI-Link
pattern file to binary format and insert it into your test plan.
Usage of ims_pat_cvt is described in the appendix, Batch File
Imports. You may also invoke ims_pat_cvt with the -help option to
view a description of its command line options and their effect.
Vanguard Pattern
Vanguard ASCII ims_pat_cvt Setup in a
Format File
Test Plan
AVI-Link
AVI-Link

A - AVI-Link
Automating the Process

Included with AVI-Link is a set of example files, including several
scripts you may use or modify to help you automate the process of
conversion. Normally, these examples are installed in the directory:
/opt/ims/avi_link/latest/examples
The script run_avi may be used to run all the steps necessary to
translate your ATS/XTS setup into a Vanguard test plan, using one
command line. The command line for this script is:
run_avi ATSsetup VBasename
where:
ATSsetup ATS or XTS setup file.

VBasename Base name of Vanguard files created by run_avi.
The script run_APT_compile may be used to run all the steps

necessary to translate one ATS/XTS pattern file into a Vanguard
Pattern setup and incorporate that setup into your test plan in binary
format. The command line for this script is:
run_APT_compile ATSdev ATSsetup ATSpattern VBasename VPatname
where:
ATSdev The appropriate Source device name: ATSmem,

ATSbin, ATSFTmem, ATSFTbin, XTSmem,
XTSbin, XTSFTmem, or XTSFTbin.
ATSsetup ATS setup file.
ATSpattern ATS pattern file to translate.
VBasename Base name of the Vanguard files used and
created (identical to VBasename as used with
run_avi).
VPatname Name of Pattern setup to create.

B
VIEWING DATA AS WAVEFORMS
This chapter discusses how to convert your simulation data file into a
format that can be loaded into the Waves window of IMS Tools. It
covers the following topics:
• Overview of SURF
• Planning Your Conversion
Viewing Data as
Viewing Data as
• Writing a SURF Run File
Waveforms
Waveforms
• Running SURF
• SURF Directives
Viewing Data as
Waveforms
Viewing Data as
Waveforms

B - Viewing Data as Waveforms
Overview of SURF
The SimUlation ReFormatter (SURF) utility is a command line
application that converts a specific portion of your simulation data file
into a format that can be loaded into the Waves window of IMS Tools
for viewing as graphical waveforms. The files created by SURF are in
the same format that the Waves window uses when you save data
from it to a file.
SURF is installed when you install IMS Tools. SURF can convert
simulation data from almost any simulation format.
Before you can convert your data, you are required to create a Run
file containing SURF commands. The Run file describes the format
of your simulation data and selects among several options for
converting it. You may create a Run file using your preferred text
editor, such as VI or EMACS.
This chapter describes the steps required for making a Run file and
how to start SURF from the command line.
Running SURF requires two input files and creates one output file:
SURF Run file

Waves
SURF
utility Format file
Source Data
file
To use SURF:
1. Identify the format and other characteristics of your simulation
data file.
2. Identify the names and locations of the signals you want to
convert in the simulation file.
3. Identify the block of vectors you want to convert in the simulation
file.
4. Write a Run file.

Overview of SURF
5. Run SURF to create an output file in Waves format.

6. Load the output file in the Waves window of IMS Tools and view
it.
Viewing Data as
Viewing Data as
Waveforms
Waveforms
Viewing Data as
Waveforms
Viewing Data as
Waveforms

Planning Your Conversion

Before you can use SURF to convert your data, you need to identify:
• the data format used in your simulation source file
• the names and other characteristics of the signals in your data
• the vectors you want to convert
Identifying the Data Format

SURF recognizes two formats: Verilog Change Dump (VCD) format
and tabular format simulation files, commonly referred to in this
document as Generic files. In the Run file, you will identify the source
format using the directive SourceFormat.
VCD Source Data

VCD formatted files generally have a .vcd or .dump file extension.
They contain a distinctive header section, whose contents consist of
nested definitions preceded by keywords.
Here is an sample fragment of a VCD file header:

.
.
.
$upscope $end
Generic Source Data

Tabular formatted simulation files (Generic files) largely consist of
rows and columns of data, where each row represents an event such
as a change of data state or the start of a cycle, and each column
represents the successive data states of your device pins.
Here is a sample fragment of a tabular file with timestamps:
.25 0 3FFFFFFF 0 1 0 FFFFFFFF 1 0 0 1111 011 00 001 000

.75 0 3FFFFFFF 0 1 0 FFFFFFFF 1 0 0 1111 011 00 001 000

1.75 0 3FFFFFFF 0 1 1 6600041E 1 1 1 0000 100 00 001 110
2.25 0 00000413 0 0 1 6600041E 1 1 1 0000 100 00 001 110
2.75 0 00000413 0 0 1 6600041E 1 1 1 0000 100 00 001 110
3.25 0 00000413 0 1 1 6600041E 1 1 1 0000 100 00 001 110
3.75 0 00000413 0 1 1 00080E8B 1 0 1 0000 100 00 001 110
Identifying Signals
You must identify the signals in your source data file.
VCD Source Data
Viewing Data as
Viewing Data as
If your simulation data file is in VCD format, your Run file only needs
Waveforms
Waveforms
to name those signals you are interesting in converting.
Viewing Data as
When your source device is VCD, the names in your Signals list must
Waveforms
follow this convention:
For example, the first two signals in this VCD file fragment are
contained in a single module named Test_74LS646:

Viewing Data as
[... this list continues...]
Waveforms
So those two signals would be identified in your Run file as:
Signals
Test_74LS646.G_
Test_74LS646.DIR
[...this list continues...]

Generic Source Data

When your source is in a tabular format, your Run file must list every
signal in your source data, in the order they appear.
Normally, in a Generic tabular file, each column of data represents
one pin. However, there is no universal method among simulators for
correlating each column of data with its corresponding signal name.
You should know how your own simulator handles this.
In some cases, the simulation signal name for each column may be
present in a comment header in the simulation data file. Examining
the file may reveal a header such as this:
/* These lines are commented out:

/* b
/* u b
/* . u r e
/* b . e b m l br
/* p r a a b a s bbbb Xdw o urp
/* h e a d d n d d d 1 eeee iXX hh ic soe
/* a s b f s a b f y 6 3210 ocr ol nnk yrr
/* s e u l N N u l N N NNNN NNN ld mtN NNe
/* e t s e N N s b N N NNNN NNN da irN NNq
/* - - -------- - - - -------- - - - ---- --- -- ---
--
This header indicates some signal names written vertically above
each column of data, such as phase and reset.
For each signal in your source data, you will need to identify:
• the name you want it to have in the Waveform Display,
• the column where its data resides,
• whether it is an input, output or bidirectional signal, and
• whether you want to translate it to Waves format.
All this information is required to create your Signal list. In order to
find each signal in your data, SURF requires a complete description
of the table containing your signals. For that reason, you must
include every signal in your list, whether or not you want to translate
it.

Bidirectional Signals in VCD and Generic

If the direction of a bidirectional signal in any given vector is correctly
reflected in the source data, using the state characters SURF
recognizes by default (1, 0 and X for input, H, L and Z for output),
then SURF should translate the signal data.
If the state characters in the source data do not contain implicit
information on signal direction, you will need to identify the following
information:
• the name of the control signal
• the name of the enable signal
• whether these signals are active when high or low (polarity)
Viewing Data as
Viewing Data as
Waveforms
Waveforms
Further information about bidirectional signals is included in the
section SURF Directives, under the description of the Bidir directive.
Identifying the Vectors to Convert

It is assumed that you are commonly interested in a subset of the
vectors in your simulation data. Limiting the number of vectors
speeds both the conversion process and the process of loading and
viewing the file in the Waves window of IMS Tools. For that reason,
Viewing Data as
you must identify a block of vectors in your source data that you want
Waveforms
to convert.
You identify the block of vectors to convert by determining the
starting time of the first vector in the block, and the number of cycles
to convert. SURF seeks out the start time you supply, either by
examining the existing timestamps in the data, or by calculating the
location based on the step time you supply in the Step directive.
To specify a starting time, use the StartTime directive. To specify
the number of cycles to convert, use the Depth directive.
Viewing Data as
Waveforms

Writing a SURF Run File

You may write your Run file using any text editor capable of saving
text in ASCII format. A Run file consists of a set of SURF directives.
In order to be well-formed, your Run file must conform to this set of
conventions:
• Certain directives are required.
• Internal components of each directive must be separated by
white space.
• Each directive must end with a semi-colon.
A Run file that violates these conventions may cause your
conversion to fail.
Required Directives
Each SURF Run file requires the following directives:
• SourceFile
• SourceFormat
• TargetFile
• TesterType
• CycleLength
• Signals
The first five lines of a typical SURF Run file will resemble this
example:
SourceFile in.VCD; //names source data file

SourceFormat VCD; //names format of source data
TargetFile vcdout.ims; //name of SURF output file
TesterType Vanguard; //identifies tester type
CycleLength 10ns; //length of tester cycle
In addition to these five directives, your Run file requires a list of the
signals in your source data. The format of the Signals list depends on
the format named in the SourceFormat directive.

When the source format is VCD, the Signals list contains only those
signals you are interested in converting to Waves format. The signal
names in the list follow the format:
Here is an example of a Signals list for a VCD source file:
Signals
Test_74LS646.pinA
Test_74LS646.pinB
Test_74LS646.pinC
Test_74LS646.pinD
Test_74LS646.cntrl
Test_74LS646.enabl
Viewing Data as
Viewing Data as
;
Waveforms
Waveforms
When the source format is Generic (tabular format), not only must
every signal in your source data must be included in the Signals list,
but the order of their appearance must reflect the left-to-right order in
which they appear in your source file.
For each signal in the list the following information is recorded:
• signal name
• signal width (number of adjacent columns the signal occupies in
Viewing Data as
the source data)
Waveforms
• signal direction (input or output)
• visibility (whether to include the signal in the output file)
Here is an example of a Signals list for a Generic source file:
Signals
pinA 1 I Y
pinB 1 I Y Viewing Data as
pinC 1 I Y Waveforms
pinD 1 I Y
enabl 1 I Y
cntrl 1 I Y
;

If a named signal has a width greater than one (meaning it has more
than one pin), it will be divided into individual pins by appending a
numeric subscript to the signal name. For example, if a signal named
busA has three pins, the pins would be referenced in the output file
as busA[1], busA[2] and busA[3], with the first subscript assigned to
the leftmost pin in the source data.
Complete details on the syntax and usage of each of the directives
described in this section are included in the section SURF Directives.
Data Dependent Directives

In addition to the six required elements, your Run file may need to
include one or more other directives, depending on the
characteristics of your source data:
Table 17. Data dependent directives.
Directive When required:
Bidir When your source is either VCD or Generic

and it contains bidirectional pins.
Comment When your source data is either VCD or
Generic and it contains comments.
LineContinue When your source format is Generic and it
contains logical lines of data that span more
than one physical line.
NoTimestamp When your source format is Generic and your
Step When your source format is Generic and your
TimeUnits When your source format is Generic, and your
source data has timestamps that do not
indicate a time unit.
Complete details on the syntax and usage of each of the directives

described in this section are included in the section SURF Directives.

Optional Directives
Another set of directives are optional, although their use may be
recommended:
• Depth (VCD or Generic)
• StartTime (VCD or Generic)
• Substitute (Generic only)
IMPORTANT — Even though your translation runs to completion

when Depth and StartTime are omitted from your Run file, you
are unlikely to achieve the desired results without including
them.
Viewing Data as
Viewing Data as
Complete details on the syntax and usage of each of these directives
Waveforms
Waveforms
is included in the section SURF Directives.
Run File Comments

You may place comments in your SURF Run file. The start of
comment delimiter is a pair of forward slashes (//). There is no end of
comment delimiter. Whenever this delimiter is detected, the
remainder of the physical line in your Run file is ignored.
Viewing Data as
// This entire line is ignored.
Waveforms
SourceFile in.generic; // This comment is ignored.
A comment may appear embedded within a SURF directive, if the

portion of the directive that follows the comment is located on a new
physical line.
Signal
// this comment line is ignored; the next line is recognized Viewing Data as
moduleName.pinName; Waveforms

Running SURF
SURF is a command line utility. Assuming SURF is in your path, to
run it, you enter the following command line at the prompt of a UNIX
terminal:
surf -r runfile
where runfile is the name of your Run file. If your Run file is not in
the current directory, you must precede the file name with the path to
the directory where the file resides. For example:
surf -r /project/simulation/8697.run
To view the command line usage for SURF, enter:
surf -help
To view the version of SURF you are running, enter:
surf -version

SURF Directives
SURF Directives
The next section describes the valid syntax and usage of each SURF
Run file directive. Directives are listed in alphabetical order.
• Bidir
• Comment
• CycleLength
• Depth
• LineContinue
• NoTimestamp
Viewing Data as
Viewing Data as
• Signals
Waveforms
Waveforms
• SourceFile
• SourceFormat
• StartTime
• Step
• Substitute
• TargetFile
Viewing Data as
Waveforms
• TesterType
• TimeUnits
Viewing Data as
Waveforms

Bidir
Use the Bidir directive to identify source signals in the Signals list
that are bidirectional. It also specifies what other signals are utilized
as the control and enable signals, and whether these are considered
active when high or low (positive or negative polarity).
One Bidir directive should appear in your SURF Run file for each
bidirectional signal in your Signals list. Each signal named in a Bidir
directive must also appear in the Signals list. A bidirectional signal
may have any signal width (consist of more than one pin).
Syntax
The syntax of the Bidir directive is:
Bidir bi_sig Control ctrl_sig:polarity Enable

enab_sig:polarity;
where:
bi_sig specifies the name of one bidirectional signal, as it appears in
the Signals list.
ctrl_sig specifies the name of the control signal, as it appears in the
Signals list.
enab_sig specifies the name of the enable signal, as it appears in
the Signals list.
polarity specifies whether the control and enable signals for bi_sig
are active when high (positive) or low (negative). Valid selections are:
• Positive
• Negative
All syntax elements are case sensitive.
Example
Assuming a bidirectional signal named pinA, having a control signal
named ctl, and an enable signal named enabl with a negative
polarity, the following line should appear in your Run file:

SURF Directives
Bidir pinA Control ctl Enable enabl:Negative;
See Also
Signals
Viewing Data as
Viewing Data as
Waveforms
Waveforms
Viewing Data as
Waveforms
Viewing Data as
Waveforms

Comment
The Comment directive identifies the comment delimiter, if any, that
appears in the source data file. If the Comment directive appears in
the Run file, SURF ignores any text or source data that appears to
the right of the delimiter on the same physical line of text. If the
Comment directive does not appear in your Run file, the entire
contents of the source data file are considered as data.
A Comment directive is required only if comments appear in the
source data file. Only one Comment directive may appear in the Run
file.
This directive is ignored when the SourceFormat is VCD.
Syntax
The syntax of the Comment directive is:
Comment string;
where:
string specifies one or more characters. If string is more than one
character, all the characters together comprise a single comment
delimiter.
Example
If the comment delimiter in your source data file is a colon, place this
line in your Run file:
Comment :;
See Also
LineContinue

SURF Directives
CycleLength
The CycleLength directive specifies the length of the tester cycle to
be specified in your target (output) file. A CycleLength directive is
required to appear in your Run file.
When you load the Waves format file created by SURF from your
source data, the cycle boundaries drawn in the Waveform Display
window will reflect the value you specify in the CycleLength directive.
The value you specify should correspond to the cycle time that best
fits your source data. If you do not know the cycle time in your source
data, initially use an appropriate value, such as 10ns, and readjust
as necessary.
Viewing Data as
Viewing Data as
Syntax
Waveforms
Waveforms
The syntax of the CycleLength directive is:
CycleLength value;
where:
value specifies the length of the tester cycle. It must be a floating
point or whole integer number, optionally followed by a time unit
indicator. If no time unit is indicated, value is interpreted as
Viewing Data as
nanoseconds (ns) by default. Valid time unit indicators are:
Waveforms
seconds s (or: sec)

milliseconds ms
microseconds us Viewing Data as
nanoseconds ns Waveforms
picoseconds ps
femtoseconds fs

Example
If your source data cycle is 10 nanoseconds this line should appear
in your Run file:
CycleLength 10ns;
See Also
TesterType

SURF Directives
Depth
Use the Depth directive to specify the number of cycles of data you
want to convert, as measured from the perspective of the target
device. It is optional. If no Depth directive appears in your Run
file,1024 cycles are converted by default.
Syntax
The syntax of the Depth directive is:
Depth value;
Viewing Data as
Viewing Data as
where:
Waveforms
Waveforms
value is an integer value between 1 and 2048, inclusive.
Example
To convert 24 cycles of target data, place this line in your Run file:
Depth 24;
Viewing Data as
Waveforms
See Also
StartTime
Viewing Data as
Waveforms

LineContinue
The LineContinue directive identifies the line continuation character,
if any, that is used in your source data file. When one logical line of
data spans more than one physical line in your file, each line except
the final line uses a line continuation character to indicate that the
following line is part of the current line of data.
If your source data contains line continuations, place a LineContinue
directive in your Run file. Logical and physical line length is limited to
8192 characters, including whitespace characters. SURF cannot
process lines longer than 8192 characters.
The line continuation character must be a backslash (\). If your
source data uses a different character, replace that character with
the backslash. If your source data uses a backslash for a purpose
other than line continuation, replace the backslash characters with
another character. Use the UNIX sed utility; not the Substitute
directive, to replace a non-standard line continuation character.
Syntax
The syntax of the LineContinue directive is:
LineContinue;
The directive takes no arguments. All syntax elements are case
sensitive.
Example
If your source data file uses line continuation, place this line into your
Run file:
LineContinue;

SURF Directives
NoTimestamp
The NoTimestamp directive is required when your Generic tabular
source data has no timestamps. If the NoTimestamp directive
appears in your Run file, the Step directive must also appear.
Syntax
The syntax of the NoTimestamp directive is:
NoTimestamp;
The directive takes no arguments. All syntax elements are case
Viewing Data as
Viewing Data as
sensitive.
Waveforms
Waveforms
Example
If your source data contains no timestamps the following line should
appear in your Run file:
NoTimestamp;
See Also
Viewing Data as
Waveforms
Step
Viewing Data as
Waveforms

Signals
Use the Signals directive to list the signals in your source data file.
One Signals directive is required to appear in your Run file, and only
one is permitted. The syntax of this directive varies, depending on
whether the format of your source data is VCD or Generic.
VCD Syntax
When your source data is VCD format, you are only required to list
the signals you want to convert, or those that pertain to them. For
example, the Signals list must also contain the names of the control
and enable signals for each bidirectional signal in the list. Signals
names from a VCD file may appear in the Signals list in any order.
The syntax of the Signals directive for VCD source data is:
Signals
name1
name2
.
.
.
nameN
;
where:
name1, name2 ...nameN represent a list of signal names, separated
by whitespace characters and terminated by a semi-colon. Names
must be in the format:
Generic Syntax
When your source data is in Generic tabular format, you are required
to list every signal in your source data, not just the signals you want
to convert.

SURF Directives
The order of the signals must exactly reflect the order in which they
appear in the source data. The first signal name in the list should be
the leftmost signal in the source data table. The next name in the list
should be the signal immediately to the right of the previous signal in
the source data. This continues until all signals are named in left-
right order.
The syntax of the Signals directive for Generic source data is:
Signals
name1 width direction visibility
name2 width direction visibility
.
.
.
Viewing Data as
Viewing Data as
nameN width direction visibility
Waveforms
Waveforms
;
where:
name1, name2 ...nameN represent signal names.
width specifies the width of the signal. This corresponds to the
number of adjacent columns of data the signal occupies in the
source data file.
direction specifies the direction of the signal. Valid selections are: I,
Viewing Data as
O, or IO. The I character denotes an input signal. The O character
Waveforms
denotes an output signal. IO denotes a bidirectional signal. Each
bidirectional signal must also appear in a Bidir directive.
visibility specifies whether to convert the signal into the target data
file output by SURF. Valid selections are: Y, N.
VCD Example Viewing Data as
Assuming you want to convert the vectors for three signals from your
Waveforms
VCD source file named pinA, pinB and pinC, and these signals are in
a module named BusY, the following Signals list should appear in
your Run file:
Signals

BusY.pinA
BusY.pinB
BusY.pinC
;
Generic Example
Assume your source file is in Generic tabular format and has eight
signals named pinA to pinH. Of these eight signals you only want to
convert three output signals, named pinD, pinE and pinF. Your
Signals list should resemble this:
Signals
pinA 1 I N
pinB 1 I N
pinC 1 I N
pinD 1 O Y
pinE 1 O Y
pinF 1 O Y
pinG 1 I N
pinH 1 O N
;
See Also
Bidir, SourceFormat

SURF Directives
SourceFile
The SourceFile directive specifies the name and location of the
source data file SURF is to convert. This directive is required.
Syntax
The syntax of the SourceFile directive is:
SourceFile filename;
where:
filename is the name of the source data file to convert. If the file is in
Viewing Data as
Viewing Data as
a location other than the current directory, the absolute or relative
Waveforms
Waveforms
path should precede the file name.
Example
Assuming the source data file you want to convert is named
8987.sim and is located in the /project/simdata directory, the
following line should appear in your Run file:
Viewing Data as
Waveforms
SourceFile /project/simdata/8987.sim;
See Also
SourceFormat
Viewing Data as
Waveforms

SourceFormat
The SourceFormat directive specifies the simulation format of your
source data file. It is required.
Syntax
The syntax of the directive is:
SourceFormat format;
where:
format specifies one of two valid format identifiers:
Table 19. Valid formats in SourceFormat directive.
If your format is: Use this format identifier:
Verilog Change Dump VCD

Tabular format Generic
Example
Assuming your source data file is in Verilog Change Dump format,
the following line should appear in your Run file:
SourceFormat VCD;
See Also
SourceFile

SURF Directives
StartTime
The StartTime directive specifies the time associated with the first
vector of source data you want to convert, as an offset from 0ns. If a
StartTime directive does not appear in your Run file, a default
starting time of 0ns is assumed.
Syntax
The syntax of the StartTime directive is:
StartTime value;
Viewing Data as
Viewing Data as
where:
Waveforms
Waveforms
value specifies the time associated with the first vector of source
data you want to convert. It must be a floating point or whole
integer value, optionally followed by a time unit indicator. If no
time unit is indicated, value is interpreted as nanoseconds (ns)
by default. Valid time unit indicators are:
Viewing Data as
Waveforms
seconds s (or: sec)
milliseconds ms
microseconds us
nanoseconds ns
picoseconds ps
femtoseconds fs
Viewing Data as
Waveforms

Example
Assuming your source data is timestamped data in a tabular format,
and the first vector you want to convert is at timestamp 600.50ns,
then the following line should appear in your Run file:
StartTime 600.50ns;
See Also
Depth

SURF Directives
Step
The Step directive specifies the implicit time value between each
vector of your source data. It is required when your source data is in
Generic tabular format and has no timestamps. However, if your
source data has timestamps and a Step directive appears in your
Run file, the step value will override the timestamp data in
determining the time value for each vector.
If your Run file includes a NoTimestamp directive, it must also
include a Step directive.
Viewing Data as
Viewing Data as
Waveforms
Waveforms
Syntax
The syntax of the Step directive is:
Step value;
where:
value specifies the time between vectors in the source data you want
to convert. It must be a floating point or whole integer value,
Viewing Data as
optionally followed by a time unit indicator. If no time unit is indicated,
Waveforms
value is interpreted as nanoseconds (ns) by default. Valid time unit
indicators are:
seconds s (or: sec)

milliseconds ms Viewing Data as
microseconds us
Waveforms
nanoseconds ns
picoseconds ps
femtoseconds fs

Example
Assuming the vectors in your source data are 10ns apart, the
Step 10ns;
See Also
NoTimestamp

SURF Directives
Substitute
The Substitute directive replaces all instances of a specific
alphanumeric character in your source data with a different character
you specify. It is optional.
The Substitute directive is only applied to the block of vectors you
want to convert and not to the entire source file. It is especially useful
to convert state characters in your source data into state characters
recognized by SURF:
Table 22: State characters recognized by SURF
Viewing Data as
Viewing Data as
Character Source Types Pin Type Pin State
Waveforms
Waveforms
1 Generic and VCD input high
0 Generic and VCD input low
X, x Generic and VCD input indeterminate
H Generic output high
L Generic output low
Viewing Data as
Z, z Generic and VCD output tristated
Waveforms
T Generic output tristated
The Substitute directive is not suitable for changing a non-standard

line continuation character to a backslash character, because line
continuation is resolved before the block of vectors to convert is
extracted and Substitute is applied.
Viewing Data as
Waveforms
Syntax
The syntax of the Substitute directive is:
Substitute oldchar newchar;

where:

oldchar specifies a single alphanumeric character you want

replaced with a different alphanumeric character.
newchar specifies a single alphanumeric character to replace
oldchar.
Example
Assuming you want each tilde character (~) in your source data
replaced with a caret character (^), the following line should appear
in your Run file:
Substitute ~ ^;
See Also
Comment, LineContinue

SURF Directives
TargetFile
The TargetFile directive specifies the name and location of the
conversion file created by SURF. It is required. If a file of that name
already exists in the indicated location, it is overwritten.
Syntax
The syntax of the TargetFile directive is:
TargetFile filename;
where:
Viewing Data as
Viewing Data as
filename is the name of the output data file to create. If the file
Waveforms
Waveforms
should be created in a location other than the current directory,
an absolute or relative path should be prepended to the file
name.
Example
Assuming you want SURF to create an output file named
Viewing Data as
initvectors.waves in the current directory, the following line
Waveforms
should appear in your Run file:
TargetFile initvectors.waves;
See Also
SourceFile
Viewing Data as
Waveforms

TesterType
The TesterType directive specifies the IMS tester architecture for
which your want to convert your source data. This directive is
required.
SURF is capable of converting source data to reflect either Vanguard
or ATS architecture. The Vanguard architecture is used with the
Vanguard Series of IMS testers. The ATS architecture is used with
the ATS Series, XTS Series and Electra Series of IMS testers.
Syntax
The syntax of the TesterType directive is:
TesterType type;
where:
type indicates the type of IMS tester you are using to test your
device. There are two valid indicators:
• Vanguard
• ATS
Example
Assuming you are testing your device on a Vanguard tester, the

SURF Directives
TimeUnits
The TimeUnits directive specifies the time units used in your
timestamps. This directive is required when your SourceFormat is
Generic and the timestamps in your source data do not indicate time
units, as in this example:

1.75 0 3FFFFFFF 0 1 1 6600041E 1 1 1 0000 100 00 001 110
In contrast, source data that includes time units might resemble this
example:
Viewing Data as
Viewing Data as
Waveforms
Waveforms
0.25ns 0 3FFFFFFF 0 1 0 FFFFFFFF 1 0 0 1111 011 00 001 000
1.75ns 0 3FFFFFFF 0 1 1 6600041E 1 1 1 0000 100 00 001 110
Syntax
Viewing Data as
Waveforms
The syntax of the TimeUnits directive is:
TimeUnits unit;
where:
unit indicates the the time unit used by your source data. Valid
time unit indicators are:
Table 23. Valid time unit indicators. Viewing Data as

Waveforms
seconds s (or: sec)

milliseconds ms
microseconds us

nanoseconds ns
picoseconds ps
femtoseconds fs
Example
Assuming the timestamps in your source data indicate picoseconds,
the following line should appear in your Run file:
TimeUnits ps;

C
BATCH PATTERN IMPORTS
Use ims_pat_cvt to:

• Convert one or more Vanguard ASCII pattern files to binary
format.
• Convert one or more binary pattern files to Vanguard ASCII.
Batch Pattern Impor ts Batch Pattern Impor ts Batch Pattern Impor ts

• Add the converted pattern setup into a test plan, either into the
test plan directory or into a reference pattern directory.
• Write the output files to any directory without connection to a test
plan.
• Concatenate several pattern files and convert them as a unit.
• Incorporate conversion into UNIX shell script and run it as a cron
job.
Batch Pattern Impor ts

The IMS Vanguard ASCII format is described in “File Formats” in the
online help.

C - Batch Pattern Imports
Command Line Syntax

To start the pattern converter, at the UNIX prompt enter
% ims_pat_cvt {options} [< pattern_file ]
where:
{options} represents any of the options listed below. All are
optional.
< is the UNIX redirection symbol. (When converting binary to
ASCII, with the -decompile option, omit redirection.)
pattern_file is the pattern file or pattern setup to be converted to
binary. (When converting binary to ASCII with the
-decompile option, omit this argument.)
Options:
-compressLevel Use pattern compression (0-3).

level 0 = no compression
1 = Huffman compression
2 = Run-Length compression
3 = Both Huffman and Run-Length
compression
Analogous to the -compressLevel switch
used with ims_server.
Not valid with -decompile.
Default: compressLevel 3.
-config configFile Use this system configuration file. This is
analogous to the -config switch used with
ims_server.
Default: use the default configuration file.
To learn what configuration file is being
used, use the -verbose option.

Command Line Syntax
-decompile Convert one or more binary pattern setups,

setupName setupName, into ASCII format. When using
[setupName...] this option, do not redirect a pattern_file into
ims_pat_cvt.
Use with these options:

-testPlan, -patternDir.
Not valid with these options:

-compressLevel, -noTestPlan, -pattern,
-reference, -source, -start, -
updateTestPlan.

-help List the syntax and options, then exit.
-noTestPlan Convert the file without using a test plan.
filename Normally, filename would be the name of
the ASCII pattern file you are converting.
The Partition block from filename is used to
determine the pin, waveform and partition
information for the conversion.
-patternFile is required with this option.
Do not use with these options: -pattern,

-project, -reference, -testPlan, -timing,
-updateTestPlan.
-pattern Give the output this setup name. Setup
setupname names are listed in IMS Tools windows. If -
patternFile is omitted, then setupname
becomes the base name for the output files,
on the model Pattern_setupname.bin
and Pattern_setupname.ims.
Not valid with -noTestPlan.
Default: If you omit both -pattern and
-patternFile the output is
Pattern_untitled.* in the test plan.

-patternDir Put the converted pattern file into this

pathname directory.
Default: the working directory. If you
specify -updateTestPlan and omit
-reference, pathname must be the test plan
directory.
-patternFile Give the output files this base name.
basename Output file names are formed on the model:
basename.bin and basename.
Required if you specify -noTestPlan.
Required together with -pattern to specify a
reference pattern and enter it into a test
plan.
-project projectFile Use project configuration file projectFile to
specify the search path for reference
patterns. This is analogous to the -project
switch used with ims_server.
To learn what project file is being used, use
the -verbose option.
Not valid if you specify -noTestPlan.
-reference Create the binary pattern as a reference
pattern.
Default: create a non-reference (local)
pattern.
-source filename Convert filename and add it to the
beginning of the pattern read from standard
input. You can use -source with more than
one file: -source file1 file2 file3 . . .
Do not use with -decompile.
To ensure that the pattern files are correct,
make sure that the number of vectors in
each file is an even multiple of 8 (for 1x
patterns) or 16 (for 2x patterns).

Command Line Syntax
-start Begin loading the pattern or patterns being

sequenceNumber compiled at sequenceNumber, which must
be an even multiple of 8 (for 1x patterns) or
16 (for 2x patterns). This sequence number
is applied both to patterns named in the
-source option and to the pattern read from
standard input.
The vectors prior to the start sequence
number are padded out with Xs.
Do not use with -decompile.
Default: begin loading from Sequence 0.
-testPlan Use this test plan. Here pathname may be

pathname absolute, or relative to the working
directory.
Default: the test plan in the working
directory.
-timing timing Use this timing setup. Here timing is the
setup name as it appears in the IMS Tools
windows.

Default: the current timing setup from the
test plan.
-updateTestPlan Add the converted setup to the test plan’s
list of patterns.
Default: do not update the test plan.
If the setupname specified by -pattern
already exists in the test plan, this switch is
ignored.
-verbose Display the names of configuration and
other files being used and some summary
information.
-version Print the software version and exit.

Pattern File Naming Conventions

For each ASCII input file, ims_pat_cvt creates two output pattern
files:
• a binary file contains the pattern and
• an ASCII file provides pin, partition, and waveform information.
If you specify -patternFile basename, the output files are

basename.bin and
basename
in the output directory.
If you specify -pattern basename, the output files are
Pattern_basename.bin and
Pattern_basename.ims
If you specify neither -patternFile nor -pattern, and do not use
-noTestPlan, the output files are
Pattern_Untitled.bin and
Pattern_Untitled.ims

Examples
Examples
Here are some examples of typical uses.
NOTE — For readability, the examples list each option on a

i separate line. To enter a command, place all elements on the
same line or use the line continuation character (\).
Example 1: Default Operation

With no command line options,
ims_pat_cvt < pattern.ascii

converts pattern.ascii into a binary pattern setup in the local test
plan.
Notes. With no command options, ims_pat_cvt:
• Writes to the current working directory.
IMPORTANT — Start ims_pat_cvt from a directory where you have

i write permission. It writes temporary files there.
• Writes two output files

current_working_directory/Pattern_Untitled.bin and
current_working_directory/Pattern_Untitled.ims.
• As required by the test plan, verifies that:
• the pins referenced in pattern.ascii are defined in the
device setup,
• the partitions and waveforms referenced in pattern.ascii
are defined in the current timing setup, and
• the tester resources used by pattern.ascii are defined in
the default system configuration file.
but does not add the pattern setup to the test plan.
Example 2: Adding a Local Pattern to a Test Plan

This example:

ims_pat_cvt -testPlan plan9 \

-patternDir plan9 \
-pattern pat2 \
-updateTestPlan \
< pat2.ascii
uses timing and device information from test plan plan9 to convert
ASCII source pattern file pat2.ascii to a pattern setup with setup
name pat2 and adds it to the testplan.
Notes:
• -testPlan specifies the test plan directory as plan9. This makes
it possible to start ims_pat_cvt from a directory other than the
test plan directory.
IMPORTANT — Start ims_pat_cvt from a directory where you have

i write permission. It writes temporary files there.
• -patternDir and -testPlan each specifies writing the output setup
to the same test plan directory: plan9.
This is required unless you specify -reference.
• -pattern specifies the base name Pat2 for the output pattern
setup files,
Pattern_Pat2.bin and
Pattern_Pat2.ims.
which avoids overwriting the untitled pattern setup. The setup
name is the name that appears in lists of setups in IMS Tools.
• -updateTestPlan ensures that the pattern setup will be entered
into the test plan.
Example 3: Converting to Independent Pattern Files

This example:
ims_pat_cvt -noTestPlan pat2.ascii \
-patternDir ../job004/patterns \
-patternFile pat2 \
< pat2.ascii
uses timing and device information from the source pattern file
pat2.ascii itself to convert it to two pattern files outside a test plan.

Examples
Notes:
• -noTestPlan specifies that pins, waveforms, and partitions will be
derived from the Partition block in pat2.ascii, and will not be
verified against any test plan or setups. Always use the source
pattern file as the argument to -noTestPlan.
• -patternDir specifies the output directory ../job004/patterns.
• -patternFile specifies the base file name pat2 for the two output
files
pat2.bin and
pat2.

(-patternFile specifies a file name, not a test plan setup name.)
When you convert to a test plan setup with -pattern, the base
name of the output files is the setup name in the test plan
When you convert to an independent pattern with -patternFile,
you must provide a base file name.
Example 4: Adding a Reference Pattern to a Test Plan

This example:
ims_pat_cvt -reference \
-testPlan plan9 \
-project proj.9 \
-patternDir patterns \
-pattern pat2 \
-patternFile pat2 \
< pat2.ascii
uses timing and device information from testplan plan9 to convert
the source pattern file pat2.ascii to a reference pattern setup, and
updates the test plan.
Notes:
• -reference makes the output setup a reference, not a local,
setup. When you specify -reference:
♦ The output directory (here patterns; if not specified, the
current directory) must be in the reference pattern search
path given in the project file.

♦ No files with the basename pat2 may exist in any directory in

the reference pattern search path other than the output
directory.
♦ -project specifies the project file, which contains a reference
file search path. To learn whether a default project file is
being used, use the -verbose option.
• -pattern specifies the output setup name as it appears in IMS
Tools windows, and -patternFile specifies a base file name as
required for reference patterns, which need not follow the
conventions used for naming local setups. The files written to the
-patternDir are:
pat2.bin and
pat2.
If the files already exist, they are overwritten.
Example 5: Overwriting a Reference Pattern in a Test

Plan
This example:
ims_pat_cvt -reference \
-testPlan plan9 \
-project proj.9 \
-pattern pat2 \
-patternFile pat2 \
< pat2.ascii
uses timing and device information from testplan plan9 to convert
the ASCII pattern file pat2.ascii to a reference pattern setup.
Notes:
• This is identical to Example 4, except that it does not use
-updateTestPlan.
• If a -patternFile was specified when the reference pattern was
created, the same -patternFile must be specified here to modify
it.

Examples
Example 6: Converting a Pattern with a Named Timing

Setup
This example:
cd <directory_containing_ASCII_pattern>
gunzip -c ascii.gz | ims_pat_cvt -testPlan plan9 \
-patternDir plan9 \
-pattern pat2 \
-timing Timing_shrink \
-updateTestPlan
uses timing information from timing setup Timing_shrink and other

information from testplan plan9 to convert an ASCII pattern piped in
from gunzip into pattern pat2 in plan9. The test plan is updated.
Notes:
• The files created are
plan9/Pattern_pat2.ims and
plan9/Pattern_pat2.bin.
• Timing setup Timing_shrink is part of plan9 but is not

necessarily the current timing setup. All other test plan
information used in the conversion comes from current setups.
• The directory named with the -patternDir switch must match the
-testPlan name.
• If -updateTestPlan is omitted, the same files will be created but
will not be part of the test plan.
Example 7: Converting an ASCII Pattern Piped in from

DPT
This example:
cd <directory_containing_DPT_run_file/test.run>
DPT -r test.run | ims_pat_cvt -testPlan plan9 \
-patternDir plan9 \
-updateTestPlan

uses current setup information from testplan plan9 to convert an

ASCII pattern piped in from DPT using the DPT run file test.run
into the current pattern in plan9.
Notes:
plan9/Pattern_Untitled.ims and
plan9/Pattern_Untitled.bin.
• The previous contents of the untitled pattern setup are replaced.
Example 8: Concatenating Pattern Files

This example
ims_pat_cvt -noTestPlan pat2.ascii \
-patternFile pat2 \
-source reset.ascii \
< pat2.ascii
This example is exactly like Example 3, except that data from ASCII
pattern file reset.ascii is loaded and converted before the pattern
data from file pat2.ascii.
Notes:
patterns/Pat2.ims and
patterns/Pat2.bin.
• A file named with the -source switch must be a standard

Vanguard ASCII pattern setup and must be compatible with the
main source pattern.
• Any number of pattern files may be inserted using multiple
-source switches on the command line. Their data are added to
the main pattern (from standard input) in command-line order.
Example 9: Converting a Binary Setup to ASCII

This example

Examples
ims_pat_cvt -decompile 646_pat2 \

-testPlan Demo646/testplan \
-patternDir 646_ref/ascii
converts a binary pattern setup from a specified test plan directory
and places the resulting ASCII file in another directory.
Input file: the binary setup Demo646/testplan/646_pat2
Output file: the ASCII pattern file
646_ref/ascii/Pattern_646_pat2.ims.
Notes: When decompiling a binary file,

• Specify the setup name as it appears in IMS Tools. Any number

of pattern names can be used after the -decompile switch. The
input setup may be a reference pattern.
• Always use one or both of -testPlan and -patternDir. If you omit
both switches, the input directory and the output directory are
both the current directory, and you overwrite the original binary
file.


INDEX
A in AVI-Link, 222
in SURF, 243
Active_input directive, APT, 115 Breakup directive, DPT, 53
APT
command line options, 110 C
Conversion section directives, 177
differences from DPT, 87 Comment directive
environment variables used by, 112 APT, 122
files used by, 86 SURF, 252
getting version number of, 111 comments
how to start, 109 in APT Run file, 92
limitiations of, 88 in DPT Run file, 31
Run file structure, 91 in source data, 25
Source section directives, 114 in SURF Run file, 247
Target section directives, 159 Compress directive, DPT, 55
Asserted_output directive, APT, 117 Concatenate directive, APT, 125
AVI-Link Concatenating pattern files with
command line options, 220 ims_pat_cvt, 284
creating a test plan from a setup, 228 Conversion section
diagram of conversion process, 217, 219 directives for, 177
handling bidirectional pins, 222 structure of, 94
preparing the test plan, 222 CycleLength directive, SURF, 253
unsupported ATS features, 221 Cyclized directive, APT, 127
using the Fixture Map file, 226
D
B
Data directive, APT
Batch imports of pattern setups, 273 Source section, 130
Bidir directive Target section, 163
APT, 119 Decompiling patterns with
DPT, 51 ims_pat_cvt, 275, 284
example of use with APT, 202 Depth directive, SURF, 255
examples of use with DPT, 32 Device directive, APT
SURF, 250 Source section, 131
bidirectional pins Target section, 164
APT example for VCD, 97 diagram of AVI-Link conversion
Bidir directive, APT, 119 process, 217, 219
Bidir directive, DPT, 51 Directives, APT
Bidir directive, SURF, 250 Active_input, 115
DPT examples, 32 Asserted_output, 117

Index
Bidir, 119 SourceFile, 68

Comment, 122 SourceFormat, 69
Concatenate, 125 Step, 70
Conversion section directives, 177 Substitute, 72
Cyclized, 127 TargetDirectory, 73
Data, in Source section, 130 TargetFormat, 74
Data, in Target section, 163 TargetSetup, 75
Device, in Source section, 131 TestPlan, 76
Device, in Target section, 164 TimeUnits, 77
End_time, 132 Tristate, 79
External_resistor, 134 UpdateTestPlan, 80
FixtureMap, 165 VCDSignals, 81
Groups, 136 WaveformOrder, 83
Include, Conversion section, 178 Directives, SURF
Include, in Source section, 140 Bidir, 250
Include, in Target section, 165 Comment, 252
Logfile, 180 CycleLength, 253
Map_tristate, 167 Depth, 255
NoSequenceNumbers, 168 LineContinue, 256
NoTimestamp, 142 NoTimestamp, 257
Option, 144 Signals, 258
Retain_halts, 146 SourceFile, 261
Setup, in Source section, 147 SourceFormat, 262
Setup, in Target section, 169 StartTime, 263
Source section directives, 114 Step, 265
Start_time, 148 Substitute, 267
Step, 150 TargetFile, 269
Substitute, 152 TesterType, 270
Target section directives, 159 TimeUnits, 271
Timebase, 156 DPT
Translate, 181 command line options, 15
VanguardTiming, 172 conditionally required directives, 29
WaveformMap, 174 differences from APT, 87
WaveformOrder, 175 files used by, 13
Zero_delay, in Source section, 158 getting version number of, 15
Zero_delay, in Target section, 176 how to start, 14
Directives, DPT optional directives, 30
Bidir, 51 required directives, 28
Breakup, 53 Run file comments, 31
Compress, 55 Run file syntax, 28
Fill, 56
GenericComment, 57 E
GenericSignals, 58
IgnoreInstructions, 60 End_time directive, APT, 132
LineContinue, 61 Examples
MatchSignals, 62 ims_pat_cvt, 279
Monitor, 64 examples
NoTimestamps, 65 APT Run file, 195, 206, 209, 213
ReferenceDirectory, 66 Generic data file, 203, 208, 212

Index
running APT, 197 Instructions keyword, APT, 144

running SURF, 194
SURF Run file, 192, 199, 204 K
use of APT Groups directive, 201
using DPT with, 189 Keep Alive data, generated at end of file by
VCD data file, 191, 199 APT, 101
External_resistor directive, APT, 134
L
F
LineContinue directive
files DPT, 61
used by APT, 86 SURF, 256
used by DPT, 13 LineContinue keyword, APT, 144
used by SURF, 238 Logfile directive, APT, 180
Fill directive, DPT, 56
Fixture Map file in AVI-Link, 226 M
FixtureMap directive, APT, 165
Map_Tristate directive, APT, 167
G MatchSignals directive, DPT, 62
example of use, 32
GenericComment directive, DPT, 57 memory, increasing amount used by APT, 112
GenericSignals directive, DPT, 58 Monitor directive, DPT, 64
Groups directive, APT Monitor keyword, APT, 144
syntax of, 136
VCD conversion using, 96 N
H NoInstructions keyword, APT, 144
NoSequenceNumbers directive, APT, 168
Halt instruction, placement of by APT, 101 NoTimestamp directive
APT, 142
I SURF, 257
NoTimestamps directive, DPT, 65
IgnoreInstructions directive, DPT, 60
Importing ASCII pattern files, 273 O
ims_pat_cvt
command line syntax, 274 Option directive, APT, 144
concatenating pattern files, 284
examples, 279 P
pattern converter utility, 273
using with DPT output files, 283 Pattern compression with ims_pat_cvt, 274
Include directive, APT Pattern converter utility
Conversion section, 178 command line syntax, 274
Source section, 140 concatenating pattern files, 284
Target section, 165 converting DPT output files, 283
examples, 279
starting, 273
pattern instructions
preserving with APT, 88

Index
Pattern setups example of generic tabular source data, 22

importing with ims_pat_cvt, 273 line length in, 25
radix, 23
R signal names in, 23
timestamps in, 22
radix in simulator data, 23 untimestamped, 22
Reference patterns Source section
creating with DPT, 66 directives, 114
creating with ims_pat_cvt, 276 structure of, 93
importing with ims_pat_cvt, 276 SourceFile directive
ReferenceDirectory directive, DPT, 66 DPT, 68
Retain_halts directive, APT, 146 SURF, 261
Run file, APT SourceFormat directive
comments in a, 92 DPT, 69
conversion section structure defined, 94 SURF, 262
conversion segments defined, 91 Start_time directive, APT, 148
converting to DPT Run file, 36 Starting APT, 109
example of, 195, 206, 209, 213 Starting DPT, 14
source section structure defined, 93 Starting SURF, 248
structure of, 91 StartTime directive, SURF, 263
target section structure defined, 94 Step directive
with AVI-Link, 230 APT, 150
Run file, DPT, 28 DPT, 70
comments in a, 31 SURF, 265
conditionally required directives, 29 Substitute directive
Generic example, 33 APT, 152
optional directives, 30 DPT, 72
required directives, 28 SURF, 267
VCD example, 32
Run file, SURF, 244 T
comments in, 247
data dependent directives, 246 Target section
optional directives, 247 structure of, 94
required directives, 244 TargetDirectory directive, DPT, 73
TargetFile directive, SURF, 269
S TargetFormat directive, DPT, 74
TargetSetup directive, DPT, 75
serial scan data TesterType directive, SURF, 270
not supported by APT, 88 TestPlan directive, DPT, 76
Setup directive, APT Timebase directive, APT, 156
Source section, 147 TimeUnits directive
Target section, 169 DPT, 77
signal names SURF, 271
Generic conversions with APT, 99
VCD names in APT, 97
Signals directive, SURF, 258
simulator data
comments in, 25
data characters in, 24

Index
timing characteristics of device pins, 18

Translate directive, APT, 181
Tristate directive, DPT, 79
U
UpdateTestPlan directive, DPT, 80
V
VanguardTiming directive, APT, 172
VCD conversions
list of supported APT directives, 98
VCDSignals directive, DPT
example of use, 32
syntax for, 81
Verilog source data
converting with APT, 96
converting with DPT, 32
version
getting for APT, 111
getting for AVI-Link, 220
getting for DPT, 15
getting for Pattern Convertor utility, 277
getting for SURF, 248
W
waveform order file
defined, 38
differences between DPT and APT syntax
in, 47
elements of, 39
how applied, 45
macros in, 42
WaveformMap directive, APT, 174
WaveformOrder directive
APT, 175
DPT, 83
Z
Zero_delay directive, APT
Source section, 158
Target section, 176

Index

IMS Pattern Conversion Manual Apt

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

IMS Pattern Conversion Manual Apt

Transféré par

Droits d'auteur :

Formats disponibles

IMS Vanguard™

Pattern Conversion Manual

Credence Systems Corporation

Customer Service Center

Printed in September 2003 in the U.S.A. All rights reserved.

2 - Planning Your Data Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 - Creating Your DPT Run File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4 - Creating the Waveform Order File . . . . . . . . . . . . . . . . . . . . . . . . 37

IMS Vanguard Pattern Conversion Manual 3

Waveform List Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5 - DPT Run File Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4 IMS Vanguard Pattern Conversion Manual

IMS Vanguard Pattern Conversion Manual 5

6 IMS Vanguard Pattern Conversion Manual

When Your Source is Generic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

7 - APT Run File Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

IMS Vanguard Pattern Conversion Manual 7

8 - Learning Through Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

8 IMS Vanguard Pattern Conversion Manual

Looking at the Generic Data File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

B - Viewing Data as Waveforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

IMS Vanguard Pattern Conversion Manual 9

Writing a SURF Run File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

C - Batch Pattern Imports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

10 IMS Vanguard Pattern Conversion Manual

IMS Vanguard Pattern Conversion Manual 11

Vanguard Pattern Conversion Tools

12 IMS Vanguard Pattern Conversion Manual

How DPT Works

Figure 1. Files used by DPT, or created by DPT during a

IMS Vanguard Pattern Conversion Manual 13

How to Start DPT

14 IMS Vanguard Pattern Conversion Manual

DPT Command Line Syntax

Table 1: Command line parameters for DPT

-config <file> (Optional) Specifies the name of the config

IMS Vanguard Pattern Conversion Manual 15

16 IMS Vanguard Pattern Conversion Manual

Planning Your Data

Planning Your Data

IMS Vanguard Pattern Conversion Manual 17

Creating Your Test Plan

18 IMS Vanguard Pattern Conversion Manual

Knowing Your Data Format

Planning Your Data

Planning Your Data

IMS Vanguard Pattern Conversion Manual 19

Evaluating Your VCD Source Data

$scope module Test_74LS646 $end

20 IMS Vanguard Pattern Conversion Manual

Evaluating Your Generic Source Data

Planning Your Data

Planning Your Data

Planning Your Data

IMS Vanguard Pattern Conversion Manual 21

Generic Source File Example

/* These lines are commented out:

Elements of a Generic Source File

22 IMS Vanguard Pattern Conversion Manual

If present, timestamps must be at the beginning of the line (preceded

Planning Your Data

Planning Your Data

Radices Planning Your Data