5.

THE PnP SYSTEM ARCHITECTURE

5.1 ISA, PCI and PCMCIA 5.1.1 Industry Standard Architecture
ISA, an acronym for industry standard architecture, is the bus architecture that was introduced as an 8 bit bus with the original IBM PC in 1981 and later expanded to 16 bit with the IBM PC/AT in 1984. The name was officially coined in 1987 by a committee of the IEEE (Institute of Electrical and Electronic Engineers). It also goes under several other names: classic bus, and its original name, AT bus. ISA has been the basis of modern personal computer and the primary architecture used in the vast majority of PC systems till today. This seemingly antiquated architecture is used in todays highperformance systems for reasons of reliability, affordability and compatibility, plus this old bus is still faster than many of the peripherals that we connect to it. Two version of the ISA bus exist, based on the number of data bits that can be transferred on the bus at a time. The original 8 bit version ran at 4.77 MHz in the PC and AT. The 16 bit version used in the AT ran at 6 MHz and then at 8 MHz. Later the industry as a whole agreed on an 8.33 MHz maximum speed for 8/16 bit versions of the ISA bus for backward compatibility. Some systems have the ability to run the ISA bus faster than this, but some adapter cards will not function properly at higher speeds. ISA data transfer require anywhere from 2 to 8 cycles. Therefore, the theoretical maximum of the ISA bus is about 8 M as the following formula shows: 5/26/10 10:55:40 AM 8 MHz * 16 bits = 128 megabits / seconds 128 megabits / seconds 2 cycles= 64 megabits / seconds 64 megabits / seconds 8 = 8 Mbytes / second

The bandwidth will be half this figure for the 8 bit bus. However, these figures are theoretical maximums, because of I/O protocols; the effective bandwidth is much lower, typically by almost half. Even so, at 8MB / sec, the ISA bus is still faster than many of the peripherals we connect to it, but much slower than the microprocessors.

Pin outs for the 16 bit ISA Bus

Since the time the IEEE set the ISA specification, its bus signals have remained essentially unchanged. The introduction of the Plug-and-Play ISA specification on May 28, 1993, a joint development by Intel and Microsoft, alters the way expansion boards work in conjunction with the bus. Plug-and-Play ISA is designed to give ISA systems the same, if not better, selfconfiguration capabilities enjoyed by more recent expansion bus designs. In fully

compliant systems, you can plug in any combination of expansion boards and never have to worry about such things as DIP switch settings, jumper positions, interrupts, DMA channels, ports, or ROM ranges. Each Plug-and-Play ISA card can tell its computer host exactly what resource it requires. If the resource requests of two or more cards conflict, the Plug-and-Play system automatically straightens things out. Instead of altering the bus, Plug-and-Play ISA substitutes an elaborate software-based isolation protocol. Effectively, it keeps an expansion board switched off until it can be uniquely addressed, so that one card can be queried at a time. The host system then can determine the resources the board needs; check to make sure that no other board requires the same resources; and reserve those resources for the target board. Plug-and-Play ISA allows for any board to ask for up to four non-contiguous ranges of memory base addresses; up to eight non-contiguous base addresses for input/output ports; up to two separate interrupt levels; and up to two DMA channels. The system can query a board as to its needs only when the board is in its Config state. Only one board can be in Config state at a time; this state is selected either during the isolation sequence or by sending a Wake command using the board's unique Card Select Number (which must be assigned earlier during the isolation sequence). Although Plug-and-Play ISA does not require so, it can make use of slot-specific addressenabled signals. The use of such signalswhich are now not part of the ISA specificationcan eliminate the complex software-query system used for isolating cards. While software-based Plug-and-Play configuration is possible with current systems, using the streamlined hardware-based scheme requires new motherboards.

5.1.2 Peripheral Component Interconnect

