Method and apparatus for interconnecting circuit cards

[0002] A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

[0003] The present invention relates to a motherboard and removable circuit card architecture and interface for use in computer systems.

[0004] Typically, a computer includes of a motherboard containing components, such as a main processor or central processing unit (“CPU”), memory, disk storage and other devices. These components normally transfer data to the CPU through a local data and address bus.

[0005] To provide additional functionality to one's computer, a user may plug a peripheral expansion card into one of a number of connectors or slots into the computer's motherboard. Additionally, one or more peripheral expansion cards may transfer data to the CPU through an external input/output (“I/O”) bus via a connector on the motherboard. As a result, the CPU's external bus permits the computer to be expanded using a modular approach. For example, peripheral expansions of a computer may include adding a sound subsystem, a video subsystem, a communications subsystem, a compact disc (“CD”) device, a storage device or hard drive, an instrumentation interface, or other special function expansions to the PC computer.

[0006] Typically, these peripheral expansion cards have pins on the edge of the card interfacing to a connector on the motherboard in order to provide electrical connections between the electronic circuits on the peripheral expansion card and the components, such as the CPU, on the motherboard. Then, the components can access these electrical circuits on the peripheral card via the CPU's external I/O bus. Further, each electrical connection on the external I/O bus typically provides a specific function. For example, one set of connections may provide the voltages required to power the peripheral expansion card (for example, +5, +12, and ground). Another group of connections might enable the data bus to transmit data between the CPU and the electronic circuits. A third group of contacts can provide the address bus in order to permit the device to be addressed through a set of I/O addresses. Finally, there may be contacts for control or other signals such as interrupts requests (“IRQ's”), direct memory access (“DMA”) channels, and clock signals.

[0007] One of the earliest PC buses is named the “8-bit bus” (also known as the XT bus) because early PCs often had 8 bit processors like the Intel 8085 and 8088. This 8-bit bus has eight interrupts (of which six could be used by peripheral expansion cards), four DMA channels, a 62 pin connector and a CPU with a clock speed of 4.77 MHz. However, the installation of a peripheral expansion card requires manual configuration to utilize available computer resources such as DMA channels, IRQs, and I/O addresses. Additionally, each peripheral expansion card is separately configured in order to avoid a conflict with another device that utilizes the bus. Each card is configured for a particular computer by using jumpers and dual in-line package switches (“DIP”) to operate with the computer according to instructions defined by the manufacturer.

[0008] The introduction of the IBM AT computer resulted in the development of a bus known as the Industry Standard Architecture (“ISA”) bus. However, the ISA bus is a 16-bit bus because the IBM AT computer has a 16-bit processor such as the Intel 8086. The ISA bus is based on the “8-bit bus” connector with the addition of a small bus connector adding several signal lines to widen the data bus to 16-bits. In addition to the extra resources, the ISA bus is backward compatible with the older 8-bit bus. The ISA bus also adds eight more interrupts, additional data and address lines, and four additional DMA channels. Further yet, improvements over the XT bus include an increased clock speed of 8 MHz for the ISA bus with “Turbo” models running near 10 MHz. Additionally, the ISA bus is capable of “bus mastering” allowing a device on a peripheral card to take control of the bus to read or write directly from another device while the CPU is momentarily idled. As a result, bus mastering can greatly improve the data transfer performance of a computer.

[0009] Both the XT and AT bus typically operate at the same clock speed as the CPU, namely 4.77 MHz and 8 MHz, respectively. However, when newer CPUs outpaced the 8 MHz bus, such as with the early 12 MHz Intel '286 CPUs, the maximum speed of the bus limited the CPU clock speed. For instance, if the CPU clock is tied to the ISA bus having a clock speed of 8 MHz, then a faster CPU such as the 12 MHz Intel 286 CPU would be forced to operate at an 8 MHz CPU clock speed despite the '286 CPU's increased operating speed. Rather than force the '286 CPU to operate at a slower clock speed, one solution was to separate the '286 CPU clock from the I/O bus clock (i.e. 8 MHz), so that the '286 CPU could run at it's maximum speed (i.e. 12 MHz). Consequently, de-coupling the I/O bus from the 3286 CPU bus allows the I/O bus to operate at 8 MHz while the CPU clock may operate at 12 MHz.

[0010] As in the 8-bit bus however, the ISA bus may be configured using the same manual procedures for configuring the 8-bit expansion cards. As a result, resources such as interrupt memory addresses, DMA channels, and I/O ports are manually configured using jumpers and DIP switches. Alternatively, one special method of configuring an ISA bus expansion card is based on an ISA “Plug-and-Play” system. According to the ISA “Plug-and-Play” system, ISA cards may also be configured using an Electronically Erasable Programmable Read Only Memory (“EEPROM”) chip on the card. Essentially, the jumper positions of the manual re-configuration method are programmed into the EEPROM and the settings could be made using a special software configuration program.

[0011] To operate properly, the ISA “Plug-and-Play” (“PnP”) system is comprised of a standard ISA bus and a special set of Basic Input/Output System (“BIOS”) extensions. In theory, these BIOS extensions examine the installed “Plug-and-Play” compatible cards at start up and set expansion cards to available resource settings. Despite intentions to make configuring an ISA card easy, the ISA “Plug-and-Play” method failed because the ISA “Plug-and-Play” enumeration algorithm was not widely accepted. As a result, conflicts between the CPU and the expansion card were frequent because the configuration system would not know about the existence of other non-PnP cards. Consequently, “Plug-and-Play” soon earned the nickname in the computer service industry as “Plug and Pray”.

[0012] IBM later developed a bus using a higher density connector known as Micro-Channel Architecture (“MCA”). The MCA bus was available in either 16-bit or 32-bit versions and featured multiple bus mastering. Although the MCA bus clock speed was set at 10 MHz, the MCA allowed change configurations under software control rather than with jumpers and DIP switches. Consequently, a user can configure an MCA peripheral card to use available resources such as IRQ, DMA channel, memory address, and I/O ports using a reference disk and an option diskette after installing the physical device in the computer. The reference disk is a special bootable disk containing a program that sends commands to bus devices to configure their parameters. This reference disk is included with the computer and is unique to the particular MCA bus computer. Each MCA peripheral card also comes with an option disk containing the device specific configuration files for the device being installed. Nevertheless, computer systems designers do not extensively use the MCA bus because it is not backward compatible with the ISA bus.

[0013] The Extended Industry Standard Architecture (“EISA”) open bus standard was developed by nine companies (Compaq, AST, Olivetti, Tandy, Hewlett-Packard, WYSE, Zenith, NEC and Epson) for defining a 32-bit software configurable EISA bus. According to the EISA standard, the peripheral expansion bus slots have both 32-bit finger and 16-bit slots to provide backward compatibility with ISA cards. However, as in the 8-bit bus, this bus is limited to an 8 MHz clock speed. Configuring an EISA bus is similar to configuring an MCA bus unless an ISA card is installed into an EISA slot. If an ISA card is installed, then the configuration procedure for an ISA card applies.

[0014] Once Pentium class 32-bit processors were introduced, the Peripheral Component Interconnect (“PCI”) bus was developed to provide an interface bus that can match the speed of the Pentium microprocessor. PCI can support both 64-bit and 32-bit wide multiplexed address and data lines, so it can be used in both 486 and Pentium class systems. The PCI bus currently operates at up to 33 MHz with future versions operating up to 66 MHz.

[0015] The PCI bus is processor-independent because the external PCI bus transfers data to the local CPU bus through a special bridge circuit. The bridge circuit contains a memory controller and is connected to a cache and memory subsystems. Additionally, the bridge circuit may include data buffering/posting and PCI central functions such as arbitration. As a result, this provides the advantage of the bus being nearly universal with other computers because the PCI bus is compatible with a variety of personal computers, Mac OS based computers, and RISC type computers. The bridge circuit including the memory controller therefore allows PCI masters direct access to main memory. Additionally, the PCI bus can support multiple bus mastering expansion cards providing maximum bus throughput of up to 265 Mbps with 64 bit cards.

[0016] The PCI controller may perform arbitration using an access-based rather than a time-slot-based arbitration scheme. A bus master must arbitrate for each master access it performs on the bus. PCI may use a central arbitration scheme, where each master agent has a unique request and grant signal. A master agent may use a request-handshake to gain access to the bus.

[0017] The PCI bus and cards also provide some Plug-and-Play capabilities. PCI Plug-and-Play permits a programmatic enumeration, which automatically configures the PCI card for memory addressing, IRQ and DMA selection and I/O port addressing without having to move jumpers or DIP switches. When a new PCI card is installed and the computer is rebooted, the basic input/output (“BIOS”) of the computer system should detect the newly installed device(s) and configure the computer resources such as memory, IRQ, I/O, and DMA settings without human intervention. Additionally, when the operating system detects the insertion of a new device, it installs the proper software so that the computer can use that motherboard or PCI card.

