US20050102488A1 - Firmware description language for accessing firmware registers - Google Patents

Firmware description language for accessing firmware registers Download PDF

Info

Publication number
US20050102488A1
US20050102488A1 US10/974,291 US97429104A US2005102488A1 US 20050102488 A1 US20050102488 A1 US 20050102488A1 US 97429104 A US97429104 A US 97429104A US 2005102488 A1 US2005102488 A1 US 2005102488A1
Authority
US
United States
Prior art keywords
register
firmware
instructions
description language
accessing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10/974,291
Inventor
George Bullis
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Finisar Corp
Original Assignee
Finisar Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US51802603P priority Critical
Priority to US51809303P priority
Application filed by Finisar Corp filed Critical Finisar Corp
Priority to US10/974,291 priority patent/US20050102488A1/en
Assigned to FINISAR CORPORATION reassignment FINISAR CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BULLIS, GEORGE ANTHONY
Publication of US20050102488A1 publication Critical patent/US20050102488A1/en
Application status is Abandoned legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing packet switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing packet switching networks
    • H04L43/50Testing arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing packet switching networks
    • H04L43/08Monitoring based on specific metrics
    • H04L43/0823Errors
    • H04L43/0847Transmission error
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing packet switching networks
    • H04L43/18Arrangements for monitoring or testing packet switching networks using protocol analyzers

Abstract