PCI is an acronym for Peripheral Component Interconnect, a local bus standard developed by Intel Corporation. Most modern PCs include a PCI bus in addition to a more general ISA expansion bus. PCI is a 32-bit bus, but supports a 64-bit extension for Pentium and later processors. It can run at clock speeds of 33 or 66 MHz. At 32 bits and 33 MHz, it yields a throughput rate of 132 MBps. 64-bit implementations running at 66 MHz provide 524 MBps. PCI defines several variations on the basic expansion board. The specification defines two sizes of board, each with three connector arrangements (5-volt, 3.3-volt, and dual voltage). The two board sizes are based on traditional ISA expansion boards. Full-size PCI expansion boards measure 12.283 inches (312 mm) long. The main body of the board is about 3.875 inches high, although the expansion edge connector and a short skirt extend the width of the board to 4.2 inches (106.68 mm). The critical reference dimension is the centerline of the notch in the expansion connector, which is displaced 4.113 inches (104.47 mm) from the back edge (retaining bracket side) of the board.

PCI also defines a short board, about half the length of a full-size board at 6.875 inches (174.63 mm) front to back. All other vital dimensions, including the distance from rear edge to the registration notch in the expansion connector are identical to a full-size board. The PCI design provides for expansion connectors extending the bus off the motherboard, but limits such expansion to a maximum three connectors (none are required by the standard). This limit is imposed by the high operating frequency of the PCI bus. More connectors would increase bus capacitance and make full-speed operation less reliable.

Primary dimensions of a PCI card

Although developed by Intel, PCI is not tied to any particular family of microprocessors. Intel Corporation introduced Peripheral Component Interconnect in July 1992. The first PCI specification fully documented Intel's conception of what local bus should be. Intel defined mandatory design rules, including hardware guidelines to help ensure proper circuit operation of motherboards at high speeds with a minimum of design complication. It showed how to link PC circuitsincluding the expansion busfor high speed operation. But the initial PCI announcement fell short exactly where the industry wanted the most guidance: the pin-out of an expansion bus connector that allows the design of interchangeable expansion boards. In truth, PCI turned out not to be a local bus at all, but a high speed interconnection system a step removed from the microprocessorbut one that runs more closely to microprocessor speed than does a traditional expansion bus. Although in its initial form, PCI was not incompatible with VL Bus, Intel positioned its design more as a VL Bus alternative by introducing PCI Release 2.0 in May 1993. The new specification extended the original document in two primary ways. It broadened the data path to 64 bits to match the new Pentium chip, and it gave a complete description of expansion connectors for both 32-bit and 64-bit implementations of a PCI expansion bus. The design is unlike and incompatible with the VL Bus. Foremost, PCI 2.0 was designed to be microprocessor-independent rather than limited to Intel's own chips. Instead of

linking almost directly to the microprocessor, the PCI 2.0 specification provided a compatibility layer, making it what some industry insiders call a mezzanine bus. PCI tolerates older buses but can also replace them. In fact, machines that combine PCI with a traditional bus may serve as a foundation to move from ISA to PCI as the primary personal computer expansion standard. The bus of tomorrow today is perhaps the best way to characterize Intel's Peripheral Component Interconnect. Of all the expansion systems currently in use in desktop PCs, PCI holds the best promise of replacing ancient ISA once and for all. Three characteristics back this promise. PCI is fast, an excellent match for the current generation of microprocessors. In addition, PCI is microprocessor-independent, so if the world of PCs does move away from the Intel microprocessor standard, PCI will still give machines expansion reach no matter what chip is inside. Finally, PCI has no real competition and solid backing.

PCI was designed to operate at the full clock speed of Intel's top-of-the-line microprocessors33 MHz and beyond. That high speed makes the layout of circuit traces on the motherboard itself critical. Consequently, the original PCI specification gave guidelines for the physical configuration of the chips to be connected on the motherboard. Intel believed that PCI devices should physically be arranged as close together as possible so that chip connections to the high speed parallel circuit traces (an onboard bus that Intel called the PCI Speedway) are spaced about one-inch apart. The chips straddle the speedway, alternating sides of the speedway so that those located on a given side appear at two-inch increments. This staggered design minimizes the length of the bus and the capacitive effects that limit its operating frequency.

When Intel upgraded the PCI specifications to match the Pentium processor, they also tightly plugged the one hole in the original design. By specifying not only a connector pin-out but also entire expansion board architecture, Intel's engineers pushed PCI into the forefront of expansion design.

A key tenant of the PCI design is processor independence; that is, its circuits and signals are not tied to the requirements of a specific microprocessor or family. Even though the standard was developed by Intel, the PCI design is not limited to Intel microprocessors. In fact, some computers based on DEC's Alpha chip are expected to use PCI.