[0018] Yet another standard known as the Audio/Modem Riser (“AMR”) specification defines an open industry-standard interface connector and mechanical form factor for adding a modem and audio riser card to ATX, micro ATX, and NLX circuit board form factors. Sensitive analog components are placed on a riser card in order to provide high quality audio and also easier modem homologation. The AMR interface provides support for Audio Codec (“AC”), Modem Codec (“MC”) and Audio/Modem Codec (“AMC”) devices. However, the AMR Specification does not define an aftermarket I/O standard expansion slot. Instead, the AMR specification only defines a system manufacturer, motherboard-only, riser interface that is intended to be fully configured prior to the initial shipment of the system. Nevertheless, the PCI bus standard typically serves as the aftermarket I/O interface. The document entitled “Audio/Modem Riser Specification”, by Intel Corporation, provides additional details on the AMR specification.

[0019] The AMR standard, however, was intended for conventional modem devices and does not accommodate today's high bandwidth communication devices. Computers today routinely take advantage of the expanding broadband network by utilizing digital subscriber lines, cable modems, and home networking technology. Needed is a system that allows greater scalability and expandability by integrating high bandwidth communication devices on a peripheral card. Moreover, needed is a system that can discover, identify and assign peripheral devices added to a computer system while arbitrating conflicts between devices.

[0020] Addressing some of the problems with systems utilizing peripherals or expansion cards as described above, the present embodiments provide the ability to support expansion card based broadband communications, networking peripheral and audio subsystem designs on one expansion card connected to a computer system motherboard. By supporting multiple peripheral devices on an expansion card, bus slots on the system motherboard can be freed up for use by other peripheral or expansion devices. Moreover, utilizing the present embodiments, printed circuit board area and cost of adapter cards can be reduced. The exemplary embodiments disclose a system and method capable of providing for a more forward approach in motherboard and removable expansion card architecture.

[0021] In an aspect of the present invention, a method for discovering devices on a peripheral card removable from the motherboard includes accessing information from a storage device located on the peripheral card. From the accessed information, a device list can be generated and utilized to program at least one appropriate controller on the motherboard with configuration parameters from the device list.

[0022] In another aspect of the present invention, a computer system includes a motherboard having a set of programmable device controllers, a bus system, and an expansion card having a set of peripheral devices. The bus system connects the set of controllers located on the motherboard to the peripheral devices located on the expansion card. At startup, a basic input/output system on the motherboard requests information relating to the peripheral devices. The information relating to the set of peripheral devices is then transmitted from a storage device located on the expansion card to the basic input/output system for distribution to the appropriate controllers.

[0023] In yet another aspect of the present invention, an expansion card contains a set of peripheral devices and a storage unit. The storage unit identifies the expansion card and the peripheral devices included on the card. In the exemplary embodiment, the storage unit contains enumeration and configuration data for the expansion card and the peripheral devices located on the card.

[0024] According to another aspect of the present invention, a motherboard includes a set of controllers including a serial bus controller, an advanced communication riser (“ACR”) connector, and a basic input/output system. The set of controllers are in communication with the ACR connector. The basic input/output system is in communication with the serial bus controller. In the exemplary embodiment, the basic input/output system obtains information relating to peripheral devices on an attached expansion card from the expansion card via the serial bus controller, and programs the information onto each of the other controllers.

[0025] In yet another aspect of the present invention, a method for saving printed board area and cost of adapter cards includes utilizing a multi-functional bus system. In the exemplary embodiment, the multi-functional bus system including an edge pin connector is configured such that the edge pin connector located on a peripheral card does not necessarily have to be as large as the full length of a connector located on a motherboard. Moreover, with careful grouping of the pins on the edge pin connector, the size of peripheral card can vary to achieve a desired card length and width. Thus, the peripheral card does not need to waste unnecessary printed board area and costly adapter cards.

[0026] The present embodiment provides many different uses and advantages. For example, the present embodiments provide a flexible method of discovering and integrating plug-and-play peripheral devices. The present embodiments provide an enumeration process to enable new devices to be discovered and assigned the appropriate device parameters and drivers without conflict with existing devices such as devices on other peripheral cards as well as motherboard-based devices. BIOS entry points can also be created to allow software programs to access and utilize the device parameters. The embodiments herein are also backward compatible with existing AMR standard systems and can provide a standard interface for future communication devices.

[0027] The present embodiments also save circuit board space on peripheral cards enabling reduced sized peripheral cards when connector pin outs are advantageously assigned as described herein. Multiple and diverse communication devices such as network interfaces, DSL and wireless interfaces, can be accommodated on a single, scalable circuit card saving board space and PCI slots. Due to the scalable architecture, future extensions and expansion can be added to existing systems.

[0028] The foregoing and other objects, features and advantages of the system and method for improving motherboard and removable circuit card architecture will be apparent from the following more particular description of preferred embodiments of the system and the method as illustrated in the accompanying drawings.

[0029] FIG. 1 illustrates a block diagram of the motherboard and expansion card architecture of an exemplary embodiment;

[0030] FIG. 2 illustrates an exemplary embodiment of the data structure of the expansion card of FIG. 1;

[0031] FIGS. 3A-3E illustrates in further detail the data structure of the storage device of the expansion card of FIG. 1;

[0032] FIG. 4 illustrates the bus topology of an exemplary bus interconnecting the motherboard and expansion card of FIG. 1;

[0033] FIG. 5 illustrates a table showing an exemplary grouping of bus signals and pin locations of the ACR connector;

[0034] FIGS. 6A-6C illustrate a table showing an exemplary signal description for each of the signals in the table of FIG. 2 as viewed from the expansion card of FIG. 1;

[0035] FIG. 7 illustrates an exemplary physical view of the expansion card and ACR connector of FIG. 1;

[0036] FIG. 8 illustrates the ACR connector suggested mechanical, electrical, and environmental performance requirements;

[0037] FIG. 9 illustrates an exemplary flow chart of the ACR enumeration utilized in the exemplary system of FIG. 1;

[0038] FIG. 10 illustrates an exemplary flow chart of programming a configuration space of the controllers shown in FIG. 1; and

[0039] FIG. 11 illustrates an exemplary flow chart of the PCI enumeration.

[0040] The system and method disclosed herein provides a form factor and interface system for supporting multiple and varied communications and audio subsystem designs for use on a personal computer (“PC”). The system and method are implemented on a motherboard and expansion card architecture that can support modem, audio, Local Area network (“LAN”), Wide Area Network (“WAN”), and Digital Subscriber Line (“DSL”) technology. It should be understood that the present embodiments are not limited to the described exemplary embodiments disclosed herein, but that they may also be implemented in systems that utilize peripheral devices or expansion cards for further function and flexibility. Therefore, details regarding the personal computer including the motherboard and expansion card are provided as an example, and are not necessary to the invention.

[0041] The system and method are implemented on a motherboard and expansion card architecture for PCs, and preferably maintain backward compatibility with the Audio/Modem Riser (“AMR”) specification through an industry standard connector such as a 120-pin peripheral component interconnect (“PCI”) connector. The AMR specification is fully incorporated by reference herein.

[0042] To maintain backward compatibility with the AMR specification, the advanced communication riser (“ACR”) connector utilizes a 120 pin PCI connector that is reversed and offset from the connector layout of the AMR specification. The AMR connector pins preferably remain unchanged from the AMR specification to further enable AMR compatibility. Therefore, according to the described embodiment, an AMR riser may be plugged into the ACR connector located on a system that utilizes the disclosed embodiments and function correctly.

[0043] FIG. 1 illustrates a block diagram of an exemplary removable circuit card, hereinafter referred to as a riser card 10, and PC motherboard 98 architecture. The riser card 10 can include a printed circuit board or adapter that plugs into the motherboard 98 via the ACR connector 20 to provide increased functionality such as LAN/WAN connectivity, as well as audio subsystems, etc. The riser card 10 can utilize an ACR connector 20 that includes a standard 120-pin connector 20 to maintain backward compatibility with current AMR designs. The riser card 10 can generally include peripheral devices such as an AMC'97 Codec 24, and Universal Serial Bus (“USB”) device 28 or USB connector. The riser card 10 also includes a storage device 50.

[0044] Additional peripheral devices can also be placed on the riser card 10 such as a physical (“PHY”) layer for a home networking device 36 (e.g., HomePNA), Ethernet 40 (e.g., 10/100 Mbit PHY), xDSL device 44, or wireless interface 48. It should be understood that the riser card 10 is not limited to using only the described peripheral devices, but can use other types of peripheral deices to provide further functionality to the motherboard 98.

