The information contained in this document has been carefully checked and is believed to be reliable.
However, no responsibility can be assumed for inaccuracies that may not have been detected.
LeCroy reserves the right to revise the information presented in this document without notice or penalty.
Trademarks and Servicemarks
LeCroy, CATC, and USB Protocol Suite are trademarks of LeCroy.
Microsoft and Windows are registered trademarks of Microsoft Inc.
All other trademarks are property of their respective companies.
This document describes the LeCroy USB Protocol Suite™ Verification Script Engine (VSE), which allows users
to perform complicated custom analyses of traffic recorded using the LeCroy protocol analyzers.
The VSE allows you to ask the application to send “events” (currently only frame-level events are available) that
occur in the recorded trace to a verification script written using LeCroy script language. This script then
evaluates the sequence of events (timing, data, or both) in accordance with user-defined conditions and
performs post-processing tasks; such as exporting key information to external files (in text or binary format) or
sending special Automation™/COM notifications to client applications.
The VSE fully utilizes the high performance and intelligence of LeCroy decoding capabilities, making processing
of information easy and fast. VSE can:
•Retrieve information about any field in frame headers, contents of frame payloads, serial data, and bus
states.
• Make complex timing calculations between different events in pre-recorded traces.
• Filter-in or filter-out data with dynamically changing filtering conditions.
• Port information to a special output window.
• Save data to text or binary files.
• Send data to COM clients connected to the application.
Writing verification scripts is easy, if you understand how the application interacts with running scripts and if you
follow some rules imposed by the verification script syntax.
The main file with the text of the verification script must have extension .vse. It must be located in the subfolder
..\Scripts\VFScripts of the main folder. Some other files must be included in the main script file using the
directive %include.
The following schema presents a common structure of a verification script. It is similar to the script template
VSTemplate.vs_, which is included with VSE.
#
# VS1.vse
#
# Verification script
#
# Brief Description:
# Verify something.
#
############################################################################################
# Module info #
############################################################################################
# Filling of this block is necessary for proper verification script operation... #
set DecoderDesc = “<Your Verification Script description>”; # Optional
#
# Include main Verification Script Engine definitions.
#
%include “VSTools.inc” # Should be set for all verification scripts.
######################################################################################
# Global Variables and Constants #
# Define your verification script-specific global variables and constant in this section.
# (Optional)
const MY_GLOBAL_CONSTANT = 10;
set g_MyGlobalVariable = 0;
# OnStartScript() #
# #
# Main intialization routine for setting up all necessary #
# script parameters before running the script. #
# #
OnStartScript()
{
######################################################################################
# Specify in the body of this function the initial values for global variables #
# and what kinds of trace events should be passed to the script. #
# (By default, only Primitive events from all channels #
# are passed to the script. #
# #
# For details about how to specify the kind of events to pass to the script, #
# please see the topic ‘Sending Functions’. #
# #
# OPTIONAL. #
######################################################################################
# Uncomment the line below if you want to disable output from
# ReportText()-functions.
#
# DisableOutput();
# Main script function called by the application when the next waited event #
# occurs in the evaluated trace. #
# #
# !!! REQUIRED !!! MUST BE IMPLEMENTED IN THE VERIFICATION SCRIPT #
# #
ProcessEvent()
{
#
# The function below shows the specified message only once,
# no matter how many times ProcessEvent is called.
#
ShowStartPrompt(“ShowStartPrompt\n”);
# Write the body of this function depending on your needs.
Return Complete();
}
# OnFinishScript() #
#
# Main script function called by the application when the script has completed #
# running. Specify in this function some resetting procedures for a successive run #
# of this script. #
# #
# OPTIONAL. #
OnFinishScript()
{
return 0;
}
# Additional script functions. #
# #
# Write your own script-specific functions here. #
# #
3 Interaction between Application and Verification
Script
The following steps describe the interaction between the application and a verification script run over a recorded
trace:
1. Before sending any information to the script main processing function ProcessEvent() (which must be
present in any verification script),VSE looks for function OnStartScript() and calls it if it is found. In this
function, some setup routines can be made, like specifying the channels, specifying the trace events to
pass to the script, and setting up initial values of the global script-specific global variables.
2. Then VSE goes through the recorded trace and checks if the current frame in the trace meets specified
sending criteria. If it does, VSE calls the script main processing function ProcessEvent(), providing
some information about the current event in the script input context variables.
(See the topic “Input context variables” below in this document for a full description of verification script
input context variables.)
3. ProcessEvent() is the main verification routine, in which all processing of incoming trace events is done.
Basically, when the whole verification program consists of a few stages, this function processes the
event sent to the script, verifies that information contained in the event is appropriate for the current
stage, and decides if VSE should continue script running. If the whole result is clear on the current
stage, it tells VSE to complete execution of the script.
The completion of the test before the whole trace has been evaluated is usually done by setting the
output context variable:
out.Result = _VERIFICATION_PASSED or _VERIFICATION_FAILED.
(See the topic “Output context variables” below in this document for a full description of verification script
output context variables.)
Note: Not only does a verification script verify recorded traces by some criteria, but it is also possible to
extract some information of interest and post-process it later by third-party applications. (There is a set
of script functions to save extracted data in text or binary files or send it to other applications via
COM/Automation™ interfaces.)
1 When script running is finished, VSE looks for the function OnFinishScript() and calls it if it is found. In
this function, some resetting procedures can be done.
The following picture presents the interaction between the application and a running verification script:
Set out.Re su lt =
_VERIFICATION_PASSED
or
_VERIFICATION_FAILED
will comp le t e the scr ipt run.
COM
Client
Call..
(If expected event )
Call..
(If expected event )
Call..
(If expected event )
Call..
(If expected event )
Call..
(If expected
event )
OnFinishScript()
PASSED
FAILED
Call..
DONE
erification Script results
Note: Verification script result <DONE> means that the script is intended for extracting and displaying some
information from recorded traces only, and you do not care about results. To specify that your script is for
displaying information only, call the function ScriptForDisplayOnly() somewhere in your script (in
OnStartScript(), for instance).
To run a verification script over a trace, you select the main menu item Report > Run verification scripts or
click the Run verification scripts button on the main tool bar (if it is not hidden):
Push the button Run scripts after you select scripts to run. VSE starts running the selected verification scripts,
shows script report information in the output windows, and presents the results of verifications in the script list:
Right-clicking the script list displays some additional operations over selected scripts:
Run verification script(s):
Edit script: Edit selected scripts in the editor application specified in Editor settings.
New script: Create a new script file using the template specified in Editor settings.
Show Grid
Show Description window
Show Output
Settings: Open a special Setting dialog to specify different settings for VSE.
: Show/hide a grid in the verification script list.
: Show/hide the script output windows (Shortcut key F3).
Start running selected script(s).
: Show/hide the script description window (Shortcut key F2).
After choosing Settings, the following dialog appears:
This option (if set) allows editor
applications supporting multi-document
interface (MDI) to edit a ll s cr ip t files
related to the selected scripts in one
application instance.
Otherwise, a new application instance
will be launched for each script file.
This option (if set) allows editor
applications to edit all included files
(extension : *.inc) along with main
verification script files (extension : *.vs e )
Otherwise, only main verification script
files will be opened for editing.
Launches editor application in full screen
mode.
Full path to the file to be used as a
template for a new script.
This setting (if set) specifies that the last
saved output for selected scripts should
be loaded into the out
This setting (if set) brings Run VS dialog
to foreground when scripts stopped
runnin
.
This option specifies that potential runtime errors and warnings like calling not
defined functions etc. shouldn't be
reported.
This setting (if set) forces the application
to save output automatically when the
scri
ts stopped running.
ut windows.
See screen pop-up tooltips for
explanation of other settings…
5 Verification Script Engine Input Context Members
All verification scripts have input contexts, special structures that can be used inside of the scripts. The
application fills their members. The verification script input contexts have two sets of members:
• Trace event-independent set of members
• Trace event-dependent set of members
Note: All input context members have integer type values unless their types are explicitly specified.
If possible values for input context members are not explicitly specified, they should comply with the current USB
specifications.
5.1 Trace Event-independent Set of Members
This set of members is defined and can be used for any event passed to a script:
in.Level: Transaction level of the trace event. It can be one of the following constants:
in.Index: Index of the event in the trace file (packet number for packets etc).
in.Time: Time of the event (type = list, having format = 2 sec 125 ns -> [2 , 125]. For more information, see
section 10.1 VSE Time Object
In.Channel: Indicates on which channel the event occured. It can be one of the following constants:
in.Speed: Indicates the speed for the trace event. It can be one of the following constants:
_FS: USB2 Full Speed (value = 1)
_LS: USB2 Low Speed (value = 2)
_HS: USB2 High Speed (value = 3)
_SS: USB3 Super Speed (value = 4)
in.Direction: Indicates the direction for the trace event. It can be one of the following constants:
_IN: Direction is from Host to Device (value = 2)
_OUT: Direction is from Device to Host (value = 3)
_BOTH: Trace event involves traffic in both directions (value = 4)
in.TraceEvent: Type of trace events. (Application predefined constants are used. See list of possible events
in Chapter 7. Verification Script Engine Events
in.Notification: Type of notifications. (Application predefined constants are used. Currently no notifications
This set of members is defined and can be used only for a specific event or after calling functions that provide
values of variables:
5.2.1 USB Packet-specific Set of Members
Members of this set are valid for all USB packet events:
in.RawPacket: Bit source of the whole packet. (You can extract any necessary information using the
GetNBits(), NextNBits(), or PeekNBits() functions.
In.RawPacketLength: Length of the packet (in bytes).
In.Duration: Time it took to transmit the packet on the bus (VSE Time object
In.Errors: A bitmap of packet level errors. The table below describes the current list of possible packet errors
and their bit positions in the error bitmap:
Error type Bit position Description
USB2 Errors:
PID_ERROR 1 Bad PID value
CRC5_ERROR 2 Bad CRC5
CRC16_ERROR 3 Bad CRC16
PACKETLEN_ERROR 4 Wrong packet length
BIT_STUFF_ERROR 5 Bit stuffing error
EOP_ERROR 6 Bad End Of Packet
BABBLE_START_ERROR 7 Babble start error
BABBLE_END_ERROR 8 Babble end (Loss Of Activity) error
FRAME_LENGTH_ERROR 9 Wrong frame length
HANDSHAKE_TIMEOUT_ERROR 10 Bad turnaroud timing or timeout
condition for handshake
INTERNAL_ERROR 11 Analyzer internal error
DATA_TOGGLE_ERROR 12 Data toggling error
MICROFRAME_ERROR 13 Bad frame or microframe number
MOD_8_ERROR 14 Last Byte Incomplete error
OTG_ERROR 15 Bad OTG Signal value
in.Addr: Value of the Address (ADDR) field of the Token packet.
In.Endp: Value of the Endpoint (ENDP) field of the Token packet.
5.2.1.2.2 USB2 Start Of Frame Packet Members
in.FrmNum: Frame number for the current USB2 frame.
In.MicroFrmNum: Microframe number for the current microframe as determined by the Analyzer (would be
zero for Full Speed frames).
5.2.1.2.3 USB2 Data Packet Members
in.Payload: Bit source of the packet payload. (You can extract any necessary information using GetNBits(),
NextNBits(), or PeekNBits() function.
In.PayloadLength: Length (in bytes) of the packet payload.
In.CRC16: CRC16 value for the Data packet.
5.2.1.2.4 USB2 Split Token Packet Members
in.HubAddr: Value of the Hub Address field, the USB device address of the hub supporting the specified full-
/low-speed device for this full-/low-speed transaction.
In.SC: Value of the Start/Complete bit for the split token.
In.Port: Value of the Port field – the port number of the target hub for which this full-/low-speed transaction is
destined.
In.S: Value of the Speed bit for the split token.
In.E: Value of the End bit for the split token.
In.ET: Value of the Endpoint Type field for the split token.
5.2.1.2.5 Link Power Management Extended Token Members
in.HIRD: Value of the Host Initiated Resume Duration field.
In.bLinkState: Value of the bLinkState field for the LPM extended token.
In.bRemoteWake: Value of the bRemoteWake bit for the LPM extended token.
In.Reserved: Value of the reserved field for the LPM extended token.
Note 1: Valid for USB3 packets only, undefined for other events.
Note 2: The system does not pass all possible fields of USB3 packets as members of Input Context. If a script
needs to use the values of those fields, use the GetHexPktField
5.2.1.3.12
for examples.
5.2.1.3.1 TSEQ Training Sequence Ordered Set Members
in.Count: Value of TSEQ count, the number of sequential TSEQ sequences sent
5.2.1.3.2 TS1/TS2 Training Sequence Ordered Set Members
in.Count: Value of TS count, the number of sequential TS1 or TS2 sequences sent
in.LnkFunctionality: Value of the whole Link Functionality (Link Configuration) byte in the training
sequence
in.Reset: Value of the Reset bit in the Link Configuration byte.
In.SSDisable: Value of the Spread Spectrum bit in the Link Configuration byte.
In.Loopback: Value of the Loopback asserted/deasserted bit in the Link Configuration byte.
In.ScrDisable: Value of the Disable Scrambling bit in the Link Configuration byte.
and GetDecodedPktField functions. See
5.2.1.3.3 LFPS Packet Members
in.Type: Type of LFP signaling
in.Duration: Duration of LFP signaling in nanoseconds
5.2.1.3.4 Inter-Packet Symbols Packet Members
in.NumOfSymbols: Number of symbols in the IPS sequence
5.2.1.3.5 Link Command Packet Members
in.LnkCmd: Value of Link Command information for the Link command
in.Count: Count of symbols in the Logical Idle sequence
5.2.1.3.8 Link Management Packet Members
in.SubType: SubType value for LMP. Use constant definitions in VS_constants.inc.
5.2.1.3.9 Isochronous Timestamp Packet Members
in.BusICounter: Bus Interval Counter value for ITP, in 1/8 of a millisecond
in.Delta: Time Delta value for ITP
in.BusIAdjCtrl: Bus Interval Adjustment Control value for ITP, specifying the device in control of
bus interval adjustment
5.2.1.3.10 Transaction Packet Members
in.SubType: SubType value for Transaction Packet. Use constant definitions in VS_constants.inc.
in.Addr: Address of the device that receives this Transaction Packet
in.Endp: Endpoint number on the device that receives this Transaction Packet
in.Dir: Direction for the specified Endpoint
in.StreamID: Value of the StreamID field
in.Addr: Address of the device which is the recipient of this Data Packet
in.Endp: Endpoint number on the device which is the recipient of this Data Packet
in.Dir: Direction for the specified Endpoint
in.StreamID: Value of the StreamID field
in.SeqN: Value of the Sequence Number for this Data Packett
in.DataLength: Length of the payload for this Data Packet
in.PayloadLength: Length of the payload actually recorded for this Data Packet
in.Payload: Bit source of the packet payload for this Data Packet. (You can extract any necessary
information using the GetNBits(), NextNBits(), or PeekNBits() function.)
in.CRC32: Value of CRC32 protecting the payload for this Data Packet
Note: In USB Protocol Suite software versions earlier than 3.71 (namely, 3.60 and 3.70), Data Packet Header
and Data Packet Payload were two separate packet types with input context members split accordingly between
them. Those were combined into a single Data Packet starting with version 3.71.
5.2.1.3.12 Getting Values of the Fields not present in Input Context
As mentioned earlier, not all the possible fields of USB3 packets are passed as members of Input Context. The
following are examples of using GetHexPktField
not present in Input Context.
If( in.TraceEvent == _USB3_LMP_PKT )
{
# Example of using decoded packet information for LMPs.
in.Addr: Device Address value for this Usb transaction.
In.Endp: Device Endpoint Number value for this Usb transaction.
In.TraCompletionFlag: Handshake PID for the transaction (if any). Possible values are:
const PID_ACK = 0x4B;
const PID_NAK = 0x5A;
const PID_STALL = 0x78;
const PID_NYET = 0x69;
const PID_ERR = 0x3C;
0xFFFFFFFF – in case no handshake was sent for the transaction.
In.Complete: Flag, signaling if the transaction was complete.
In.XferType: Type of the USB Transfer this transaction belongs to. See Transfer Types for possible values.
In.CtrlDirection: For a Setup transaction represents the direction of the corresponding Control Transfer.
0 = Host-to-device
1 = Device-to-host
in.FirstInXfer: This flag is set when the transaction is first in the transfer it belongs to.
In.LastInXfer: This flag is set when the transaction is last in the transfer it belongs to.
In.Errors: Error code for the transaction, if any error happened.
If the transaction is a Setup transaction, the following input context members provide values of the
corresponding fields of the USB Device Request:
in.Split: Signals that the transaction is a start-split or complete-split.
In.HubAddr: Value of the Hub Address field, the USB device address of the hub supporting the specified full-
/low-speed device for this full-/low-speed transaction.
In.SC: Value of the Start/Complete bit for the split token.
In.Port: Value of the Port field – the port number of the target hub for which this full-/low-speed transaction is
destined.
In.S: Value of the Speed bit for the split token.
In.E: Value of the End bit for the split token.
In.ET: Value of the Endpoint Type field for the split token.
In.OTGHostId: For USB On-The-Go transactions, indicates if the A-device is acting as the host (value of 0) or
the B-device is acting as the host (value of 1).
In.OTGErrorCode: For USB On-The-Go transactions, indicates error code if non-zero.
In.OTGErrorCodeOffset: For USB On-The-Go transactions with errors, indicates the offset from the first
packet in the transaction to the packet with error.
In.PayloadLength: Length (in bytes) of the packet payload. If zero, the transaction does not have any
payload.
In.Payload: Bit source of the transaction data payload. Note: You can extract any necessary information using
the GetNBits(), NextNBits(), or PeekNBits() function.
All the input context members that are defined for USB2 transactions are also applicable to Split Transactions. In
addition to those, Split Transactions define the following members:
in.TraHalted: Indicates that this split transaction was halted.
in.XferType: Type of transfer. Repeats the trace event value for the transfer.
In.Addr: Device Address value for this USB transfer.
In.Endp: Device Endpoint Number value for this USB transfer.
In.Completed: Flag signaling if the transfer was completed.
In.Halted: Flag signaling if the transfer was halted (usually that means STALL handshake sent).
In.CtrlDirection: For a Control Transfer, represents the direction:
0 = Host-to-device
1 = Device-to-host
If the transfer is a Control Transfer, the following input context members provide values of the corresponding
fields of the USB Device Request:
6 Verification Script Engine Output Context Members
All verification scripts have output contexts, special structures that can be used inside of the application. The
scripts fill their members. The verification script output contexts have only one member:
out.Result: Result of the whole verification program defined in the verification script.
This member can have three values:
• _VERIFICATION_PROGRESS: Set by default when a script starts running.
• _VERIFICATION_PASSED
• _VERIFICATION_FAILED
The last two values should be set if you decide that a recorded trace does (or does not) satisfy the imposed
verification conditions. In both cases, the verification script stops running.
If you do not specify any of those values, the result of script execution is set to VERIFICATION_FAILED at exit. Note: If you do not care about the result of script running, call the function ScriptForDisplayOnly
VSE defines a large group of trace “events” that can be passed to a verification script for evaluating, retrieving,
and displaying some contained information. The information about the type of event can be seen in the
in.TraceEventinput context member.
The application defines a set of VSE constants for Trace Event types. Those constants should be used by the
scripts for determining the event types.
See the topic “Sending Functions” for details about how to specify the events to send to verification scripts.
The table below describes the current list of packet level (lowest level of transactions) events and values
(application-defined constants) for in.TraceEvent:
Types of packets in.TraceEvent
USB2 packet events
All USB2 packet events _USB2_PACKET
USB2 Bus conditions _USB2_BUS_CONDITION
USB2 Start Of Frame packets _USB2_SOF
USB2 Token packets _USB2_TOKEN
USB2 Data packets _USB2_DATA
USB2 Handshake packet _USB2_HSK
USB2 SPLIT packets _USB2_SPLIT
USB Full Speed Hub prefix packets _USB2_PRE
USB2 Link Power Management extended token _USB2_LPM
All other USB2 packets _USB2_OTHER
USB3 packet events
All USB3 packet events _USB3_PACKET
TSEQ Training Sequence Ordered Sets _USB3_TSEQ
TS1 Training Sequence Ordered Sets _USB3_TS1
TS2 Training Sequence Ordered Sets _USB3_TS2
Low Frequency Periodic Signaling _USB3_LFPS
Interpacket Symbols _USB3_IPS
Link Commands _USB3_LINK_CMD
SKIP Sequences _USB3_SKP_SEQ
Logical Idle Symbols _USB3_SYMBOL_IDLE
Isochronous Timestamp packets _USB3_ITP_PKT
Link Management packets _USB3_LMP_PKT
Transaction packets _USB3_TP_PKT
Data Packets _USB3_DP_PKT
Data Packet headers _USB3_DPH_PKT (only for traces before
Data payload packets _USB3_DPP_PKT (only for traces before
All other USB3 packets _USB3_OTHER_PKT
The table below describes the current list of transaction level events and values (application-defined constants)
for in.TraceEvent:
Types of transactions in.TraceEvent
Setup transactions _T_SETUP
In transactions _T_IN
Out transactions _T_OUT
All other transaction types _T_OTHER
7.3 Split Transaction Level Events
The table below describes the current list of split transaction level events and values (application-defined
constants) for in.TraceEvent:
Types of transactions in.TraceEvent
All split transactions _SPLIT_TRA
7.4 Transfer Level Events
The table below describes the current list of transfer level events and values (application-defined constants) for
in.TraceEvent:
Types of transfers in.TraceEvent
Control transfers _X_CONTROL
Isochronous transfers _X_ISO
Bulk transfers _X_BULK
Interrupt transfers _X_INTERRUPT
All other (undefined) transfer types _X_OTHER
This topic contains information about the special group of VSE functions that specify the events the
verification script should expect to receive.
8.1 SendLevel()
This function specifies that events of specified transaction level should be sent to the script.
Currently only frame level events can be sent to verification scripts.
This function specifies that ONLY events of a specified transaction level should be sent to the script.
Currently only frame level events can be sent to verification scripts.
This function specifies that events of a specified transaction level should NOT be sent to the script.
Currently only frame level events can be sent to verification scripts.
SendChannelOnly (_USB2); # Send ONLY events from USB2 channel.
…
SendChannelOnly (_CHANNEL_2); # Send ONLY events from channel 2(USB3_RX).
SendChannelOnly (_CHANNEL_3); # Send ONLY events from channel 3(USB3_TX).
…
SendChannelOnly (2); # Send ONLY events from channel 2 (USB3_RX).
SendChannel Only (3); # Send ONLY events from channel 3 (USB3_TX).
…
DontSendChannel(_USB3_TX); # DO NOT send events from USB3 downstream channel.
…
DontSendChannel(_CHANNEL_2); # DO NOT send events from channel 2 (USB3_RX).
DontSendChannel(_CHANNEL_3); # DO NOT send events from channel 3 (USB3_TX).
…
DontSendChannel(2); # DO NOT send events from channel 2 (USB3_RX).
DontSendChannel(3); # DO NOT send events from channel 3 (USB3_TX).
…
tra_type Specifies the type of Transaction event (see transaction event types
xfer_type Specifies the type of Transfer this transaction is being part of (see transfer event types
address Specifies that only Transaction events with the specified Address value are sent.
The value _ANY means any Address is accepted.
endpoint Specifies that only Transaction events with the specified Endpoint value are sent.
The value _ANY means any Endpoint is accepted.
completion_flag Specifie s that only Transaction events with the specified Handshake PIDs are sent.
The value _ANY means any handshake is accepted.
The possible values are:
SendPktsWithBadCRC ( 0 ); # Send frames with no CRC errors.
Optional parameter specifies whether frames with bad CRC should be
sent to the verification script or not.
If it is omitted or set to 1, frames with bad CRC are sent to the script.
Otherwise, VSE sends only frames with correct CRC.
9 Packet and Script Decoded Fields Retrieving Functions
This group of functions covers VSE generic capability to extract information about data payload fields decoded
with CATC Script Language (CSL) at Transfer level and all decoded fields at Packet level for USB3 packets.
9.1 GetDecodedPktField()
Extracts information about a USB3 packet field and determines how it is shown in the USB Protocol Suite
trace view or the "View … Fields" dialog.
Format : GetDecodedPktField ( fld_name )
Parameters
fld_name Name of the field supposedly existing in the current packet
Return Values
If the field name is in the current packet, the return value is the text value of the decoded field and how to display
it in the trace view. Otherwise, the return value is the empty string.
Example
if( in.TraceEvent == _USB3_LMP_PKT )
{
# Example of using decoded packet information for LMPs.
# ‘SubType’ field
# String value
str = FormatEx(“\tSubType(str) = ‘%s’”, GetDecodedPktField(“SubType”));
ReportText( str );
}
Remark
The field name should be exactly the same as it is in the trace. The field name is case sensitive.
Extracts the raw hexadecimal value of the USB3 packet field.
Format : GetHexPktField ( fld_name )
Parameters
fld_name Name of the field supposedly existing in the current packet
Return Values
If the field name is in the current packet, the function returns the hex value of the decoded field:
o integer value if field length is less than 32 bits
o raw binary value if field length is greater than 32 bits. The raw binary value gives a list of bytes.
See the CSL Manual for further details about raw binary values.
o null value if the field was not found.
Example
# Link Control Word
if( ( in.TraceEvent == _USB3_TP_PKT ) ||
( in.TraceEvent == _USB3_DP_PKT ) )
{
ReportText( “LCW:” );
val = GetHexPktField ( “Hseq” );
str = FormatEx( “\tHseq = %d”, val );
ReportText( str );
val = GetHexPktField ( “Hdepth” );
str = FormatEx( “\tHDepth = %d”, val );
ReportText( str );
val = GetHexPktField ( “D1” );
str = FormatEx( “\tDelayed (D1) = %d”, val );
ReportText( str );
val = GetHexPktField ( “D2” );
str = FormatEx( “\tDeferred (D2) = %d\n”, val );
ReportText( str );
}
Remark
The field name should be exactly the same as it is in the trace. The field name is case sensitive.
Extracts information about the script decoded field and determines how it is shown in the USB Protocol Suite
trace view or the “View … Fields” dialog.
Format : GetDecodedScriptField ( fld_name )
Parameters:
fld_name Name of the field supposedly existing in the current Transfer
Return Values:
If the field name is in the current Transfer, the return value is the text value of the decoded field and how to
display it in the trace. Otherwise, the return value is the empty string.
Example:
# Extract the decoded value of wValue field
# for a Control transfer that uses a certain Class
# or Vendor specific decoding.
str = GetDecodedScriptField (“wValue”);
# If the bulk transfer payload decoded by the script decoder
The field name should be exactly the same as it is in the trace. The field name is case sensitive.
This function can be used only at the Transfer level.
Extracts the raw hexadecimal value of the script decoded field.
Format : GetHexScriptField ( fld_name )
Parameters
fld_name Name of the field supposedly existing in the current Transfer
Return Values
If the field name is in the current Transfer, the function returns the hex value of the decoded field:
o integer value if field length is less than 32 bits
o raw binary value if field length is greater than 32 bits. The raw binary value gives a list of bytes.
See the CSL Manual for further details about raw binary values.
o null value if the field was not found.
Example# Extract the hex value of the LBA field for mass storage.
val = GetHexScriptField ( “Logical Block Addr” );
# Extract the hex value of the SomeBig field.
if( GetHexScriptField ( "Some Big" ) == 'FE80000000000000' )
ReportText( "Some Big field = FE80-0000-0000-0000");
Remarks
The field name should be exactly the same as it is in the trace. The field name is case sensitive.
This function can be used only at the Transfer level.
This group of functions covers VSE capability to work with timers, internal routines that repeatedly measure a
timing interval between different events.
10.1 VSE Time Object
A VSE time object presents time intervals in verification scripts. The verification script time object is a
“list” object of two elements.
[seconds, nanoseconds]
Note: The best way to construct a VSE time object is to use the Time() function (see below).
Starts a timing calculation from the event at which this function was called.
Format: SendTimer(timer_id = 0)
Parameters:
timer_id Unique timer identifier.
Example:
SetTimer(); # Start timing for timer with id = 0.
SetTimer(23); # Start timing for timer with id = 23.
Remark:
If this function is called a second time for the same timer ID, it resets the timer and starts timing the calculation
again from the point where it was called.
This group of functions is used to construct VSE time objects.
11.1 Time()
Constructs a verification script time object.
Format: Time(nanoseconds)
Time(seconds, nanoseconds)
Parameters:
nanoseconds Number of nanoseconds in specified time
neconds Number of seconds in specified time
Return values:
First function returns [0, nanoseconds], second one returns [seconds, nanoseconds]
Example:
Time (50 * 1000); # Create time object of 50 microseconds.
Time (3, 100); # Create time object of 3 seconds and 100 nanoseconds.
Time(3 * MICRO_SECS); # Create time object of 3 microseconds.
Time(4 * MILLI_SECS); # Create time object of 4 milliseconds.
Note: MICRO_SECS and MILLI_SECS are constants defined in VS_constants.inc.
Verifies that a VSE time object is greater than a minimum VSE time object and less than a maximum
VSE time object.
Format: IsTimeInInterval(min_time, time, max_time)
Parameters:
min_time VSE time object representing a minimum interval
time VSE time object representing a time interval
max_time VSE time object representing a maximum interval
Return values:
Returns 1 if min_time <= time <= max_time,
Returns 0 otherwise.
This function forces the application to jump to some trace event and shows it in the main trace view.
Format: GotoEvent(level, index)
GotoEvent()
Parameters:
level Transaction level of the event to jump
index Transaction index of the event to jump
Remarks:
If no parameters were specified, the application jumps to the current event being processed by VSE.
If wrong parameters were specified (for example, index exceeding the maximal index for the specified
transaction level), the function does nothing and an error message is sent to the output window.
Example:
…
if(Something == interesting) GotoEvent(); # Go to the current event.
If no parameters were specified, other than marker_text, the application sets the marker to the current event
being processed by VSE.
If wrong parameters were specified (for example, index exceeding the maximal index for the specified
transaction level), the function does nothing and an error message is sent to the output window.
Example:
…
# Set marker to the current event.if(Something == interesting) SetMarker("!!! Something cool !!!");
file_path Full path to the file to open. (For ‘\’ use ‘\\’)
append This parameter (if present and not equal to 0) specifies that VSE should append
the following write operations to the contents of the file; otherwise, the
contents of the file are cleared.
mode This parameter specifies the open mode (text or binary) for the file.
If omitted, text mode is used. It can be one of the following values:
_FO_BINARY (= 0): Opens file in binary mode
_FO_TEXT (= 1): Opens file in text mode (by default)
Return Values:
The “handle” to the file to be used in other file functions.
Example:
…
set file_handle = 0;
…
file_handle = OpenFile(“D:\\Log.txt”); # Opens file in text mode.
# The previous contents
# are erased.
…
WriteString(file_handle, “Some Text1”); # Write text string to file.
WriteString(file_handle, “Some Text2”); # Write text string to file.
…
CloseFile(file_handle); # Closes the file.
…
# Opens file in text mode.
# The following file operations append to the contents of the file.
If the file_handle parameter refers to a text file, then a trailing End-Of-Line symbol is added to the text. In case
of binary files, the End-Of-Line symbol is not added.
Example:
…
set file_handle = 0;
…
file_handle = OpenFile(“D:\\Log.txt”); # Opens text file.
# The previous contents are erased.
…
WriteString(file_handle, “Some Text1”); # Write text string to file.
WriteString(file_handle, “Some Text2”); # Write text string to file.
file_handle "handle" to the file previously opened by OpenFile()
value Data to write
num_of_bytes Optional parameter specifying how many bytes to take from the
value parameter (if omitted, length is calculated automatically
based on the value type)
Remarks:
This function is primarily for binary files. It can be used for text files only if the value parameter is a string of text.
In that case, it is equivalent to the WriteString() function and the num_of_bytes parameter is ignored.
file_path Full path to the trace file to be created. (For
Return Values:
The “handle” to the trace file to be used in other trace-file-related functions.
Remarks:
If file_path contains just a file name (such as test.usb), the trace file is created in the application folder.
Example:
This group of functions covers VSE capabilities to communicate with COM/Automation™ clients connected to
the application. (See the Automation Manual for details about how to connect to the application and VSE.)
20.1 NotifyClient()
This function sends information to COM/Automation™ client applications in custom format. The client
application receives a VARIANT object, which it is supposed to parse.
param_list List of parameters to be sent to the client application.
Each parameter might be an integer, string, raw data (byte chain), or list.
Because the list itself may contain integers, strings, raw data, or other lists, it is possible
to send very complicated messages. (Lists should be treated as arrays of VARIANTs.)
Displays a message in a dialog box, waits for the user to click a button, and returns an Integer indicating
which button the user clicked.
Format: MsgBox(prompt, type, title)
Parameters:
prompt Required. String expression displayed as the message in the dialog box.
type Optional. Numeric expression that is the sum of values specifying the number
and type of buttons to display, the icon style to use, the identity of the default button,
and the modality of the message box. If omitted, the default value for buttons is
_MB_OK. (See the list of possible values in the table below.)
title Optional. String expression displayed in the title bar of the dialog box.
If title is omited, the script name is placed in the title bar.
The type argument values are:
Constant Description
_MB_OKONLY Display OK button only (by Default).
_MB_OKCANCEL Display OK and Cancel buttons.
_MB_RETRYCANCEL Display Retry and Cancel buttons.
_MB_YESNO Display Yes and No buttons.
_MB_YESNOCANCEL Display Yes, No, and Cancel buttons.
_MB_ABORTRETRYIGNORE Display Abort, Retry, and Ignore buttons.
_MB_EXCLAMATION Display Warning Message icon.
_MB_INFORMATION Display Information Message icon.
_MB_QUESTION Display Warning Query icon.
_MB_STOP Display Critical Message icon.
_MB_DEFBUTTON1 First button is default.
_MB_DEFBUTTON2 Second button is default.
_MB_DEFBUTTON3 Third button is default.
_MB_DEFBUTTON4 Fourth button is default.
This function returns an integer value indicating which button was clicked.
Constant Description
_MB_OK OK button was clicked.
_MB_CANCEL Cancel button was clicked.
_MB_YES Yes button was clicked.
_MB_NO No button wa s clicked.
_MB_RETRY Retry button was clicked.
_MB_IGNORE Ignore button was clicked.
_MB_ABORT Abort button was clicked.
Remark:
This function works only for VS Engines controlled via a GUI. For VSEs controlled by COM/Automation™ clients,
it does nothing.
This function "locks" the application, which means that there is no access to other application features until the
dialog box is closed. To prevent too many MsgBox calls (in case a script is not written correctly), VSE keeps
track of all function calls demanding user interaction and doesn't show dialog boxes if some customizable limit is
exceeded (returns _MB_OK in this case).
Example:
…
if(Something)
{
…
str = "Something happened!!!\nShould we continue?"
result = MsgBox(str ,
_MB_YESNOCANCEL | _MB_EXCLAMATION,
"Some Title");
Displays a prompt in a dialog box, waits for the user to input text or click a button, and returns a CSL list
object or string containing the contents of the text box.
prompt Required. String expression displayed as the message in the dialog box.
title Optional. String expression displayed in the title bar of the dialog box.
If title is omitted, the script name is placed in the title bar.
default_text Optional. String expression displayed in the text box as the default response
if no other input is provided. If default_text is omited, the text box is displayed empty.
return_type Optional. It specifies the contents of the return obje ct.
The return_type argument values are:
Constant Value Description
_IB_LIST 0
_IB_STRING 1 String input as it was typed in the text box
Return Values:
Depending on the return_type argument, this function returns either a CSL list object or the text typed in the text
box as it is.
If return_type = _IB_LIST (by default), the text in the text box is considered to be a set of list items divided by ','
(only hexadecimal, decimal and string items are currently supported).
For example, the text:
Hello world !!!, 12, Something, 0xAA, 10, "1221"
produces a CSL list object (5 items):
list = [ "Hello world !!!", 12, "Something", 0xAA, 10, "1221" ];
Note: Although the dialog box input text parser tries to determine a type of list item automatically, text enclosed
in quote signs " " is always considered to be a string.
Remark:
This function works only for VS Engines controlled via a GUI. For VSEs controlled by COM/Automation™ clients,
it does nothing.
This function "locks" the application, which means that there is no access to other application features until the
dialog box is closed. To prevent too many InputBox calls (in case a script is not written correctly), VSE keeps
track of all function calls demanding user interaction and does not show dialog boxes if some cu stomizable limit
is exceeded. (In that case, it returns a null object.)
Example:
…
if(Something)
{
…
v = InputBox("Enter the list", "Some stuff",
"Hello world !!!, 0x12AAA, Some, 34");
ReportText (FormatEx("input = %s, 0x%X, %s, %d", v[0],v[1],v[2],v[3]));
… # Go on…
Writes formatted data to a string. Format is used to control the way that arguments print out. The
format string may contain conversion specifications that affect the way in which the arguments in the
value string are returned. Format conversion characters, flag characters, and field width modifiers are
used to define the conversion specifications.
Format: FormatEx (format_string, argument_list)
Parameters:
format_string Format-control string
argument_list Optional list of arguments to fill in the format string
Return Values:
Formatted string
Format conversion characters:
Code Type Output
c Integer Character
d Integer Signed decimal integer
i Integer Signed decimal integer
o Integer Unsigned octal integer
u Integer Unsigned decimal integer
x Integer Unsigned hexadecimal integer, using "abcdef."
X Integer Unsigned hexadecimal integer, using "ABCDEF."
s String String
Page 100 of 107
Loading...
+ hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.