The present invention provides for a firmware description language for accessing firmware registers. Computer-readable media store a data structure representing a firmware description language that includes at least a blade type field containing a blade type value that represents a blade type and a register description field containing a one or more register configuration values for accessing a register at a blade of the blade type represented in the blade type field. In some embodiments, a computer system receives application instructions for accessing a firmware register. The computer system refers to the firmware description language to identify register attributes of the firmware register. The computer system generates low-level instructions for accessing the firmware register in accordance with register attributes referred to in the firmware description language. The computer system issues the low-level instructions for accessing the firmware register.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • The present application claims priority to U.S. Provisional Patent Application Ser. No. 60/518,026, entitled “Firmware Description Language For Accessing Firmware Registers”, filed Nov. 7, 2003, which is hereby incorporated by reference in its entirety. The present application claims priority to U.S. Provisional Patent Application Ser. No. 60/518,093, entitled “Using Description Files To Configure Components In A Distributed System”, filed Nov. 7, 2003, which is hereby incorporated by reference in its entirety.
  • BACKGROUND OF THE INVENTION
  • 1. The Field of the Invention
  • The present invention relates generally to data transmission systems and components. More particularly, embodiments of the present invention relate to a firmware description language for accessing firmware registers.
  • 2. The Relevant Technology
  • Nearly all computing devices include a processor and one or more registers. Registers are used to temporarily store data that is to be or has been processed by the processor. For example, when a computing device is to perform an addition operation, each input value is first stored in a register. The processor then retrieves the input values and calculates the sum of the input values. Then sum is then stored as an output value in a register. Execution of appropriate software at a computing device can cause values to be stored in and retrieved from registers.
  • In many computing environments, direct access to registers is not needed. For example, in a home or office computing environments, most users have no knowledge (and probably do not care) how registers operate. In these computing environments, system software (e.g., an operating system, compiler generated instructions, etc.) automatically controls access to registers. Automated control of registers allows users to operate most, if not all, applications (e.g., word processing, electronic mail, etc) without having knowledge of register operation.
  • Even programmers that program in high-level languages (e.g., C++, C#, Visual Basic) do not necessarily have to have any knowledge of register operation. For example, a programmer could write source code that multiplies two numbers together without having to include instructions that expressly reference any registers. During compilation of the source code into computer-executable instructions (e.g., machine code), the compiler would include additional computer-executable instructions for appropriately accessing registers.
  • However, in some environments, more direct control of registers is beneficial. For example, in network testing environments, network testing devices may need to be precisely configured for operation in many different (and sometimes adverse) network conditions. Configuring network testing devices can include modifying various configuration options based on current testing needs. Often, configuration options are represented by values stored in network testing device registers. Thus, a technician or administrator can change the values of network testing device registers to configure a network testing device. Since changes to network testing device registers may occur quite frequently, network testing devices often include software for interfacing directly with network testing device registers.
  • Development of register manipulation software for interfacing directly with network testing device registers typically includes a system programmer developing a series of functions for accessing appropriate registers. For example, a network testing device may be configured with a clock speed register for changing the network testing device's clock speed. Accordingly, the system programmer can develop a customized set clock function that directly accesses and changes the value stored in the clock speed register. Internal to the set clock function would be a hard-coded value representing the address of the clock speed register.
  • Register manipulation software can also include a number of other customized functions for changing other network testing device options (e.g., protocol, transmission speed, buffer sizes, etc). Accordingly, internal to each of these other customized functions would also be a hard-coded value representing the address of an appropriate register. Thus, as the number of configuration options increase, so does the number of customized functions included in a network testing device's register manipulation software. A coding error in any one customized function can cause a network test to fail or otherwise operate improperly (e.g., capture incorrect network traffic, store captured data in an incorrect buffer, etc). Since a customized function is typically utilized for each configuration option, network testing devices with increased numbers of configuration options have a corresponding increased chance of operating improperly during a test.
  • Therefore systems, methods, computer program products, and data structures for more efficient and reliable access to firmware registers would be advantageous.
  • BRIEF SUMMARY OF THE INVENTION
  • The foregoing problems with the prior state of the art are overcome by the principles of the present invention, which are directed towards methods, systems, computer program products, and data structures of a firmware description language for accessing firmware registers. Computer-readable media store a data structure representing a firmware description language. The firmware description language includes at least a blade type field containing a blade type value that represents a blade type and a register description field containing a one or more register configuration values for accessing a register at a blade of the blade type represented in the blade type field. The register description field can further include a register identifier field can containing a register identifier value that identifies the register, an address field containing an address value that can be used access the register, and an attributes field containing one or more attribute values used to configure the register. Attribute values can include, for example, a register type value, a bit mask value, a bit value, a field type value, a shift value, an increment, or a reference to one or more other registers, etc.
  • Computer systems can utilize the firmware description language to access firmware registers, for example, contained in a diagnostic chassis. In some embodiments, a computer system receives application instructions for accessing a firmware register. The computer system refers to the firmware description language to identify register attributes of the firmware register. The computer system generates low-level instructions for accessing the firmware register in accordance with register attributes referred to in the firmware description language. The computer system issues the low-level instructions for accessing the firmware register.
  • These and other objects and features of the present invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth hereinafter.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • To further clarify the above and other advantages and features of the present invention, a more particular description of the invention will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the invention and are therefore not to be considered limiting of its scope. The invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:
  • FIG. 1 illustrates an example of chassis architecture and associated modules and data structures for utilizing a firmware description language to access registers.
  • FIG. 2 illustrates an example data structure representing a firmware description language.
  • FIG. 3 illustrates an example chassis computer system architecture including a plurality of network diagnostic modules.
  • FIG. 4 illustrates a suitable operating environment for the principles of the present invention.
  • FIG. 5 illustrates an example of a network diagnostic module and diagnostic ports that can interoperate to implement a network diagnostic function.
  • FIG. 6 illustrates a flowchart of a method for a utilizing firmware description language to access registers.
  • FIG. 7A illustrates an example architecture for configuring a component in a distributed system.
  • FIG. 7B illustrates an example flow chart for utilizing the components and data in FIG. 7A to configure a component in a distributed system.
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
  • The principles of the present invention provide for a firmware description language for accessing firmware registers. Computer-readable media store a data structure representing a firmware description language. The firmware description language includes at least a blade type field containing a blade type value that represents a blade type and a register description field containing a one or more register configuration values for accessing a register at a blade of the blade type represented in the blade type field. The register description field can further include a register identifier field can containing a register identifier value that identifies the register, an address field containing an address value that can be used access the register, and an attributes field containing one or more attribute values used to configure the register. Attribute values can include, for example, a register type value, a bit mask value, a bit value, a field type value, a shift value, an increment, or a reference to one or more other registers, etc.
  • Computer systems can utilize the firmware description language to access firmware registers, for example, contained in diagnostic chassis. In some embodiments, a computer system receives application instructions for accessing a firmware register. The computer system refers to the firmware description language to identify register attributes of the firmware register. The computer system generates low-level instructions for accessing the firmware register in accordance with register attributes referred to in the firmware description language. The computer system issues the low-level instructions for accessing the firmware register.
  • A diagnostic chassis contains one or more configurable network diagnostic modules (e.g., blades). Each network diagnostic module includes one or more programmable logic modules (e.g., one or more Field Programmable Gate Arrays (“FPGAs”)) that include circuitry for implementing any of a plurality of different network diagnostic functions (e.g., network analyzer, jammer, generator, bit rate error test, etc). Each programmable logic module controls one or more test ports that provide interfaces for different physical configurations (e.g., Gigabit Ethernet, Fiber Distributed Data Interface, Fiber Channel, etc.) and that can interoperate with the programmable logic module to implement a selected network diagnostic function. In some embodiments, a network diagnostic module is included in a printed circuit board (hereinafter referred to as a “card” or “blade”) that is inserted into an appropriate receptacle at a chassis (e.g., using a Peripheral Component Interconnect (“PCI”) interface). Accordingly, the network diagnostic module may exchange data through electrical contacts of the receptacle.
  • Generally, a network diagnostic module receives a bit file with instructions for implementing a selected diagnostic function at one or more test ports that interface with a network. A bit file can be received from a mass storage device or even from a memory location at the network diagnostic module. Instructions can include computer-executable or computer-interpretable code that is processed by the network diagnostic module to implement the selected network diagnostic function.
  • The network diagnostic module identifies a programmable logic module (e.g., an FPGA) that controls the one or more test ports. The network diagnostic module loads the included instructions at the identified programmable logic module to cause the programmable logic module and the one or more test ports to interoperate to implement the selected diagnostic function. Accordingly, instructions contained in a bit file can be loaded at an FPGA to cause the FPGA to implement any of a network analyzer, jammer, bit error rate tester, generator, etc. When a new implementation is desired (e.g., changing from a jammer to a bit error rate tester) instructions from a new bit file can be loaded.
  • It may be that a network diagnostic function is part of a “port personality” represented in a bit file. For example, a port personality can include a network diagnostic function, a speed (e.g., 1.065, 2.5, or 10.3125 Gigabits per second), and a protocol (e.g., Fiber Channel, Gigabit Ethernet, Infiniband, etc). Thus, a programmable logic module can process computer-executable or computer-interpretable instructions to cause a programmable logic module and a corresponding test port or test ports to interoperate to implement a port personality in accordance with the processed computer-executable or computer-interpretable instructions. For example, a programmable logic module can process instructions from a bit file to cause the programmable logic module and corresponding test ports to interoperate to implement a Fibre Channel jammer at 2.125 Gb/s. Accordingly, the personality of the corresponding test ports can include implementation of a particular network diagnostic function.
  • In some embodiments, a number of network diagnostic modules are included in a common chassis computer system. Thus, chassis computer systems with increased numbers of flexibly configurable test ports can be utilized to test a network. A common chassis computer system can include a mass storage interface for transferring network diagnostic data to and/or from a mass storage device, a trigger port for detecting the occurrence of events, an interconnect port for connecting to other chasses, and a remote access port for receiving commands from remote computer systems. Connected chasses can exchange control signals over links between corresponding interconnect ports. Accordingly, network diagnostic modules at a number of different chasses can be controlled from any of the other chasses. Connecting a number of chasses together can further increase the number test ports utilized to test a network.
  • FIG. 1 illustrates an example of chassis architecture 100 and associated modules and data structures for utilizing a firmware description language accordance with the principles of the present invention. FIG. 1 depicts chassis 101. Chassis 101 can be connected to a Local Area Network (“LAN”), Wide Area Network (“WAN”) or even the Internet. Chassis 101 can utilize the network to compatibility transfer electronic messages in accordance with any number of different protocols, such as, for example, Internet Protocol (“IP”) and other protocols (e.g., Transmission Control Protocol (“TCP”), Simple Mail Transfer Protocol (“SMTP”), and HyperText Transfer Protocol (“HTTP”)) that utilize IP. Chassis 101 (which may be a chassis computer system) includes firmware access module 106, register 117 (vertical ellipsis 167, a series of three periods, indicates that other registers can be included), blade 111, and blade 141.
  • Blade 111 includes bus interface 114, control module 113, register 112 (vertical ellipsis 168 indicates additional registers can be included), memory modules 116 and 126, programmable logic modules 111 and 127, and ports 122, 123, 132, and 133. Programmable logic module 117 includes clock 118 and registers 119 and 121 (vertical ellipsis 163 indicates additional registers can be included). Programmable logic module 117 can be configured (e.g., by changing values in registers 119 and 121) to interoperate with ports 122 and 123 to implement various diagnostic functions. Similarly, programmable logic module 127 includes clock 128 and registers 129 and 131 (vertical ellipsis 164 indicates additional registers can be included). Programmable logic module 127 can be configured (e.g., by changing values in registers 129 and 131) to interoperate with ports 132 and 133 to implement various diagnostic functions.
  • Blade 141 includes bus interface 144, control module 143, register 142 (vertical ellipsis 169 indicates additional registers can be included), memory modules 146, programmable logic modules 147, and port 152. Programmable logic module 147 includes clock 148 and registers 149 and 151 (vertical ellipsis 166 indicates additional registers can be included). Programmable logic module 147 can be configured (e.g., by changing values in registers 149 and 141) to interoperate with port 152 to implement various diagnostic functions.
  • Blade 111 and blade 141 can be different types of blades. Further, vertical ellipsis 162 represents that chassis 112 can include one or more additional blades. Each blade at chassis 112 can include one or more programmable logic modules that are currently interoperating with one or more ports to implement network diagnostic functions. For example, programmable logic module 127 can be interoperating with test ports 132 and 133 to implement a Fibre Channel jammer. Likewise, programmable logic module 147 can be interoperating with test port 152 to implement a Gigabit Ethernet generator.
  • Firmware access module 106 can receive application instructions, such, as, for example, application instructions 104, from a computer system that is network connectable to chassis 101. Firmware access module 106 can refer to a firmware description language, such as, for example, firmware description language 102 to identify attributes (e.g., register type, offset, mask, etc.) for accessing firmware registers. Firmware description language 102 can be stored at mass storage device 103, which can be internal or external to chassis 101.
  • Firmware access module 106 can generate low-level instructions (e.g., assembly or machine level instructions) for appropriately accessing firmware registers in accordance with attributes contained in firmware description language 102. Firmware access module 106 can issue generated low-level instructions, such as, for example, low-level instructions 107, to access firmware registers (in accordance with attributes included in firmware description language 102). Low-level instructions 107 can be, for example, computer-executable instructions or circuit design data. Issuing low-level instructions can include sending low-level instructions to a blade (e.g., blade 111 or blade 141) or to chassis firmware registers (e.g., register 117). In some embodiments, firmware description language 102 is built into firmware access module 106.
  • It may be that hardware access module 106 receives mapped application instructions. For example, a mapping module can receive (unmapped) application instructions representing configuration settings that are to be implemented at a chassis 101 (e.g., by altering values of firmware registers at chassis 101, blade 111, and/or blade 141). The mapping-module can refer to a register mapping (which can be internal or external to chassis 111) to identify registers that are to be manipulated to implement the received application instructions. The mapping module can generate mapped application instructions that include references to the identified registers (e.g., to register 131). The mapping module can send mapped application instructions (e.g., as application instructions 104) to firmware access module 106.
  • Firmware description language 102 can constrain the meaning of mapped application instructions. It may be that firmware description language 102 is a schema that defines data formats for mapped application instructions. For example, firmware description language 102 may be an extensible Markup Language (“XML”) schema that defines the data formats for application instructions 104. FIG. 2 depicts a data structure 200 representing an example of a firmware description language 201.
  • Firmware description language 201 includes blade type fields 202 and 212. Each of blade types fields can contain a value that represents a specific type of blade. For example, blade type field 202 can include a blade type value representing the blade type of blade 111 and blade type field 212 can include a value representing the blade type of blade 141. Vertical ellipsis 253 represents that firmware description language 201 can include additional blade type fields representing other blade types.
  • Blade type field 202 includes register description field 203. Register description field 203 can contain one or more register configuration values that describe a register included in the represented blade type represented (by the blade type value) in blade type field 202. For example, register description field 203 may describe register 121. Register description field 203 includes register identifier field 204, address field 206, and attributes field 207. Register identifier field 204 can contain a register identifier value (e.g., a register name) that identifies the register described in register description field 203. A register identifier value can include in received application instructions (e.g., application instructions 104). For example, register identifier field 204 can contain a register identifier value that identifies register 121. Address field 206 can contain an address value that represents a hardware address of the register identified by the register identifier value contained in register identifier field 204. For example, address field 206 can contain an address value (e.g., an address offset value) that represents a hardware address for register 121.
  • Attributes field 207 can contain one or more register attribute vales representing register attributes for the register identified (by the register identifier value) in register identifier field 204. For example, attributes field 207 can contain one or more register attribute values representing register attributes for accessing register 121. Attributes field 207 further includes register attributes 208 and 209 (the depicted vertical ellipses represent that other attributes can be included before, between, or after the register attributes 208 and 209). Each register attribute (e.g., a name/value pair) can contain an attribute value corresponding to a specified register attribute. Register attributes can be utilized along with an address value to access a register identified in a register identifier field. For example, attribute values in register attributes 208 and 209 can be used along with an address value in address field 206 to access the register identified (by the register identifier value) in register identifier field 204.
  • As depicted by vertical ellipsis 251, blade type field 202 can include other register description fields (e.g., for registers 119, 129, and 131) in addition to register description field 203.
  • Blade type field 212 includes register description field 213. Register description field 213 can contain one or more register configuration values that describe a register included in the blade type represented (by the blade type value) in blade type field 212. For example, register description field 213 may describe register 142. Register description field 213 includes register identifier field 214, address field 216, and attributes field 217.
  • Register identifier field 214 can contain a register identifier value (e.g., a register name) that identifies the register described in register description field 213. For example, register identifier field 214 can contain a register identifier value that identifies register 149. Address field 216 can contain an address value that represents a hardware address of the register identified by the register identifier value contained in register identifier field 214. For example, address field 216 can contain an address value (e.g., an address offset value) that represents a hardware address for register 149.
  • Attributes field 217 can contain one or more register attribute vales representing register attributes for the register identified (by the register identifier value) in register identifier field 214. For example, attributes field 217 can contain one or more register attribute values representing register attributes for accessing register 149. Attributes field 217 further includes register attributes 218 and 219 (the depicted vertical ellipses represent that other attributes can be included before, between, or after the register attributes 218 and 219). Each register attribute can contain an attribute value corresponding to a specified register attribute. Register attributes can be utilized along with an address value to access a register identified in a register identifier field. For example, attribute values in register attributes 218 and 219 can be used along with an address value in address field 216 to access the register identified (by the register identifier value) in register identifier field 214.
  • As depicted by vertical ellipsis 252, blade type field 212 can include, other register description fields (e.g., for register 151) in addition to register description field 213.
  • Attribute values can include a bit mask value, a bit value, a shift value, a max value (as well as other attributes, for example, as described in example A below). Attribute values can be used to identify portions of a register, such as, for example, the upper 8 bits of a 16 bit register. When more than one instance of a register is available, a register can also include an increment attribute. In some embodiments, a plurality of related registers (a register complex) is accessed with the same register name. Accordingly, the name value for a register can be converted to low-level instructions for accessing a register having any of these (and possibly other) characteristics.
  • FIG. 6 illustrates a flowchart of a method 600 for utilizing firmware description language to access registers. The method 600 will be described with respect to the data and modules in chassis architecture 100.
  • Method 600 includes an act of receiving application instructions for accessing a firmware register (act 601). For example, chassis 101 can receive application instructions 104 (e.g., XML instructions) and forward application instructions 104 to firmware access module 106. Firmware access module 106 can receive application instructions 104. Application instructions can be received from another module at chassis 101 (e.g., entered through a user-interface) or from another computer system that is network connectable to chassis 101.
  • Method 600 includes an act of referring to a firmware description language to identify register attributes of the firmware register (act 602). For example firmware access module 106 can refer to firmware description language 102 (or firmware description language 201) to identify register attributes corresponding to application instructions 104. Firmware description language 102 (and firmware description langue 201) can include XML instructions that abstract register attributes such that a developer can refer to the register attributes generally and need not have knowledge of the specific functionality of a particular firmware register.
  • Method 600 includes an act of generating low-level instructions for accessing the firmware register in accordance with register attributes referred to in the firmware description language (act 603). For example, firmware access module 106 can generate low-level instructions 107 in accordance with register attributes contained in firmware description language 102 (or, for example, register attributes 208, 209, etc. contained in firmware description language 201). Thus, firmware access module can utilize firmware description language 102 to convert application instructions 104 into low-level instructions 107.
  • Low-level instructions 107 can be of a format that is compatible with an appropriate firmware register. For example, if application instructions 104 are for accessing register 129, low-level instructions 107 can be of a format that is compatible with register 129. Accordingly, low-level instructions for accessing a firmware register can be generated automatically without a developing having to have knowledge of the specific functionality of a particular firmware register.
  • Method 600 includes an act of issuing the low-level instructions for accessing the register (act 604). For example, firmware access module 106 can send low-level instructions (e.g., register access and configuration commands), which implement the received application instructions 104, to the identified registers. For example, firmware access module 106 can send low-level instructions 107 that implement application instructions 104 to registers 108, 112, 119, 121, 129, 131, 142, 149 and/or 151 in accordance with values contained in firmware description language 102.
  • Low-level instructions 107 can include instructions that configure blade 111 or blade 141 to perform diagnostic functions. For example, low-level instructions 107 can include instructions for implementing an Infiniband BERT at test ports 122 and 123. Low-level instructions 107 can change the values stored in registers 119 and 121 (and possible other registers corresponding to programmable logic module 117) to implement the Infiniband BERT. Alternately, low-level instructions can include instructions that modify an existing configuration of a blade. For example, low-level instructions 107 may modify the speed of a Gigabit Ethernet Generator implemented at test port 152. Altering an existing configuration can include changing a register value, such as, for example, changing the value of register 149.
  • Some registers, such as, for example, register 117 can correspond to a chassis configuration. Other registers, such as, for example, registers 112 and 142 can correspond to a blade setting. Yet other registers, such as, for example, registers 119, 121, 129, 131, 149, and 151 can correspond to a programmable logic module. Low-level instructions 107 can include instructions for changing the value of any of these registers or other registers included in chassis 101 (e.g., indicated or represented by vertical ellipses). Accordingly, firmware description language 102 can include register description fields for appropriately accesses these other registers.
  • FIG. 7A illustrates an example architecture 700 for configuring a component in a distributed system. As depicted in architecture 700, computer system 701 includes client 702. Client 702 can be an application for generating application eXstensible Markup Language (“XML”) instructions, such as, for example, application XML 711. Firmware register description module 703 can receive application XML, such as, for example, application XML 711. Firmware register description module 703 can access application to firmware XML 712 and firmware description XML 713 from hardware access library 709. Application to firmware XML 712 and firmware description XML 713, can be description files (e.g., similar to description file 121) that were previously created by a computer system or program developer and included in hardware access library 709.
  • Firmware register description module 703 can map tags included in application XML 711 to appropriate values for configuring firmware 704 and hardware 706, based on further instructions included in application to firmware XML 712 and firmware description XML 713 (e.g., collectively representing a firmware description language). Firmware register description module 703 can generate bit file 714 based on the mapped tags and send bit file 714 to firmware 704 (a portion of a distributed component). Firmware 704 can receive and process bit file 714 and configure hardware 706 according to bit file 714, for example, to implement a network diagnostic function.
  • Firmware register description module 703 (which may be viewed as a server) is configured to reduce the ongoing development and maintenance required to support a plurality of different (and potentially optional) diagnostic subsystems. Subsystems with similar functionality are abstracted, for example, with an identical interface, even if the functionality is implemented differently. Support of new functionality or even new subsystems can be reduced to a minimalist description rather than a new procedural and potentially lengthy and complex implementation.
  • Firmware register description module 703 enables a developer to support a new distributed component, such as, for example, a blade, or new features on existing blades, with less lines of code and thus less possibility for error. Using firmware register description module 703, new features can be added with as little as a one line description of a firmware register to firmware description XML 712, and as little as one line to application to firmware XML 713. In some embodiments, no changes to executables are required, which reduces the testing burden. New distributed components can be supported by generating component specific firmware description XML and application to firmware XML, which abstract out distributed component differences and present a common interface to client 702. By reducing the amount of code, new features can be added faster and with less opportunity for failure.
  • FIG. 7B illustrates an example flow chart 750 for utilizing the components and data of architecture 700 to configure a component in a distributed system. Flow chart 750 will be described with respect to the components and data in architecture 700.
  • As previously described, firmware register description module 700 can receive command, such as, for example, an XML string, from client 702. For example, firmware register description module 703 can receive application XML 711 from client 702. As depicted in flow chart 750, application XML 711 can include computer-executable or computer-interpretable instructions 721 (one or more name/value pairs).
  • As previously described, firmware register description module 703 can be configured to understand the high level structure application XML 711. Firmware register description module 703 can locate the tags within XML instructions, which used to configure the distributed component firmware from a register mapping. For example, firmware register description module 703 can locate the <Features> tag within instructions 721.
  • The <Features> tag is looked up in the application to firmware XML 712. If the <Features> tag is not found it can be ignored. However, in the example, flow chart 750, the <Features> tag is found in instructions 722. The <Features> tag in instructions 722 describes how to interpret the <Features> tag in instructions 721. Instructions 722 map “settingA” and “settingB” from instructions 721 to to “RegisterA” and “RegisterB” respectively. Values for “settingA” and “settingB” (i.e., 51 and 52) are rewritten as values for “RegisterA” and “RegisterB” respectively.
  • “RegisterA” and “RegisterB” are in turn looked up in firmware description XML 713. Instructions 723 map “RegisterA” and “RegisterB” to offsets “0x0200” and “0x0204” respectively. These offset attributes for “RegisterA” and “RegisterB” describe the physical address that the values (i.e., 51 and 52) specified in instructions 712 are to be written to.
  • The end result can be a calls to distributed component routine, such as, for example:
      • distributed component->portWrite(addr, value); with addr set to 0x0200 and value set to 51; and
      • distributed component->portWrite(addr, value); with addr set to 0x0204 and value set to 52.
  • In the example, flow chart 750, the Feature, RegisterA, and RegisterB tokens were application specific and may not be included in firmware register description module 703 source code. Other tokens, such as, for example, memory-start, memorystop, SpeedReg, ModeReg, MemStartReg, MemStopReg, SpeedReg, ControlReg, ModeReg, DebugReg, XlateReg can also be applicaiotn spefic tokens. Application specific tokes can be soft tokens that are chosen by an author of corresponding XML instructions.
  • The following Examples A, B, and C are examples of description files that can be generated in accordance with the principles of the present invention. Tokens in Example A that are found in an engine (e.g., in firmware register description module 703) include: type, lliComplexParent, Register, attribute, lliRegister, offset. These constitute part of a firmware register description language.
  • EXAMPLE A Sample Firmware Description XML
  • <!-- Registers section. This section contains definitions for registers (or bit fields in registers) that have a single instance - and that stand alone, i.e. are not part of a group. --> <!— Registers The child elements of the Registers element (registers) are named after the registers listed in the firmware documentation. Each child element of Registers must have a unique name. The required attributes of the register elements depend on the kind of register being described. type=“int32” - The int32 type register is assumed. The only required attribute is offset, which is the address that would be passed to a CPort object to access the register. type=“BIT” - The BIT type has two required attributes (beyond the type=“BIT” attribute). reg=“registerelement” is the name of a int32 type register which holds this BIT register. bitvalue=“0x0001” is the value to be or'd in to set this bit_register, or nand'd out to clear the bit_register. Note that it is legal to specify more than one bit in the bitvalue. type=“Field” - The Field type is used to describe multi-bit fields in int32 registers. Like the BIT type, there is a required reg=“int32Registerelement” attribute. There are two more attributes which are required; shift=“numbitsToShift” and a max = “maxvalueofField”. Note that the max is used to clear out the field before the new value is or'd in, so the value of the max attribute should be an integer max = 2**n−1, where n is the width of the bitfield. type=“Match” The Match type describes Match registers. MatchMask strings are in the form “01XX” where the “XX”'s are don't cares, and all the other digits are to be matched. So when converting these match strings to firmware match values, the X's are set to 0. The Match type registers have an additional optional attribute byteLen=“4”, which defaults to 4, and is currently always 4 or 32. type=“Mask” The Mask type describe Mask registers. MatchMask strings are in the form “01XX” where the “XX”'s are don't cares, and all the other digits are to be matched. So when converting these matchMask strings to firmware mask values, the X's are set to 0, and all the other digits are set to F's. The Mask type registers have an additional optional attribute byteLen=“4”, which defaults to 4, and is currently always 4 or 32. Optional register attributes increment=“0x2000” The presence of the optional increment flag indicates that more than one instance of the register is available in the firmware. Access to successive elements is performed by multiplying the increment by the instance count and adding the result to the reg attribute value. Increment units can be in bytes. Complexes Complexes describe a collection of registers that are a related group. Because the subfunctions of the groups of registers are often repeated, the names of registers in a complex are not required to be globally unique. However, they may be unique within the complex in which they are found. When registers of type BIT and Field, are found in a complex group, the reg attribute can refer to a register which is in the same complex. Other Types of Register types include: PortDependantBIT, csr_int32, MatchMask SingleByte --> <Registers> <!-- Example Register descriptions -->  <RegisterA  offset=“0x0200”/>  <RegisterB  offset=“0x0204”/>  <otherregisterC  offset=“0x0208”/>  <otherregisterD  offset=“0x020C”/> <!-- End of Example Register descriptions -->  <aControlBit  type=“BIT” reg=“RegisterA” bitvalue=“0x4000”/>  <anotherControlBit type=“BIT” reg=“RegisterA” bitvalue=“0x2000”/  <controlState  type=“Field” reg=“RegisterB” shift=“0” max = “7”/> </Registers>
  • EXAMPLE B Sample Application to Firmware XML
  • <!— App2Firmware.XML contains information to help map AppClient XML messages to FRD.XML described hardware settings. --> <!-- TYPE LIST            default type - write value as int32 to register default bitType - write (value==“True”) to bit value constant - look up value under <Constants> element to write to register                             BitNegateRegister - write opposite of setting to specified register BitMatchValue - write truth value of (setting==matchValue) to specified register MB2B_AddTCLLIConstant - convert from MB's to Bytes and add to specificed TC_LLI constant and write to specified register --> <!-- ------------- Example Section - Features --------- --> <Features type=“Complex” lliComplexParent=“Registers” >  <Register lliRegister=“RegisterA” attribute=“speed” />  <Register lliRegister=“RegisterB” attribute=“mode” />  <Register lliRegister=“otherregisterC” attribute=“settingC” />  <Register lliRegister=“otherregisterD” attribute=“settingD” /> </Features> <!-- End of example --> </App2Firmware>
  • EXAMPLE C Sample Application XML
  • <APP_XML version=“0.1” date=“19/06/03” time=“13:38:50” type=“DomainCommand”>  <Configure>   <PortConfigure ipAddress=“10.32.0.74” bladeNumber=“1”   portNumber=“0” >    <Features speed = “51” mode = “0” />   </PortConfigure>  </Configure> </APP_XML>
  • As previously described, firmware access module 106 can receive application instructions 104 (possibly mapped application instructions). Chassis 101 can refer to a register mapping (e.g., as represented in Example B above) to identify registers that are to be manipulated (e.g., as represented in Example C above). The register mapping can be stored at a mass storage device (e.g., mass storage device 103), which can be internal or external to chassis 101.
  • It may be that firmware access module 106 receives unmapped application instructions and maps the application instructions to generate mapped application instructions. A mapping module (e.g. included in firmware access module 106) can generate mapped application instructions that more concretely identify the registers that are to be manipulated to implement the application instructions 104. For example, the mapping module can cause an attribute (e.g., speed or mode from Example C) to correspond to a register name (e.g., RegisterA or RegisterB from Example B). Depending on the type of blade, a register mapping can map attributes to different register names. For example, the speed attribute for a first blade may be mapped to RegisterA, while the speed attribute for a second blade is mapped to RegisterD. Thus, with an attribute name and value, the corresponding attribute can be mapped to the appropriate register for a specified blade type. For example, Firmware access module 106 can refer to firmware description XML (e.g., as represented in Example A above) to identify characteristics for accessing named registers (e.g., as represented in Example B above.
  • As previously described, firmware access module 106 generate low-level instructions 107 in accordance with register attributes contained in firmware description language 102. Thus, low-level instructions 107 can more concretely identify the registers that are to be manipulated to implement the application instructions 104. For example, firmware access module 106 can cause a register name (e.g., RegistersB or RegisterC from Example B) to correspond to a hardware address (e.g., 0x0204 or 0x0208 from Example A). Depending on the type of blade, firmware description language 102, can generate different low-level instructions. For example, RegisterA may refer to hardware address 0x0200 for a first blade, while the RegisterA refers to hardware address 0x020A.
  • However, through reference to firmware description language 102, firmware access module 106 can convert the register name into appropriate instructions for accessing a register at a specified type of blade. For example, firmware access module 106 may refer to blade type field 202 when directing low-level instructions 107 to blade 111 and may refer to blade type field 212 when directing low-level instructions 107 to blade 141. Register identifier field 204 and register identifier field 214 may both include a register identifier value of RegisterA.
  • Further, address field 206 can contain a first address value for accessing an appropriate register corresponding to RegisterA at blade 111 and address field 216 can contain an second address value (that may differ from the first address value) for accessing an appropriate register corresponding to RegisterA at blade 141. Thus, a user (or application) can generate the same application instruction for accessing a register independent of the blade type. Firmware acces module 106 utilizes firmware description language 102 (or firmware description langue 201) to generate appropriate low-level instructions for accessing the firmware register. Similarly, a developer can reuse code for generating an application instruction with a plurality of different blade types. That is, once code for generating an application instruction functions properly with one blade type, the same code can be reused with other different blade types without significant additional testing. Reusing code increases the efficiency of application development and reduces coding errors.
  • FIG. 3 illustrates an example computer system architecture 300 including a plurality of network diagnostic modules in accordance with the principles of the present invention. Depicted in computer system architecture 300 is chassis 350, which includes blades 301, 302, 303, and 304. Although not expressly depicted, each of blades 301, 302, 303, and 304 are coupled, through an appropriate bus interface, to a computer system bus of chassis 350. For example, each of blades 301, 302, 303, and 304 can include PCI bus interfaces that are inserted into PCI receptacles at chassis 350. Accordingly, computer-executable or computer-interpretable instructions can be transferred over the computer system bus to blades 301, 302, 303, and 304 to configure and re-configure corresponding test ports.
  • Blades coupled to a chassis can have different numbers and configurations of test ports. For example, depicted at blade 301 test ports 321, 322, 323 and 324 can each be SFP ports. Depicted at blade 303 test ports 327, 328 and 329 can be RJ-45 ports and test port 331 can be a 300-pin MSA port. Depicted at blade 302 test port 326 can be a 300-pin MSA port. Depicted at blade 304 test ports 361, 362, 363, and 364 can be SFP ports and test ports 365, 366, 367, and 368 can be RJ-45 ports. Accordingly, the test ports of chassis 350 can be simultaneously connected to the same or a variety of different networks, such as, for example, 10 Gigabit Ethernet, 100 Megabit Ethernet, Infiniband, and SONET networks, to implement the same or a variety of different network diagnostic functions.
  • Mass storage interface 307 can be an interface for coupling to mass storage devices. Accordingly, as network diagnostic data, for example, results of network diagnostic functions, is collected at blades 301, 302, 303, and 304, the network diagnostic data can be transferred to the mass storage device for storage. Statistics and logs resulting from network diagnostic functions can be stored at a coupled mass storage device. Mass storage interface 307 may be a Small Computer System Interface (“SCSI”) that is coupled to a SCSI hard drive.
  • Interconnect ports 311 and 312 (e.g., RJ-11 ports) can be utilized to connect chassis 350 to other chasses (not shown). Connections from chassis 350 to other chasses, for example, as illustrated by links 351 and 352, can be utilized to transfer control signals that coordinate the collection of network diagnostic data. For example, the collection of network diagnostic data for a network analyzer implemented in blade 304 can be coordinated with the collection of network diagnostic data for a bit error rate tester implemented at another chassis coupled to link 351. Accordingly, through the exchange of control signals, it may be that test ports at a plurality of different chasses are configured to implement network diagnostic functions in a coordinated manner.
  • Trigger input port 308 and trigger output port 309 (e.g., TTL ports) can be utilized to transfer trigger signals to and from chassis 350. Generally, trigger signals can indicate the occurrence of an event to a chassis. In response to the occurrence of an event, a chassis can activate or deactivate network diagnostic functionality. For example, it may be that a programmable logic module controlling test port 326 is implementing a bit error rate tester. However, it may be desirable to activate bit error rate testing of a network coupled to port 326 only when a particular computer system is transmitting data onto the network. An appropriate mechanism for detecting when the particular computer system is transmitting data can be utilized to generate a trigger signal.
  • When a trigger signal is received at trigger input port 308, bit error rate testing through port test 326 can be activated. When the trigger signal is not longer received at trigger input port 308, bit error rate testing through test port 326 can be deactivated. In some embodiments, for example, when a plurality of chasses are connected, trigger inputs and outputs of different chasses can be coupled together so that the chasses receive the same triggers. For example, trigger input port 308 can be coupled to a trigger output port of a chassis connected to link 351 and/or trigger output port 309 can be coupled to a trigger input port of a chassis connected to link 352. Accordingly, when test ports at a plurality of different chasses are configured to perform coordinated network diagnostic functions, the network diagnostic functions can be activated and deactivated in response to the same events.
  • Remote access port 313 (e.g., an RJ-45 port) can be utilized to remotely configure chassis 350. Through remote access port 313, chassis 350 can be coupled to a network, such as, for example, a Local Area Network (“LAN”) or Wide Area Network (“WAN”), along with one or more other computer systems (e.g., a computer system that sent application instructions 104). The other computer systems can utilize the network to access configuration information from chassis 350. The other computer systems can also initiate configuration requests to configure or re-configure ports included in chassis 350 and can request results of network diagnostic functions. Accordingly, an administrator or user at a remote computer system can configure the test ports of chassis 350 (as well as configuring test ports at other chasses connected to the network) to implement selected network diagnostic functions and can request collected results.
  • In some embodiments, a hardware description language defines similar (or the same) low-level instructions for accessing registers of similar types (or of the same type). Using similar definitions for similar registers reduces the coding burden and thus corresponding reduces the chance for error.
  • FIG. 4 illustrates a suitable operating environment for the principles of the present invention. FIG. 4 and the following discussion are intended to provide a brief, general description of a suitable computing environment in which the invention may be implemented. With reference to FIG. 4, an example system for implementing the invention includes a general-purpose computing device in the form of computer system 420.
  • Computer system 420 includes a processing unit 421, a system memory 422, and a system bus 423 that couples various system components including the system memory 422 to the processing unit 421. Processing unit 421 can execute computer-executable instructions designed to implement features of computer system 420, including features of the present invention. The system bus 423 may be any of several types of bus structures including a memory bus or memory-controller, a PCI bus, a peripheral bus, and a local bus using any of a variety of bus architectures. Computer system 420 can include one or more receptacles for receiving print circuit boards or “cards” that interface with system bus 423. System memory 422 includes read only memory (“ROM”) 424 and random access memory (“RAM”) 425. A basic input/output system (“BIOS”) 426, containing the basic routines that help transfer information between elements within the computer 420, such as during start-up, may be stored in ROM 424.
  • The computer system 420 may also include a magnetic hard disk drive 427 (e.g., a SCSI drive) for reading from and writing to a magnetic hard disk 439, a magnetic disk drive 428 for reading from or writing to a removable magnetic disk 429, and an optical disk drive 430 for reading from or writing to removable optical disk 431, such as, or example, a CD-ROM or other optical media. The magnetic hard disk drive 427, magnetic disk drive 428, and optical disk drive 430 are connected to the system bus 423 by hard disk drive interface 432, magnetic disk drive-interface 433, and optical drive interface 434, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer-executable instructions, data structures, program modules, and other data for computer system 420. Although the example environment described herein employs a magnetic hard disk 439, a removable magnetic disk 429 and a removable optical disk 431, other types of computer readable media for storing data can be used, including magnetic cassettes, flash memory cards, digital versatile disks, Bernoulli cartridges, RAMs, ROMs, and the like.
  • Program code means comprising one or more program modules may be stored on the hard disk 439, magnetic disk 429, optical disk 431, ROM 424 or RAM 425, including an operating system 435, one or more application programs 436, other program modules 437 (e.g., bit files), and program data 438. A user may enter commands and information into the computer system 420 through keyboard 440, pointing device 442, or other input devices (not shown), such as, for example, a microphone, joy stick, game pad, scanner, or the like. These and other input devices can be connected to the processing unit 421 through input/output interface 446 coupled to system bus 423. Alternatively, input devices can be connected by other interfaces, such as, for example, a parallel port, a game port, a universal serial bus (“USB”) port, or a Fire Wire port. A monitor 447 or other display device is also connected to system bus 423 via video adapter 448. Computer system 420 can also be connected to other peripheral output devices (not shown), such as, for example, speakers and printers.
  • Computer system 420 is connectable to networks, such as, for example, an office-wide or enterprise-wide computer network, an intranet, and/or the Internet. Computer system 420 can exchange data with external sources, such as, for example, remote computer systems, computer system chasses containing network diagnostic modules, remote applications, and/or remote databases over such a network.
  • Computer system 420 includes network interface 453, through which computer system 420 receives data from external sources and/or transmits data to external sources. As depicted in FIG. 4, network interface 453 facilitates the exchange of data with remote computer system 483 via link 451. Link 451 represents a portion of a network, and remote computer system 483 represents a node of the network.
  • Likewise, computer system 420 includes input/output interface 446, through which computer system 420 receives data from external sources and/or transmits data to external sources. Input/output interface 446 is coupled to modem 454, through which computer system 420 receives data from and/or transmits data to external sources. Alternately, modem 454 can be a Data Over Cable Service Interface Specification (“DOCSIS”) modem or digital subscriber lines (“DSL”) modem that is connected to computer system 420 through an appropriate interface. However, as depicted in FIG. 4, input/output interface 446 and modem 454 facilitate the exchange of data with remote computer system 493 via link 452. Link 452 represents a portion of a network, and remote computer system 493 represents a node of the network.
  • While FIG. 4 represents a suitable operating environment for the present invention, the principles of the present invention may be employed in any system that is capable of, with suitable modification if necessary, implementing the principles of the present invention. The environment illustrated in FIG. 4 is illustrative only and by no means represents even a small portion of the wide variety of environments in which the principles of the present invention may be implemented.
  • Modules of the present invention, as well as associated data, can be stored and accessed from any of the computer-readable media associated with computer system 420. For example, portions of such modules and portions of associated program data may be included in operating system 435, application programs 436, program modules 437 and/or program data 438, for storage in system memory 422. When a mass storage device, such as, for example, magnetic hard disk 439, is coupled to computer system 420, such modules and associated program data may also be stored in the mass storage device. In a networked environment, program modules and associated data depicted relative to computer system 420, or portions thereof, can be stored in remote memory storage devices, such as, for example, system memory and/or mass storage devices associated with remote computer system 483 and/or remote computer system 493. Execution of such modules may be performed in a distributed manner.
  • FIG. 5 illustrates an example of a network diagnostic module and test ports that can interoperate to implement a network diagnostic function. The network diagnostic module and test ports are implemented in blade 501, which can be a printed circuit board. Bus interface 502 can be inserted into an appropriate receptacle (e.g., a Peripheral Component Interconnect (“PCI”) interface) at a computer system to communicatively couple blade 501 to the computer system. Blade 501 can communicate (e.g., sending and receiving appropriate electrical signaling) with a corresponding computer system bus (e.g., a PCI bus) through bus interface 502.
  • Blade 501 includes memory 504 and programmable logic module 506 that control the functionality of test ports 508 and 509. Memory 504 can be any of a variety of different types of memory, such as, for example, Random Access Memory (“RAM”). Memory 504 can be used to store instructions for programmable logic module 506 and to buffer data that is transferred between programmable logic module 506 and control module 503. Programmable logic module 506 can be virtually any type of programmable circuit, such as, for example, a Field-Programmable Gate Array (“FPGA”), Programmable Logic Array (“PLA”), or other type programmable logic device. Programmable logic module 506 can include circuitry form implementing any of a plurality of network diagnostic functions (e.g., network analyzer, jammer, generator, or bit error rate tester, etc).
  • It may be that a network diagnostic function is part of a “port personality” represented in a bit file. For example, a port personality can include a network diagnostic function, a speed (e.g., 1.065, 2.5, or 10.3125 Gigabits per second), and a protocol (e.g., Fiber Channel, Gigabit Ethernet, Infiniband, etc). Accordingly, programmable logic module 106 can process computer-executable or computer-interpretable instructions to cause programmable logic module 506 and test port 508 and/or test port 509 to interoperate to implement a port personality in accordance with the processed computer-executable or computer-interpretable instructions. For example, programmable logic module 506 can process instructions from a bit file to cause programmable logic module 506 and test ports 508 and test port 509 to interoperate to implement a Fiber Channel jammer at 2.125 Gb/s. Accordingly, the personality of test port 508 and the personality of test port 509 can include implementation of a particular network diagnostic function.
  • It may that a plurality of test ports are utilized together to implement a particular network diagnostic function. For example, test ports 508 and 509 can be utilized together to implement a network analyzer. On the other hand, it may be a first test port is utilized to implement a first network diagnostic function, while a second different test port is simultaneously utilized to implement a second different network diagnostic function. For example, test port 508 can be utilized to implement a generator, while test port 509 is simultaneously utilized to implement a bit error rate tester. A bit file having appropriate instructions can be loaded at a programmable logic module 506 to cause test port 508 and test port 509 to simultaneously implement different network diagnostic functions. Clock 507 can coordinate the appropriate timing of data transferred to and from test port 508 and test port 509.
  • Blade 501 also includes memory 514 and programmable logic module 516 that control the functionality of test ports 518 and 519. Similar to memory 504, memory 514 can be any of a variety of different types of memory, such as, for example, Random Access Memory (“RAM”). Memory 514 can be used to store instructions for programmable logic module 516 and to buffer data that is transferred between programmable logic module 516 and control module 503. Similar to programmable logic module 506, programmable logic module 516 can be virtually any type of programmable circuit, such as, for example, a Field-Programmable Gate Array (“FPGA”), Programmable Logic Array (“PLA”), or other type programmable logic device. Similar to programmable logic module 506, programmable logic module 516 can include circuitry form implementing any of a plurality of network diagnostic functions (e.g., network analyzer, jammer, generator, or bit error rate tester, etc). Although not required, it may be that programmable module 506 and programmable logic module 516 are the same type of programmable logic module.
  • Similar to programmable logic module 506, programmable logic module 516 can process computer-executable or computer-interpretable instructions (e.g., instructions 536) to cause programmable logic module 516 and test port 518 and/or test port 519 to interoperate to implement a port personality (including network diagnostic function, speed, and protocol) in accordance with the processed computer-executable or computer-interpretable instructions. Test ports 518 and 519 can be utilized together to implement a particular network diagnostic function. On the other hand, test port 518 may be utilized to implement a first network diagnostic function, while test port 519 is utilize to implement a second different network diagnostic function. For example, programmable logic module 516 can process instructions from a bit file (e.g., bit file 527) to cause programmable logic module 516 and test ports 518 to interoperate to implement a Fiber Channel bit error rate test at 10.51875 Gb/s and to cause programmable logic module 516 and test ports 519 to interoperate to implement a Inifiband generator at 1.065 Gb/s. A bit file having appropriate instructions can be loaded at programmable logic module 516 to cause test port 518 and test port 519 to simultaneously implement different network diagnostic functions. Clock 517 can coordinate the appropriate timing of data transferred to and from test port 518 and test port 519.
  • Test ports of different programmable logic modules can be configured to implement the same personalities. For example, programmable logic module 506 may process instructions that that cause test ports 508 and 509 to implement a Gigabit Ethernet analyzer at 1.065 GB/s, while programmable logic module 516 also processes instructions that cause test ports 518 and 519 to implement a Gigabit Ethernet analyzer at 1.065 GB/s. On the hand, test ports of different programmable logic modules can be configured to implement different personalities. For example, programmable logic module 506 may process instructions that that cause test ports 508 and 509 to implement a Fiber Channel analyzer at 2.125 GB/s, while programmable logic module 516 processes instructions that cause test ports 518 and 519 to implement an Infiniband analyzer at 10.51875 GB/s.
  • Test ports 508, 509, 518 and 519 can be of virtually any physical configuration, such as, for example, RJ-11, RJ-45, small form-factor pluggable (“SFP”), Universal Serial Bus (“USB”), IEEE 1394 (Firewire), 300-pin MSA, etc. Test ports 508, 509, 518 and 519 can also be physically configured to receive virtually any type of cabling, such as, for example, cabling that carries electrical signals or carries optical signals. Although not required, it may be that ports controlled by the same programmable logic module are configured as the same type of port. For example, test ports 508 and 509 (both controlled by programmable logic module 506) may both be SFP ports configured to receive optical cable.
  • Control module 503 coordinates the transfer of data between bus interface 102 and memories 504 and 514. Control module 503 can translate data received from bus interface 502 (e.g., a PCI interface) into a format that can be processed by programmable logic modules included in blade 501. Likewise, control module 503 can translate data received from a programmable logic module into a format that can be compatibly transferred over a computer system bus (e.g., a PCI bus) that is communicatively coupled to bus interface 502. Based on received data (e.g., appropriate addressing information), control module 503 can also identify the programmable logic module that is associated with the received data. Accordingly, control module 503 can transfer at least a portion of the received data (e.g., computer-executable or computer-interpretable instructions) to the associated programmable logic module.
  • Generally, bit file 527 can include instructions (e.g., low level instructions 107) for configuring one or more ports of blade 501 to perform a network diagnostic function. Thus, bit file 527 may be generated by converting application instructions (e.g., application instructions 104) into low-level instructions in accordance with a firmware description language (e.g., firmware description language 102). Accordingly, bit file 527 can include appropriate instructions for altering register values of blade 501.
  • The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims (32)

1. At a computer system, a method for accessing a firmware registers, the method comprising:
an act of receiving application instructions for accessing a firmware register;
an act of referring to a firmware description language to identify register attributes of the firmware register;
an act of generating low-level instructions for accessing the firmware register in accordance with register attributes referred to in the firmware description language; and
an act of issuing the low-level instructions for accessing the firmware register.
2. The method as recited in claim 1, wherein the act of receiving application instructions for accessing a firmware register comprises an act of receiving application XML instructions.
3. The method as recited in claim 1, wherein the act of receiving application instructions for accessing a firmware register comprises an act of receiving application instructions for configuring a blade to implement a network diagnostic function.
4. The method as recited in claim 1, wherein the act of referring to a firmware description language to identify register attributes of the firmware register comprises an act of referring to a firmware description language that abstracts firmware register values from the underlying firmware registers such that different types of firmware registers can be accessed with essentially the same application instructions.
5. The method as recited in claim 1, wherein the act of referring to a firmware description language to identify register attributes of the firmware register comprises an act of referring to a register description field for a register type corresponding to the firmware register.
6. The method as recited in claim 1, wherein the act of referring to a firmware description language to identify register attributes of the firmware register comprises an act of referring to application to firmware XML instructions to identify attributes of the firmware register.
7. The method as recited in claim 1, wherein the act of referring to a firmware description language to identify register attributes of the firmware register comprises an act of referring to firmware description XML instructions to identify attributes of the firmware register.
8. The method as recited in claim 1, wherein the act of generating low-level instructions for accessing the firmware register in accordance with register attributes referred to in the firmware description language comprises an act of generating register access and configuration commands.
9. The method as recited in claim 1, wherein the act of generating low-level instructions for accessing the firmware register in accordance with register attributes referred to in the firmware description language comprises an act of generating low-level instructions to configure a blade to implement a network diagnostic function.
10. The method as recited in claim 9, wherein the act of generating low-level instructions to configure a blade to implement a network diagnostic function comprises an act of generating low-level instructions to configure a blade to implement a network diagnostic function, the network diagnostic function selected from among a network analyzer, a jammer, a generator, and a bit error rate tester.
11. The method as recited in claim 1, wherein the act of generating low-level instructions for accessing the firmware register in accordance with register attributes referred to in the firmware description language comprises an act of a firmware access module utilizing the firmware description language to convert the application instructions into low-level instructions of a format compatible with the firmware register.
12. The method as recited in claim 1, wherein the act of issuing the low-level instructions for accessing the firmware register comprises an act of issuing register access and configuration commands to a firmware register at a blade.
13. The method as recited in claim 1, wherein the act of issuing the low-level instructions for accessing the firmware register comprises an act of issuing low-level instructions to configure a blade to implement a network diagnostic function.
14. The method as recited in claim 13, wherein the act of issuing low-level instructions to configure a blade to implement a network diagnostic function comprises an act of issuing low-level instructions to configure a blade to implement a network diagnostic function, the network diagnostic function selected from among a network analyzer, a jammer, a generator, and a bit error rate tester.
15. A computer program product for use at a computer system, the computer program product for implementing a method for accessing a firmware registers, the computer program product comprising one or more computer-readable media having stored thereon computer-executable instructions that, when executed by a processor, cause the computer system to perform the following:
receive application instructions for accessing a firmware register;
refer to a firmware description language to identify register attributes of the firmware register;
generate low-level instructions for accessing the firmware register in accordance with register attributes referred to in the firmware description language; and
issue the low-level instructions for accessing the firmware register.
16. The computer program product as recited in claim 15, wherein computer-executable instructions that, when executed, cause the computer system to receive application instructions for accessing a firmware register comprise computer-executable instructions that, when executed, cause the computer system to receive application XML instructions.
17. The computer program product as recited in claim 15, wherein computer-executable instructions that, when executed, cause the computer system to receive application instructions for accessing a firmware register comprise computer-executable instructions that, when executed, cause the computer system to receive application instructions for configuring a blade to implement a network diagnostic function.
18. The computer program product as recited in claim 15, wherein computer-executable instructions that, when executed, cause the computer system to refer to a firmware description language to identify register attributes of the firmware register comprise computer-executable instructions that, when executed, cause the computer system to refer to a firmware description language that abstracts firmware register values from the underlying firmware registers such that different types of firmware registers can be accessed with essentially the same application instructions.
19. The computer program product as recited in claim 15, wherein computer-executable instructions that, when executed, cause the computer system to refer to a firmware description language to identify register attributes of the firmware register comprise computer-executable instructions that, when executed, cause the computer system to refer to a register description field for a register type corresponding to the firmware register.
20. The computer program product as recited in claim 15, wherein computer-executable instructions that, when executed, cause the computer system to generate low-level instructions for accessing the firmware register in accordance with register attributes referred to in the firmware description language comprise computer-executable instructions that, when executed, cause the computer system to generate low-level instructions to configure a blade to implement a network diagnostic function.
21. The computer program product as recited in claim 15, wherein computer-executable instructions that, when executed, cause the computer system to generate low-level instructions for accessing the firmware register in accordance with register attributes referred to in the firmware description language comprise computer-executable instructions that, when executed, cause a firmware access module to utilize the firmware description language to convert the application instructions into low-level instructions of a format compatible with the firmware register.
22. The computer program product as recited in claim 15, wherein computer-executable instructions that, when executed, cause the computer system to issue the low-level instructions for accessing the firmware register comprise computer-executable instructions that, when executed, cause the computer system to issue low-level instructions to configure a blade to implement a network diagnostic function.
23. One or more computer-readable media having stored thereon a data structure representing a firmware description language, the data structure comprising:
a blade type field containing a blade type value that represents a blade type; and
a register description field containing one or more register configuration values, the one or more register configuration values for accessing a register at a blade of the blade type represented in the blade type field.
24. The data structure representing a firmware description language as recited in claim 23, wherein the register description field is comprised of:
a register identifier field containing a register identifier value, the register identifier value representing a register identifier used in application instructions to refer to the register represented in the register description field.
25. The data structure representing a firmware description language as recited in claim 23, wherein the register description field is comprised of:
an address field containing an address value, the address value representing an address used to access the register represented in the register description field.
26. The data structure representing a firmware description language as recited in claim 23, wherein the register description field is comprised of:
an attributes field containing one or more attribute values, the one or more attribute values used to access the register represented in the register description field.
27. The data structure representing a firmware description language as recited in claim 26, wherein the attributes field is comprised of:
a register attribute field containing a register attribute value, the register attribute value representing at least one attribute for accessing the register description field.
28. The data structure representing a firmware description language as recited in claim 27, wherein the register attribute field is comprised of:
a register attribute field containing a register attribute value, the register attribute value selected from among a register type value, a bit mask value, a bit value, a field type value, a shift value, and an increment.
29. The data structure representing a firmware description language as recited in claim 27, wherein the register attribute field is comprised of:
a register attribute field containing a reference to one or more other registers related to the register represented in the register description field.
30. The data structure representing a firmware description language as recited in claim 23, wherein the firmware description language is further comprised of:
a second blade type field containing a second blade type value that represents a second blade type.
31. The data structure representing a firmware description language as recited in claim 23, wherein the firmware description language is further comprised of:
a second register description field containing one or more second register configuration values, the one or more second register configuration values for accessing a second register at a blade of the second blade type represented in the second blade type field.
32. One or more computer-readable media having stored thereon a data structure representing a firmware description language, the data structure comprising:
a plurality of blade type fields containing a plurality of corresponding blade type values, each blade type value representing a different blade type; and
each blade type field including a plurality of a register description fields containing a one or more corresponding register configuration values, each of the one or more register configuration values for accessing a register at a blade of the blade type represented in the blade type field such that similar application instructions can be used to implement similar functionality at different blade types.
US10/974,291 2003-11-07 2004-10-27 Firmware description language for accessing firmware registers Abandoned US20050102488A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US51802603P true 2003-11-07 2003-11-07
US51809303P true 2003-11-07 2003-11-07
US10/974,291 US20050102488A1 (en) 2003-11-07 2004-10-27 Firmware description language for accessing firmware registers

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/974,291 US20050102488A1 (en) 2003-11-07 2004-10-27 Firmware description language for accessing firmware registers

Publications (1)

Publication Number Publication Date
US20050102488A1 true US20050102488A1 (en) 2005-05-12

Family

ID=34557405

Family Applications (2)

Application Number Title Priority Date Filing Date
US10/974,291 Abandoned US20050102488A1 (en) 2003-11-07 2004-10-27 Firmware description language for accessing firmware registers
US10/980,004 Active 2027-03-05 US7603444B2 (en) 2003-11-07 2004-11-03 Using description files to configure components in a distributed system

Family Applications After (1)

Application Number Title Priority Date Filing Date
US10/980,004 Active 2027-03-05 US7603444B2 (en) 2003-11-07 2004-11-03 Using description files to configure components in a distributed system

Country Status (1)

Country Link
US (2) US20050102488A1 (en)

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050081023A1 (en) * 2003-10-09 2005-04-14 Bullis George Anthony Creating description files used to configure components in a distributed system
US20090282229A1 (en) * 2008-05-08 2009-11-12 International Business Machines Corporation Conditional inclusion of resources in a computer system configuration
US20110191632A1 (en) * 2010-02-04 2011-08-04 Gary Miller Small form factor pluggable (sfp) checking device for reading from and determining type of inserted sfp transceiver module or other optical device
US8261050B2 (en) 2008-05-08 2012-09-04 International Business Machines Corporation Vital product data collection during pre-standby and system initial program load
DE102013212842A1 (en) 2013-07-02 2015-01-08 Robert Bosch Gmbh Method for operating a control device and control device with a model calculation unit
US20170093682A1 (en) * 2015-09-25 2017-03-30 Contec, Llc Universal Device Testing System
US9810735B2 (en) 2015-09-25 2017-11-07 Contec, Llc Core testing machine
US9838295B2 (en) 2015-11-23 2017-12-05 Contec, Llc Wireless routers under test
US9900116B2 (en) 2016-01-04 2018-02-20 Contec, Llc Test sequences using universal testing system
US9900113B2 (en) 2016-02-29 2018-02-20 Contec, Llc Universal tester hardware
US9992084B2 (en) 2015-11-20 2018-06-05 Contec, Llc Cable modems/eMTAs under test
US10122611B2 (en) 2015-09-25 2018-11-06 Contec, Llc Universal device testing interface
US10158553B2 (en) 2015-09-25 2018-12-18 Contec, Llc Systems and methods for testing electronic devices using master-slave test architectures
US10291959B2 (en) 2015-09-25 2019-05-14 Contec, Llc Set top boxes under test
US10320651B2 (en) 2015-10-30 2019-06-11 Contec, Llc Hardware architecture for universal testing system: wireless router test

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8065399B2 (en) 2000-04-17 2011-11-22 Circadence Corporation Automated network infrastructure test and diagnostic system and method therefor
US20060198318A1 (en) * 2005-02-01 2006-09-07 Schondelmayer Adam H Network diagnostic systems and methods for statistical triggering
US20060198319A1 (en) * 2005-02-01 2006-09-07 Schondelmayer Adam H Network diagnostic systems and methods for aggregated links
US20060200711A1 (en) * 2005-02-01 2006-09-07 Schondelmayer Adam H Network diagnostic systems and methods for processing network messages
US8107822B2 (en) 2005-05-20 2012-01-31 Finisar Corporation Protocols for out-of-band communication
US20080075103A1 (en) * 2005-05-20 2008-03-27 Finisar Corporation Diagnostic device
US20060264178A1 (en) * 2005-05-20 2006-11-23 Noble Gayle L Wireless diagnostic systems
US20070038880A1 (en) * 2005-08-15 2007-02-15 Noble Gayle L Network diagnostic systems and methods for accessing storage devices
US20070038881A1 (en) * 2005-08-15 2007-02-15 Finisar Corporation Network diagnostic systems and methods for accessing storage devices
US20070211697A1 (en) * 2006-03-13 2007-09-13 Finisar Corporation Method of analyzing network with generated traffic
US20070211696A1 (en) * 2006-03-13 2007-09-13 Finisar Corporation Method of generating network traffic
US7899057B2 (en) * 2006-04-28 2011-03-01 Jds Uniphase Corporation Systems for ordering network packets
US20070260728A1 (en) * 2006-05-08 2007-11-08 Finisar Corporation Systems and methods for generating network diagnostic statistics
US8213333B2 (en) 2006-07-12 2012-07-03 Chip Greel Identifying and resolving problems in wireless device configurations
US8526821B2 (en) * 2006-12-29 2013-09-03 Finisar Corporation Transceivers for testing networks and adapting to device changes
US8102777B2 (en) * 2007-01-26 2012-01-24 Jds Uniphase Corporation Network diagnostic systems and methods for aggregated links
KR101552188B1 (en) * 2007-09-07 2015-09-10 삼성전자 주식회사 Method and apparatus for providing implicit variability rules for a component model and architecture design
US8145641B2 (en) * 2008-01-18 2012-03-27 Oracle International Corporation Managing feature data based on spatial collections
JP5208872B2 (en) * 2009-07-15 2013-06-12 日立オートモティブシステムズ株式会社 Memory diagnostic device for vehicle equipment control device
US8340120B2 (en) 2009-09-04 2012-12-25 Brocade Communications Systems, Inc. User selectable multiple protocol network interface device
US8769173B2 (en) * 2010-10-14 2014-07-01 International Business Machines Corporation Systems and methods for detecting supported small form-factor pluggable (SFP) devices
US9778915B2 (en) 2011-02-28 2017-10-03 Microsoft Technology Licensing, Llc Distributed application definition
US9990184B2 (en) 2011-03-25 2018-06-05 Microsoft Technology Licensing, Llc Distributed component model
US9465589B2 (en) 2011-04-05 2016-10-11 Microsoft Technology Licensing, Llc Stateful component authoring and execution
US8966321B2 (en) * 2012-05-09 2015-02-24 Ixia Logical port and layer protocol test configuration resource manager
WO2015061439A1 (en) * 2013-10-22 2015-04-30 Studio Weber + Associates Multifunctional power supply device

Citations (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5619702A (en) * 1994-05-25 1997-04-08 National Instruments Corporation Method and apparatus for programming registers using simplified commands
US20020034181A1 (en) * 2000-09-20 2002-03-21 Broadcom Corporation Switch assembly having multiple blades in a chassis
US20030041098A1 (en) * 1999-06-23 2003-02-27 Victor Lortz Network-based detection and display of product replacement information
US6539520B1 (en) * 2000-11-28 2003-03-25 Advanced Micro Devices, Inc. Systems and methods for generating hardware description code
US20030126260A1 (en) * 2001-11-21 2003-07-03 Husain Syed Mohammad Amir Distributed resource manager
US20030159124A1 (en) * 2002-02-20 2003-08-21 Fisher Rory L. System and method for generating integrated circuit boundary register description data
US6654914B1 (en) * 1999-05-28 2003-11-25 Teradyne, Inc. Network fault isolation
US20040006546A1 (en) * 2001-05-10 2004-01-08 Wedlake William P. Process for gathering expert knowledge and automating it
US20040066095A1 (en) * 2002-10-02 2004-04-08 Hewlett-Packard Company Apparatus for controlling transmissions to reduce electromagnetic interference in an electronic system
US20040098458A1 (en) * 2002-09-16 2004-05-20 Husain Syed Mohammad Amir Distributed computing infrastructure including multiple collaborative sessions
US20040255191A1 (en) * 2003-06-16 2004-12-16 International Business Machines Corporation Automated diagnostic service
US20050015755A1 (en) * 2003-07-18 2005-01-20 Agere Systems Incorporated System and method for automatically generating a hierarchical register consolidation structure
US6862563B1 (en) * 1998-10-14 2005-03-01 Arc International Method and apparatus for managing the configuration and functionality of a semiconductor design
US20050050189A1 (en) * 2003-08-26 2005-03-03 Yang Harold (Haoran) Accessing results of network diagnostic functions in a distributed system
US7069526B2 (en) * 1999-11-30 2006-06-27 Synplicity, Inc. Hardware debugging in a hardware description language
US7152123B2 (en) * 2002-12-23 2006-12-19 Micron Technology, Inc. Distributed configuration storage
US7185214B2 (en) * 2002-08-12 2007-02-27 Hewlett-Packard Development Company, L.P. System and method for load dependent frequency and performance modulation in bladed systems
US7334064B2 (en) * 2003-04-23 2008-02-19 Dot Hill Systems Corporation Application server blade for embedded storage appliance
US7421686B2 (en) * 1998-10-10 2008-09-02 Transitive Limited Program code conversion

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3833090A (en) * 1973-08-29 1974-09-03 R Georgianna Settable lugs for climbing racks
US4450936A (en) * 1983-05-18 1984-05-29 Interlake, Inc. Removable step for pallet rack
US4953662A (en) * 1989-01-17 1990-09-04 Porter William M Climbing apparatus
US5097925A (en) * 1990-06-14 1992-03-24 George T. Walker, Jr. Tree walker
US5234076A (en) * 1990-09-14 1993-08-10 Louk Robert L Tree stand
CA2077977C (en) * 1992-09-10 2002-01-29 Steven Normand Carriere Tree stand
US5862883A (en) * 1995-03-10 1999-01-26 Jennifer Carriere Tree stand
US6397973B1 (en) * 1998-01-09 2002-06-04 Summit Specialties, Inc. Non-climbing tree stand with cable attachment
US5975242A (en) * 1998-01-09 1999-11-02 Summit Specialties, Inc. Climbing tree stand with cable attachment
US6264000B1 (en) * 1999-01-29 2001-07-24 Usl Products Incorporated Tree stand and climbing devices
US6308801B1 (en) * 1999-02-04 2001-10-30 John D. Futch Tree climbing apparatus
US6269906B1 (en) * 1999-09-02 2001-08-07 Clark Equipment Company Twist lock holder or step
US6247553B1 (en) * 2000-01-20 2001-06-19 Darren L. Jones Step assembly for t-post, components therefor and methods of making the same
US6481529B1 (en) * 2000-10-13 2002-11-19 Barry Kent Voorhies Climbing tree stand
US6523642B1 (en) * 2001-09-05 2003-02-25 Buckshot, Inc. Adjustable tree stand
US6622823B2 (en) * 2002-01-09 2003-09-23 Ardisam, Inc. Tree climbing apparatus
US6698549B2 (en) * 2002-03-15 2004-03-02 Buckshot, Inc. Climbing tree stand

Patent Citations (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5619702A (en) * 1994-05-25 1997-04-08 National Instruments Corporation Method and apparatus for programming registers using simplified commands
US7421686B2 (en) * 1998-10-10 2008-09-02 Transitive Limited Program code conversion
US6862563B1 (en) * 1998-10-14 2005-03-01 Arc International Method and apparatus for managing the configuration and functionality of a semiconductor design
US6654914B1 (en) * 1999-05-28 2003-11-25 Teradyne, Inc. Network fault isolation
US20030041098A1 (en) * 1999-06-23 2003-02-27 Victor Lortz Network-based detection and display of product replacement information
US7069526B2 (en) * 1999-11-30 2006-06-27 Synplicity, Inc. Hardware debugging in a hardware description language
US20020034181A1 (en) * 2000-09-20 2002-03-21 Broadcom Corporation Switch assembly having multiple blades in a chassis
US7466704B2 (en) * 2000-09-20 2008-12-16 Broadcom Corporation Switch assembly having multiple blades in a chassis
US6539520B1 (en) * 2000-11-28 2003-03-25 Advanced Micro Devices, Inc. Systems and methods for generating hardware description code
US20040006546A1 (en) * 2001-05-10 2004-01-08 Wedlake William P. Process for gathering expert knowledge and automating it
US20030126260A1 (en) * 2001-11-21 2003-07-03 Husain Syed Mohammad Amir Distributed resource manager
US20030159124A1 (en) * 2002-02-20 2003-08-21 Fisher Rory L. System and method for generating integrated circuit boundary register description data
US7185214B2 (en) * 2002-08-12 2007-02-27 Hewlett-Packard Development Company, L.P. System and method for load dependent frequency and performance modulation in bladed systems
US20040098458A1 (en) * 2002-09-16 2004-05-20 Husain Syed Mohammad Amir Distributed computing infrastructure including multiple collaborative sessions
US20040066095A1 (en) * 2002-10-02 2004-04-08 Hewlett-Packard Company Apparatus for controlling transmissions to reduce electromagnetic interference in an electronic system
US7152123B2 (en) * 2002-12-23 2006-12-19 Micron Technology, Inc. Distributed configuration storage
US7334064B2 (en) * 2003-04-23 2008-02-19 Dot Hill Systems Corporation Application server blade for embedded storage appliance
US20040255191A1 (en) * 2003-06-16 2004-12-16 International Business Machines Corporation Automated diagnostic service
US20050015755A1 (en) * 2003-07-18 2005-01-20 Agere Systems Incorporated System and method for automatically generating a hierarchical register consolidation structure
US20050050189A1 (en) * 2003-08-26 2005-03-03 Yang Harold (Haoran) Accessing results of network diagnostic functions in a distributed system

Cited By (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7222313B2 (en) * 2003-10-09 2007-05-22 Finisar Corporation Creating description files used to configure components in a distributed system
US20050081023A1 (en) * 2003-10-09 2005-04-14 Bullis George Anthony Creating description files used to configure components in a distributed system
US8261050B2 (en) 2008-05-08 2012-09-04 International Business Machines Corporation Vital product data collection during pre-standby and system initial program load
US8423584B2 (en) 2008-05-08 2013-04-16 International Business Machines Corporation Conditional inclusion of resources in a computer system configuration
US20090282229A1 (en) * 2008-05-08 2009-11-12 International Business Machines Corporation Conditional inclusion of resources in a computer system configuration
US8566643B2 (en) 2010-02-04 2013-10-22 Hubbell Incorporated Small form factor pluggable (SFP) checking device for reading from and determining type of inserted SFP transceiver module or other optical device
US20110191632A1 (en) * 2010-02-04 2011-08-04 Gary Miller Small form factor pluggable (sfp) checking device for reading from and determining type of inserted sfp transceiver module or other optical device
US9785410B2 (en) 2013-07-02 2017-10-10 Robert Bosch Gmbh Method for operating a control unit and a control unit having a model calculation unit
DE102013212842A1 (en) 2013-07-02 2015-01-08 Robert Bosch Gmbh Method for operating a control device and control device with a model calculation unit
US10122611B2 (en) 2015-09-25 2018-11-06 Contec, Llc Universal device testing interface
US9810735B2 (en) 2015-09-25 2017-11-07 Contec, Llc Core testing machine
US10298483B2 (en) 2015-09-25 2019-05-21 Contec, Llc Universal device testing interface
US20170093682A1 (en) * 2015-09-25 2017-03-30 Contec, Llc Universal Device Testing System
US10291959B2 (en) 2015-09-25 2019-05-14 Contec, Llc Set top boxes under test
US9960989B2 (en) * 2015-09-25 2018-05-01 Contec, Llc Universal device testing system
US10277497B2 (en) 2015-09-25 2019-04-30 Contec, Llc Systems and methods for testing electronic devices using master-slave test architectures
US10158553B2 (en) 2015-09-25 2018-12-18 Contec, Llc Systems and methods for testing electronic devices using master-slave test architectures
US10320651B2 (en) 2015-10-30 2019-06-11 Contec, Llc Hardware architecture for universal testing system: wireless router test
US9992084B2 (en) 2015-11-20 2018-06-05 Contec, Llc Cable modems/eMTAs under test
US10230617B2 (en) 2015-11-23 2019-03-12 Contec, Llc Wireless routers under test
US9838295B2 (en) 2015-11-23 2017-12-05 Contec, Llc Wireless routers under test
US10116397B2 (en) 2016-01-04 2018-10-30 Contec, Llc Test sequences using universal testing system
US9900116B2 (en) 2016-01-04 2018-02-20 Contec, Llc Test sequences using universal testing system
US9900113B2 (en) 2016-02-29 2018-02-20 Contec, Llc Universal tester hardware

Also Published As

Publication number Publication date
US7603444B2 (en) 2009-10-13
US20050114083A1 (en) 2005-05-26

Similar Documents

Publication Publication Date Title
Corbet et al. Linux Device Drivers: Where the Kernel Meets the Hardware
JP6194252B2 (en) Process control system
US7263632B2 (en) Programmatic computer problem diagnosis and resolution and automated reporting and updating of the same
EP1658692B1 (en) Multi-purpose network diagnostic modules
EP0585082B1 (en) Computer management system and associated management information base
DE60010011T2 (en) Method and device for testing a computer system by software error injection
US7603471B2 (en) Protocol adapter for transferring diagnostic signals between in-vehicle networks and a computer
US7650592B2 (en) Systems and methods for multi-view debugging environment
US8555238B2 (en) Programming and development infrastructure for an autonomic element
US7428606B2 (en) Method, system and apparatus to allow users to remotely mount USB devices and access KVM through a server interface pod (SIP)
US6892231B2 (en) Method and apparatus for verifying the contents of a global configuration file
US7028175B2 (en) System and method for computer hardware identification
US6393341B1 (en) Architecture neutral device abstraction layer for interfacing devices and applications
DE60113780T2 (en) Method and apparatus for tracking hardware states with dynamic reconfigurable test circuits
US7793019B1 (en) Redirecting input and output for multiple computers
US20050086644A1 (en) Method and system for debugging a program
US20030177477A1 (en) Java to NSMP MIB mapping
US7386609B2 (en) Method, system, and program for managing devices in a network
US5999941A (en) Database access using active server pages
EP0751656A2 (en) Protocol independent and adaptive network interface
US20030159137A1 (en) Remote validation of installation input data
US6418392B1 (en) System and method for simulating operations of an instrument
US7844866B2 (en) Mechanism to report operating system events on an intelligent platform management interface compliant server
US5963726A (en) Instrumentation system and method including an improved driver software architecture
US6964034B1 (en) Application development server and a mechanism for providing different views into the same constructs within a strongly encapsulated environment

Legal Events

Date Code Title Description
AS Assignment

Owner name: FINISAR CORPORATION, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:BULLIS, GEORGE ANTHONY;REEL/FRAME:015939/0947

Effective date: 20041026

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO PAY ISSUE FEE