[0045] The peripheral devices 24-48 may also utilize additional circuitry on the riser card 10. For example, according to this described embodiment, the AMC'97 CODEC 24, HPNA 36 and the xDSL 44 are shown in connection with a RJ11 jack via the analog interface network 52. Furthermore, the 10/100 Mbit PHY 40 is in connection with an RF45 jack. The wireless interface 48 is shown linked to antenna.

[0046] To accommodate the peripheral devices on the riser card 10, hard-wired lines (e.g., electrical or optical conductors) can be used for transferring data between the peripheral devices 24-48 and their respective controllers 100-120. These hardware lines, or buses, can include an AC'97 52, USB 54, ACR Serial Bus 56, Primary MII 62, Integrated Packet Bus (“IPB”) 64, secondary MII-MII/GPSI 68, and wireless bus 72. Each bus can preferably transmit data to and from each of the active peripheral devices 24-48 to their appropriate controller 100-120, preferably located off of the riser card 10 as described with respect to the motherboard 98 below.

[0047] Referring again to FIG. 1, the exemplary motherboard 98 can support LAN/WAN connectivity as well as audio subsystems from the riser card 10. The motherboard 98 can include the main circuit board that generally contains the primary components of the computer, such as the CPU 122, BIOS 124, main memory, and support circuitry, and so forth. The CPU 122 and BIOS 124 are shown in the block diagram.

[0048] The BIOS 124 assists the CPU 122 by including a set of hardware or software routines that can test motherboard 98 hardware at startup, start the operating system, and support the transfer of data among hardware devices on the motherboard 98 and riser card 10. The BIOS 124 can be stored in ROM on the CPU 124, and is executed when the computer is turned on or reset. It should be understood that the BIOS 124 may support more than one riser card 10 attached to the motherboard 98 at any one time, if desired.

[0049] The motherboard 98 can also contain a set of controllers 100-120 for controlling peripheral devices 24-48 on the riser card 10. In this exemplary embodiment, the controllers 100-120 are shown linked to a bus such as a peripheral component interconnect (“PCI”) bus 128. Each of the controllers 100-120 are preferably configured from the enumeration and configuration data received from the storage device 50 on the riser card 10. The controllers 100-120 can include a DC'97 100, USB 104, serial bus controller 108, other desirable controllers such as general purpose MAC controllers, labeled MAC 1 108 and MAC 2 112, Integrated Packet Bus (“IPB”) controller 114, and a wireless controller 120. The controllers 100-120 preferably each have a configuration register to identify and assign the controller to a peripheral device such as a device on the riser card 10 or the motherboard 98. The configuration register is a programmable memory space, and is programmed to store enumeration and configuration data for the device that the controller is assigned. The configuration spaces are programmed by the BIOS 124 for use with appropriate peripheral devices 24-48 or devices on the motherboard 48.

[0050] Therefore, according to this described embodiment, the following buses are configured to transmit data between the controllers 100-120 and their respective peripheral devices 24-48. The AC'97 bus 52 links DC'97 controller 100 with AMC'97 CODEC 24. The AMC'97 CODEC 24 is also shown linked to an RJ11 jack via the analog interface network 58. The USB bus 54 links USB controller 104 with USB device or connector 28. The ACR serial bus 56 links serial bus controller 108 with storage device 50. The MII bus 62 links MAC 1 112 with HPNA PHY 36. The HPNA PHY 36 is also shown linked to an RJ11 jack via the analog network interface 58. The IPB bus 64 links IPB controller 114 with xDSL device 44. The xDSL device 44 is also shown linked to an RJ11 jack via the analog network interface 58. The MII/GPSI bus 68 links MAC 2 116 with 10/100 Mb PHY 40. The 10/100 Mb PHY is also shown linked to an RJ45 connector. The wireless bus 72 links wireless controller 120 with 10/100 Mbit wireless interface 48.

[0051] Preferably, the storage device 50 located on the riser card 10 holds enumeration and configuration data. The storage device 50 is preferably in communication with an serial bus controller 108 located on the motherboard 98 via the ACR serial bus 56. The storage device 50 can be implemented in any technology, but shall appear to the ACR bus controller 108, and other devices on the same ACR serial bus 56, as a 24xx-class serial electrically erasable programmable read-only memory (“EEPROM”) device.

[0052] The enumeration and configuration data stored in the storage device 50 identifies the peripheral devices 24-48 located on the riser card 10. The storage device 50 can optionally contain a description of the riser card 10 itself for completeness or a description of any vendor-defined data if access to the vendor-defined area is desired.

[0053] Referring to FIG. 2, the storage device 50 preferably contains two units of memory, namely an enumeration unit 76 and a vendor defined unit 80. The enumeration unit 76 is a variable sized area that stores the enumeration data for the peripheral devices 24-48 located on the riser card 10. Preferably, this enumeration unit 76 is programmed by the manufacturer of the riser card 10 to ensure that the enumeration data accurately reflects the peripheral devices 24-48 and accurate. The enumeration area 76 contains a header 84 followed by a list of the peripheral devices 24-48 present on the riser card 10, and are correspondingly represented by an enumeration object 88. The enumeration objects 88 end at a tag-end object 90. For example, according to the described embodiment, an enumeration object 88 that describes the riser card 10 itself may contain the riser card name, manufacturer identification, serial number, and power consumption information.

[0054] Thus, the storage device 50 may contain enumeration data for the riser card 10 itself and all of the peripheral devices 24-48 located on the riser card 10. Additionally, the storage device 50, if so desired, can contain the size of the memory on the storage device 50, the allocation of data, and a checksum for self-testing. Consequently, if an enumeration entry exists, the entry preferably matches the physical and logical characteristics of the storage device 50.

[0055] Further, the storage device 50 may provide access to the vendor defined unit 80 for providing device peripheral device 24-48 specific information often useful in enumeration. For example, the storage device 50 may specify the address location for a vendor defined unit 80.

[0056] FIGS. 3A-3E illustrates in further detail the data structure of the storage device of FIG. 2. The data structure in the peripheral device list preferably represents the hardware present of the riser card 10. The information in the data structure can be used by a basic input/output system (“BIOS”) to program controllers corresponding to the peripheral devices 24-48 on the riser card 10, as described below. Additionally, the information in the data structure can be made accessible to software on the motherboard 98 via BIOS calls or BIOS entry points.

[0057] A BIOS entry point allows an application or driver to access device information via an Application Programming Interface (“API”). An API is a set of standard software interrupts, calls, and data formats that an application program uses to initiate contact with another service, such as the BIOS 124. In one embodiment, the BIOS 124 may support two distinct entry points. A real mode interface, for example, may be evoked via INT 1AH and a 32-bit protected mode mechanism to allow access for ring zero device drivers. Some controllers 100-120 may require initialization by the BIOS 124 during the boot procedure. Such initialization may preferably take place either after the PCI enumeration is accomplished or temporary resources may be assigned to permit initialization at any time. Probably the most convenient time to carry out any multi-function bus related initialization is before PCI enumeration. By then all existing devices have PCI controllers with the correct identification and permanent resources can then be assigned. Additionally, all non-existent devices may be turned off.

[0058] The peripheral device list preferably contains a header followed by a list of object descriptors. Each object descriptor is itself a list of items associated with that object. The nature of the items can depend on the object's functions, the bus it uses, and the purpose of the information. The last object descriptor in the peripheral device list is an END object to indicate the end of the device list and carry the global checksum.

[0059] FIG. 3A shows the peripheral device list header, which is shown starting at memory address zero, and is composed of four bytes. The header preferably allows quick identification of the riser card 10 to make aware that the riser card 10 is an ACR compatible riser card 10.

[0060] FIG. 3B shows an exemplary object or object descriptor, which is a self-contained packet of information. Each object preferably contains an object header byte, one object size byte, an optional object size extension byte. These bytes are then followed by the object's data of variable size. Each object descriptor contains zero or more data items. The data items can carry the various kinds of information such as peripheral device identification, serial numbers, and so forth. Data items can be arranged inside an object in any sequence, but the BIOS preferably executes them in the sequence that they appear.

[0061] FIG. 3C shows an exemplary object byte header and the values as they are defined for the tag and bus fields. The object byte header includes a tag field of 4 bytes and a bus field of 4 bytes. The values defined for the tag field shown correspond to a particular peripheral device 24-48. The values defined for the bus field shown correspond to a particular bus 52-72 that is used to connect the appropriate peripheral device 24-48 to controller 100-116. Therefore, according to the values defined for the tag field, a value of 3 in the tag field would represent a TAG_SOUND, which refers to a sound device. In the bus field corresponding to the BUS_ACLINK, a value of 1 might be found indicating that the sound device should utilize the AC-Link bus.

