MP IP Strategy public Stateye Training (Advanced) Manfred Dolag Alexander Weimann public Munich, January 19th, 2006

MP IP Strategy public Introduction The latest service release Stateye V is currently available from –Stateye V full installer package for Windows –Stateye V binaries and scripts for Windows (sufficient to run elaborated m files on Windows systems, but does neither contain CBF-Elaborator nor Smatrix-Helper) –Stateye V source and scripts for Unix (sufficient to create a Unix build and to run elaborated m files on Unix systems) –Stateye V documentation At the same location, a link to the recently published web front end WebLaborator is provided. This advanced training might rely on basic information provided in the Stateye Training (Getting Started) available for download from the above location, too. It is recommended that for 1 st time users that basic training be followed before dealing with this advanced training.

MP IP Strategy public Release Note Overview Stateye V offers the following additional features: Support for CEI-11G-LR Receiver B (new object type ) in Stateye algorithms, CBF-Elaborator and Smatrix-Helper Improved and considerably accelerated createwidth Bug fix in pdf calculation for a high number of xt aggressors New XML attribute “flipeye” in output – graphics – results (to set whether to generate a double contour eye if desired) New XML attribute “plot8x8” in output – graphics – results (to generate a separate graphic for each smatrix object containing the frequency response of each possible port relation (8x8)) Generation of indented m code within CBF-Elaborator Web frontend for Stateye V.4.0 CBF-Elaborator („WebLaborator“) yielding identical results as the Windows version; accessible by means of any web browser; intended for use by those who cannot install the Windows CBF- Elaborator

MP IP Strategy public Stateye Objects (Repetition)

MP IP Strategy public Stateye Objects (Repetition)

MP IP Strategy public Advanced Training - Overview The following slides will provide information on the basic XML structure of Stateye XML files along with a description of typical single objects. A complete description of all node types and all attributes can be found in the documentation which also specifies compulsory elements, permissible values, default values, and attribute inheritance. The default value for all non-compulsory boolean attributes is “false”, i.e. you don’t need to specify a boolean attribute at all if you would like to set it to “false”. Please note that the id attribute is compulsory for all objects which might be referenced later (transmitters, smatrices, channels, receivers, jitters, runs), and that all ids must be unique wthin the scope of the XML file (and possibly included other files).

MP IP Strategy public Basic CBF-XML Structure

MP IP Strategy public XML Root Element Each XML file requires exactly one single root element. For Stateye, this root element is the node: The root element follows the header immediately. It contains all other objects which are required in Stateye CBF-XML files. Here it is possible to specify the referenced XML namespaces. To start with, you only need to reference the XInclude namespace in case you want to make use of the inclusion feature for other XML files, see further below. However, it is suggested not to change any attributes of the node, rather using the settings above.

MP IP Strategy public The node is used to define basic settings. Typical attributes are shown below. basedirectory: directory to be used if a relative path is specified in any other filename or directory attribute within the file. scriptdirectory and bindirectory: if specified, these directories will be added to your MATLAB path at runtime of the generated m file to locate the MATLAB scripts and binaries. If not set, on a Windows system Stateye will try to locate the scripts and binaries in the default installation dirctory of the package. individualruns: –if set to "true", CBF-Elaborator will generate m code which is executable separately for each inividual run within a parameter sweep. All internal MATLAB variables will be regenerated for each individual run. –If set to "false", MATLAB will make use of already available variables as far as possible, resulting in lower memory consumption and considerably faster analysis. However, if an error occurs in a run, all subsequent runs might be affected, too. <settings basedirectory=".." scriptdirectory="/scripts" bindirectory="/bin" individualruns="true" diary="true" echo="true" clearall="true" tictoc="true" />

MP IP Strategy public The section has no attributes itself. It contains all Stateye objects (as XML sub-nodes) which might be referenced later: The transmitterlist contains all single transmitter objects referenced in a run. The smatrixlist contains all single smatrix objects referenced by resp. used for the definition of channel objects: The channellist contains all single channel objects referenced in a run. The receiverlist contains all single receiver objects referenced in a run. The jitterlist contains all single jitter objects referenced in a run.