PCI can operate synchronously or asynchronously. In the former case, the speed of operation of the PCI bus is dependent on the host microprocessor's clock, and PCI components are synchronized with the host microprocessor. Typically, the PCI bus will operate at a fraction of the external interface of the host microprocessor. The most common arrangement runs the PCI bus at one-half of the microprocessor external clock, a PCI at 33 MHz while the microprocessor runs externally at 66 MHz. The PCI standard

allows operation at any frequency in the range from 20 to 33 MHz to accommodate most microprocessor clocks at reasonable multiples.

5.1.3 PCMCIA
The world of movable computers has its own demands for expansion that were becoming apparent in 1987, by which time memory manufacturers were packing expansion RAM for notebook computers in slide-in credit card-size boards. In order to standardize the design and operating guidelines of the miniaturized cards produced by various competing companies, Personal Computer Memory Card Industry Association or PCMCIA was formed in 1988 under the initiatives of Fujitsu. The expansion standards promulgated by the Personal Computer Memory Card Industry Association differ radically from conventional expansion boards. These standards envision fitting components into credit-card size or smaller packages. Their small size makes them the natural way to augment notebook computers. Better yet, the designers of the PCMCIA standards anticipated many of the demands of next generation computers. They incorporated automatic configuration abilities similar to those used by Plug-andPlay into their designs. They also conceived the idea of external expansionletting us slide cards into your PC without opening its case. These novel attributes have made PCMCIA expansion standards part of the next generation of small computer design. Sealed box NetPCs will rely on the PCMCIA standards for expansion. In face of the rapid increases in peripheral performance brought by local bus interfaces, the original PCMCIA specifications look laggardly indeed. To keep in step with technology, the organization developed a new standard that incorporated the strengths of the local bus design. To distinguish the standards, PCMCIA now prefers to term its original, AT-bus based standard as PC Card and the local bus-based cards as CardBus. In addition, another industry group developed a smaller version of PCMCIA cards using a subset of its signals and restricted to memory operations. The resulting standard is termed Miniature Card. PC Card, Release 1.0, the first generation of the PCMCIA standard, was introduced in September 1990. It contemplated only the use of solid-state memory on the card as a means of data storage. But the PC Card intrigued both the makers of sub-notebook computers and peripheral developers, who believed that the standard could be expanded to incorporate I/O devices as well as memory. As a result, the PC Card standard was updated in September 1991 to comprise a more generalized interface that would accommodate both storage and input/output devices. Additionally, the new Release 2.0 standard allowed the use of thicker cards, permitting the incorporation of a wider variety of semiconductor circuits. It also allowed programs stored on PC Cards to be executed in the card memory instead of requiring the code to be downloaded into standard RAM. In keeping with good practice, backward compatibility was maintained: Cards designed under PCMCIA Release 1.0 plug into and work in Release 2.0 machines. Because Release 2.0 adds a wealth of features that older hardware may not understand, however, all the functions of a new card may not work in an older system. Because normal