[0062] FIG. 3D shows an exemplary object size byte and the values as they are defined for the Mobo, Long, and Len fields. The Mobo field specifies the location of the device, such the device is located on the motherboard or the device is a peripheral device located on a riser card. The Long field describes the contents of the Len field such as a zero if the Len field contains the number of bytes in the object descriptor or a one if the Len field contains the 6 most significant bits of a 14-bit len. The len is the size or length of the object descriptor.

[0063] FIG. 3E shows an exemplary tag-end object to signal that the end of the object list in the storage device 50 and can provide a checksum for the entire enumeration area. The end object may include the checksum such as the sum of the bytes in the enumeration area should add up to 0FFh (0FF in hexadecimal).

[0064] Objects are followed by optional data items. Each data item describes a characteristic of the object. The BIOS must process data items in the order that they are encountered in each object descriptor. When a BIOS client requests the ACR enumeration data, the data items will be presented in the same order that they appear in the original source (ROM BIOS or EEPROM).

[0065] Data items are composed of a header containing the Item and Isize fields, followed by the item payload. In some cases, the Item and Isize fields are omitted. The Item field specifies the meaning of the information in the payload, while Isize specifies the size of the data payload. The data values must immediately follow the header, and if present, the size extension byte. More details regarding the data item format are given in Appendix-Data Storage.

[0066] In the exemplary embodiment, an object can be executed during the configuration phase. The object preferably carriers optional, real mode 16-bit x86 code. This code is preferably called in real mode by the BIOS once per system power up or reset sequence. Preferably, the code in the executable object is relocatable. The BIOS can then copy the code to a paragraph boundary and perform a far call to the first byte with parameters set as follows:

[0067] CS:IP: Set to the 1st byte of the code in the executable object.

[0068] DS:SI: Points to the beginning of the fully prepared device list in memory.

[0069] ES:DI: Points to a 32 byte table containing the PCI handle for each controller.

[0070] SS:SP: Points to the stack area, with at least 1k bytes of free stack space for use by the executable object.

[0071] Further, the direction flag is preferably set to UP via CLD instruction.

[0072] Upon termination, the executable object preferably executes a far return instruction. Furthermore, the PCI handle table can contain the PCI handles for each controller on the motherboard 98. If a controller does not exist in the hardware for a specific bus, its PCI handle entry can be set to 0FFFFh. The table can contain one 16-bit entry for each of the controllers in the order defined by the bus field or the object header byte. However, for the AC-Link there are preferably two controllers defined for the AC-Link, a modem controller and a sound controller.

[0073] The exemplary program below illustrates an example of the BIOS code utilized to invoke an exemplary executable object:

[0074] ; Assumes that DS:SI points to the 1st byte of the executable object code,

[0075] ; and CX contains the number of bytes in the executable object (from the

[0076] ; object header)

[0077] EXEC:Mov ax,4000h; Point to free RAM

[0078] Mov es,ax; set segment

[0079] Mov di,0000h; good location

[0080] Cld; clear direction flag

[0081] Rep movsb; move code over safe area

[0082] Mov si, offset DevList; pointer to device list (DS must OK)

[0083] Les di,AdrOfPciHandles; pointer to PCI handle table

[0084] Pusha; save registers if needed

[0085] Call fat 4000h:0; call executable object

[0086] Popa; restore registers

[0087] . . . ; keep going

[0088] Enumeration information, however, is not required to be stored in an EEPROM type of storage device 50. One skilled in the art may readily implement other devices such as non-volatile memory (“NVRAM”), flash memory, programmable array, read only memory (“ROM”), random access memory (“RAM”), a hard drive, bubble memory, or any other suitable storage device. The term storage device will be used throughout this specification to refer to a generalized storage device without limiting the invention to any particular type of storage device. The storage device capacity can vary according to the desired amount of information that is stored for each particular peripheral device 24-48 or application.

[0089] FIG. 4 illustrates the topology of an exemplary ACR serial bus 56 utilized by the motherboard 98 riser 10 architecture of FIG. 1. The ACR serial bus 56 can allow an ACR bus controller 108, preferably located on the motherboard 98, to read enumeration and configuration data from the storage device 50, preferably located on the riser card 10. The ACR serial bus 56 may include a two-wire serial bus based upon the I²C protocol for communication with the storage device 50. The I²C protocol may support the Byte Write, Page Write, Current Address Read, Random Byte Read, and Sequential Read protocols as defined in the Microchip Technology Inc. 24LC02B datasheet, document number DS20071J the controls of which are incorporated herein by reference. The ACR serial bus 56 may also connect to other peripheral devices 24-48 located on the riser card 10.

[0090] The ACR bus controller 108 and storage device 50 communicate over the ACR serial bus 56. The ACR serial bus 56, as described above, preferably utilizes I²C protocol and allows the BIOS 124 to generate I²C transactions on the ACR serial bus 56. The I²C protocol utilizes two signals, the serial clock line (“SCL”) and the serial data line (“SDL”). As such, the ACR bus controller 108 is an I²C master. The motherboard 98 preferably supplies any pull-up devices.

[0091] The ACR bus controller 108 can be located on the motherboard 98, and may include a System Management Bus (“SMBus”) controller. Alternatively, a General Purpose Input/Output (“GPIO”) controller, or any other applicable serial bus controller, as known in the art, may be used to function as the ACR bus host controller 108.

[0092] In another embodiment, the controller 100-120 functions can be integrated on a single bus controller (not shown). Integrating controllers onto a single bus controller on the motherboard 98 can also be more efficient and less costly. The single bus controller may have the capacity to perform multiple or all controller functions, the cost to integrate multiple controllers into a single controller is less than the cost of implementing multiple, distributed controllers 100-120. Additionally, the cost and space requirements of a riser card 10 is further reduced because the controllers 100-120 are not required to be provided on the peripheral card, rather the controller 100-120 are provided on the motherboard 98. Further, other bus standards, either mentioned herein, known to those skilled in the art, or those developed in the future can be applied to this bus controller integration scheme.

[0093] FIG. 5 illustrates a table showing an exemplary grouping of bus signals and pin locations of the ACR connector 20 that connects the peripheral devices 24-48 to their appropriate controller 100-120. As described above, the buses can include an AC'97 52, USB 54, ACR Serial Bus 56, Primary MII 62, Integrated Packet Bus (“IPB”) 64, secondary MII-MII/GPSI 68, and a wireless communication 72. In this exemplary grouping of signals, the AC'97 52 bus and USB 54 utilize A1-A23 and B1-B23 pin locations. The ACR serial bus 56 utilizes pin location B24 and A24 for the serial clock line (“SCL”) and the serial data line (“SDL”) respectively (SCL and SDL are described below). The primary MII 62 utilizes pin locations A25-A35 and B25-B35; IPB 64 utilizes A36-A44 and B36-B44; secondary MII/GPSI utilizes A45-A55 and B45-B55; and wireless 72 or reserved pin locations utilizes A56-A60 and B56-B60. A keyway to ensure the proper signals are connected by limiting the ACR connector to fit a certain way is placed between pins A11, A12 and B11, B12.

[0094] FIGS. 6A-6C illustrate a table showing an exemplary signal description for each of the signals in FIG. 5 as viewed from the riser card 10. The table includes the signal name, type of signal (input or output), pin count, and description. For example, according to this table, signal AC97_SDATA_OUT is an input at pin B17 and the signal is AC'97 serial data received from the DC'97 controller 100 and input into the AC'97 Codec 24. Furthermore, the ACR serial bus 56 utilizes pins B24 and A24 for the SCL and SDA respectively. The signal SCL is an input into the storage device 50 and is a serial bus clock, whereas the signal SDA is both an input and output bus to transport data serially to and from the storage device 50. Nevertheless, the bus signals given in FIGS. 5 and 6A-6C can be used to connect the peripheral devices 24-48 to their appropriate controller 100-120.

[0095] FIG. 7 illustrates an exemplary physical view of the riser card 10 and ACR connector 20. The exemplary view of the riser card 10 does not show peripheral devices 24-48, but shows a surface of the riser card 10 that the peripheral devices 24-48 may be located on. The length of the riser card 10 should not exceed 7.500 inches (190.5 millimeters) and the height should not exceed 4.200 inches (106.68 millimeters). When peripheral devices 24-48 are placed on the riser card 10, the maximum height of the devices 24-48 on the primary component side of the riser card 10 should not exceed 0.570 inches, and the devices 24-48 on the backside of the riser card 10 should not exceed 0.105 inches. Other measurements are shown by way of example and should not be limited to such. The ACR connector 20 preferably includes the buses 52-72 for connecting the peripheral devices 24-48 to their appropriate controllers 100-120.