MP IP Strategy public The definition of receiver and jitter objects is straightforward. See Stateye documentation for a full list of all attributes currently supported. For a better understanding, let us start dealing with jitter objects: As other Stateye CBF-XML objects, a jitter object is a XML node of its own, describing the parameters of the jitter by means of XML attributes. A jitter objects needs a unique id for later reference, as do transmitter, smatrix, channel, receiver and run objects. Jitter data can be calculated by MATLAB automatically at runtime, if description="template" is selected. Currently, template="gauss" is supported for gauss jitter. Furthermore it is possible to load an existing jitter file by setting description="file" and specifying the name of the file to be loaded (filename="…") <jitter id="CEI6GSR_Jit" description="template" template="gauss" dj="0.15" rj="0.15/(2*7.94)" />

MP IP Strategy public Let us now have a closer look at some sample receiver objects: The following attributes directly influence the calculation of the eye opening: –ber: target bit error rate –dfetaps: number of DFE taps to be taken into account and calculated –cdrenabled: consider CDR to calculate the position of the center of the eye if possible Futher attributes are used for the decision on standards compliance after successful calculation: –eye: required minimum eye opening for standards compliance –dj: required dj value for jitter compliance –q: required q value for jitter compliance –tj: required tj value for jitter compliance <receiver id="CEI6GSR_Rx" ber="1e-15" cdrenabled="true" dfetaps="0" eye="(62.5*2)/400" q="(2*7.94)" dj="0.30" tj="0.60" /> <receiver id="CEI6GLR_Rx" ber="1e-15" cdrenabled="false" dfetaps="5" eye="(50*2)/800" q="(2*7.94)" dj="0.325" tj="0.60" />

MP IP Strategy public (1) Please find some typical examples for transmitters without emphasis parameter optimization below: emphasis: The single parameters describe the emphasis values for an arbitrary number of pre- and postcursors along with the center, e.g.: emphasis="precursor2 precursor1 center postcursor1 postcursor2" Each of the precursor and postcursor parameters is sweepable with discrete values or with a range of values (see parameter sweeps below). The center emphasis value may be calculated automatically by means of setting it to “x” or “X”. In this case, the value will be calculated according to the rule that the sum of all absolute values of the parameters is 1, if possible. This is helpful when parameter sweeps are used for precursors or postcursors, as the center value depends on the actual values of all pre- and postcursors. Example: emphasis="0:-0.05:-0.1 x -0.1" will be converted to " " and " " and " ". <transmitter id="CEI11GSR_Tx" dcd="0.0" emphasis="1"/> <transmitter id="trans_sweep" dcd="0.05" emphasis="0:-0.05:-0.1 x -0.1" />

MP IP Strategy public (2) Sample transmitter objects with emphasis parameter optimization: optemphasis="true": Perform optimization of emphasis parameters when running an analysis If emphasis parameter optimization is activated, the following rules apply: Each precursor and each postcursor value must specify a range within which the optimization should be performed. The resolution of the optimization replaces the step-size of normal parameter range definition. The center cursor must always be denoted with “x” or “X” in order to define which values are precursors and which postcursors. Example: emphasis="x -0.25:0.025:0" optemphasis="true" will run an optimization with one postcursor coefficient to be optimized (valid range … 0.0, resolution 0.025). <transmitter id="CEI6GSR_Tx" dcd="0.0" emphasis="x :0.025:0" optemphasis="true" /> <transmitter id="CEI6GLR_Tx_post" dcd="0.0" emphasis="x -0.25:0.025:0" optemphasis="true" />

MP IP Strategy public (introduction) smatrix objects are used to describe various objects : –smatrix objects created by reading S-parameter files (typically 8x8, 4x4 or 2x2 Touchstone format) –filters and optfilters –cascades of other smatrix objects smatrix objects must comply with Stateye's target 8x8 S parameter matrix format. smatrix objects always consist of one or more components, the component format depends on the object type to be described. smatrix objects will never directly be referenced in an analysis run. They will rather be used for definition of channels later on, which in turn will be made use of in analysis runs.

MP IP Strategy public (target 8x8 description) The target 8x8 S parameter matrix format is based on a fixed port mapping (as already shown in the introduction slides above): Please note: it is particularly important to map any input file S parameter matrix ports correctly to the fixed target 8x8 description. This will allow handling all smatrix objects in the same way, e.g. with respect to cascading. You may use Stateye Smatrix-Helper for simple generation of the respective XML fragments, as shown in the basic training. It offers a little GUI for easy entry of port mappings. Smatrix-Helper is delivered with CBF-Elaborator as part of the installation package.

