Docstoc

DDC_ASM_PDR_SPS2

Document Sample
DDC_ASM_PDR_SPS2 Powered By Docstoc
					              SOFTWARE PRODUCT SPECIFICATION
                                          for
                                     DDC Assembler



                Common Aircraft Portable Reprogramming Equipment
                                    (CAPRE)




                                            Prepared
                                               by

                                    2006 DDC Assembler Clinic
              University of Utah, Department of Electrical and Computer Engineering
                                  Clinic06@vlsigroup.ece.utah.edu



ISSUE: Preliminary Design Review                               CAPRE-DDC-ASM-NOV2006
                          CAPRE-DDC-ASM-SPS-01NOV2006




APPROVED BY: _(Signed)____________________________________   Date _______________

               Brent Watson
               Industry Liaison




REVIEWED BY: _(Signed)____________________________________   Date _______________

               Dr. Chris Myers
               Clinic Advisor




PREPARED BY: _(Signed)____________________________________   Date _______________

               DDC ASM Clinic




                                        2
                                                 CAPRE-DDC-ASM-SPS-01NOV2006


                                                                  Table of Contents
1     SCOPE ................................................................................................................................................................4
    1.1           IDENTIFICATION .......................................................................................................................................4
    1.2           SYSTEM OVERVIEW .................................................................................................................................4
    1.3           DOCUMENT OVERVIEW............................................................................................................................5
2     REFERENCES ...................................................................................................................................................6
    2.1           TECHNICAL ORDERS ................................................................................................................................6
    2.2           SPECIFICATIONS AND STANDARDS ...........................................................................................................6
    2.3           TECHNICAL REFERENCE MANUALS .........................................................................................................6
3     LANGUAGE DESIGN ......................................................................................................................................6
    3.1           ASSEMBER ...............................................................................................................................................6
    3.2           ASSEMBLY LANGUAGE ............................................................................................................................6
    3.2.1         INSTRUCTION LIST ...................................................................................................................................6
    3.2.2         MESSAGE BLOCK .....................................................................................................................................6
    3.2.3         DATA BLOCK ...........................................................................................................................................7
    3.2.4         OTHER COMPILER DIRECTIVES ................................................................................................................7
    3.2.5         COMMENTS ..............................................................................................................................................7
4     LEXER AND PARSER .....................................................................................................................................9
    4.1           LEXER AND PARSER GENERATION TOOLS................................................................................................9
5     CODE GENERATION .................................................................................................................................... 12
    5.1           DATA STRUCTURE ................................................................................................................................. 12
    5.2           CODE GENERATION ............................................................................................................................... 13
    5.3           IMAGE FILE GENERATION ...................................................................................................................... 14
6     GLOSSARY ...................................................................................................................................................... 17
    6.1           ACRONYMS. ........................................................................................................................................... 17
    6.2           DEFINITIONS. ......................................................................................................................................... 18




                                                                                    3
                               CAPRE-DDC-ASM-SPS-01NOV2006


1   SCOPE
1.1 Identification

This Software Product Specification (SPS) proposes changes to the architecture, interface, design, and
code characteristics for the USB 1553 Interface Module (IM) of the Common Aircraft Portable
Reprogramming Equipment (CAPRE).

1.2 System Overview

The CAPRE is a lightweight hardware and software system providing a means to transfer Mission Critical
Data (MCD) and Operational Flight Programs (OFP), from a field laptop running CAPRE to a Line
Replaceable Unit (LRU). The transfer of MCD is performed by the CAPRE Host Software in conjunction
with AAG-specific software, in the form of a Dynamic Link Library (DLL), which is incorporated into the
system through a check-in process. The CAPRE Host Software, which consists of a Graphical User
Interface (GUI), a control database, and communications functions, as well as the AAG specific software
resides on the laptop.

A CAPRE System consists of a common portion and an AAG portion. The common portion includes the
CAPRE Laptop and the USB1553 IM hardware. The AAG unique portion consists of a Line Replaceable
Unit (LRU) cable.




                                                                                 LRU



                                                                            MIL-STD-1553 Interface
                                   USB1553
                               Interface Module


                             Figure 1. CAPRE USB1553 IM AAG Configuration

         CAPRE Common                             Aircraft Adapter Group         Line Replaceable Unit




                                                   4
                                  CAPRE-DDC-ASM-SPS-01NOV2006



                                          1553IM
              PC                                            EMACE
                                                            1553                          LRU
                                                            engine
                                          EZ-USB
                                          Micro-
                       USB Port           controller


                                          Program            2
                                                            I C Bus
                                          EEPROM




                          CAPRE                                               AAG
                          Common 2. CAPRE System Block Diagram
                              Figure
                          CommonCom
                          monCommon
