This document contains a description of the CATC’s Verification Script Engine (VSE) – a new
feature in the IBTracer software that allows users to create custom tests on Infiniband(IB) traffic,
recorded on CATC’s Infiniband protocol analyzers.
The VSE conveniently allows users to ask the IBTracer application to send some of desired
“events” ( packets and some predefined notifications ) that occurred in the recorded IB trace to a
special verification script written using CATC script language. The script then evaluates the sequence
of events (timing, data or both) in accordance with user-defined conditions.
Using the VSE API, users can easily retrieve information about any field in IB packet headers,
Link packets and MADs, make very complex timing calculations between different events in recorded
trace, filter data in or out of the trace with dynamically changing filtering conditions, and display all
interesting information in the special output window.
2. Verification Script Structure.
A varification script file should have extension *.dec, and be located in the subfolder
..\Scripts\VFScripts of the main IBTracer folder. Some other files might be included in the main script
file using directive %include. (see CATC Script Language (CSL) manual for details)
The following schema can present the common structure of verification script:
############################################################################################
#Module info
#
############################################################################################
#Filling of this block is necessary for proper verification script operation...
#
############################################################################################
set ModuleType= "Verification Script";# Should be set for all verification scripts
set OutputType= "VS";# Should be set for all verification scripts
set InputType= "VS";# Should be set for all verification scripts
set DecoderType = "<Your VScript name>";# Should be set for all verification scripts
set DecoderDesc = "<Your Verification Script description>"; # Optional
######################################################################################
# Specify in the body of this function initial values for global variables#
# and what kind of packets or trace events should be passed to the script.#
# ( By default, only MAD packets and Link state change events from both channels#
#will be passed to the script.#
##
#For details – how to specify what kind of events should be passed to the script#
#please see the topic ‘sending functions’.#
##
#OPTIONAL.#
######################################################################################
# Uncomment the line below - if you want to disable output from
# ReportText()-functions.
#
# DisableOutput();
######################################################################################
# It is a main script function called by the application when the next waited event#
# occured in the evaluated trace.#
##
# !!! REQUIRED !!! – MUST BE IMPLEMENTED IN VERIFICATION SCRIPT#
######################################################################################
##
ProcessData()
{
#
# The function below will show specified message only one time # no matter how many times ProcessData is called.
#
ShowStartPrompt("ShowStartPrompt\n");
# Write the body of this function depending on your needs …
######################################################################################
# It is a main script function called by the application when the script completed#
# running. Specify in this function some resetting procedures for a successive run#
# of this script.#
##
#OPTIONAL.#
######################################################################################
3. Interaction between IBTracer and verification script
The following describes how IBTracer interacts with a verification script to test an open trace:
1. When a verification script is run, VSE looks for the function OnStartScript() and calls it if it is
found. In the OnStartScript() function, setup routines can be created that can perform tasks such
as specifying what kind of trace events should be passed to the script, and setting up initial
values of global script-specific global variables.
2. VSE then goes through the recorded trace and checks if the current packet in the trace meets
specified sending criteria – if the criteria are met, VSE calls the script’s main processing
function ProcessData() and provides input context variables to the script about the current
event. (Please refer to the topic “Input context variables” below in this document for full
description of verification script input context variables )
3. The ProcessData() function, which is present in all verification scripts, then processes whatever
event has been sent to the script and verifies that the information in the event is appropriate for
the current stage of the verification process. At the completion of each stage, the ProcessData()
function determines if VSE should continue running the script or not. If the result for any given
stage of the script is clear, the script tells VSE to complete execution of the script.
The decision to terminate the test prior to evaluating the entire trace is controlled by the
output context variable: out.Result = _VERIFICATION_PASSED or
_VERIFICATION_FAILED.
(Please refer to the topic “Output context variables” below in this document for full description
of verification script output context variables)
4. 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 describes the interaction between the IBTracer application and the running
verification script:
NOTE: Verification script result : <DONE> means that the script is intended solely for
extracting and displaying some information from recorded traces and that the user does not
care about the result . To specify that your script is intented only for the purposes of
displaying information, call somewhere in your script ( in OnStartScript() – for instance )
function ScriptForDisplayOnly() )
Edit script – allows you to edit selected scripts using whatever editor application has been
specified in ‘Editor settings’.
New script – creates a new script file using the template specified in ‘Editor settings’.
-
Editor settings – allows to specify some settings for editing scripts and creating new ones.
-
4.2Editor settings.
After choosing ‘Editor settings’ the following dialog will appear:
This option (if set) allows editor
applications supporting multi-document
interface (MDI) to edit all script 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 : *.dec )
Otherwise, only main verification script
files will be open for editing.
Launches editor application in
full screen mode.
Full path to the file to be used
as a template for a new script.
5. Verification Script Engine Input Context members
All verification scripts have input contexts –special structures whose members are set by the script
and can be used inside of the application. ( For more details about input contexts – please refer to the
CATC Script Language(CSL) Manual ). The verification script input contexts have two sets of
members:
This set of members is defined and can be used for any event passed to script:
in.Time - time of the event( type : list, having format : 2 sec 125 ns -> [2 , 125])
in.Channel - channel where the event occured. ( can be _CHANNEL_LEFT or _CHANNEL_RIGHT
indicating on which channel event occurred )
in.TraceEvent - type of trace events( application predefined constants are used. See list of possible
events below )
5.2Trace event-dependent set of members.
This set of members is defined and can be used only for a specific events or after calling some
functions filling out some of variables:
5.2.1 All packet-specific set of members.
( valid for any packets - but only after RetrievePktPayload()-function was called – see description of
this function for details )
in.Payload - bit source of the packet payload ( you can extract any necessary
information using GetNBits(), NextNBits() or PeekNBits() functions – please refer to CSL Manual for
details about these functions )
in.PayloadLength - the length( in bytes of the retrieved packet payload )
5.2.2 Link packet-specific set of members.
(valid for link packets only, undefined for other events )
in.Opcode
in.VL
in.FCCL
in.FCTBS
in.LPCRC
5.2.3 Link state change notification-specific set of members.
(valid for Link State Change notifications only, undefined for other events )
6. Verification Script Engine Output Context members
All verification scripts have output contexts –special structures whose members are set by the
script and can be used inside of the application ( For more details about output contexts – please refer
to the CATC Script Language(CSL) Manual ). The verification script output contexts have only one
member:
out.Result - the result of the whole verification program defined in the verification script.
This member is supposed to have 3 values:
_VERIFICATION_PROGRESS,( is set by default when script starts running )
_VERIFICATION_PASSED,
_VERIFICATION_FAILED
The last two values should be set if you decide that recorded trace does ( or not ) satisfy the
imposed verification conditions. In both cases the verification script will stop running.
If you don't specify any of those values - the result of script execution will be set as
VERIFICATION_FAILED at exit.
7. Verification Script Engine events
VSE defines a large group of trace “events” – packets or special notifications – that can be
passed to a verification script for evaluation or retrieving and displaying some contained information.
The information about the type of event can be seen in in.TraceEvent. Please refer to the topic
“Sending functions” in this manual for details about how to send events to scripts.
7.1Packet events.
The table below shows current list of packet events and value of in.TraceEvent:
VSE defines a group of notification events that can be passed to a verification script for
evaluation or for retrieving and displaying some contained information. The information about the type
of event can be seen in in.TraceEvent. Please refer to the topic “Sending functions” in this manual for
details about how to send events in scripts. The notification events are not the same as packets – they
basically indicate that something changed in current stream of evaluated data.
The table below shows current list of packet events and value of in.TraceEvent:
Notification event in.TraceEvent
Physical link woke up from silence _EVNT_CONNECT
Physical link came to silence (no physical signal) _EVNT_DISCONNECT
Changing of Opcode in series of link packets _EVNT_LINKSTATE_CHANGE
8. Sending functions
This topic contains information about the special group of VSE functions designed to specify
what kind of event verification script expects to receive.
8.1SendChannel()
This function specifies that events occurred only on specified channel should be sent to script.
Format : SendChannel( channel )
Parameters:
_CHANNEL_RIGHT – send events only from right channel
_CHANNEL_BOTH – send events from both channels
Example:
SendChannel( _CHANNEL_LEFT ); # - send events from left channel
channel – This parameter can be one of following values:
_CHANNEL_LEFT – send events only from left channel
This function specifies what kind of events should be sent to script.
Format : SendEvent( event )
Parameters:
event – This parameter can be combination of the following values:
eventvalueDescription
_PKT_TS1 TS1
_PKT_TS2 TS2
_PKT_LINK Link Packet
_PKT_MAD MAD packets
_PKT_RC Reliable Connection packets
_PKT_RD Reliable Datagram packets
_PKT_UC Unreliable Connection packets
_PKT_UD Unreliable Datagram packets
_PKT_SKIPS Skips
_EVNT_CONNECT Physical link woke up from silence
_EVNT_DISCONNECT Physical link came to silence (no physical signal)
_EVNT_LINKSTATE_CHANGE Changing of Opcode in series of link packets
Some special values can be used covering large groups of events:
_ALL_PACKETS All possible packets
_ALL_EVENTS All possible notification events
_ALL All possible packets and notification events
Example:
SendEvent( _PKT_LINK ); # - send link packets
SendEvent( _PKT_LINK | _PKT_MAD ); # - send link packets and MADs
SendEvent(_ALL_PACKETS | _EVNT_DISCONNECT );
# - send all possible packets and Disconnect notification
This function specifies more precise tuning for sending link packets.
Format : SendLinkPkt( opcode = _ALL, vl = _ALL )
Parameters:
opcode – This parameter specifies that only link packets with this Opcode will be sent
( _ALL – means that link packets with all opcodes will be sent )
vl – This parameter specifies that only link packets with this VL will be sent
( _ALL – means that link packets with for all VLs will be sent )
Example:
SendLinkPkt(); # - send all link packets – equal to SendEvent( _PKT_LINK );
SendLinkPkt( 0x1 ); # - send all link packets with Opcode = 0x1 SendLinkPkt( 0x1 , 0x7 ); # - send all link packets with Opcode = 0x1 and VL = 0x7 SendLinkPkt( _ALL, 0x7 ); # - send all link packets with VL = 0x7
8.4SendMAD ()
This function specifies more precise tuning for MAD packets.
Format : SendMAD( mgmtclass = _ALL,
attrId= _ALL,
method= _ALL,
field_name = “” , # means no care about field_name
field_value =0)
Parameters:
mgmtclass – This parameter specifies that only MADs with this management class will be sent
( _ALL – means that MADs with all management classes will be sent )
attrId – This parameter specifies that only MADs having AttributeId equal to attrId will be
sent
( _ALL – means that MADs with any AttributeIds will be sent )
method – This parameter specifies that only MADs having Method equal to method will be
sent
( _ALL – means that MADs with any Method will be sent )
field_name – This parameter specifies that only MADs having a field with field_name (how it is
This group of functions covers VSE capability to work with timers -an internal routines that
repeatedly measures a timing intervals between different events.
9.1VSE time object
A VSE time object – is a special object that presents time intervals in verification scripts.
From point of view of CSL - the verification script time object is a “list”-object of two elements :
( Please see CSL Manual for more details about CSL types )
[seconds, nanoseconds]
NOTE: The best way to construct VSE time object is to use Time() function (see
below )
9.2SetTimer()
Format : SendTimer( timer_id =0)
Parameters:
Example:
SetTimer(23); # - start timing for timer with id = 23;
Remark :
If this function is called second time for the same timer id – it resets timer and starts timing
calculation again from the point where it was called.
9.3KillTimer()
Format : KillTimer( timer_id =0)
Parameters:
.
Starts timing calculation from the event where this function was called.
timer_id – a unique timer identifier.
SetTimer(); # - start timing for timer with id = 0;
Stops timing calculation for a specific timer and frees related resources.
Disables showing information in the output window.
Format : DisableOutput ()
Example:
DisableOutput ();
15. Common Retrieving functions
This group of functions covers VSE capability to retrieve information from the recorded trace.
15.1 RetrievePktPayload()
Retrieves the packet payload inside the script and makes valid two input context members :
in.Payload - the bit source of the packet payload and
in.PayloadLength - the length(in bytes of the retrieved packet payload)
Format : RetrievePktPayload ()
Example:
RetrievePktPayload ( ); # actualize input context packet payload related members
val = GetNBits( in.Payload, 128, 8 ); # retrieve one byte from packet payload starting
Before calling this function - in.Payload and in.PayloadLength are empty but some other
retrieving functions can be used to receive all information about fields in link packets, packet headers
and MAD decoded fields.
15.2 IsMad()
Verifies that current event is MAD
Format : IsMad()
Example:
if( IsMad() ) DoSomething();
16. Packet Header retrieving functions
This group of functions covers VSE capability to extract information about IB packet header fields.
If the header is not present in the packet – all of those functions will return null-value ( see CSL
Manual –for details about null-value ).
16.1 GetLRHField()
Extracts information about LRH header field
Format : GetLRHField ( lrh_fld )
Parameters:
lrh_fld - LRH field identifier that can be one of the following values:
Identifier Meaning
_VL
_LVER
_SL
_DLID
_SLID
_PLEN
_LNH
Virtual Lane
Link version
Service Level
Destination LID
Source LID
Packet length
Link next header field
Specifies that the script is designed for displaying information only and that its author doesn’t
care about verification script result. Such a script will have a result <DONE> after execution.
Format : ScriptForDisplayOnly ()
Example:
ScriptForDisplayOnly();
18.2 Sleep()
Asks VSE not to send any events to a script until the timestamp of the next event is greater than
timestamp of current event plus sleeping time.
Format : Sleep( time )
Parameters:
time - VSE time object specifying sleep time
Example:
Sleep ( Time(1000) ); # Don’t send any event occurred during 1 microsecond from the current
event
NOTE : Some other useful miscellaneous functions can be found in the
file : VSTools.inc
19. The VSE important script files
The VSE working files are located in ..\Scripts\VFScripts subfolder of the main IBTracer
folder. The current version of VSE includes following files:
main VSE file containing definitions of VSE script functions
file containing definitions of some important VSE global constants
template file for new verification scripts with detailed comments
template file for new verification scripts with just a few comments
file of user global variables and constants definitions
Call for technical support… US and Canada: 1 (800) 909-2282
Fax your questions… Worldwide: 1 (408) 727-6622
Write a letter … Computer Access Technology
Send e-mail…support@CATC.com
Visit CATC’s web site…http://www.CATC.com/
CONTRACT
Worldwide: 1 (408) 727-6600
Corporation
Customer Support
2403 Walsh Avenue
Santa Clara, CA 95051-1302
Warranty and License
Computer Access Technology Corporation (hereafter CATC) warrants this
product to be free from defects in material, content, and workmanship, and
agrees to repair or replace any part of the enclosed unit that proves defective
under these terms and conditions. Parts and labor are warranted for one year
from the date of first purchase.
The CATC software is licensed for use on a single personal computer. The
software may be copied for backup purposes only.
This warranty covers all defects in material or workmanship. It does not cover accidents, misuse,
neglect, unauthorized product modification, or acts of nature. Except as expressly provided above,
CATC makes no warranties or conditions, express, implied, or statutory, including without limitation
the implied warranties of merchantability and fitness for a particular purpose.
CATC shall not be liable for damage to other property caused by any defects in this product,
damages based upon inconvenience, loss of use of the product, loss of time or data, commercial loss, or
any other damages, whether special, incidental, consequential, or otherwise, whether under theory of
contract, tort (including negligence), indemnity, product liability, or otherwise. In no event shall
CATC's liability exceed the total amount paid to CATC for this product.
CATC reserves the right to revise these specifications without notice or penalty.
Page 35 of 35
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.