MP IP Strategy public (s8x8) A smatrix object used to read in a single 8x8 touchstone format file consists of exactly one component of format "s8x8": Use the attribute p for a correct mapping: –Mapping of the original eight input file ports (fixed sequence ) to the target description format ports (appropriate sequence to be entered here). E.g. p=” ” for a 1:1 mapping, see above. –I.e. enter the sequence of the target description ports as they are described by the input ports –It is required that all 8 ports be mapped explicitly, no port must be missing in the list. A 8x8 smatrix object will always contain a forward/through channel along with a crosstalk aggressor, which can be made use of for channel definition.

MP IP Strategy public (s4x4) A smatrix object used to read in 4x4 touchstone format files consists of one or two components of format "s4x4": Use attribute p once again in order to map the ports correctly. Each of your input files (forward channel and crosstalk aggressor file) will contain four ports, all of which need to be mapped: –Mapping of the original four input file ports (fixed sequence ) to the target description format ports (appropriate sequence to be entered here). E.g. p=” ” for a typical forward 4x4 file, p=" " for a typical crosstalk file. If only a forward channel file is defined, only the forward channel can be used for channel definition. If both a forward channel and a crosstalk file are read into a s4x4 smatrix object, both can be made use of for channel definition later. If you would like to define multiple crosstalk aggressors, please define one s4x4 smatrix object for each aggressor, using the same forward channel again and again. You can reference the crosstalk aggressors contained in these multiple smatrix objects when setting up channel objecs later.

MP IP Strategy public (s2x2) A smatrix object used to read in 2x2 touchstone format files consists of several components of format "s2x2": Once again, use the p attribute for a correct port mapping. Please make sure to use a sufficient number of files containing the appropriate ports in order to have a full through channel definition (and crosstalk channel, if desired) available. forward definition crosstalk definition

MP IP Strategy public (filter&optfilter) Filters and optfilters are defined as smatrix objects, too: Filters are smatrix objects of componentformat "filter" with exactly one component. Such a object defines an 'n' pole, 'm' zero time continuous filter, where the pole/zeros positions are specified by the attributes “poles” and “zeros”. The return loss for given ports can be specified by a simple single ended model of a parallel R/C combination. Optfilters are smatrix objects of componentformat "optfilter" with exactly one component. Such an object defines an 'n' pole/zero time continuous filter, where the pole/zero positions are square error fitted to a given Sdd21, defined by an id of an existing smatrix object, at given frequency points defined by the attribute “targetfreq”. As multiple solutions exist for this optimization, a simple random walk algorithm is used from a given initially zero split pole/zero position defined by the attribute “optinitfreq”. As for filter objects, a return loss can be defined through a simple parallel R/C combination. <filter f="0:(6.375e9/2*3)/1000:(6.375e9/2*3)" r="40" c="620e-15" poles="(0.75*6.375e9)" zeros="" /> <filter f="0:(6.375e9/2*3)/1000:(6.375e9/2*3)" r="40" c="620e-15" poles="" zeros="" /> <optfilter f="0:(11.1e9/2*3)/1000:(11.1e9/2*3)" r="40" c="360e-15" targetfreq="11.1e9/ e9/ e9/ e9/ e9/5 11.1e9/3 11.1e9/2" optinitfreq="11.1e9/ e9/ e9/3" sdd21="[must be completed]" />

MP IP Strategy public (cascade) smatrix objects which keep to the target 8x8 description can be cascaded with each other resulting in a new smatrix object describing the cascade: Clearly, the smatrix objects referenced in a cascade must be defined within, too. The resulting cascade is a smatrix object itself and can be handled as such, e.g. be referenced later on for channel definitions, as usual. <filter f="0:(6.375e9/2*3)/1000:(6.375e9/2*3)" r="40" c="620e-15" poles="(0.75*6.375e9)" zeros="" /> <filter f="0:(6.375e9/2*3)/1000:(6.375e9/2*3)" r="40" c="620e-15" poles="" zeros="" /> <smatrix id="cascade1" componentformat="cascade" referencefrequency="matrix8x8">

MP IP Strategy public (Introduction) Let us now proceed to the definition of channel objects. Such channel objects will be used when running a Stateye analysis later on. Channel objects consist of several subnodes named. Exactly one subnode describes the forwad/through channel. Additional subnodes may describe any crosstalk aggressor to be taken into consideration. There are basically two ways to define forward channel and crosstalk: If your input data is available as frequency domain representation in S parameter files (Touchstone format), the files will be loaded into Stateye smatrix objects as shown before. These smatrix objects will then be referenced for the channel description. The same applies for Time Domain S- Parameter Step Response files, see documentation for details. Time domain differential step response files for forward and crosstalk channels (typical extension “.tim”) can be used, too. These files can be directly read in into channel objects (but they cannot be used for the description of smatrix objects). The following slides will show both the approaches.