[0096] In the exemplary embodiment, the ACR connector 20 includes a multi-functional bus system having an edge pin connector to communicate information between the riser card 10 and the motherboard 98. Preferably, the multi-functional bus is configured such that the edge pin connector on the riser card 10 is not required to fill the entire slot or connector located on the motherboard 98. Consequently, the riser card 10 can vary in size, needing only to accommodate the peripheral devices located on the riser card 10. For example, according the exemplary embodiment, if the riser card 10 has only a USB device and the storage device. Then the edge pin connector might need pins for power, ground, serial bus to accommodate the storage device, and a USB bus to accommodate the USB device . As a result of the small multi-functional bus system, the edge pin connector of the riser card 10 is not necessarily required to access unused pins on the slot or connector of the motherboard 98.

[0097] The multi-functional bus system preferably including an edge pin connector organizes and groups the pins such as according to pin functionality or needed pins. For example, according the above described embodiment (i.e., a riser card 10 generally having only a USB device and storage device), pins located on the edge pin connector could be organized by power, ground, serial bus to accommodate the USB device, and a serial bus to accommodate the storage device. By placing the pins according to pin functionality or needed pins, the edge pin connector does not need to include unnecessary pins. It should be understood that the multi-functional bus system is not limited to use on an ACR compatible riser card 10, but can be utilized in any type of computer utilizing expansion or peripheral cards.

[0098] FIG. 8 illustrates the ACR connector 20 suggested mechanical, electrical, and environmental performance requirements. Such parameters utilized in characterizing the performance requirements are durability, mating force, and contact normal force for mechanical; contact resistance, insulation resistance, dielectric withstand voltage, capacitance, current rating, voltage rating, and certification for electrical; operating temperature, thermal shock, and flowing mixed gas test for environmental.

[0099] ACR enumeration includes determining the peripheral devices 24-48 present on the riser card 10, allocating non-conflicting PC resources to the controllers 100-120, and then configuring the controllers 100-120 to access the allocated peripheral devices 24-48. After ACR enumeration, a PC utilizing the ACR serial bus 56 may consider a riser card 10 as an extension of the motherboard 98. As a result, the BIOS 124 may have knowledge of the riser card 10 capability supported on the motherboard 98. Consequently, the BIOS 124 may have appropriate routines to insure that all peripheral devices 24-48 are properly configured for ACR enumeration to occur.

[0100] ACR enumeration may be performed on a riser card 10, the peripheral devices 24-48 identified on-board the riser card 10, the operating system, devices on the motherboard 98, and the software device drivers for the purpose of identifying themselves. Additionally, the identification of these devices ensure that a conflict between computer resources or devices does not occur. ACR Enumeration further ensures that the operating parameters for the devices are correctly set by the BIOS 124, that the correct set of drivers are loaded by the operating system, and that any additional vendor-defined information is available to the device driver. Perferably ACR enumeration maintains compatibility with the Microsoft Windows operating system, or with other operating systems, such as Linux, Unix, Solaris, Macintosh OS, Palm OS, or any other computer operating system.

[0101] Operating systems, including BIOS 124 have improved dramatically in their ability to use standardized register space to uniquely identify hardware added to a system and to install the appropriate driver(s) for the newly installed hardware. The PCI standard uses registers defined as Vendor ID (“VID”), Device ID (“DID”), Subsystem Vendor ID (“SVID”), and Subsystem ID (“SID”). The VID and the DID may be hardwired with the PCI card for each function implemented. Analog type devices such as AMR devices, however, may be supplied by different vendors. Consequently, each analog type device implementing the AMR functions differently. Therefore, the SVID and SID may be assigned on a case by case basis during enumeration. As a result, ACR enumeration information may be provided to the operating system using a combination of storage device 50 and specialized BIOS 124 routines.

[0102] A riser card 10 may utilize several different combinations of interfaces. To prevent resource conflicts, the BIOS 124 is preferably responsible for making sure that the resources from the motherboard 98 are supplied to the interfaces in order to support the feature set on the riser card 10. Therefore, during enumeration, the BIOS 124 may determine the interfaces required by the riser card 10. Once the BIOS determines the required interfaces, then they may identify the supported functions of the riser card 10. Any discrepancies between the riser card 10 and the motherboard 98 interfaces may be communicated to the user through a displayed warning message.

[0103] FIG. 9 illustrates an exemplary flow chart for performing ACR enumeration using the ACR serial bus 56. The buses feeding the riser card 10 are comprised of buses 52-72, most originating from a corresponding dedicated controller 100-120. Preferably each of these controllers 100-120 is addressed individually, and therefore may be individually identifiable to the BIOS 124. As a result, any controller 100-120 installed on the motherboard 98 as well as peripheral devices 24-48 on the riser card 10 may be considered during the ACR enumeration.

[0104] After a Power On Self Test (“POST”) and general initialization of the computer boot procedure, the ACR enumeration process can begin at step 500. Alternatively, an equivalent process may be executed by the BIOS 124 upon motherboard 98 reset. Any computer system implementing a BIOS 124 may provide enumeration for devices on the motherboard 98 and peripheral devices 24-48 located on the riser card 10.

[0105] At step 510, the BIOS 124 may create an empty device list containing the header information for an object entry. The BIOS 124 may begin creating the BIOS device list based on objects already defined in the BIOS 124 such as devices on the motherboard 98, or peripheral devices 24-48 on the riser card 10. The objects may be defined as data burned into the BIOS 124 by the manufacturer or via the BIOS 124 set-up, or any other appropriate method. For example, according to the described embodiment the BIOS device list may be created in system RAM or a suitable register or memory. Additionally, all configuration space registers in the controllers 100-120 may be set to default values that do not conflict with another device prior to ACR enumeration.

[0106] At step 520, the BIOS 124 detects if any objects or devices are on the motherboard 98. If the BIOS 124 detects an object or device on the motherboard 98, then the BIOS 124 determines if the device(s) specified are enabled per step 530. The BIOS 124 may determine if the devices specified by the objects are enabled by reading an object in the BIOS device list, a BIOS setup entry, detecting jumpers, and so forth. If the BIOS 124 determines that the object(s) are enabled, then the BIOS 124 may add the object or device to the device list per step 540. If there are no detected devices on the motherboard 98 per step 520, or after objects are added to the device list per step 540, then detection of a storage device 50 is performed at step 550.

[0107] At step 550, the BIOS 124 determines if a storage device 50 is on the riser card 10. If the storage device 50 is present on the riser card 10, the riser card 10 is considered to be an ACR compatible riser card 10. The BIOS 124 can then read the storage device 50 per step 600. For example, the BIOS 124 may read the contents of the storage device 50 and look for a header (84 in FIG. 6) and checksum. If the header is present and the checksum is correct, then the contents of the storage device 50 may be presumed valid and the riser card 10 is a valid ACR compatible riser card 600. Thus, per step 600, the storage device 50 is read by the BIOS 124.

[0108] At step 605, the objects from the storage device 50 (e.g., objects 88 in FIG. 6) are added to the BIOS device list such that the peripheral devices 24-48 are included in the BIOS device list.

[0109] At step 610, the BIOS device list is complete for that particular riser card 10.

[0110] If a storage device 50 is not detected, per step 550, the riser card is assumed to be an AMR card and consequently the BIOS 124 enumerates the AMR card per step 560, according to the AMR specification.

[0111] FIG. 10 illustrates an exemplary flowchart for programming the configuration space of the appropriate controller 100-120 on the motherboard. The controllers 100-120 are advantageously programmed in response to the BIOS device list, such as the BIOS device list generated in FIG. 9.

[0112] At step 630, peripheral device 24-48 conflicts are preferably resolved. The BIOS 124 can arbitrate conflicts that may exist between peripheral devices 24-48 and any additional devices on the motherboard 98, before programming the controllers 100-120. For example, if a peripheral device similar to one of the peripheral devices 24-48 on the riser card 10 exists on the motherboard 98, the BIOS 124 may chose to disable the peripheral device on the motherboard 98. Likewise, the BIOS 124 may disable the peripheral device 24-48 on the riser card 10 if a similar peripheral device exists on the motherboard 98. In either example the BIOS 124 preferably resolves any conflicts by disabling of the conflicting devices.

[0113] At step 640, the configuration process starts by parsing each object in the BIOS device list. The BIOS 124 will attempt to parse the objects listed in the BIOS device list to the appropriate controller 100-120.

[0114] Therefore, at step 650, the objects of the BIOS device list are examined by the BIOS 124 and the contents are parsed to the appropriate controller 100-120. If the object is on end, then the PCI enumeration boot process can begin, per step 660. If not, then data from the object in the BIOS device list is programmed into the configuration space of the relating controller 100-120, at step 680. For example, according to the described embodiment, if an object in the BIOS device list includes information relating to an AMC'97 Codec 24, then the BIOS would preferably parse and write that information into the configuration space of the DC'97 Controller 100.

