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

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 inFIG. 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 ofchassis architecture100 and associated modules and data structures for utilizing a firmware description language accordance with the principles of the present invention.FIG. 1 depictschassis101.Chassis101 can be connected to a Local Area Network (“LAN”), Wide Area Network (“WAN”) or even the Internet.Chassis101 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. Chassis101 (which may be a chassis computer system) includesfirmware access module106, register117 (vertical ellipsis167, a series of three periods, indicates that other registers can be included),blade111, andblade141.
• Blade111 includes bus interface114,control module113, register112 (vertical ellipsis168 indicates additional registers can be included),memory modules116 and126,programmable logic modules111 and127, andports122,123,132, and133.Programmable logic module117 includesclock118 andregisters119 and121 (vertical ellipsis163 indicates additional registers can be included).Programmable logic module117 can be configured (e.g., by changing values inregisters119 and121) to interoperate withports122 and123 to implement various diagnostic functions. Similarly,programmable logic module127 includesclock128 andregisters129 and131 (vertical ellipsis164 indicates additional registers can be included).Programmable logic module127 can be configured (e.g., by changing values inregisters129 and131) to interoperate withports132 and133 to implement various diagnostic functions.
• Blade141 includes bus interface144,control module143, register142 (vertical ellipsis169 indicates additional registers can be included),memory modules146,programmable logic modules147, andport152.Programmable logic module147 includesclock148 andregisters149 and151 (vertical ellipsis166 indicates additional registers can be included).Programmable logic module147 can be configured (e.g., by changing values inregisters149 and141) to interoperate withport152 to implement various diagnostic functions.
• Blade111 andblade141 can be different types of blades. Further,vertical ellipsis162 represents thatchassis112 can include one or more additional blades. Each blade atchassis112 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 module127 can be interoperating withtest ports132 and133 to implement a Fibre Channel jammer. Likewise,programmable logic module147 can be interoperating withtest port152 to implement a Gigabit Ethernet generator.
• Firmware access module106 can receive application instructions, such, as, for example,application instructions104, from a computer system that is network connectable tochassis101.Firmware access module106 can refer to a firmware description language, such as, for example,firmware description language102 to identify attributes (e.g., register type, offset, mask, etc.) for accessing firmware registers.Firmware description language102 can be stored atmass storage device103, which can be internal or external tochassis101.
• Firmware access module106 can generate low-level instructions (e.g., assembly or machine level instructions) for appropriately accessing firmware registers in accordance with attributes contained infirmware description language102.Firmware access module106 can issue generated low-level instructions, such as, for example, low-level instructions107, to access firmware registers (in accordance with attributes included in firmware description language102). Low-level instructions107 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.,blade111 or blade141) or to chassis firmware registers (e.g., register117). In some embodiments,firmware description language102 is built intofirmware access module106.
• It may be thathardware access module106 receives mapped application instructions. For example, a mapping module can receive (unmapped) application instructions representing configuration settings that are to be implemented at a chassis101 (e.g., by altering values of firmware registers atchassis101,blade111, and/or blade141). The mapping-module can refer to a register mapping (which can be internal or external to chassis111) 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 register131). The mapping module can send mapped application instructions (e.g., as application instructions104) tofirmware access module106.
• Firmware description language102 can constrain the meaning of mapped application instructions. It may be thatfirmware description language102 is a schema that defines data formats for mapped application instructions. For example,firmware description language102 may be an extensible Markup Language (“XML”) schema that defines the data formats forapplication instructions104.FIG. 2 depicts a data structure200 representing an example of afirmware description language201.
• Firmware description language201 includes blade type fields202 and212. Each of blade types fields can contain a value that represents a specific type of blade. For example,blade type field202 can include a blade type value representing the blade type ofblade111 andblade type field212 can include a value representing the blade type ofblade141.Vertical ellipsis253 represents thatfirmware description language201 can include additional blade type fields representing other blade types.
• Blade type field202 includes register description field203. Register description field203 can contain one or more register configuration values that describe a register included in the represented blade type represented (by the blade type value) inblade type field202. For example, register description field203 may describeregister121. Register description field203 includesregister identifier field204,address field206, and attributesfield207.Register identifier field204 can contain a register identifier value (e.g., a register name) that identifies the register described in register description field203. A register identifier value can include in received application instructions (e.g., application instructions104). For example, registeridentifier field204 can contain a register identifier value that identifiesregister121.Address field206 can contain an address value that represents a hardware address of the register identified by the register identifier value contained inregister identifier field204. For example,address field206 can contain an address value (e.g., an address offset value) that represents a hardware address forregister121.
• Attributes field207 can contain one or more register attribute vales representing register attributes for the register identified (by the register identifier value) inregister identifier field204. For example, attributesfield207 can contain one or more register attribute values representing register attributes for accessingregister121. Attributes field207 further includes register attributes208 and209 (the depicted vertical ellipses represent that other attributes can be included before, between, or after the register attributes208 and209). 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 attributes208 and209 can be used along with an address value inaddress field206 to access the register identified (by the register identifier value) inregister identifier field204.
• As depicted byvertical ellipsis251,blade type field202 can include other register description fields (e.g., forregisters119,129, and131) in addition to register description field203.
• Blade type field212 includesregister description field213.Register description field213 can contain one or more register configuration values that describe a register included in the blade type represented (by the blade type value) inblade type field212. For example, registerdescription field213 may describeregister142.Register description field213 includesregister identifier field214,address field216, and attributesfield217.
• Register identifier field214 can contain a register identifier value (e.g., a register name) that identifies the register described inregister description field213. For example, registeridentifier field214 can contain a register identifier value that identifiesregister149.Address field216 can contain an address value that represents a hardware address of the register identified by the register identifier value contained inregister identifier field214. For example,address field216 can contain an address value (e.g., an address offset value) that represents a hardware address forregister149.
• Attributes field217 can contain one or more register attribute vales representing register attributes for the register identified (by the register identifier value) inregister identifier field214. For example, attributesfield217 can contain one or more register attribute values representing register attributes for accessingregister149. Attributes field217 further includes register attributes218 and219 (the depicted vertical ellipses represent that other attributes can be included before, between, or after the register attributes218 and219). 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 attributes218 and219 can be used along with an address value inaddress field216 to access the register identified (by the register identifier value) inregister identifier field214.
• As depicted byvertical ellipsis252,blade type field212 can include, other register description fields (e.g., for register151) in addition to registerdescription field213.
• 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 amethod600 for utilizing firmware description language to access registers. Themethod600 will be described with respect to the data and modules inchassis architecture100.
• Method600 includes an act of receiving application instructions for accessing a firmware register (act601). For example,chassis101 can receive application instructions104 (e.g., XML instructions) andforward application instructions104 tofirmware access module106.Firmware access module106 can receiveapplication instructions104. Application instructions can be received from another module at chassis101 (e.g., entered through a user-interface) or from another computer system that is network connectable tochassis101.
• Method600 includes an act of referring to a firmware description language to identify register attributes of the firmware register (act602). For examplefirmware access module106 can refer to firmware description language102 (or firmware description language201) to identify register attributes corresponding toapplication instructions104. Firmware description language102 (and firmware description langue201) 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.
• Method600 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 (act603). For example,firmware access module106 can generate low-level instructions107 in accordance with register attributes contained in firmware description language102 (or, for example, register attributes208,209, etc. contained in firmware description language201). Thus, firmware access module can utilizefirmware description language102 to convertapplication instructions104 into low-level instructions107.
• Low-level instructions107 can be of a format that is compatible with an appropriate firmware register. For example, ifapplication instructions104 are for accessingregister129, low-level instructions107 can be of a format that is compatible withregister129. 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.
• Method600 includes an act of issuing the low-level instructions for accessing the register (act604). For example,firmware access module106 can send low-level instructions (e.g., register access and configuration commands), which implement the receivedapplication instructions104, to the identified registers. For example,firmware access module106 can send low-level instructions107 that implementapplication instructions104 toregisters108,112,119,121,129,131,142,149 and/or151 in accordance with values contained infirmware description language102.
• Low-level instructions107 can include instructions that configureblade111 orblade141 to perform diagnostic functions. For example, low-level instructions107 can include instructions for implementing an Infiniband BERT attest ports122 and123. Low-level instructions107 can change the values stored inregisters119 and121 (and possible other registers corresponding to programmable logic module117) to implement the Infiniband BERT. Alternately, low-level instructions can include instructions that modify an existing configuration of a blade. For example, low-level instructions107 may modify the speed of a Gigabit Ethernet Generator implemented attest port152. Altering an existing configuration can include changing a register value, such as, for example, changing the value ofregister149.
• Some registers, such as, for example, register117 can correspond to a chassis configuration. Other registers, such as, for example, registers112 and142 can correspond to a blade setting. Yet other registers, such as, for example, registers119,121,129,131,149, and151 can correspond to a programmable logic module. Low-level instructions107 can include instructions for changing the value of any of these registers or other registers included in chassis101 (e.g., indicated or represented by vertical ellipses). Accordingly,firmware description language102 can include register description fields for appropriately accesses these other registers.
• FIG. 7A illustrates an example architecture700 for configuring a component in a distributed system. As depicted in architecture700,computer system701 includesclient702.Client702 can be an application for generating application eXstensible Markup Language (“XML”) instructions, such as, for example,application XML711. Firmwareregister description module703 can receive application XML, such as, for example,application XML711. Firmwareregister description module703 can access application tofirmware XML712 andfirmware description XML713 fromhardware access library709. Application tofirmware XML712 andfirmware description XML713, can be description files (e.g., similar to description file121) that were previously created by a computer system or program developer and included inhardware access library709.
• Firmwareregister description module703 can map tags included inapplication XML711 to appropriate values for configuringfirmware704 andhardware706, based on further instructions included in application tofirmware XML712 and firmware description XML713 (e.g., collectively representing a firmware description language). Firmwareregister description module703 can generate bit file714 based on the mapped tags and send bit file714 to firmware704 (a portion of a distributed component).Firmware704 can receive and process bit file714 and configurehardware706 according to bit file714, for example, to implement a network diagnostic function.
• Firmware register description module703 (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.
• Firmwareregister description module703 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 firmwareregister description module703, new features can be added with as little as a one line description of a firmware register tofirmware description XML712, and as little as one line to application tofirmware XML713. 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 toclient702. By reducing the amount of code, new features can be added faster and with less opportunity for failure.
• FIG. 7B illustrates anexample flow chart750 for utilizing the components and data of architecture700 to configure a component in a distributed system.Flow chart750 will be described with respect to the components and data in architecture700.
• As previously described, firmware register description module700 can receive command, such as, for example, an XML string, fromclient702. For example, firmwareregister description module703 can receiveapplication XML711 fromclient702. As depicted inflow chart750,application XML711 can include computer-executable or computer-interpretable instructions721 (one or more name/value pairs).
• As previously described, firmwareregister description module703 can be configured to understand the high levelstructure application XML711. Firmwareregister description module703 can locate the tags within XML instructions, which used to configure the distributed component firmware from a register mapping. For example, firmwareregister description module703 can locate the <Features> tag withininstructions721.
• The <Features> tag is looked up in the application tofirmware XML712. If the <Features> tag is not found it can be ignored. However, in the example,flow chart750, the <Features> tag is found ininstructions722. The <Features> tag ininstructions722 describes how to interpret the <Features> tag ininstructions721.Instructions722 map “settingA” and “settingB” frominstructions721 to to “RegisterA” and “RegisterB” respectively. Values for “settingA” and “settingB” (i.e.,51 and52) are rewritten as values for “RegisterA” and “RegisterB” respectively.
• “RegisterA” and “RegisterB” are in turn looked up infirmware description XML713.Instructions723 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 and52) specified ininstructions712 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 chart750, the Feature, RegisterA, and RegisterB tokens were application specific and may not be included in firmwareregister description module703 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 module703) include: type, lliComplexParent, Register, attribute, lliRegister, offset. These constitute part of a firmware register description language.
EXAMPLE ASample 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 BSample 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 CSample 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 module106 can receive application instructions104 (possibly mapped application instructions).Chassis101 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 device103), which can be internal or external tochassis101.
• It may be thatfirmware access module106 receives unmapped application instructions and maps the application instructions to generate mapped application instructions. A mapping module (e.g. included in firmware access module106) can generate mapped application instructions that more concretely identify the registers that are to be manipulated to implement theapplication instructions104. 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 module106 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 module106 generate low-level instructions107 in accordance with register attributes contained infirmware description language102. Thus, low-level instructions107 can more concretely identify the registers that are to be manipulated to implement theapplication instructions104. For example,firmware access module106 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 language102, 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 tofirmware description language102,firmware access module106 can convert the register name into appropriate instructions for accessing a register at a specified type of blade. For example,firmware access module106 may refer toblade type field202 when directing low-level instructions107 toblade111 and may refer toblade type field212 when directing low-level instructions107 toblade141.Register identifier field204 and registeridentifier field214 may both include a register identifier value of RegisterA.
• Further,address field206 can contain a first address value for accessing an appropriate register corresponding to RegisterA atblade111 andaddress field216 can contain an second address value (that may differ from the first address value) for accessing an appropriate register corresponding to RegisterA atblade141. Thus, a user (or application) can generate the same application instruction for accessing a register independent of the blade type.Firmware acces module106 utilizes firmware description language102 (or firmware description langue201) 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 examplecomputer system architecture300 including a plurality of network diagnostic modules in accordance with the principles of the present invention. Depicted incomputer system architecture300 ischassis350, which includesblades301,302,303, and304. Although not expressly depicted, each ofblades301,302,303, and304 are coupled, through an appropriate bus interface, to a computer system bus ofchassis350. For example, each ofblades301,302,303, and304 can include PCI bus interfaces that are inserted into PCI receptacles atchassis350. Accordingly, computer-executable or computer-interpretable instructions can be transferred over the computer system bus toblades301,302,303, and304 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 atblade301test ports321,322,323 and324 can each be SFP ports. Depicted atblade303test ports327,328 and329 can be RJ-45 ports andtest port331 can be a 300-pin MSA port. Depicted atblade302test port326 can be a 300-pin MSA port. Depicted atblade304test ports361,362,363, and364 can be SFP ports andtest ports365,366,367, and368 can be RJ-45 ports. Accordingly, the test ports ofchassis350 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 interface307 can be an interface for coupling to mass storage devices. Accordingly, as network diagnostic data, for example, results of network diagnostic functions, is collected atblades301,302,303, and304, 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 interface307 may be a Small Computer System Interface (“SCSI”) that is coupled to a SCSI hard drive.
• Interconnect ports311 and312 (e.g., RJ-11 ports) can be utilized to connectchassis350 to other chasses (not shown). Connections fromchassis350 to other chasses, for example, as illustrated bylinks351 and352, 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 inblade304 can be coordinated with the collection of network diagnostic data for a bit error rate tester implemented at another chassis coupled to link351. 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 port308 and trigger output port309 (e.g., TTL ports) can be utilized to transfer trigger signals to and fromchassis350. 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 controllingtest port326 is implementing a bit error rate tester. However, it may be desirable to activate bit error rate testing of a network coupled toport326 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 attrigger input port308, bit error rate testing throughport test326 can be activated. When the trigger signal is not longer received attrigger input port308, bit error rate testing throughtest port326 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, triggerinput port308 can be coupled to a trigger output port of a chassis connected to link351 and/or triggeroutput port309 can be coupled to a trigger input port of a chassis connected to link352. 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 port313 (e.g., an RJ-45 port) can be utilized to remotely configurechassis350. Throughremote access port313,chassis350 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 instructions104). The other computer systems can utilize the network to access configuration information fromchassis350. The other computer systems can also initiate configuration requests to configure or re-configure ports included inchassis350 and can request results of network diagnostic functions. Accordingly, an administrator or user at a remote computer system can configure the test ports of chassis350 (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 toFIG. 4, an example system for implementing the invention includes a general-purpose computing device in the form ofcomputer system420.
• Computer system420 includes aprocessing unit421, asystem memory422, and asystem bus423 that couples various system components including thesystem memory422 to theprocessing unit421.Processing unit421 can execute computer-executable instructions designed to implement features ofcomputer system420, including features of the present invention. Thesystem bus423 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 system420 can include one or more receptacles for receiving print circuit boards or “cards” that interface withsystem bus423.System memory422 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 thecomputer420, such as during start-up, may be stored inROM424.
• Thecomputer system420 may also include a magnetic hard disk drive427 (e.g., a SCSI drive) for reading from and writing to a magnetichard disk439, amagnetic disk drive428 for reading from or writing to a removablemagnetic disk429, and anoptical disk drive430 for reading from or writing to removableoptical disk431, such as, or example, a CD-ROM or other optical media. The magnetichard disk drive427,magnetic disk drive428, andoptical disk drive430 are connected to thesystem bus423 by harddisk drive interface432, magnetic disk drive-interface433, andoptical drive interface434, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer-executable instructions, data structures, program modules, and other data forcomputer system420. Although the example environment described herein employs a magnetichard disk439, a removablemagnetic disk429 and a removableoptical disk431, 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 thehard disk439,magnetic disk429,optical disk431,ROM424 orRAM425, including anoperating system435, one ormore application programs436, other program modules437 (e.g., bit files), andprogram data438. A user may enter commands and information into thecomputer system420 throughkeyboard440, pointingdevice442, 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 theprocessing unit421 through input/output interface446 coupled tosystem bus423. 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. Amonitor447 or other display device is also connected tosystem bus423 viavideo adapter448.Computer system420 can also be connected to other peripheral output devices (not shown), such as, for example, speakers and printers.
• Computer system420 is connectable to networks, such as, for example, an office-wide or enterprise-wide computer network, an intranet, and/or the Internet.Computer system420 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 system420 includesnetwork interface453, through whichcomputer system420 receives data from external sources and/or transmits data to external sources. As depicted inFIG. 4,network interface453 facilitates the exchange of data withremote computer system483 vialink451.Link451 represents a portion of a network, andremote computer system483 represents a node of the network.
• Likewise,computer system420 includes input/output interface446, through whichcomputer system420 receives data from external sources and/or transmits data to external sources. Input/output interface446 is coupled tomodem454, through whichcomputer system420 receives data from and/or transmits data to external sources. Alternately,modem454 can be a Data Over Cable Service Interface Specification (“DOCSIS”) modem or digital subscriber lines (“DSL”) modem that is connected tocomputer system420 through an appropriate interface. However, as depicted inFIG. 4, input/output interface446 andmodem454 facilitate the exchange of data withremote computer system493 vialink452.Link452 represents a portion of a network, andremote computer system493 represents a node of the network.
• WhileFIG. 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 inFIG. 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 withcomputer system420. For example, portions of such modules and portions of associated program data may be included inoperating system435,application programs436,program modules437 and/orprogram data438, for storage insystem memory422. When a mass storage device, such as, for example, magnetichard disk439, is coupled tocomputer system420, 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 tocomputer system420, or portions thereof, can be stored in remote memory storage devices, such as, for example, system memory and/or mass storage devices associated withremote computer system483 and/orremote computer system493. 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 inblade501, which can be a printed circuit board. Bus interface502 can be inserted into an appropriate receptacle (e.g., a Peripheral Component Interconnect (“PCI”) interface) at a computer system to communicatively coupleblade501 to the computer system.Blade501 can communicate (e.g., sending and receiving appropriate electrical signaling) with a corresponding computer system bus (e.g., a PCI bus) through bus interface502.
• Blade501 includesmemory504 andprogrammable logic module506 that control the functionality oftest ports508 and509.Memory504 can be any of a variety of different types of memory, such as, for example, Random Access Memory (“RAM”).Memory504 can be used to store instructions forprogrammable logic module506 and to buffer data that is transferred betweenprogrammable logic module506 andcontrol module503.Programmable logic module506 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 module506 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 module106 can process computer-executable or computer-interpretable instructions to causeprogrammable logic module506 andtest port508 and/ortest port509 to interoperate to implement a port personality in accordance with the processed computer-executable or computer-interpretable instructions. For example,programmable logic module506 can process instructions from a bit file to causeprogrammable logic module506 andtest ports508 andtest port509 to interoperate to implement a Fiber Channel jammer at 2.125 Gb/s. Accordingly, the personality oftest port508 and the personality oftest port509 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 ports508 and509 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 port508 can be utilized to implement a generator, whiletest port509 is simultaneously utilized to implement a bit error rate tester. A bit file having appropriate instructions can be loaded at aprogrammable logic module506 to causetest port508 andtest port509 to simultaneously implement different network diagnostic functions.Clock507 can coordinate the appropriate timing of data transferred to and fromtest port508 andtest port509.
• Blade501 also includesmemory514 andprogrammable logic module516 that control the functionality oftest ports518 and519. Similar tomemory504,memory514 can be any of a variety of different types of memory, such as, for example, Random Access Memory (“RAM”).Memory514 can be used to store instructions forprogrammable logic module516 and to buffer data that is transferred betweenprogrammable logic module516 andcontrol module503. Similar toprogrammable logic module506,programmable logic module516 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 toprogrammable logic module506,programmable logic module516 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 thatprogrammable module506 andprogrammable logic module516 are the same type of programmable logic module.
• Similar toprogrammable logic module506,programmable logic module516 can process computer-executable or computer-interpretable instructions (e.g., instructions536) to causeprogrammable logic module516 andtest port518 and/ortest port519 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 ports518 and519 can be utilized together to implement a particular network diagnostic function. On the other hand,test port518 may be utilized to implement a first network diagnostic function, whiletest port519 is utilize to implement a second different network diagnostic function. For example,programmable logic module516 can process instructions from a bit file (e.g., bit file527) to causeprogrammable logic module516 andtest ports518 to interoperate to implement a Fiber Channel bit error rate test at 10.51875 Gb/s and to causeprogrammable logic module516 andtest ports519 to interoperate to implement a Inifiband generator at 1.065 Gb/s. A bit file having appropriate instructions can be loaded atprogrammable logic module516 to causetest port518 andtest port519 to simultaneously implement different network diagnostic functions.Clock517 can coordinate the appropriate timing of data transferred to and fromtest port518 andtest port519.
• Test ports of different programmable logic modules can be configured to implement the same personalities. For example,programmable logic module506 may process instructions that thatcause test ports508 and509 to implement a Gigabit Ethernet analyzer at 1.065 GB/s, whileprogrammable logic module516 also processes instructions that causetest ports518 and519 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 module506 may process instructions that thatcause test ports508 and509 to implement a Fiber Channel analyzer at 2.125 GB/s, whileprogrammable logic module516 processes instructions that causetest ports518 and519 to implement an Infiniband analyzer at 10.51875 GB/s.
• Test ports508,509,518 and519 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 ports508,509,518 and519 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 ports508 and509 (both controlled by programmable logic module506) may both be SFP ports configured to receive optical cable.
• Control module503 coordinates the transfer of data betweenbus interface102 andmemories504 and514.Control module503 can translate data received from bus interface502 (e.g., a PCI interface) into a format that can be processed by programmable logic modules included inblade501. Likewise,control module503 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 interface502. Based on received data (e.g., appropriate addressing information),control module503 can also identify the programmable logic module that is associated with the received data. Accordingly,control module503 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 file527 can include instructions (e.g., low level instructions107) for configuring one or more ports ofblade501 to perform a network diagnostic function. Thus, bit file527 may be generated by converting application instructions (e.g., application instructions104) into low-level instructions in accordance with a firmware description language (e.g., firmware description language102). Accordingly, bit file527 can include appropriate instructions for altering register values ofblade501.
• 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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 inclaim 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.

Images