thickness cards of both generations are physically the same, new cards will fit slots in old systems. No combination of card and system will result in damage at either end of the connection. To bring the PC Card into the 32-bit world, PCMCIA adapted the highly regarded PCI expansion bus to the credit-card format in November 1994, to create the CardBus. Just as PC Card is a miniaturized version of ISA, CardBus shrinks down PCI while yielding the same high data transfer rates with one important exception: due to limitations in the connector design, CardBus extends only to a 32-bit bus width while the PCI standard allows for 64-bit buses. The reason for this constraint is, as usual, backward compatibility. CardBus cards are physically identical to PC Cards both in size and connections. You can slide either one into a slot and either kind of card will work in a PC that supports them. For memory applications where even a PC Card is too big, chip maker Intel developed an even smaller standard called, appropriately, Miniature Card, first released as version 1.0 on February 29, 1996. Envisioned as the perfect memory solution for digital cameras and miniaturized digital audio recorders, Miniature Cards are less than an inch and a half square but can store up to 64MB using any standard memory technology. In addition, the Miniature Card design is readily adaptable as a replacement for conventional memory modules, providing all the signals required for access as ordinary system memory. Thus, three different standards fall under the PCMCIA rubric. PC Card was the initial design created by PCMCIA, essentially a miniaturized version of ISA optimized for memory and mass storage. CardBus takes credit-card expansion into PCI territory with full 32-bit, high speed expansion support. Miniature Card further shrinks expansion resources into tiny modules for the utmost in compact storage. The PC Card expansion system is not a simple extension to the bus circuitry of a computer. Rather, it is a system that includes everything from a computer and hostindependent socket for the PC Cards to program calls that link software into the PCMCIA system. The centerpiece of PCMCIA 2.1 is the PC Card itself. Measuring 54 by 85 millimeters (2.126 by 3.37 inches) and 3.3 mm (just over one-eighth-inch) thick, the PC Card physically follows the form factor of earlier memory cards (including the IC Card) standardized by JEIDA (the Japan Electronic Industry Design Association). The first release of the PCMCIA specification paired this single-size card with a Fujitsu-style 68pin connector. Under the current PCMCIA 2.1 specification, this form factor is designated as the Type I PC Card. The PCMCIA 2.0 standard puts the extra thickness in a planar bulge, called the substrate area, in the middle of the card. This thicker area measures 48 mm wide and 75 mm long. Three millimeters along each side of the Type II PC Card are kept to the thinness of the Type I standard so that the same card guides can be used for either card type. Similarly, the front 10 mm of a Type II card maintain the 3.3 mm thickness of the Type I standard so that the same connector can be used for either card type. Naturally, the actual card slot for a Type II PC Card must be wide enough to accommodate the maximum thickness of the card.

In September 1992, PCMCIA approved a third, Type III form factor for PC Cards. These still-thicker cards expand the bulge of Type II from 5 mm to 10.5 mm and are designed to accommodate miniaturized hard disks and similar mechanical components. As with Type II cards, Type III PC Cards remain thin at the edges to fit standard card guides and standard connectors. In practical terms, a Type I card comes closest to being a truly flat, credit-card style card. Type II has small bulges top and bottom to accommodate circuitry. Type III cards have thick lumps to hold disk drives. Miniature Cards measure 33 millimeters (about 1.3 inches) by 38 millimeters (about 1.5 inches) and are 3.5 millimeters (about 0.14 inch) thick. The Miniature Card electrical specifications are a subset of the PC Card standard, restricted to memory applications only. It uses a 16-bit data bus and a 24-bit address bus to allow a single card to store up to 64 megabytes. To allow for the widest possible application, the standard allows nearly any memory to be installed on the card including dynamic, static, flash, and read-only memory. A simple adapter can convert a Miniature Card into a Type II PC Card that can slide into any PC Card slot. Some analysts believe that the PC card has the potential to become the dominant expansion technology for desktop model computers as well as portable computers.

5.2 PnP Device Configuration

All Plug-and-Play boards, whether active or inactive, boot up in their Wait for Key state. In this condition, the boards refuse to respond to any signal on the ISA bus until they receive an explicit command called an Initiation Key. Because an ordinary PC BIOS does not know how to carry out the Initiation Key process, it cannot remove Plug-and-Play boards from the Wait for Key state. The configuration circuitry of the Plug-and-Play boards does not activate (if at all) until the Plug-and-Play operating system loads. In a fully Plug-and-Play PC, the BIOS automatically sends out the Initiation Key. It can then take control of individual boards, interrogate each Plug-and-Play device about the system resources it requires, and resolve conflicts between boot-up devices. The BIOS ordinarily does not, however, make resource assignments or activate the boards not involved in boot-up. Instead, it leaves that decision-making to the operating system. In order to configure each expansion board, the Plug-and-Play BIOS or operating system must be able to individually communicate with each board to independently instruct each what to do. Ordinarily, that's difficult in the ISA system because all signals are broadcast in common to all expansion boards. The Plug-and-Play creators envisioned the ISA bus being modified to include slot-specific signals to unambiguously identify each expansion board. Knowing such changes would take years to creep onto desktops, however, they also developed a board-identification system compatible with the existing ISA bus that allows individual addressing except when multiple identical boards are installed in a single PC. In this Plug-and-Play system, a Card Select Number (CSN) identifies each board. Each board is dynamically assigned its CSN by the Plug-and-Play BIOS (if your PC has one) or the Plug-and-Play operating system.