[0115] At step 690, after the previous object in the BIOS device list has been parsed, the BIOS 124 can go to the next object and repeat the steps 630-680. This can continue until the object is at an end and accordingly the PCI boot process per step 660 can begin.

[0116] Below is a summary of ACR enumeration, OS enumeration and the device driver loading process for a device on the multifunction bus 160. Step 1 may be executed by PC hardware. Steps 2, through 7 may be performed by the ROM BIOS 124 during boot-up, and steps 8 through 12 may execute under operating system control.

[0117] Upon motherboard 98 power up or reset, a POST (Power on Self Test) is first performed. A general initialization of the computer begins the boot process. During this process the computer detects any available devices and creates a device map indicating the presence of a device. All configuration space registers are reset to their default values creating an empty BIOS device list with a header.

[0118] According to an exemplary embodiment, the enumeration of the PC may be performed under BIOS control. Based on the objects defined in the BIOS 124 for objects or devices on the motherboard 98 (and on riser card 10 if applicable), the BIOS 124 detects if the devices are enabled and then adds the enabled objects onto the BIOS device list. The BIOS 124 reads the storage device 50 contents (if available) on riser card 10 to look for a checksum and a header.

[0119] If no storage device 50 is available and an AMR card is detected, then the BIOS 124 may enumerate the AMR device(s) per the AMR specification. For example, the BIOS 124 may attempt to enumerate the CODEC(s) on the AC'97 bus 52. Instead of programming the configuration registers of the DC'97 controller 97 with the results of the AMR-like enumeration, the BIOS 124 may construct objects with the same information. If however, no AMR objects are found, no entries may be added to the device list.

[0120] If the storage device 50 is available, then the BIOS 124 parses the storage device 50 contents and identifies objects as defined within the data structure of the storage device 50. The BIOS 124 adds the objects described in the storage device 50 to the BIOS device list. The BIOS device list is parsed to direct the configuration of the controllers 100-120. Each object is identified as a device Dev, the device controller Vendor ID, System ID (“SID”) and any other configuration space parameters. The BIOS 124 also assigns its own defaults (i.e. device ID's) to the configuration space of each controller 100-120 for each device 10 supported in accordance with the identified object(s). When the BIOS device list is complete, the BIOS 124 matches the peripheral devices 24-48 on the riser card 10, devices on the motherboard with their respective controllers 100-120, and programs the controller configuration space registers.

[0121] The BIOS 124 disables all controllers 100-120 that do not have peripheral devices 24-48 or motherboard devices attached to them, and declares all applicable configuration space registers as read-only (and otherwise avoids conflicts).

[0122] The BIOS 124 runs any specific initializations required, such as initializing the IPB bus 64. PCI enumeration is performed on the configuration space values by assigning computer resources, (also known as linking, mounting or mapping) the parameters specified in the objects of the storage device 50 to the BIOS device list. Enumeration is complete.

[0123] The BIOS 124 will read and execute the boot loader. The boot loader is the piece of BIOS 124 code that bootstraps the operating system (“OS”).

[0124] According to another exemplary embodiment, the PC enumeration can be performed under OS control. First, of course, the OS starts loading.

[0125] An optional device driver queries the BIOS 124 for the configuration and enumeration data and enters it in a registry.

[0126] The OS scans the PCI bus to read all devices in the system, merges all motherboard devices and matches INF files to the ID registers in the controllers 100-120 configuration space.

[0127] The OS loads the appropriate device driver, pointed to by its entry in the INF file in the configuration space.

[0128] The vendor specific device driver starts executing. It can optionally query the BIOS 124 for the enumeration data or read it from the registry if needed.

[0129] With the ACR bus devices initialized, the PCI enumeration process completes the discovery and assignment of available devices. Preferably the PCI Enumeration process is executed after the ACR enumerates devices to program the PCI configuration space of the host controllers. PCI Enumeration process can then examine the PCI configuration space to report the corrected devices on the system as described in more detail below.

[0130] Referring now to FIG. 11, shown is a flow chart further detailing an exemplary PC enumeration process beginning at Step 800. At Step 810, the BIOS device list is empty awaiting assignment of the appropriate BIOS device list which is generated according to the devices found on the system and connected cards and devices. The BIOS device list informs the BIOS of the available devices so that clients wishing to use the device can access them.

[0131] At Step 820 the motherboard 98 is examined to discover and identify any devices that reside on the motherboard 98. If devices reside on the motherboard 98, they are checked to determine if the devices are enabled at Step 830. If the device is enabled, the device is added to the device list at Step 840.

[0132] At Step 850, PCI enumeration checks for PCI devices on PCI cards in PCI slots.

[0133] At Step 860, the discovered devices are checked to determine if they are enabled. If the devices are enabled, the configuration space of each device controller is read.

[0134] At Step 870, the object read from the configuration space of the active device is added to the device list.

[0135] At Step 880, when the devices have been discovered and the device lists generated the PCI slots that are empty are disabled. For example, the BIOS can disable the configuration space of host controllers associated with devices that are not present in the system. Disabling the host controllers can prevent the OS from detecting non-existent devices.

[0136] At Step 890, system resources can be assigned to the device objects in the generated lists. For example, the devices are assigned a unique base address and interrupt level.

[0137] At Step 900, the appropriate device drivers are loaded using information from the object list. For example, the Vender ID and Device ID Registers can identify appropriate device drivers.

[0138] As the operating system continues to boot, the operating system will examine the configuration space of all enabled controllers 100-120. Therefore, there is no distinction whether a peripheral device 24-48 is physically a riser card 10 or motherboard 98. The peripheral device 24-48 may be contained in a card, either on a riser card 10 or the motherboard 98. However, the contents of the configuration space of the controllers 100-120 may vary depending on the device's location and method of enumeration.

[0139] The present embodiment provides many different uses and advantages. For example, the present embodiments provide a flexible method of discovering and integrating plug-and-play peripheral devices. The present embodiments provide an enumeration process to enable new devices to be discovered and assigned the appropriate device parameters and drivers without conflict with existing devices such as devices on other peripheral cards as well as motherboard-based devices. BIOS entry points can also be created to allow software programs to access and utilize the device parameters. The embodiments herein are also backward compatible with existing AMR standard systems and can provide a standard interface for future communication devices.

[0140] The present embodiments also save circuit board space on peripheral cards enabling reduced sized peripheral cards when connector pin outs are advantageously assigned as described herein. Moreover, by utilizing the multi-function bus system architecture, devices on the expansion or peripheral card can be addressed via one or more input/output buses to provide the advantage of addressing and transferring data from the peripheral devices to the motherboard. Further yet, capacitative coupling and grounding problems of older buses are reduced or not present on the multi-function bus, because long and parallel circuit traces are purposely avoided. Consequently, the multi-functional bus system allows for faster data transfer.

[0141] Because of the present embodiments, multiple and diverse communication devices such as network interfaces, DSL and wireless interfaces, can be accommodated on a single, scalable circuit card saving board space and PCI slots. Due to the scalable architecture, future extensions and expansion can be added to existing systems.

[0142] According to the exemplary embodiment, provided below are several examples of the enumeration process generating an appropriate device list. First is an example of a device list for an empty ACR compatible riser card. It is comprised of a riser card with just the enumeration storage device on board, and no peripheral devices. The listing below shows the minimum possible device list for this scenario.

[0143] Second, shown below is a more complete device list of the same riser card without peripheral devices. The device list includes an object descriptor for the riser card with a name, serial number and a user-defined flag byte. It also includes a description of the storage device, so that a portion of it can be used by other applications.

[0144] Third, is an example of a riser card having an AMR compatible software modem. One of the many possible configurations of a software modem on an AMR card will contain a modem CODEC. To make that design compliant with the ACR specification, the hardware vendor should also provide a properly programmed storage device connected to the serial bus. This example shows a possible device list that would result in the same ID's as an AMR card might.

[0145] The bytes ssvidl, ssvidh, ssidl and ssidh in the table below is preferably set to the desired resulting value in the Subsystem Vendor ID and Sybsystem ID registers of the host controller” configuration space. They depend on the values obtained from the AC-Link CODEC ID registers at addresses 7Ch and 7Eh. For clarity, only required data is included in the table. The vendor is free to add any other descriptors as necessary.

[0146] This example is functional independent of whether there is a sound CODEC on the motherboard. If there is one, the BIOS must provide the enumeration data for it, and the riser card does not need to be aware of it.

[0147] Fourth, is a device list of a riser card having an AMR compatible audio and modem card. The list below shows the storage device contents of an audio modem combo card, with both CODECs sharing the AC-Link bus.

[0148] Fifth, a device list of a riser card having an ACR-style sound and modem card. A difference between this setting and the previous example is the data in the storage device. While in the AMR enumeration process the values for Vendor ID and Device ID are always set to their defaults, the ACR card can attempt to change them. Because it is recommended but not required that the AC-Link controller function in the ACR motherboard have the Vendor ID and Device ID registers writable, these values may remain set to their default values.

[0149] In this example, it is desired that at the end of the enumeration process, the audio device ID's be set to 12B9:2038 FOR Vendor ID and Device ID, and 12B9:0072 for Subsystem Vendor ID and Subsystem ID. The modem object will attempt to set the ID's to 12B9:3005 and 12B9:0003 respectively. Since the Vendor ID and Device ID may be hardwired in some host controllers, the INF file and device driver should be prepared to connect to the device at (8086:2415, 12B9:0072) and (8086:2416, 12B9:0003).

[0150] Sixth, a device list of a riser card having an Audio/modem/HPNA combination of peripheral devices. This example combines the audio and modem functionality with an HPNA PHY on board.

[0151] The HPNA PHY in this example requires that only the Vendor ID and Device ID registers be set to reflect the hardware. The subsystem Vendor ID and Subsystem ID registers are unimportant in this case, and can be left with their defaults. The INF file for the driver must be keyed to 12B:2A04 in the Vendor ID and Device ID fields.

[0152] Seventh, a device list of a riser card having a DSL modem with software protection. This example shows how to describe a DSL modem while insuring that its devices driver software would work in conjunction with this particular device. This mechanism provide protection for the device driver: in order to execute the code the hardware device must be present, acting as an enabling key to the software.

[0153] There are two distinct ways to accomplish this functionality, and the two methods can be combined to accomplish “extra” security. The first method assigns the key validation task to the software. When the OS loads the device driver, it must request that the BIOS provide enumeration information, parse the data and decide whether the correct hardware is present.

[0154] To implement this method, a vendor-defined field is used authenticate the device. The values of the PCI configuration space ID registers are unimportant (from the enumeration and security point of view) because the INF file can be written to connect to any combination of values, including the default ID's of the controllers. 12B:1004 is used for this example.

[0155] The table below shows how to implement the device list as described above. The BIOS will parse this data during enumeration and assign 12B9:1004 to the Device ID and Vendor ID registers. The Operating System will start to load and find the host controller. It will look for the INF file that matches and start loading the corresponding device driver.

[0156] The driver must request the device list from the BIOS and look for the “magic” key, in this case a user defined item with the ASCII string “3Com”. If the key is found, the driver proceeds to load normally. Otherwise, the driver can notify the OS that it was not successful.

[0157] The second method enforces the matching of the driver and hardware by requesting that the BIOS disable the host controller if it cannot assign the required ID's to the configuration space registers. At the end of the configuration, but before the OS loads, if the host controller is left enabled by the BIOS it is guaranteed that its IDS registers match those specified in the enumeration storage device.

[0158] When the OS loads, it will encounter a PCI device with a set of ID's, and will scan the INF files for one that matches it. Only the correct driver will have matching INF ID's, therefore matching is guaranteed.

[0159] The table below lists the contents of the storage device illustrating this method. The ID's chosen for this example are 12B9:1004. Although the system ID's are not specified or checked) in this example, the vendor is encourage to expand the data to include them.