1.3 Document Overview

This document is a preliminary compilation of the components and structure needed to create an
assembler for the Enhanced Mini-Advanced Communication Engine (EMACE). It is organized into 3 main
sections: language design, lexer/parser components, and image file generation. The language design
section will consist of the general syntax and format of the assembly language that will be used to
generate an image file for the EMACE chip. The lexer and parser section will discuss the workings of the
components, choice of tools, and any other aspect of turning the assembly file into information for code
generation and verification. The section on image file generation will delve into the internal data structure
of the object code and the image file that the structure will be stored to on disk.




                                                       5
                             CAPRE-DDC-ASM-SPS-01NOV2006


2   REFERENCES
2.1 Technical Orders

T.O. 33D7-3-27-1, Operation and Maintenance with Illustrated Parts Breakdown, Common Aircraft
Portable Reprogramming Equipment (CAPRE) User Manual, 31 July 2000.

2.2 Specifications and Standards

Software Product Specification for CAPRE Host Software CPIN 85T-AN/PYM1CAPRE-F001-00A,
CAPRE-HOSTSPS-14SEP2001.

Software Product Specification for CAPRE 1553 AAG Developers
CAPRE-1553SW-DEV-GD-30OCT200

2.3 Technical Reference Manuals

Enhanced Miniature Advanced Communications Engine, 2000,
Data Device Corporation

BU-69090 Enhanced Mini-ACE Runtime Library Software Manual, Rev-J, 2006,
Data Device Corporation




                                                6
                                 CAPRE-DDC-ASM-SPS-01NOV2006


3    LANGUAGE DESIGN
3.1 Assembler

The assembler creates an image file by translating assembly instruction mnemonics into opcodes, and by
resolving symbolic names for memory locations and other entities. The use of symbolic references is a
key feature of the assembler, saving tedious calculations and manual address updates after program
modifications.

3.2 Assembly Language

There are five main constructs used in the assembly language. These are compiler directives,
instructions, labels, values, and comments. For the image file sent to the DDC chip there are three main
blocks: the instruction list, the message block, and the data block.

3.2.1   Instruction List

The instruction list is a group of instructions that will be executed in sequential order. Each instruction
consists of an opcode, a parameter and a conditional. An instruction may also be unconditional in which
case the conditional is not used. The opcode is a mnemonic representing one of the 20 opcodes
recognized by the DDC chip. The parameter is a value or a pointer to the address of another instruction
or the address of a message block. The conditional is also a mnemonics that represents a flag or a value.

Example piece of code:
…
        FLG 0x2FD0 ALWAYS
wait:   DLY 1 ALWAYS
        JMP wait GP6_1
        RTN GP4_1
…

The „wait:‟ on the second line is a label that acts as a pointer. The address of this pointer is calculated at
compile time and inserted into the JMP instruction. On the fourth line the RTN call has no parameter
because it is not used for that instruction.


3.2.2   Message Block

The message block is a group of 8 or 10 16 bit words. In the assembly language these blocks can be
assigned using the org (origin) and fdb (form double byte) commands. The org command changes the
location of the program counter to the specified location. The fdb command forms the specified bytes in
the current memory location.

Example message block:

org 0x8000
msg_blk_1:     fdb 0x0030
               fdb 0xFFEE
               fdb data_1
               fdb 0x33AC
               fdb …
…

This section of code places those bytes in sequential order starting and the location 0x8000. The address
of „data_1‟ is insterted at compile time.



                                                       7
                               CAPRE-DDC-ASM-SPS-01NOV2006



3.2.3   Data Block

The data block is created the same way that the message block was created just using a different label
and different memory location.

Example data block:

org 0x0100
data_1: fdb 0x0001
         fdb 0x10AD
         fdb 0x011F
         fdb …
…

3.2.4   Other Compiler Directives

Along with org and fdb there is also an equ (equals) command. The equ command assigns an expression
value to an identifier.

Example assignments:
VAL1 equ 0
VAL2 equ 0x013C
VAL3 equ VAL1
…

3.2.5   Comments