MP IP Strategy public (referencing smatrix objects) A typical channel definition using smatrix objects (e.g. created from Touchstone files, or cascades) references the appropriate smatrix objects within the subnodes:: For each characteristic subnode, there needs to be specified the type (forward or crosstalk), the description ("smatrix" in the example) and the referenced smatrix object id. As you can see, various smatrix objects can be referenced, e.g. for using several crosstalk aggressors. The attributes of the node shown above are used to define the number of ports and the port mapping. In case that all smatrix objects do comply with Stateye's target 8x8 description, you may always use the above settings. These attributes are indeed attributes, but for simplicity you can specify them in a parent node (e.g. ) to propagate them automatically to all children (this inheritance of attributes will be explained later). Note: you may also use Smatrix-Helper again for easy channel definition which it creates automatically along with the smatrix XML fragments. <channellist noports="8" txp_fwd="1" txn_fwd="2" txp_xt="3" txn_xt="4" rxp="5" rxn="6">

MP IP Strategy public (using.tim files) Here is an example of a channel which is defined using.tim files: Once again, for each characteristic subnode, there needs to be specified the type (forward or crosstalk), and the description ("pulsefile" in case you would like to read in.tim files). Furthermore, the filename of the file to be used must be specified (instead of a smatrix object reference as shown before). We use the standard/default port definition again which we do not need to enter again and again for each node, if we make use of inheritance from. <channellist noports="8" txp_fwd="1" txn_fwd="2" txp_xt="3" txn_xt="4" rxp="5" rxn="6">

MP IP Strategy public (Summary) At this stage, all necessary objects should have been defined in the section of the XML file. These objects may now be used (referenced) in order to set up one or more Stateye analysis runs. Please note: you may define more objects in the definitions section than you actually need for a specific analysis, e.g. if you want to compose a template file of your own. However, all defined objects must be defined correctly and must be valid as explained before, even if they are not used in a specific run. Otherwise CBF-Elaborator will display appropriate error messages and not finish elaboration, as all objects are checked for valid syntax when the XML file is parsed.

MP IP Strategy public (1) The analysis section of the XML file contains single nodes describing the specific parameters to be considered when performing a Stateye analysis. Typical analysis runs are defined as follows: You may define several runs, all of which will be considered: The resulting m file will contain the code for all runs defined here. The run ids need to be unique as they will be used for the directory structure to store the results of the run. Results will be stored with a time stamp as part of the filename so that you do not overwrite older results when executing the same m file containing the same run(s) again. A common result list will be generated containing all results of each specific run as an overview in the respective (parent) directories. <run id="CEI6GLR_Template_pre" baudrate="6.375e9" bins="4000" jitter="CEI6GLR_Jit" postcursors="90" precursors="4" width="60"> <composition transmitter="CEI6GLR_Tx_pre" channel="ch_filter_mx" receiver="CEI6GLR_Rx" /> <run id="CEI6GLR_Template_post" baudrate="6.375e9" bins="4000" jitter="CEI6GLR_Jit" postcursors="90" precursors="4" width="60"> <composition transmitter="CEI6GLR_Tx_post" channel="ch_filter_mx" receiver="CEI6GLR_Rx" />

MP IP Strategy public (2) Let us have a look at some more details: The node itself has additional attributes specifying the parameters of the specific analysis, see documentation. The jitter attribute can only reference ids of jitter objects defined in the. Furthermore, each run must contain a subnode which describes the specific transmitter, channel and receiver objects to be taken into account. All three attributes must be defined and must reference appropriate object ids out of the, and respectively. <run id="CEI6GLR_Template_pre" baudrate="6.375e9" bins="4000" jitter="CEI6GLR_Jit" postcursors="90" precursors="4" width="60"> <composition transmitter="CEI6GLR_Tx_pre" channel="ch_filter_mx" receiver="CEI6GLR_Rx" />