[0160] Additional details of the exemplary embodiment, a detailed description of an exemplary object data structure and exemplary enumeration process, are provided below. For further details of the particular exemplary embodiment, reference can be made to the below description.

[0161] Objects are typically followed by optional data items, where each data item describes a characteristic of the object. Data items include a header containing the Item and Isize fields, followed by the item payload. In some cases, however, the Item and Isize fields are omitted. The Item field preferably specifies the meaning of the information in the payload, while the Isize preferably specifies the size of the data payload.

[0162] Item and Isize are packed into an 8-bit byte item header as shown below:

[0163] The value encoded in the Item field selects among the possible Item types.

[0164] The value in Isize preferably encodes the number of bytes in the Item's payload. If Isize is set to Oh then the byte immediately following the Item Header contains the 8-bit Isize value. The offsets shown in the item formats in the next sections do not reflect the use of the extended size byte. Therefore, if the 8-bit version of Isize is used, it should be placed in offset 1, and all offsets shown for data items will be adjusted accordingly.

[0165] Encoding of the item field:

[0166] ITEM_DEVID

[0167] This Item type is used to identify the vendor and device. It can be used to label the ACR riser card itself or any functional peripheral or analog device on the card.

[0168] If this item is included in the description of a functional object with a controller on the motherboard, the BIOS preferably attempts to program the specified ID fields into the corresponding registers in the configuration space of the controller. The BIOS will not verify if the configuration space write operation was successful or not. If the host controller's register(s) cannot be written they will retain their original values.

[0169] If any of the ID fields of this item is set of 0000h, the BIOS will not attempt to write to the corresponding configuration space register. Such register will retain its default value.

[0170] ITEM_SUBID

[0171] This item type is preferably used to identify the subsystem vendor and subsystem ID. It can be used to label the ACR card itself or any functional device on board. The Subsystem Vendor ID and Subsystem ID fields must comply with the PCI SIG specifications.

[0172] If this item is included in the description of a functional object with a PCI-based host controller, the BIOS must attempt to program the specified ID fields into the corresponding registers in the PCI configuration space of the host controller. The BIOS will not verify if the configuration space write operation was successful or not. If the host controller's register(s) cannot be written they will retain their original values.

[0173] If any of the ID fields of this item is set to 0000h, the BIOS will not attempt to write to the corresponding configuration space register. Such register will retain its default value. See section 8.14 for configuration space registers defaults.

[0174] ITEM_DEVSUBID

[0175] This item type is preferably used to identify the vendor ID, device ID, Subsystem Vendor ID and Subsystem ID. It can be used to label the ACR card itself or any functional device on board. The four ID fields should comply with the PCI SIG specifications to enable compatibility.

[0176] If this item is included in the description of a functional object with a PCI-based host controller, the BIOS preferably attempts to program the specified ID fields into the corresponding registers in the PCI configuration space of the host controller. The BIOS will not verify if the configuration space write operation was successful or not. If the host controller's register(s) cannot be written they will retain their original values.

[0177] If any of the ID fields of this item is set to 0000h, the BIOS will not attempt to write to the corresponding configuration space register. Such register will retain its default value. See section 8.14 for configuration space registers defaults.

[0178] ITEM_DEVSUBID is intended as a shortcut when both ITEM_DEVID and ITEM_SUBID need to be specified.

[0179] ITEM_DEVIDCHK

[0180] This item type is preferably used to verify the vendor ID, device ID, Subsystem Vendor ID and Subsystem ID programmed in the host controller's PCI configuration space. Such verification may be desired to ensure that a certain host controller will only be available in conjunction with a specific add-on card, thus protecting the host controller's IP.

[0181] The ITEM_DEVIDCHK specifies a list of host controller ID's that are acceptable by the device being enumerated. Each entry in the list is composed of 8 bytes representing the Vendor ID, Device ID, Subsystem Vendor ID and Subsystem ID to be matched. If any of these values is set to 0000h then the BIOS will not verify that particular register and assume a match.

[0182] The number of entries in the list is specified by the Isize parameter in the Item Header. The actual number of data bytes specified must be a multiple of 8: partial ID entries are not allowed and may result in unpredictable behavior.

[0183] If, after testing all entries in the ITEM_DEVIDCK ID list, a match is not found, the BIOS must disable the host controller by writing zeroes to all programmable ID registers, BAR registers and the Interrupt Line register in configuration space. If the BIOS has enough control and the hardware supports it, the BIOS must also logically remove the host controller from the system.

[0184] The table below shows the format of the ITEM_DEVIDCHK item. Please note that there can be any number of PCI ID quadruples in the ID list.

[0185] ITEM_CLASS

[0186] The ITEM_CLASS type specifies a 3-byte value to be populated in the PCI configuration space of a PCI host controller. The use of the ITEM_CLASS type allows the ACR device manufacturer to override the default class type of a given host controller.

[0187] ITEM_MINGNT

[0188] The ITEM_MINGNT type specifies a 1-byte value to be populated in the PCI configuration space of a PCI host controller. The use of the ITEM_MINGNT type allows the ACR device manufacturer to override the default Min-Gnt of a given host controller.

[0189] ITEM_PCIPWRMG

[0190] The function of the ITEM_PCIPWRMG item is to convey power management information to the PCI configuration space of a host controller. PCI devices report its power management related features in its configuration space registers. A 2 DWORD Capability record with Capability ID set to 01h exists for all devices that support power management. The PCI 2.2 specification is hereby fully incorporated by reference. Please refer to the PCI 2.2 specification and the PCI Bus Power Management Interface Specification Revision 1.1 for more information.

