ࡱ> 5@ 08qbjbj22 "XXfYR(pFpFpF8FTF(jGG(GGGHHHGjIjIjIjIjIjIj$xlRndmjmIHHmImImjGGjbbbmIHGGGjbmIGjbFbc:h,hGG 0,76zpFYKh Gjj0jUhR.o]a .oh((.ohHHbH HHHHmjmj((< Cdib(( CProposed Statefile Syntax Statefiles store setup information for all the tools that run in the CDP environment. The huge variety of tools and setups means we need a very general, yet simple way to save this information. The basic requirements are: Statefiles must provide a complete setup of all tools. Statefiles must be kept in a single location to ensure portability of testcases and archives. Statefiles must be easily readable, so that users can quickly locate any property they need to change in a script. Syntax to set parameters in a script should be the same. This last requirement needs some explanation. Currently most statefiles are not readable. In fact, some are not even text files. Even those that are text files are so complex that the average user will never figure them out. This leads to a scripting language that is every bit as complex as the statefiles, with dozens of intricate commands to change various setup parameters in different tools. Even with all these commands, we have access to only a small fraction of the needed setup parameters. What if we could make the scripting language change setup parameters directly via the statefiles. That would give us complete control over every setting of every tool. Statefiles must be complete or we will never have repeatability. It should not be necessary to repeat this effort in an attempt to make a complete scripting language. If instead, we make changes via statefiles that have a sensible format, then there is no need for huge volumes of documentation on the scripting language. The statefiles can be self-documenting. Users can read those files, and copy settings directly into a script. The basic scripting commands to run any tool should be: load one or more statefiles, change whatever parameters you want, and initiate the run. With these three commands, and a complete set of statefiles, we can do anything. Actually, we can do anything with just two commands, but the command to change individual statefile parameters will be a great convenience. Design variables, for example, could be changed by loading a new statefile, but this may be cumbersome if we are changing one variable repeatedly. A general purpose setparam command will be handy. loadstate ( , , ... ) # default is all files setparam ( , , ... ) run ( ) Note: section is optional, and can be a hierarchical name, e.g. setparam (wavescan.template7, window1.subwindow2.xaxis.label.font.size 12 ) The details of this long hierarchical name are easily discovered by running the tool interactively, saving the statefile, then looking at the hierarchical set of properties listed in the saved file. This is far easier than searching through manuals, hoping to find a special command to change the size of a label on a graph. In this proposal we offer two alternative statefile syntaxes to satisfy the basic requirements above. One other requirement is that we follow existing standards to the extent that we can without sacrificing our primary requirements. For example, in the syntax for quoted strings, we follow the conventions of Python, a modern scripting language that has made great efforts to define such things in a simple and versatile way. A side benefit is that we can use the Python string processing functions, and all the dirty details, such as escaped quotes within a quoted string, are taken care of. Another alternative is to simply use XML. This is a well-established standard, with routines already available to read and write XML files, verify their syntax, etc. The problem with XML is readability and usability in a script. See Appendix A for a realistic example. Syntax Proposal 1 Filename is the name of the setup to be loaded. For the example above, the filename would be wavescan. The file is a simple text file with a section for each subsetup. Subsetups in a file are optional. The simplest statefile may have nothing but parameters and values. Again, using the example above, SubSetup1 could be window1. SubSetup1 { # This is an illustration of statefile syntax. | param1 value1; param2 value2; param3 value3 | param4 { | . param4a value4a | . param4b { | . . param4b1 value4b1 ... | . . param4bN value4bN | . . paramX valX, paramY valY, paramZ valZ | . } | } | param5 + [ listitem1, listitem2, listitem3, + listitem 4 has embedded blanks, + listitem5 ] | param6 value6 } SubSetup2 ... SubSetupN Notes 1) No data type declarations are needed. The tool that reads each statefile already knows what to expect for each parameter. 2) Leading . (dot whitespace) or | (pipe whitespace) sequences are ignored. These are for readability only, and are very handy in statefiles that have deeply indented hierarchies running over a page boundary. 3) Column one + (plus whitespace) indicates a continuation of the previous line. Lines can also be continued with a \ at the end of the first part. 4) A single parameter can contain a list of values. List items are enclosed in [] and separated by commas. 5) param = value is also a valid syntax. Some users prefer an equal sign with numeric values. 6) # comments out remainder of any line. 7) ; has the same effect as end-of-line. 8) , separates multiple parameters with same prefix. 9) (double quote) or (single quote) must be used when a string value has characters that would otherwise terminate the string. 10) Blank lines are ignored. Syntax Proposal 2 Same as Proposal 1, but let the dots be significant. This follows the Python philosophy of making good formatting a syntactical requirement. Cleaner and more compact. Not so many { }. SubSetup1 { # This is an illustration of statefile syntax. param1 value1; param2 value2; param3 value3 param4 . param4a value4a . param4b . . param4b1 value4b1 ... . . param4bN value4bN . . paramX valX, paramY valY, paramZ valZ param5 + [ listitem1, listitem2, listitem3, + listitem 4 has embedded blanks, + listitem5 ] param6 value6 }### end SubSetup1 SubSetup2 ... SubSetupN Notes 1) { } are used only to delimit optional sub-setups. 2) Hierarchical parameters can be abbreviated with leading . (dot whitespace). In the example above, the value of param4.param4b.param4b1 is value4b1 . 3) Positioning of the leading dots is not enforced by the statefile reader, but we highly recommend putting them in the same columns as the parameters that they spot. Some allowed variations param4 . param4a value4a . param4b value4b # mid-level values are optional. . . param4b1 value4b1 ... . . param4bN value4bN param4.param4c value4c # Repetition of param4 is harmless. . param4d . . p4d1 val4d1; . . p4d2 val4d2; . . p4d3 val4d3 # save space param5 ... 4) Values are normally assigned only to the lowest level parameters, however, assignment to mid-level parameters is allowed, and will not interfere with assignment or usage of normal parameters. This additional complexity is not recommended, but if the tool requires it, the syntax will support it. 5) Repetition of higher-level parameters, although syntactically unnecessary, can clarify a long listing. Use this to improve readability of your statefile. 6) Putting high-level parameters first is usually more readable, as shown in the first two examples below, but either one is syntactically correct. Examples xaxis.label.font.size 12 . . . family arial . . . color blue . . . bold True . . text Frequency (MHz) . . position 0.5 xaxis.label.text Frequency (MHz) . . position 0.5 . . font.size 12 . . . family arial . . . color blue . . . bold True yaxis1.scale . . style dB20 . . min 0 . . max 120 . . sigdigits 2 . . majdivisions 6 . . mindivisions 4 analyses.tran; . . start 10u; . . stop 20u . . method gear2 . . skipdc yes . . readic final50u Setting Parameters in a Script setparam analyses.tran method=euler # equal sign is optional setparam wavescan.window1 { xaxis.label.text Frequency (MHz) . . position 0.5 . . font.size 12 . . . family arial . . . color blue . . . bold True } The first argument picks the setup and subsetup. Subsequent arguments are parameter-value pairs. Curly brackets are needed only for multi-line commands. Blocks of parameters can be copied right out of the statefiles with no change in syntax. The example above can be made even more compact by using commas for multiple parameters on the same level. This is handy when editing scripts in a small window, but can also lead to confusion. setparam wavescan.window1 { xaxis.label.text Frequency (MHz) . . position 0.5, font.size 12 . . . family arial, color blue, bold True } In this example, parameters family, color, and bold are all under xaxis.label.font, not xaxis.label.position, as you might expect from reading it quickly. Perhaps the user has sacrificed too much clarity to save one line, but that is the users choice. Our statefile writer should never output a file like this, but the statefile reader allows it, because our simple syntax cant rule it out. All the parser knows when it gets to the token family is that the current parameter being processed is xaxis.label.font.size, so it picks up the first three items to replace the dots ahead of family. Syntax Errors The following examples are illegal, and should be flagged by the statefile reader and script interpreter: setparam wavescan.window1 ( No parameters or { before EOL xaxis.label.text Frequency (MHz) . . position 0.5 . font.size 12 ( No such parameter xaxis.font . . . family arial . . . color blue . . . bold True, . italic false ( Cant change level after a comma # end xaxis } ( } is masked by # Note: The font.size assignment above is actually legal syntax, but can be flagged as an error if the reader or interpreter is running in a context where all legal parameters are known. Deeply Nested Example This is an example of an even more deeply nested hierarchy, a piece of the Python parse tree  HYPERLINK "http://www.python.org/doc/current/lib/node565.html" http://www.python.org/doc/current/lib/node565.html DOCSTRING_STMT_PATTERN = ( stmt, (simple_stmt, (small_stmt, (expr_stmt, (testlist, (test, (and_test, (not_test, (comparison, (expr, (xor_expr, (and_expr, (shift_expr, (arith_expr, (term, (factor, (power, (atom, (token.STRING = ['docstring']) ))))))))))), xxx = 999) )))), (token.NEWLINE = '') )) While this certainly beats XML and Javabeans for compactness and readability, it is still too hard to see the hierarchy by drawing lines with a ruler or counting parens. For example, what is the complete hierarchical name of the parameter xxx above? Here is the same hierarchy in our proposed syntax. DOCSTRING_STMT_PATTERN . stmt . . simple_stmt . . . small_stmt . . . . expr_stmt . . . . . testlist . . . . . . test . . . . . . . and_test . . . . . . . . not_test . . . . . . . . . comparison . . . . . . . . . . expr . . . . . . . . . . . xor_expr . . . . . . . . . . . . and_expr . . . . . . . . . . . . . shift_expr . . . . . . . . . . . . . . arith_expr . . . . . . . . . . . . . . . term . . . . . . . . . . . . . . . . factor . . . . . . . . . . . . . . . . . power . . . . . . . . . . . . . . . . . . atom . . . . . . . . . . . . . . . . . . . token.STRING = ['docstring'] . . . . . . . xxx = 999 . . . token.NEWLINE = '' The complete name we need is: DOCSTRING_STMT_PATTERN.stmt.simple_stmt.small_stmt.expr_stmt.testlist.test.xxx While it is not likely we will ever need a statefile as deeply nested as this example, you can see that even in this extreme case, we can read this file and determine the complete name of any parameter we need to set. The dots are not just a visual aid. In this example, they guarantee that xxx is a subparameter of test, the closest level-7 parameter above xxx. The vertical alignment of all the dots is not enforced by the statefile reader, but is highly recommended ( and also easy to type ). Appendix A: Comparing XML to Proposed Syntax 2 The following is a typical statefile to set up a display tool (Cadence Wavescan). The original information (XML format) is in orange font, (except that weve added some leading dots to help decipher what properties apply to which object). The equivalent information in the proposed statefile format is in black. The proposed format is much more compact and readable. We need to decide if the features offered by XML and JavaBean classes are worth enough in this application to warrant the extra complexity. Note: In the black sections, weve deviated from the organization of information in the original statefile in order to separate template information from signal connection information. Templates should be re-usable with different signals. Signal connection information stored with a template will only cause confusion. . . . . . . . . . . . . . . . 465 . . . . . ~/simresults/bandgapTest/spectre/schematic/psf ~/simresults/bandgapTest/spectre/schematic/xR4=1.042 ~/simresults/bandgapTest/spectre/schematic/xR4=1.04 ~/simresults/_VCOtest/spectre/schematic/psf ~/simresults/_VCOtest/spectre/schematic/temp=30 ~/simresults/ampTest/spectre/schematic/CAP=7e-13,temp=100 ~/simresults/ampTest/spectre/schematic/CAP=7e-13,temp=0 ~/simresults/ampTest/spectre/schematic/ ~/simresults/ampTest/spectre/schematic/psf ~/projects/TRO/wscan/ampsim.raw . . . . . True 875 5 431 . . . . . . . . . BrowserWindow { . windowVisible True . height 465 . width 875 . xLocation 5 . yLocation 431 . resultsDirs + ~/simresults/bandgapTest/spectre/schematic/psf, + ~/simresults/bandgapTest/spectre/schematic/xR4=1.042, + ~/simresults/bandgapTest/spectre/schematic/xR4=1.04, + ~/simresults/_VCOtest/spectre/schematic/psf, + ~/simresults/_VCOtest/spectre/schematic/temp=30, + ~/simresults/ampTest/spectre/schematic/CAP=7e-13,temp=100, + ~/simresults/ampTest/spectre/schematic/CAP=7e-13,temp=0, + ~/simresults/ampTest/spectre/schematic, + ~/simresults/ampTest/spectre/schematic/psf, + ~/projects/TRO/wscan/ampsim.raw } . . False . . . . . . . . . . . . . . . . . . . . /usr1/dmq/simresults/bandgapTest/spectre/schematic/psf tran-tran /usr1/dmq/simresults/bandgapTest/spectre/schematic/psf Rectangular Vout . . . . . . . . /usr1/dmq/simresults/bandgapTest/spectre/schematic/psf . . . . . . . . . . . . 0 0 . . chan1 { # setup for channel 1 . template template1 # set all your knobs . signal { # connect a signal . . name Vout . . title Transient Analysis `tran': time = (0 s -> 10 us) . . type SIGNAL . . dataSet tran-tran . . dir /usr1/dmq/simresults/bandgapTest/spectre/schematic/psf . . index 0 . . compound False . } } . . . . . . . . 592 570 False False 0 False True False 0.0 True V black lightGray True 1 0.0 True 9 12 0 0 white 5 False 3 5 True True Dialog True black Vout 6 Identity 0 Vout /usr1/dmq/simresults/bandgapTest/spectre/schematic/psf tran-tran 0 SIGNAL False 0 V False 20 0 red /usr1/dmq/simresults/bandgapTest/spectre/schematic s 31 tran-tran Vout True False 0 False True False 0.0 True s black time lightGray True 1 0.0 True 2 False Transient Analysis `tran': time = (0 s -> 10 us) 410 False 0 . . . . . . template1 { . graphType Rect2Dgraph . xLocation 410, yLocation 0, height 592, width 570 . windowVisible False, cursorOn False, stripChartState False . labelText # no labels . freeze False, dataSnapOn False . title # Null title in the template means use the signal title. . fontSize 12, fontStyle 0 . nameId 0, backgroundName white . stripChartOn False, visibleStripChartRows 5 . peakSnapOn False, visibleDigitalRows 3, displayType 5 . minorGridsOn True, majorGridsOn True . useDefaultSubTitle True, useDefaultTitle True . fontName Dialog, foregroundName black . dependentAxis { . . forceOrigin False . . minGridsOn True . . majGridsOn True . . logScale False . . userMin 0.0 . . userMax 0.0 . . baseUnit V . . foregroundName black . . minorForegroundName lightGray . . sigDigitsDefault True . . scaleMode 1 . . sigDigits 9 . } . independentAxis { . . forceOrigin False . . minGridsOn True . . majGridsOn True . . logScale False . . userMin 0.0 . . userMax 0.0 . . baseUnit s . . foregroundName black . . title time . . minorForegroundName lightGray . . sigDigitsDefault True . . scaleMode 1 . . useDefaultTitle True . . sigDigits 2 . } . trace { . . indepAxisId 0 . . depUnit V . . symbolsOnFlag False . . symbolCount 20 . . depAxisId 0 . . forgroundName red . . indepUnit s . . traceType 31 . } }  Setup information is also stored in init files, but these are less complete than the statefiles, and are intended for just those setups that occur when the tools are initialized.  The need for metadata like variable types and default values is an open question. We could extend the proposed syntax on each parameter (at the cost of making statefiles less readable), or we could add an include statement referencing another file that holds any parameters needing metadata. These include statements could facilitate working with tools that have not yet migrated to the new statefile syntax. CDP/Statefiles/ FILENAME statefile_format.doc 1.0.1  PAGE 1 DMQ 11/15/03 op2 : < ! . I g  " I *-EGJa{|ٝٝ٧ٓٝٝىٝ٧ٝٓhB*PJphh>tB*PJphhIUB*PJphh{B*PJph h{PJ hOPJ hdPJ hagPJ h--PJh8V@B*PJphhDB*PJph jhD0JB*PJUph h(PJ hDPJ62  < 4 GZ;<xgd<gd fgd(;gdIUgdIUxgdIUxgdukgdaggd-- & Fgd8V@ & F & Fxgd@$a$gd(np7q#24:eooq|0UV56BKuý÷÷ñtkbhW6PJ]hD6PJ]hvIzhF0JPJhvIzhD0JPJ h{PJ hw]PJ h fPJh fh fPJ hhPJ h(;PJ hFPJ h%N6PJ hPJ h9PPJ h UPJ hIUPJ hPJ hDPJhDB*PJphh{B*PJphh>tB*PJph$}:;ik&'(*+?@ACklɽɽɴɨɜɮɍ{{ɍ{ɮɍ{ɮu hAPJ#h!hDOJPJQJ\^JaJh!OJPJQJ\^JaJjh00JPJU hPJ hH#PJhvIzhDPJ h NPJ hcPJ hDPJ hHPJ hEPJhD6PJ]hW6PJ]#hhWOJPJQJ\^JaJ,<ju7\l|~Xgdngd!gdH#gdvIzP CVX[\bf~۽۽ᷥufhl6OJPJQJ]^J"h<hD6OJPJQJ]^J"h<h6OJPJQJ]^J hPJ h?7PJ#h!hEOJPJQJ\^JaJ hEPJ h!PJ hnPJ#h!hDOJPJQJ\^JaJ hH#PJ hDPJ hAPJ#h!hAOJPJQJ\^JaJ#bMN8?fPgd3xgd?7gdN:"gdH#!FGKM]CE    ' ( M N O P Q ;vgXgh6DOJPJQJ\^JaJhaOJPJQJ\^JaJh|h 1PJh|h$PJh|hDPJ#h|hDOJPJQJ\^JaJh|h|PJ hL:PJ h;nPJ h3PJ hDPJh<h<PJ"h<hD6OJPJQJ]^Jhl6OJPJQJ]^J"h<hl6OJPJQJ]^J" U!m!t!!!!!!9"C""""#Y$$$%"%4%F%b%gd|gd7Rgd`[gd|gd6Dgd|gdL: X!Z!b!l!m!""7"9""""""####2$9$Y$\$$$$$$$$A%E%%%&&('E''''''((b)Ļ֙֙֙ hFFPJh qB*PJphhi%B*PJphhDB*PJph h7RPJh`[h4,PJh`[hDPJh`[h|PJ h`[PJ h$PJ h4,PJ hDPJ h9PJ h|PJh|h|PJh|hDPJ haPJ2b%t%u%%%%%%%%&&&*&;&P&e&f&&&&&&(')'E'i'}''gd|'''''0(()))))**k,y,,-A-U-----. gd1A gdGgdGgdj 1gd rgd|gdFFb))))**1*H*V*i*l*n**++Y+c+}+++++++, ,,c,i,j,k,,,-e-f----}pfh1AB*PJph jhDB*PJph jhDPJhj 1OJPJQJ^JhhOJPJQJ^Jhh rOJPJQJ^J hj 1PJ hPJhrWh rOJPJQJ^JhrWh rPJh rOJPJQJ^Jh qB*PJphhDB*PJph hDPJ h rPJ&----....J.O.P.V....E/F////////x22236=66777778.8θueuuuuuuhHdB*OJPJQJ^JphhDB*OJPJQJ^JphhDPJ\aJhD0JCJPJ\ jhDCJPJU\jhDCJPJU\hDCJPJ\ hGPJ hD>*PJ hDPJh9B*PJph jhDB*PJphhDB*PJphhi%B*PJph%...////00.0E0Y0r0000001?1\1|1111262K2 gdGK2j2w2x23333333 4444M4j44444525Y5555666=6 =66688::;;$<%<c<r<<<<'===^>>$??@]@@Agdwgdw gdT .8N8888839?9@9;;BDKLhnnnnBoCoDoEoQoRoppup|ppppùßߕxgUx#hDhIUOJPJQJ\^JaJ hDhIUOJPJQJ^JaJh0hIUCJaJhIUCJaJ hIUCJhIUjhIU0JUhwB*PJphhwB*OJPJQJ^JphfhwB*PJphfhwB*OJPJQJ^Jph hbuPJ hwPJhDB*OJPJQJ^JphhTB*OJPJQJ^Jph AKA{AAAA BBB*B@BUBjBBBBB CDCsCCCDHDvDDDDD Egdw EEXEEEEF]F~FF#GpGGGaHHHICIeIIII.JJJbJxJJJJgdwJKKKAKlKKKKKLZLnLLLLLLLM1MqMMMM0NXNNNNgdwNBOxOOO)PsPPQFQQQRtRRSJSSST'TITTTUGUUUV[Vgdw[VVV+WrWWW2XYXXX3YtYYY,ZtZZG[[[$\R\|\\\,]x]]^gdw^N^^ _P___`,`N```aZaaa bTbbb'cjcccPddd&eseegdweef%fffffg.ghggggh,hBhThdhthhhhhhi8iYiiiigdwij@jgjjjjjk k;kVkqkkkkkkll.lIlcl}lllllmmgdwm=mWmrmmmmmmmnn9nRninnnnnnCopp5q6q7q8q  !P%gdkgdD gdwppppqqqqq$q%q&q'q4q5q7q8qûîûhDB*OJPJQJ^JphhIUhIU0JCJmHnHuhIU0JCJjhIU0JCJUhIUCJmHnHujhIUCJUhuChIUCJjhuChIUCJU hIUCJ 1h/ =!'"'#$%ADyK 3http://www.python.org/doc/current/lib/node565.htmlyK fhttp://www.python.org/doc/current/lib/node565.htmlh@h Normal,Comments-B* CJOJQJ^J_HaJmH phsH tH N@N  Heading 1$<@&5CJ KH \aJ N@N vIz Heading 2$<@&5CJ\]aJJ@J vIz Heading 3$<@& 56\aJDA@D Default Paragraph FontViV  Table Normal :V 44 la (k(No List :B@: Body TextxCJ\ZOZ\Personal Compose StyleCJOJQJ^JphVOVlPersonal Reply StyleCJOJQJ^JphDZ@"D Plain TextCJOJQJ^JaJ4@24 Header  !4 @B4 Footer  !.)@Q. Page Number>@b>  Footnote TextCJaJ@&@q@ Footnote ReferenceH*6U@6 Hyperlink >*B*phHH uC Balloon TextCJOJQJ^JaJlOl vIzHeading 1 Char75B* CJ KH OJQJ\^J_HaJ mH phsH tH jOj vIzHeading 2 Char65B* CJOJQJ\]^J_HaJmH phsH tH o8iX[8i 2<4 G Z ; <ju7\l|~XbMN8?fUmt9CY"4Fbtu*;Pef()Ei}0 !!!!!""k$y$$%A%U%%%%%&&&''''((.(E(Y(r(((((()?)\)|))))*6*K*j*w*x*+++++++ ,,4,M,j,,,,,-2-Y----...=...002233$4%4c4r4444'555^66$778]889K9{9999 :::*:@:U:j::::: ;D;s;;;<H<v<<<<< ==X====>]>~>>#?p???a@@@ACAeAAAA.BJBbBxBBBBCCCAClCCCCCDZDnDDDDDDDE1EqEEEE0FXFFFFBGxGGG)HsHHIFIIIJtJJKJKKKL'LILLLMGMMMN[NNN+OrOOO2PYPPP3QtQQQ,RtRRGSSS$TRT|TTT,UxUUVNVV WPWWWX,XNXXXYZYYY ZTZZZ'[j[[[P\\\&]s]]]^%^f^^^_._h____`,`B`T`d`t``````a8aYaaaab@bgbbbbbc c;cVcqccccccdd.dIdcd}dddddee=eWereeeeeeeff9fRfiffffffCghh5i6i9i00 0 0 0 000000000000p0p00000000000000000000(0000000000000p0p00p0p0p0p0p0p0p0p0p0000p0p00p0p0(0p0p0p0p(0p00p00p0000000000000p0p0p0p0p0p0p0p0p0p00p0p0000p00p0p0p0p0p0p00000000 00 00 00 0 0 00 0 0000p0p0p0p0p0p00p0p0p0p0p0p00p0p0p00p00p0p0p0p0p00p00p00p000000000 00 00 0 0 0(0p0p0p0p0p0p00p0p0p0p0p00p0p0000p0p00p0p0p00000000000000 000p0p0p0p0p0p000p0p0p0p00p0p00p0p0p0000p000p00p00000 00 00 0 0 0 0 0 0 0 080p0p0p0p0p000p0p0p00p00p0p0p00p0p0p0p0p0p0p0p00p00p0000000000 0 0 0 0 0 0 0000 0@0 0@0p0p0p0p0p0p00p0p00p0p000p0p0p0p0p0p0p0000p00p00p00p00p00p00p00 00 00 0 0 00 0 00 0 00P0p0p0p0p0p0p0p0p0p000p0p0p000p0p00p0p0p0p0p00000p00p0000000000000 0 0 00 0(0(0 0@0`0p0p0p0p0p0p00p0p0p00p0p0p00p0p0p00p0p00p0p00p0p00p0p00p0p00p0p00p0p00p000p00 00 0 0p0(0 0 0 0@@0p@0p0m+@0@00@+2<4 G Z 0 !!!!""k$9i 0x0x 0x 0x 0x 0x0x0x0x0x0x0x0x0x*0O900O900D(_(O900O900O900O900DL(O900O9000O900Oy00wQQQT b)-.8p8q9<=?ACFGKU<b%'.K2=6A EJN[V^eim8q:>@BDEHIJLMNOPQRST7q;E'''8iX/8?AT!T8@0(  B S  ? Z,i9i4i9i8*urn:schemas-microsoft-com:office:smarttagsdate 11152003DayMonthYear $2<xzhr'1U_DM   * / 4 N V } d m e n QY\e*3;C0:JT x%&*,237jrWaNW !u.7?KT`fs )1EU !!!!!!!!W"g"n""###Y#b# $$$$$$%-%W%`%z%%%%%%#&,&'' ((#(,(;(C(h(p((((((((())3)=)))))V*c***+ +++++++, ,+,3,D,L,~,,,,,,,,------ ....//>0G0000111^2f23!3&4.464`44444448889,99999999::':-:::m:v:::::::H;q;w;;;;;<"<F<L<t<<<<<<<<=8=E=r======>>'>/>7>Z>? ?EFENEnEF"FkFsF%G/GhGuGGGGGHHUH`HHHHH.I5IrI|IIII JJJ]J_JhJJJJJ2K9KvKKKKL%LoLwLLLLL&M4MmMMMMM NANLNNNNNOOQO`OOOPPP/PPPPPPP_QeQQQQQQQdRhR)S0S2S;SrTzTTTUUXUeUUUUU/V=VVV7W@W|WWWWWW"X*XtXXXXX Y(Y0Y8YWYYYYY8ZBZZZZZ [[S[[[[[&\9\;\D\|\\\\]]R]a]]]]^K^S^^^^^__N_W_____ ``J`R`v`~```````````aaa!aHaRaaaaaaaaaaaab bbb.b2b=bBbNbUbabib{bbbbbbbbbbbbb cc$c,c?cFcZcacuc}ccccccccccccdd+d2d=dMdWdgdqddddddddddde1e3eJQfnu  #.:?KT`svy~)1EXmu!!!!!!!!i""$$%0%E%M%W%d%%%%%%%%%%%'';(C(S(W(((((V)Z)t)z)))))+*.*++, ,,,_,i,~,,--1-R-X-{------j0o034~7777-:::C:I:X:]:m:v:::::CCKCnCtCCCCCCCDDDD^DcDrDD^^``````a!a:a@a[a`aaaaaaa bbBbNbib{bbbbbbbbb cc$c,c?cFcZcacuc}ccccccccccdd+d2d=dMdWdgdqddddddddddde ee8V@AuC6DDhDFFdqH-"J?%J)yJ9PqSUW`[+#e fagkuknp qvIz{9`}9 NB?7>tl{N(;q{ rrWw]h0@;n|<7R<--FGT7!1AEc UIU(wc@ , 8i@UnknownGz Times New Roman5Symbol3& z ArialG  MS Mincho-3 fg?5 z Courier New;Wingdings5& zaTahoma"qhiƷ{z~c N>W4N>W4!'24dXfXf 3QH(?W<David MacQuiggDavid MacQuigg  Oh+'0   < H T `lt|<ssDavid MacQuiggaviavi Normal.dotiDavid MacQuigg126Microsoft Word 10.0@O@$}@9g@zN>W՜.+,D՜.+,D hp  Cadence Design Systems, Inc4XfA < Title 8@ _PID_HLINKSA!y3http://www.python.org/doc/current/lib/node565.html  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVXYZ[\]^`abcdefghijklmnopqrstuvwxyz{|}~Root Entry FL6zData W1Table_BoWordDocument"SummaryInformation(DocumentSummaryInformation8CompObjj  FMicrosoft Word Document MSWordDocWord.Document.89q