The CSN is actually a convenience that works as a handle, much like the file handles used by DOS. The ROM on each Plug-and-Play board model includes a serial identifier, an eight-byte code coupled with a one-byte checksum. Two bytes store a three-letter manufacturer identification in compressed ASCII code (five bits per character). Two more store the model number of the board, and four more bytes code a board-specific serial number that makes the serial identifier for each expansion board (or at least each board in a given PC) unique. In contrast, the CSN is a single byte, making it more convenient to store and manipulate than the 72-bit serial identifier. All Plug-and-Play boards boot up with a CSN of zero (0). To assign a unique CSN to a Plug-and-Play board, the Plug-and-Play BIOS or operating system must isolate individual boards from the bus. It does this by first arousing all boards from the Sleep state into their Isolation state by broadcasting a Wake command that specifies the default CSN of zero to the Write Data ports of all boards. In the Isolation state, each board interacts with your PC (and the Plug-and-Play BIOS or operating system) in a precisely defined manner called the Isolation Sequence. The Plugand-Play BIOS or operating system uses the serial identifier to uniquely locate each board. The system merely compares the bit patterns of the serial identifiers, ignoring their information content. The Isolation Sequence involves simultaneously scanning all serial identifiers one bit at a time in the Linear Feedback Shift Register. The host system sends out 72 consecutive one-bit read operations (one operation for each of the 64 bits in the code plus its 8-bit checksum). At every step, each Plug-and-Play board compares one bit in its LFSR to that of the other boards by observing bus signals. When the board has a high bit (digital 1) in its LFSR, it asserts a data signal across the bus; boards with low bits (digital 0) at that position in their serial identifiers do not. When a board with a low bit detects the signal from one or more boards with high bits in a given position in their ID codes, it drops out of the isolation sequence by slipping back into its Sleep state. This bit-comparison process continues until, at the end of 72 evaluations, only one board has not dropped off to sleep. Once a single board is thus uniquely identified, the operating system then assigns that board its unique CSN number. The board then stores the CSN for future reference in a special CSN register and it, too, goes into its Sleep state. Then the Plug-and-Play BIOS or operating system initiates another Isolation Sequence to assign the next CSN, and so on until all boards have been assigned their CSNs. Only the boards with a CSN of zero participate in later Isolation Sequences because only they respond to the Wake command that starts the sequence. After all Plug-and-Play boards have been isolated and assigned CSNs, the BIOS or operating system then checks the resource needs of each one. To do this, the BIOS or operating system individually switches each board into its Configuration mode to read its resource needs from the data stored on the board. A board with a valid CSN switches into Configuration mode when it detects a Wake command specifying its CSN. Only one board is permitted in Configuration mode at a

time, so other boards automatically switch to sleep mode when they detect the Wake command meant for another board. In PCs with a Plug-and-Play BIOS, the BIOS checks each board by reading registers through its Read Data port to compile a list of resource requirements, then finishes the boot-up process. The Plug-and-Play operating system takes over at that point. In PCs without Plug-and-Play BIOSes, the operating system merely jumps from the isolation to the configuration process. After a given expansion board has been configured, the operating system can activate it by writing to the appropriate register on the board. A single expansion board may have several functions, each called a virtual device, which the operating system can separately activate. After the configuration process is completed (or at any other necessary time) the operating system can switch the designated expansion board out of its Sleep state and back to its Configuration state to activate it, deactivate it, or change its configuration. It controls each board individually using the Wake command and specifying a CSN. This process allows the operating system to dynamically modify the resource usage of any board in the system as applications require.

5.3 Plug and Play Card Resource Requirement