Comments can be put into the code after double forwards slashes (//). They can be on a separate line or
after an instruction.

Example comments:
// Retrieve data from LRU

XEQ msg_blk_1 GP2_0          // Message block 1 loads data into 0x1000
FLG 0x0001 ALWAYS            // …
…




                                                   8
                                 CAPRE-DDC-ASM-SPS-01NOV2006


4    LEXER AND PARSER
This section will discuss the need for and construction of lexers and parser generators. In general terms,
a lexer recognizes specified patterns of characters or patterns of strings and returns a specified token for
each match found. For example, a “+” (plus character) found in an input document could cause the lexer
to return a designated PLUS token. These predetermined token types can then be processed by a parser,
where every token is checked to see if it conforms to a determined syntax specified by a context free
grammar. A lexer, then, parses character strings to produce tokens, while a parser parses token streams
to verify the syntactical correctness of each complete expression.

4.1 Lexer and Parser Generation Tools

A hand written lexer could be written for this project. There are, however, several freely available lexer
generators that are easier to use. As stated in the specified requirement list, all considered lexer
generators produce lexers in C#, compatible with Microsoft‟s .Net 2.0 project. A long list of lexer and
parser generators found at
http://dmoz.org/Computers/Programming/Compilers/Lexer_and_Parser_Generators/ provided a reference
for finding lexer generators that could generate C# lexers.

To choose a lexer/parser generator tool, we evaluated the pros and cons of each tool option. One of the
generators listed on the above website was Grammatica, found at
http://grammatica.percederberg.net/index.html. This tool has a detailed explanation of the functions used
to construct token trees that the parser produces. Unfortunately, Grammatica has very poor, if any
support, almost no documentation, and it comes with only five training examples.

Another tool, called CSTools47, was found at http://cis.paisley.ac.uk/crow-ci0/ and was created by
Professor Malcolm Crow of the University of Paisley, U.K. This tool has considerably more
documentation, coming with a ninety-page Word document outlaying how to use the program step by
step to generate lexers and parsers. Around fifty simple lexer and parser generator examples are given
as well. The support or outside documentation and tutorials, however, are minimal. A search of the
Internet using www.google.com for “CSTools47”found only a few irrelevant items. The only contact or
support seemed to be emailing the professor Malcolm Crow, which did not sound feasible.

The final tool we looked at was ANTLR, a free open source lexer and parser generator program. ANTLR
is a popular program, with over five thousand downloads a month. Antler‟s website, www.antlr.org, lists
seven starting tutorials, an updated wiki, and a very large official documentation of about 180 pages. In
addition the file download contains around twenty example cases. These tutorials, however, while
producing the correct C# lexer code, have no documentation. Moreover, most of the other tutorials and
examples, including the simple ones, use Java as the target language, thus making it difficult to convert
the tutorial examples to lexers that use C#.

ANTLR, though, was chosen as our lexer and parser generation tool, mainly because of its extensive
documentation. Microsoft Visual Studio, using .Net 2.0, will be used to compile the lexers and parser
generated by ANTLR.

ANTLR takes an input a .g file which specifies both the lexer and parsers generated. To declare the lexer
part of the .g file a new class is created that extends the Lexer class. In the options section of the .g file, a
language = Csharp flag must be set, as well as a look ahead depth. For example, to distinguish between
matching ab and ac, the look ahead depth must be at least two. Then internal “protected” sub-rules may
be declared, which can be used by rules that, when matched, can produce tokens to send to the parser.
In addition, the .g file can specify that a return returns a special token for a string match, such as the skip
token upon encountering white space.

Below in Fig. 3 is a commented lexer part of a .g file that specifies tokens used in a calculator program.
This example is taken from the ANTLR‟s example library..



                                                        9
                          CAPRE-DDC-ASM-SPS-01NOV2006



class CalcLexer extends Lexer;        Declare lexer class
WS :     (' '                          Set rule for character literal token matches for WS
     |   '\t‘                         (i.e. space OR escape sequences \t OR \n etc)
     |   '\n'
     |   '\r')

         { _ttype = Token.SKIP; } Run C# code upon finding WS that returns a SKIP token
     ;
LPAREN: '(‘                           Set rules for characters to match tokens
     ;
RPAREN: ')'
     ;
STAR: '*'
     ;
PLUS: '+'
     ;
SEMI: ';'
     ;
protected                             Makes DIGIT rule internal and does not produce a
                                      token upon being recognized by itself
DIGIT
     :   '0'..'9'                      A DIGIT token is created upon recognizing any
digit                                 between 0 and 9
     ;
INT :    (DIGIT)+                     an INT token is created upon recognizing at least 1
DIGIT
     ;



                    Figure 3 Lexer Class that Defines Lexer Generation




                                            10
                                CAPRE-DDC-ASM-SPS-01NOV2006

To specify token rules, a regular expression must be used. A regular expression is an expression that
describes a set of strings by matching string patterns. There are a number of different regular expression
operations. The “|” operator specifies that either expression can result in the rule being satisfied. “Gray |
Grey” will evaluate to expression matched if either Gray or Grey is matched. How many times each
element can be repeated can be expressed as well. The question mark operator, (?) signals that zero or
one of the previous expression can be matched. For example “colou?r” matches colour and color. The
star operator (*) is used to indicate that zero, one, or any number of previous expressions can be
matched. For example ca*t can match with ct, cat, caat, caaat, o caaaat, etc. The plus operator (+)
matches at least one of the previous expression. For example, “ca+t” does not match with ct, but it does
match with cat, caat, caaat, caaaat, etc.

Some matching sets are predefined. The expression [a ..z] | [A ..Z] matches any character, in both upper
and lower cases. [„0‟ ..‟9‟] matches any one digit and [„0‟..‟9‟]+ matches any length of digits.

Finally, the compliment operator (^) matches all characters in a set except the indicated characters. The
expression [^abc], for instance, matches all letter characters except „a,‟ „b,‟ and „c.‟

The lexer built for this clinic project will have to parse the files that implement our chosen assembly
language structure. For this reason, the lexer must be able to recognize the mnemonic opcode for each
instruction, plus all sixteen of the conditional codes. In addition, it must be able to match the commands
used to create the message control/status block, as well as commands used to initialize the data block.
Pseudops, such as “org” or “word” must also be recognized as well. All of the types of terms to be
recognized, then, must be specified by a developed assembly language structure.




                                                     11
                                 CAPRE-DDC-ASM-SPS-01NOV2006


5    CODE GENERATION
5.1 Data Structure

To facilitate the creation of an image file from an assembly file, we will create a data structure with an API
that the parser will call to build it. The assembly file will include several different kinds of instructions to
the assembler that the data structure will need to manage. These include DDC native instructions, data
to be placed in Message Control Blocks or Data Blocks, and instructions to tell the assembler where in
memory to put the code or data. The data structure must also be able to accommodate labels in the
assembly code.

The DDC instructions are found in the DDC EMACE chip documentation. They will be implemented using
the syntax described above. Each instruction contains an opcode, a condition code, and a parameter.
An instruction could also have a label associated with it. We anticipate that the parameters will primarily
be labels to other portions of the assembly file. One line of the assembly file that contains a DDC native
instruction might look like this:
      XEQ NE label1

To fill Message Control Blocks or Data Blocks, assembler-specific instructions will be used. Like the DDC
instructions, these instructions can also have labels. These instructions will tell the assembler what data
to put in each block. An example might look like this:

          org 0xB600
mcb:      fdb 0x1002
          fdb 0x1001
          fdb data
          fdb 0xBA12
          fdb 0xBEEF
          fdb 0x1010
          fdb 0x1234
          fdb 0x1F21

data:     fdb 0x1451
          fdb 0x5123
          fdb 0xF141
          fdb 0xBE14

The first block of this example is a Message Control Block. The immediate values will be loaded into
memory starting at the address B600 (as indicated by the org statement). The fdb command (form
double byte) loads the following 16 bits into the current memory address. The third fdb instruction loads a
pointer to the data label into its double byte in memory. As already noted, the org statement will be used
to specify where in memory to load the instructions or data.




                                                       12
                                CAPRE-DDC-ASM-SPS-01NOV2006


A data structure would need to be able to handle all of these cases. The following is a diagram of the
proposed data structure for the instructions. The top line is used for DDC instructions, the next line for
Message Control Block data, the third line for Data Block data, and the last line for general purpose
information.



                       Instruction/ Condition Parameter
                         Opcode
                                    MCB Block                         Pointer Next

                       Size              Data Block
                                                                      Pointer Next
                        Label     Instruction
                                     Type
                                                            Data      Next

                                                            Data      Next

This block will then be integrated with the rest of the blocks into a "beaded curtain" arrangement as
depicted in the following diagram. Each org statement would create a new string of beads with the
address of the org statement filling the Address block on the top row of the diagram. Each block of
instructions or data will be represented by a linked list from the top row, each element having a pointer to
the data structure discussed on the previous page

                 Address                        Address                   Address
                Data Next                     Data Next                 Data Next


                Data          Data            Data          Data        Data         Data
                            Structure                     Structure                Structure
                Next                          Next                      Next

                Data          Data            Data          Data        Data         Data
                            Structure                     Structure                Structure
                Next                          Next                      Next

Once the parser has generated this data structure, we can implement code to build the image file from
the data structure.

5.2 Code Generation

Overview: The Assembler will use a Lexer and Parser and predefined data structure to generate byte
code in Memory loadable format S19. The Assembler will be a GUI created in C# using Microsoft's Visual
Studio 2005 .Net 2.0.




                                                     13
                                    CAPRE-DDC-ASM-SPS-01NOV2006

Details:

          A separate window will be opened when the assembly code is loaded from a file for the user to
           review. The window will be scrollable.

          The Assembler will then call the lexer and parser for any functions that they perform and generate
           their corresponding files.

          The assembler will take the files generated from the lexer and parser and then create a data
           structure of the assembly instructions.

          The data structure will be used to hold instructions and their accompanying data types. The
           Assembler will use the data structure much like a queue by pulling the instructions from the front
           of the list and handling the instruction accordingly

          The Assembler will use function calls like are similar to the ones we received already from Hill Air
           Force Base to generate the byte codes for each instruction.

          The Assembler will make two passes through the data structure of instructions. The first pass will
           consist of converting everything but address labels to byte code.

          The Second pass will involve changing the address labels into byte address.

          The byte code will be stored in a C# string array. Integers in C# strings can be converted to
           hexcode directly. An array of strings will allow easy access of the bytes and C# has a built in
           object called a StringWriter which writes a specified string to a file which will be the image file.

          After the byte code has been decoded for the given instruction, it will be written out to an s19 file
           (.s19). It will be organized in the memory format S19. This will allow the generated file to be
           loaded directly to RAM or ROM.

          The GUI will also output the resulted file to the screen in the Assembler GUI for the user to be
           able to review. A separate window will open when the Assembler is finished containing all of the
           information.

5.3 Image File Generation

We intend to use the s19 file format to generate an image file of the data structure mentioned above. The
.s19 file is a file consisting of readable characters in the set of {S,0-9,A-F}. The file contains addresses
and byte-information to be located in memory starting from the addresses. Addresses are specified by 4,
6, or 8 character HEX strings, and bytes are specified by 2-character HEX strings.
                                                     Details:
          All leading white-space on each line is ignored.

          The first 4 characters in each line of the file contain:

               o   the character 'S',

               o   a single-digit code {1-9},

               o   and a 2-character number indicating the number of bytes in the line.

          The last 2 characters in a line are a checksum.

          The remaining characters in the line are 2-character data bytes.



                                                          14
                                  CAPRE-DDC-ASM-SPS-01NOV2006

        The end-of-line characters in the file can be either '\n' or '\r' (0x0A or 0x0D), or both.

Note: Each line MUST start with an 'S' character.
                                                  Line-Codes
The following codes are known:

        1 - Characters 5- 8 in the line specify a 16-bit address.

        2 - Characters 5-10 in the line specify a 24-bit address.

        3 - Characters 5-12 in the line specify a 32-bit address.

        7, 8, 9 - end of file. A checksum follows but if generally ignored.

The data bytes are character-pairs which are the byte data in HEX to be located in memory starting at the
specified address.

Looking at the first line:
                                                 Start of Line:
The line starts with an 'S'.

S123B600BDB653CC0800FD1018FD101AFD101CFD101EBDB665CC0002DD007F00067F001055
                                                  Command:
The second character on the line is the command, in this case a '1':

S123B600BDB653CC0800FD1018FD101AFD101CFD101EBDB665CC0002DD007F00067F001055

This means that the address will be a 2-byte (4-character) address.
                                                  Line Length:
The third and fourth characters on the line are the number of character pairs (bytes) on the line, including
the address:

S123B600BDB653CC0800FD1018FD101AFD101CFD101EBDB665CC0002DD007F00067F001055

In this line this is a 23 (a HEX 23), which is 35 in decimal.
                                                    Address:
The next section on the line is the address, the length of which is specified by the command character:

S123B600BDB653CC0800FD1018FD101AFD101CFD101EBDB665CC0002DD007F00067F001055

B600 This 4-character (2-byte) address is a HEX $B600, the start of the EEPROM in a 68HC11E1.
                                                  Check-Sum:
The last 2 characters are a 1-byte check-sum for the line. The check-sum is calculated by summing, in
HEX, all of the 2-character bytes on the line starting wit the third and fourth characters (the length byte),
and running up to the check-sum byte. This resulting number is truncated to a number in the range of 0 to
255 (anded with 0x00FF), and then complemented. This result is the line's checksum.

S123B600BDB653CC0800FD1018FD101AFD101CFD101EBDB665CC0002DD007F00067F001055

For this line, starting with the "23" and summing through the "10", the sum is 0xCAA. Truncating we get
0xAA, and complementing we get 0x55, the 55 as seen at the end of the line.




                                                        15
                                 CAPRE-DDC-ASM-SPS-01NOV2006

                                                 Data-Bytes:
The character-pairs between the address and the end-of-the-line checksum are the data-bytes:

S123B600BDB653CC0800FD1018FD101AFD101CFD101EBDB665CC0002DD007F00067F001055

These bytes will be placed sequentially in memory starting with the specified address. In this line, the first
data-byte is BD, which is the machine-code for the JSR line of the code, will be placed in memory at
address $B600. The next 2 bytes, B653, is the machine-code of the address the jump will take, the
location of the Init_4_Servos subroutine, and will be places in memory locations $B601 and $B602; and
so on.

Note that even when the data spans more than 32 sequential bytes in memory, a maximum of 32 data
bytes is used. The data is continued on the next line in the file, with the address being specified ($B620 in
our example). This is redundant, but allows each line in the .s19 file to completely specify the address
and the data.
                                                 End-Of-File:
The last line in this example .s19 file shows the end-of-file specifier.

S9030000FC

The end-of-file command is a '9' (and as specified in Randy's code, a '7' or an '8' may also be specified).

The next 2 characters are the line-length byte, 3 bytes in this case:

S9030000FC

The remaining 6 characters in the file are perhaps some sort of file check-sum, but I do not have the
details for how they are calculated, nor could I see the connection for the use of this data.




                                                       16
                           CAPRE-DDC-ASM-SPS-01NOV2006


6     GLOSSARY
6.1 Acronyms.

AAG       Aircraft Adapter Group

BC        Bus Controller

CAPRE     Common Aircraft Portable Reprogramming Equipment
CPIN      Computer Program Identification Number

DLL       Dynamic Link Library

EEPROM    Electronic Erasable Programmable Read Only Memory
EMACE     Enhanced Mini-Advanced Communication Engine

FPGA      Field Programmable Gate Array
FW        Firmware

GPD       General Purpose Driver
GUI       Graphical User Interface
GPIF      General Programmable InterFace

IM        Interface Module

LRU       Line Replaceable Unit

MCD       Mission Critical Data
MDF       Mission Data Files

OFP       Operational Flight Program
OOD       Object Oriented Design

PAM       Personality Adapter Module
PC        Personal Computer
PCB
PIM       Programmable Interface Module

TBD       To Be Determined

USB       Universal Serial Bus




                                           17
                           CAPRE-DDC-ASM-SPS-01NOV2006



6.2 Definitions.

             Term                                        Meaning
                      MIL-STD-1553 Interface Standard for digital time division command/response
     1553
                      multiples database
     8051             Type of microprocessor contained in EZ-USB chip.
                      A string and/or numerical value that is stored in a CAPRE cable or personality
     Cable ID
                      module and uniquely identifies that cable or module.
     CAPRE Device     One of either a Xilinx-based or a 1553-based Interface Module.
                      A numerical value that is stored in a CAPRE device and uniquely identifies
     Device ID        that device‟s device type. Currently there are two device types: Xilinx and
                      1553.
     Firmware (F/W)   The software program that runs in the EZ-USB chip.
                      A numerical value - essentially a “handle” - provided by the communications
     Resource ID      S/W to a DLL that allows access to other functions provided by the
                      communications S/W in order to communicate with a CAPRE device.
                      A numerical value that is stored in a CAPRE device and, along with the
     Serial Number
                      Device ID, uniquely identifies that device.
                      The process by which a USB device during connection receives it‟s USB
     Enumeration
                      address, and loads any data specified from the host PC.
                      A free open source lexer and parser generator program, located at
     ANTLR
                      www.antlr.org
     Regular          A string that describes or matches a set of strings, according to certain syntax
     Expression       rules.
     Lexer Look-      Determines how many characters the lexer will look ahead before making a
     ahead depth      rule decision.
                      Program which takes as an input a string of charcters and outputs a series of
     Lexer
                      tokens, based on the string pattern match, which can be used by a parser

     Grammar          A formal way of stating the syntax of language

                                  Table 1. Common Terms




                                                18

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:7
posted:11/20/2011
language:English
pages:18