MP IP Strategy public (3) A helpful feature is parameter sweeping, which will be dealt with in a few moments. For our example, this means: <run id="CEI6GLR_Template_pre" baudrate="6.375e9" bins="4000" jitter="CEI6GLR_Jit" postcursors="90" precursors="4" width="60"> <composition transmitter="CEI6GLR_Tx_pre" channel="ch_filter_mx" receiver="CEI6GLR_Rx" /> <run id="CEI6GLR_Template_post" baudrate="6.375e9" bins="4000" jitter="CEI6GLR_Jit" postcursors="90" precursors="4" width="60"> <composition transmitter="CEI6GLR_Tx_post" channel="ch_filter_mx" receiver="CEI6GLR_Rx" /> … is identical with … <run id="CEI6GLR_Template" baudrate="6.375e9" bins="4000" jitter="CEI6GLR_Jit" postcursors="90" precursors="4" width="60"> <composition transmitter="CEI6GLR_Tx_pre;CEI6GLR_Tx_post" channel="ch_filter_mx" receiver="CEI6GLR_Rx" /> CBF-Elaborator will create two runs with internally unique ids derived from the original run id, each of them considering the first referenced transmitter object and the second one respectively.

MP IP Strategy public Finally the section is to be dealt with: All settings defined in the output section will influence the way the results are presented, but they will not influence the analysis calculations. The settings will be applied to the output of all runs contained in the section of the XML file. Within the node itself you may set an output directory for saving results, if any are to be stored. For each run, a subdirectory named after the run id will be created. The subnode specifies format and output options for all non-graphical results. E.g. format="csv" will produce a semicolon(!) separated values file for easy import into spreadsheet applications. The subnode specifies format and output options for generated graphics, e.g. which graphics are to be generated at all. You can also see the new option flipeye="true" to generate a double contour eye, if desired. <graphics format="fig" save="true" show="false" ampcdf="" bathtub="true" charfreqdomain="true" chartimedomain="true" eye="true" flipeye="true" />

MP IP Strategy public XML Structure (Summary) We have now talked about all relevant XML objects. For simplicity, we have not shown each single attribute. Please refer for the documentation (PDF) for further details. There are some more specific features which are helpful when setting up Stateye CBF-XML files, which we would like to present on the following slides: –Parameter sweeps –Inheritance/propagation of attributes –Inclusion of external XML files and of their fragments –XML comments –Displaying XML data in various ways –Using the web frontend "WebLaborator"

MP IP Strategy public Parameter Sweeps Some object attributes can be handled as parameter sweeps, e.g. you can set the baudrate to a set of discrete values or to a range in order to have the elaborator automatically generate separate analyses for each value. Attributes which support sweeping are marked correspondingly in the documentation. –As a general rule, no sweeps are permissible within smatrixlist and channellist. –Some attributes allow parameter sweeps with both discrete values and a range. A range definition is only possible for numerical values, e.g. baudrate. –Some other attributes only support parameter sweeps with discrete values, e.g. object references. –Discrete values are specified using the following syntax (values separated by semicolons): attribute="param1;param2;param3;param4" This will lead to the generation of 4 different analysis runs using each of the specified values separately. –Parameter ranges are defined as follows (values separated by colons): attribute="numericstartvalue:numericstep:numericendvalue" An appropriate number of analysis runs will be generated covering the full parameter range with each specific value handled separately. –Multiple nested sweeps are permissible, too. For example, several transmitters could be analyzed over a range of baudrates.

MP IP Strategy public Inheritable Attributes Some attributes of Stateye XML nodes can be inherited from parent nodes. This means that typical attributes need to be set only once in an appropriate parent node (object) instead of defining them in each single node. When a XML node is parsed by CBF-Elaborator, the attributes explicitly defined within the node always have priority over the attributes defined in a parent node. If an attribute is inheritable and not set in the object itself, the parser will try to read the appropriate attribute from the parent node, if available. In some cases, attributes can even be inherited from grand- parents.

MP IP Strategy public XML Inclusion (1) CBF-Elaborator supports inclusion of other XML files or of their fragments within an XML file. This allows to reuse object definitions contained in other files, e.g. template files. This procedure had been already used in the basic training. The inclusion syntax is:, where the href attribute specifies the path and filename of the file to be included. For the web frontend "WebLaborator" you may only include files located within the same directory! In the including XML file, a reference to the namespace xmlns:xi=" needs to be set. This should be done in the root element (see above). Multiple files can be included. Recursive inclusion (inclusion of XML files within an included XML file) is permissible, too. The XML code of the XML file to be included must be a valid XML fragment within the context of the including file exactly at the location where the inclusion file is referenced. The XML file to be included must be valid XML code itself.