The large variety of different cards that can be added to PCs to expand their capabilities is both a blessing and a curse. Problems arise because each component needs to communicate with the processor and other peripherals, and there are only a few channels for that communication. These channels are usually referred to as system resources, like interrupt (IRQ), DMA (direct memory access) etc. If two devices use the same DMA, one device will overwrite data the other has already stored in memory. When anything like this happens, its called a conflict, and its not a pretty sight. Configuring the system and dealing with resource conflicts is part of the curse of having so many different nonstandard devices on the market. Dealing with these issues can be a tremendously confusing, difficult and time-consuming task. In an attempt to resolve this ongoing problem, the Plug and Play (also called PnP) specification was developed by Microsoft with cooperation from Intel and many other hardware manufacturers. In theory, if every device in the PC conforms to the Plug and Play standard, the PCs BIOS, Windows, and the devices themselves work together to automatically make sure no two of them compete for the same resources. The goal of Plug and Play is to create a computer whose hardware and software work together to automatically configure devices and assign resources, to allow for hardware changes and additions without the need for large-scale resource assignment tweaking. As the name suggests, the goal is to be able to just plug in a new device and immediately be able to use it, without complicated setup maneuvers. A form of Plug and Play was actually first made available on the EISA and MCA buses many years ago. For several reasons, however, neither of these buses caught on and 10

became popular. PnP hit the mainstream in 1995 with the release of Windows 95 and PC hardware designed to work with it. The basic Plug-and-Play procedure is a three-step process that lends itself to automation: First, your system checks what resources each expansion device needs. Next it coordinates the assignments to avoid conflicts. Finally, it tells your system and software which choices it has made. Devices that do not support the PnP standard are called legacy devices, which is geekspeak for "old hardware we have to keep using even though it doesn't have the capabilities we wish it did". Legacy devices can be used in a PnP system, but they present special problems. They make resource assignment much more difficult because they cannot be automatically configured by the BIOS. Generally, the BIOS deals with non-PnP devices by ignoring them. It simply considers them as "part of the scenery" and avoids any resources they are using. There is usually no problem using these devices with PnP, but using too many non-PnP devices can make it more difficult for PnP to work, due to the large number of resources that it is not allowed to touch.

Requirements for Plug and Play

Automatically detecting and configuring hardware and software is not a simple task. To perform this work, cooperation is required from several hardware and software areas. The four "partners" that must be Plug and Play compliant in order for it to work properly are:

System Hardware: The hardware on the system, through the system chipset and system bus controllers, must be capable of handling PnP devices. For modern PCI-based systems this is built in, as PCI was designed with PnP in mind. Most PCI-based systems also support PnP on their ISA bus, with special circuitry to link the two together and share resource information. Older PCs with ISA-only or VL-bus system buses generally do not support Plug and Play. Peripheral Hardware: The devices added into the system must themselves be PnP
compatible. PnP is now supported for a wide variety of devices, from modems and network cards inside the box to printers and even monitors outside it. These devices must be PnP-aware so that they are capable of identifying themselves when requested, and able to accept resource assignments from the system when they are made. Plug and play adapter cards need to be able to communicate with the system BIOS and the operating system to convey information about what system resources are needed. The BIOS and the operating system, in turn, will resolve conflicts (whenever possible) and inform the adapter cards which specific resources it should use. The adapter card then can modify its configuration to use the specified resources.

11

The System BIOS: The system BIOS plays a key role in making Plug and Play
work. When a Plug and Play system is turned on, the primary arbitrator between Windows 98 and hardware, the BIOS, is the first component to take charge. The BIOS searches for all the devices it needssuch as a video card, keyboard, and floppy drive so the PC can run properly. The BIOS identifies these devices based on their unique identifiers, which are codes that are burned permanently into the devices ROM, or readonly memory. The BIOS then passes control to the operating system. Routines built into the BIOS perform the actual work of collecting information about the different devices and determining what should use which resources. The BIOS also communicates this information to the operating system, which uses it to configure its drivers and other software to make the devices work correctly. In many cases older PCs that have outdated BIOS but otherwise have support for PnP in hardware (PCI-based Pentiums produced between 1993 and 1995 are the prime candidates) can be made PnP-compliant through a BIOS upgrade.