[0191] The data stored under the ITEM_PCIPWRMG is destined to the Power Management Capability registers. Host controllers that implement power management must be prepared to accept relevant data from the ITEM_PCIPWRMG item.

[0192] All devices that connect to a PCI host controller report their power management capabilities using this item. Devices that attach to a PCI host controller and do not contain an ITEM_PCIPWRMG in its object do not support power management.

[0193] The host controller can provide some functionality even for devices that do not support power management. The BIOS must be aware of the power management capabilities of the host controllers and ensure that they are enabled to the extend supported by devices.

[0194] The format of the ITEM_PCIPWRMG item is shown below.

[0195] The ACRPMC contains data to be fed into the PMC register in the PCI configuration space of host controllers that support PCI 2.2 power management. This field is a 16-bit word, stored LSB first. The format of the ACRPMC field is described below.

[0196] Bits 15 through 11. These bits specify, for each power state, whether the device can generate a power management event. A bit set to one indicates that the device can generate an event.

[0197] Bit 15: PME_D3C. Set to 1 if PME from D3cold is possible.

[0198] Bit 14: PME_D3. Set to 1 if PME from D3 (hot) is possible.

[0199] Bit 13: PME_D2. Set to 1 if PME from D2 is possible.

[0200] Bit 12: PME_D1. Set to 1 if PME from D1 is possible.

[0201] Bit 11: PME_D0. Set to 1 if PME form D0 is possible.

[0202] Bit 10: D2SUP. Set to 1 if the device supports D2.

[0203] Bit 9: D1SUP. Set to 1 if the device supports D1.

[0204] Bit 8 through 6. These bits map to bits 8 through 6 of the PMC register as specified by the PCI 2.2 specification and specify the maximum current draw from the 3.3 Vaux supply.

[0205] Bit 5: DSINIT. This bit must be set to 1 if the device requires a specific initialization for class driver to use. See PCI 2.2 specification.

[0206] Bits 4 through 0. Reserved. Must be set to 0.

[0207] The Data Pair carries information destined to the PMCSR and DATA registers in the PCI configuration space of the host controller. It carries information about the actual power use of the device. The number of data pairs specified is determined by the size of the ITEM_PCIPWRMG item.

[0208] The first byte of the pair specify the index and scale, and the second byte represents the value that must be read from the DATA register when the Data_Select field of the PMCSR register is set to the corresponding index. The scale bits specified in each entry can be made available in the Data_Scale field of the PMCSR.

[0209] The format of the two bytes is shown below.

[0210] These bits describe the scale of the power data in the next byte. It can optionally be made to appear in bits 14 and 13 of the PMCSR register when the encoding in bits 12 through 9 of the PMCSR matched the encoding in the DSELECT bits. See the PCI Bus Specification Revision 2.2 and the PCI Bus Power Management Interface Revision 1.1 specifications for details.

[0211] Bits 5 and 4: Reserved. These bits must be set to 0.

[0212] Bits 3 through 0: DSELECT. This 4-bit field associates the power data in the following byte with the power consumed and dissipated by the device in its various power modes. The encoding must be the same as the Data_Select value encoding specified by the PCI 2.2 specification. Please refer to the PCI Bus Specification Revision 2.2 and the PCI Bus Power Management Interface Revision 1.1 specification for more information.

[0213] ITEM_NAME

[0214] This item specifies a Friendly Name for a device or the riser card itself. The ITEM_NAME entry can displayed by the BIOS during boot in the same manner that BIOS may display disk drives and PCI cards.

[0215] The ITEM_NAME also provides a method for the OS device driver to retrieve a vendor-defined name for the device.

[0216] ITEM_SERNUM

[0217] This item is intended to carry the serial number of the ACR card itself. The LEN field in the item header minus one (or minus two if the header contains an additional byte for Isize) encodes the length, in bytes, of the serial number.

[0218] The Serial Number format Flag field of this item will determine how the serial number is stored.

[0219] The possible values for the Serial Number Format Flag are:

[0220] ITEM_CAPACITY

[0221] This item is intended to describe the capacity of the ACR EEPROM attached to the Serial bus. Devices that use this memory for parameter storage, such as an Ethernet NIC, should read this item in order to determine how much free memory space is available.

[0222] ITEM_USER

[0223] This data item is used to carry vendor-specific information.

[0224] Controller Default ID's

[0225] The BIOS will attempt to assign values to the four ID registers in the PCI configuration space of any host controller as specified in the enumeration EEPROM. If the object data in the EEPROM does not specify a value for a register, or if the value specified is 0000h, then the host controller must keep its default values.

[0226] In this particular embodiment, it is preferred that at least the Subsystem Vendor ID and Subsystem ID fields of all generic host controllers be writable by the enumeration and configuration procedures.

[0227] During configuration, the BIOS will attempt to write new values to the ID registers in the PCI configuration space of all host controllers that have devices attached. Once the configuration is complete, but before the BIOS attempts to boot the OS, the BIOS must ensure that the ID registers of all enabled host controllers are set to READ-ONLY. The host controller hardware must provide a mechanism to permit the BIOS to write to the ID registers but make them read-only after configuration. This can be accomplished by implementing these registers as write-once as the AC-Link controller for AMR or any other fail-proof mechanism.

[0228] The table below shows the default values that must be loaded into the various registers in the PCI configuration space of the host controllers assigned to the ACR subsystem.

[0229] The table below marks registers as being of type Read-Only (“RO”) or Write-Once (“WO”). There may be special cases where it may be desired to break away from this recommendation, such as when protecting IP or special Original Equipment Manufacturer (“OEM”) bundles.

[0230] ACR Plug and Play Functionality

[0231] There are several different ways to specify the identify of an ACR device attached to a PCI host controller, depending on how much identification information is specified by the vendor in the EEPROM and the flexibility of the host controller. The ACR card vendor must choose the right amount of information in order to accomplish his or her intention.

[0232] Combined with the mechanism used by the OS and functionality of the device driver, it is possible to build solutions that are IP-restricted, IP-open or any degree between them.

[0233] A vendor may optionally specify in the enumeration EEPROM the values to be written to the configuration space of the host controller. These values include the Vendor ID and Device ID pair, the Subsystem Vendor ID and Subsystem ID pair, both pairs or none at all.

[0234] Provided below are further details of an exemplary embodiment of the enumeration process. The pseudo-code program listing below further illustrates the enumeration procedure, as shown in the flowchart. DevList is a pointer to a pre-allocated region of memory where the device list is assembled.

[0235] Provided below are further details of an exemplary embodiment of the BIOS entry points. The pseudo-code program listing below further illustrates exemplary function calls of the BIOS entry points. The BIOS preferably provides a copy of the configuration table to a real mode or protected mode client. The client can provide a region of memory large enough to contain the whole device table.

[0236] The function call, BIOS present, is used to determine if the BIOS is present on the host machine.

[0237] The function call, Get enumeration table size, is used to determine the amount of memory that a client needs to allocate to hold the enumeration table.

[0238] The function call, Get ACR default controller ID, is used to obtain the default PCI ID's of the host controller for a given ACR bus. These values are most likely “hardwired” into the BIOS code.

[0239] An operating environment for devices of the present invention may include a processing system with at least one high speed CPU and a memory. It will be appreciated that acts and symbolically represented operations include the manipulation of electrical signals by the CPU. The electrical system represents data bits which cause a resulting transformation or reduction of the electrical signal representation, and the maintenance of data bits at memory locations in a memory system to thereby reconfigure or otherwise alter the CPU's operation, as well as other processing of signals. In accordance with the practices of persons skilled in the art of computer programming, the present invention is described above with reference to acts and symbolic representations of operations that are performed by the processing system, unless indicated otherwise.

[0240] The memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to the data bits. The data bits may also be maintained on a computer readable medium including magnetic disks, optical disks, organic disks and any other volatile (e.g., Random Access Memory (“RAM”), flash RAM) or non-volatile (e.g., Read-Only Memory (“ROM”)) mass storage system readable by the CPU.

[0241] Preferred and alternative embodiments of the present invention have been illustrated and described. This and other arrangements described herein are shown for purposes of illustration only, and those skilled in the art will appreciate that other arrangements and other elements (e.g., machines, interfaces, functions, etc., whether or not separately known in the prior art) can be used instead, and some elements may be omitted altogether. Further, as in most computer applications, those skilled in the art will appreciate that many of the elements described herein are functional entities that may be implemented as discrete components or in conjunction with other components, in any suitable combination and location. It will be understood, however, that changes and modifications may be made to the invention without deviating from its true spirit and scope, as defined by the following claims.