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.
Page 30 of 107
Loading...
+ 77 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.