The Operating System: Finally, the operating system must be designed to work with the BIOS (and thus indirectly, with the hardware as well). The operating system sets up any low-level software (such as device drivers) that are necessary for the device to be used by applications. It also communicates with the user, notifying him or her of changes to the configuration, and allows changes to be made to resource settings if necessary. The mainstream operating system with full PnP support is Windows 95 and all later versions of windows.
Windowss configuration manager adds to itself special device drivers called enumeratorsprograms that act as the interface between the operating system and the different devices. There are bus enumerators, enumerators for a special type of bus called SCSI (small computer system interface), port enumerators, and more. Windows asks each enumerator to identify which devices the enumerator is going to control and what resources it needs. Windows 98 takes the information from the enumerators and stores it in the hardware tree, which is a database stored in RAM. The operating system then examines the hardware tree for resource arbitration. In other words, after storing the information in a database, the operating system decides what resources interrupts (IRQs), for exampleto allocate to each device. The system then tells the enumerators what resources it allocated to their respective devices. The enumerators save the resource allocation information in the peripherals microscopic programmable registers, which are sort of digital scratch pads located in some chips.

Finally, the operating system searches for the appropriate device driver for each device. A device driver is a small piece of add-on code for Windows that tells the operating system the facts about a piece of hardware the system needs to communicate with it. If the system doesnt find a device driver it needs, it prompts you to install it. The system

12

then loads all necessary device drivers, and tells each driver which resources its device is using. The device drivers initialize their respective devices, and the system finishes booting. The following is a summary of the Plug and Play event sequence in a full Plug and Play system. Power On Plug and Play logical devices required for boot come up active using power up defaults. Plug and Play Devices Plug and Play devices not required for boot come up inactive. Before POST (Power On Self Test) the BIOS will Isolate a Plug and Play card Assign a handle Read resource data Repeat above until no cards respond Each logical device required for boot is checked for conflict free resource assignments before activating the logical device. POST BOOT System BIOS

13

Operating System will Get Plug and Play information from the system BIOS Read resource from all cards data

Arbitrate system Operating resources for Plug and Play System cards Assign a conflict free resource for all inactive logical devices Activate all logical devices just configured Load device drivers

A lot of effort is thus needed for Plug and Play to work, and this is why the vast majority of older systems (pre-1996) do not properly support this standard.

5.4 PnP BIOS and OS

To be fully Plug and Play compliant the personal computer must support the many levels of support that exists. At the highest level, the application must be Plug and Play aware and must be capable of automatically requesting system resources from the operating system and dynamically adjusts needs as required. The operating system must be fully capable of managing the available resources, eliminate conflicts, and meet application needs requiring resources and support automatic installation and reconfiguration of device drivers. The system BIOS must be able to isolate and interrogate Plug and Play devices and report or attempt to resolve conflicts by reconfiguration and support reconfiguration requests from the operating system. Also, the devices and adapters must be fully Plug and Play. For BIOS to be Plug and Play compatible, it must support 13 additional system function calls, which can be used by the operating system component of the Plug and Play system. The operating system component can be implemented by a brand new version or through DOS extensions. It is the responsible of the operating system to inform users of conflicts that cannot be resolved by the BIOS. Depending upon the sophistication of the operating system, the user then can configure the offending cards manually on-screen or turn off the system and set switches on the physical cards. When the system is restarted, the

14

system is checked for remaining conflicts, any of which are brought to the users attention. Through this repetitive process, all system conflicts are resolved. When the system is not fully Plug and Play compliant or one of the Plug and Play levels is missing the success rate of trouble free installation or upgrade may be reduced. Goals of a Plug and Play System BIOS Considering the scope of Plug and Play, the following are the goals of the Plug and Play BIOS Specification.

Maximize ISA compatibility This is the key consideration in a system BIOS. It is considered unacceptable to change the architecture of a System BIOS to prevent the thousands of ISA cards and software programs that rely on the system BIOS for services.

Eliminate resource conflicts during the POST procedure A common problem that plagues many ISA systems today is the fact that there are a lot more devices available than there are system resources. In this environment, devices are bound to have conflicting resources. The system BIOS will now play a key role to help prevent these resource conflicts by not enabling devices which conflict with the primary boot devices, and relocating boot devices, if necessary, to allow a successful load of the operating system. It is the role of the operating system to provide support for communicating irreconcilable resource conflicts to the user.

Support Plug and Play ISA cards A Plug and Play system BIOS is responsible for the isolation, enumeration, and optional configuration of Plug and Play ISA cards. These cards, which provide information on their resource requirements and permit software to configure those resources, will allow the system BIOS to arrive at a conflict free configuration necessary to load the operating system.