MP IP Strategy public XML Inclusion (2) Let us have a look at a fragment of the template file "OIF_analysis.xml" which makes use of XML inclusion: Each of the included files is a valid XML file itself and contains a fragment of CBF-XML code which fits in the place where it is included. The included files don't need to be no complete CBF files, e.g. if they contain only a. <settings basedirectory=".." clearall="true" diary="true" echo="true" individualruns="true" longvarnames="false" tictoc="true" /> <run baudrate="11.1e9" bins="4000" id="CEI11GMR_Template" jitter="CEI11GLR_Jit" postcursors="90" precursors="4" width="60"> <graphics format="fig" save="true" show="false" ampcdf="" bathtub="true charfreqdomain="true" chartimedomain="true" eye="true" plot8x8="false" />

MP IP Strategy public XML Inclusion (3) The previous example used the inclusion of complete files. Furthermore, you can include fragments of XML files, too, using xpointer an xpath notation. Let's create a file which re-uses the settings, definitions, and output sections of OIF_analysis.XML, includes a specific run with id="CEI11GMR_Template" and adds a new run: <run baudrate="11.1e9" bins="4000" id="CEI11GMR_version2" jitter="" postcursors="90" precursors="4" width="60"> Using this notation you can specify exactly which fragments (nodes) of an XML file to include. It is possible to set various selection conditions. Please refer to relevant websites for additional help (see links provided in the documentation). Here we also see recursive inclusion, as the included file includes other files itself. Clearly, all referenced files must be available when elaborating the including CBF-XML file.

MP IP Strategy public XML Comments You can add comments to your XML files for better understanding and you can comment out XML fragments (e.g. objects which are temporarily not needed). Some XML editors allow commenting out and uncommenting of XML blocks by means of a single mouse click. Comments will not be parsed by CBF-Elaborator. Please use the following XML syntax for comments: <run baudrate="11.1e9" bins="4000" id="CEI11GSR_Template" jitter="CEI11GSR_Jit" postcursors="90" precursors="4" width="60"> <!--<run baudrate="11.1e9" bins="4000" id="CEI11GLR_DFE_Template" jitter="CEI11GLR_Jit" postcursors="90" precursors="4" width="60"> <run baudrate="11.1e9" bins="4000" id="CEI11GLR_TC_Template" jitter="CEI11GLR_Jit" postcursors="90" precursors="4" width="60"> --> The example shows how to comment out objects which are not needed for a specific configuration. Using comments, you don't need to delete the XML code from the file, so you can reactivate it later on very quickly.

MP IP Strategy public Displaying XML Data Up to now, we have dealt with a plain text representation of XML data which is useful for a good understanding and for explicit adjustment of attributes etc. As soon as the XML structure is more stable in a future release, we will provide a XML schema definition which allows more intelligent syntax parsing and even intellisense, if supported by the editor. Some editors additionally offer other representations, see screenshots. XML data can be re-used in a very flexible way, e.g. stored to databases. Please be aware that some editors do not support Xinclude syntax for graphical views.

MP IP Strategy public CBF-Elaborator Valid Stateye CBF-XML files as described above must finally be elaborated, i.e. converted into executable MATLAB m files, as already explained in the basic training. On a Windows system with Stateye V4.0 installation package installed, start CBF-Elaborator. Then open a file, which will be elaborated upon opening automatically. After sccessful elaboration, you may save the generated m code to disk. There are several options/settings for elaboration, e.g.: –Batch mode elaboration of multiple files –Switching warning messages on and off –Save settings –Elaborate CBF-XML files with extension ".cbf" by just doubleclicking them.

MP IP Strategy public Web Frontend For those users who cannot install the Windows version of Stateye V.4.0 we have published a web frontend to the CBF-Elaborator ("WebLaborator") which can be accessed by means of any browser from any computer with internet access, please see the link at The usage is very easy: –just upload all the XML files necessary for elaboration –then elaborate one or all of the uploaded files by clicking a button –all successfully generated m files will be offered for download to the local computer after elaboration. Please see a more detailed description on the web page. WebLaborator uses the same codebase for elaboration as the Windows version, it is fully compatible. The website will always support the latest officially released version.

MP IP Strategy public Advanced Training - Summary You will find a lot more details in the documentation Don't hesitate to contact the support which is available via Many thanks for your attention