Allow dynamic configuration of systemboard devices Systemboard devices have traditionally been treated as having somewhat static configurations. It is a goal of the Plug and Play BIOS specification to provide a standard mechanism whereby systemboard devices may be configured dynamically by system software. This will grant configuration management software a great deal of flexibility when system resources are in demand and alternate configurations are necessary.

Provide system event notification

15

The system BIOS is capable of detecting certain hardware events that could affect the system configuration. By providing an event notification mechanism, an operating system can recognize the event and process any necessary configuration changes.

Hardware and Operating System independence The extensions to the system BIOS isolate the systemboard hardware through well defined interfaces and structures. The system device nodes represent devices that are controlled by the system BIOS. The operating system requires no specific knowledge of the systemboard in order to control these devices, and instead relies on the system BIOS to isolate it from the underlying hardware.

5.5 PnP POST and Device ROM

Most of the actual work involved in making Plug and Play function is performed by the system BIOS during the boot process. At the appropriate step of the boot process, the BIOS will follow a special procedure to determine and configure the Plug and Play devices in your system. The Plug and Play features of the BIOS are implemented through an extended power on self test (POST). The BIOS is responsible for identification, isolation, and possible configuration of Plug and Play adapter cards. Here is a rough layout of the steps that the BIOS follows at boot time when managing a PCI-based Plug and Play system: 1. 2. 3. 4. 5. Disable any configurable devices on the motherboard or on adapter cards. Create an initial resource allocation table of the available IRQs, DMA channels and I/O addresses, excluding any that are reserved for system devices. Search for and identify PnP and non-PnP devices on the PCI and ISA buses. Load the last known system configuration from the ESCD area stored in nonvolatile memory. Compare the current configuration to the last known configuration. If they are unchanged, continue with the boot; this part of the boot process ends and the rest of the bootup continue from here. If the configuration is new, begin system reconfiguration. Start with the resource table by eliminating any resources being used by non-PnP devices. Check the BIOS settings to see if any additional system resources have been reserved for use by non-PnP devices and eliminate any of these from the resource table. Assign resources to PnP cards from the resources remaining in the resource table, and inform the devices of their new assignments.

6. 7. 8.

16

9. 10. 11.

Update the ESCD area by saving to it the new system configuration. Most BIOSes will print a message when this happens like "Updating ESCD ... Successful". Start the bootstrap loader. Transfer control to the Operating System.

5.6 PnP BIOS Services

In order to achieve the goals of Plug and Play, the system BIOS is responsible for availing the services listed below:

Maintain ISA POST compatibility The important issue of this broad requirement is that a Plug and Play system BIOS is responsible for the same POST requirements of an existing PC compatible system BIOS. This document focuses only on the enhancements necessary to a PC compatible system BIOS and assumes that the basic BIOS POST initialization is still performed.

Configuration of all static devices known to system BIOS At a minimum, this includes system board devices. It can also include Plug and Play ISA Cards and devices located on EISA, ISA, PCI, or any of the other static bus architectures available. How this configuration is completed will be described in a later section.

BIOS POST Resource arbitration The system BIOS must now be aware of system resource usage. Using the information provided through runtime services, along with resource information known to the system BIOS, critical resource conflicts can be avoided. Loading the operating system with a conflicting device disabled is better than causing a resource conflict and a possible system failure.

Initialization of the Initial Program Load (IPL) device It is the responsibility of the system BIOS POST to make sure that resources for the IPL device get allocated correctly in anticipation of a successful load of the operating system. If disabled IPL devices are needed to achieve boot, then the system BIOS POST should take the initiative to re-enable "disabled" IPL devices in an intelligent sequence to provide the best opportunity for system boot.

Support for both Plug and Play and Non-Plug and Play Operating Systems

17

The Plug and Play system BIOS POST must configure the system to operate with both Plug and Play aware, as well as non-Plug and Play operating system. In non-Plug and Play environments, either the system BIOS or the appropriate system software (device drivers) must configure all devices (Plug and Play ISA Cards, PCI devices, etc.). This will allow all environments to load exactly as they would on standard PC compatible systems. However, in a Plug and Play environment, the system BIOS can now assist the operating system to perform features such as runtime configuration of system board devices and event recognition when system board devices have changed.

18