Design Feature: March 2, 1995

Many a slip 'twixt plugging and playing

In nearly every segment of the PC industry, people are hard at work on a group of initiatives known as Plug-and-Play (PnP), an umbrella term for a design philosophy that aims to make PCs easier to set up and thus accessible to a wider audience. While the best known PnP initiatives cover PCI, PCMCIA, and the venerable ISA bus, others cover such buses as EISA, SCSI, and VL. For a quick acronym review, see box, "Bus gobbledygook," a glossary that decodes these bus names. There are even PnP initiatives (Access.bus, for example) that deal with parallel and serial ports, external modems, monitors, and mice. Nevertheless, although PnP proponents have good reason for optimism, few of them should declare victory just yet.

Although hardly anyone thinks that much is right about the current trial-and-error method of assigning resources when installing PC peripherals, the industry's challenge is to implement a practical system of automatic resource allocation. (For ISA bus cards, the resources are interrupt-request lines (IRQs), DMA channels, memory-address space occupied by the card firmware, and I/O-port addresses.) The trial-and-error approach involves repeatedly restarting the system after trying to find the right jumper- and DIP-switch settings on I/O cards. Often, it also involves trying several software drivers and configuration options in applications packages. This approach, dubbed "plug and pray" by industry wags and "plug and hope" by Intel's more politically correct marketers, is a holdover from PC's early-1980s origins.

Under Windows 95, the operating system (OS) allocates the resources. Windows NT (including versions for µPs from vendors other than Intel) and IBM's OS/2 (IBM calls its latest release OS/2 Warp) also handle resource allocation. Other OSs for computers that use buses covered by PnP initiatives will follow suit. Add-ons will impart a subset of Windows 95's PnP capabilities to Windows 3.1, but Microsoft would prefer to see Windows 3.1 users upgrade to Windows 95 rather than add onto the older version. The software giant is thus almost certain to use Windows 95's more extensive PnP capabilities to convince users to upgrade.

Having the OS take care of resource allocation is technically elegant, but in the PC business, elegance doesn't necessarily equate with success. What nearly always prevails is marketing clout. Luckily, the prime movers behind several of the PnP initiatives (the ones for ISA, PCI, and PCMCIA) are Microsoft and Intel. These two industry giants pack all of the clout imaginable. Scores of other companies that believe in PnP are cooperating. Representatives of smaller companies think that being first, or among the first, to market PnP products will give them a competitive edge, whereas failing to deliver such products when Microsoft first ships Windows 95 or shortly thereafter could be fatal.

Memories of failed attempts

But hanging over these initiatives are memories of failed attempts to rectify PC shortcomings. The MicroChannel bus of IBM's PS/2 line is an example. Though technically superior to ISA, it never achieved critical mass. When the introduction of a new technology is imminent, vendors and trade journalists often set PC users' expectations unrealistically high. A technology that falls short of user expectations when it first appears rarely gets a second chance, regardless of its merits. In the case of PnP, a prolonged "teething period" is likely. One reason for this is that many pieces must fit into place to make PnP work. A second reason is that there is an enormous legacy of software and hardware that predates PnP standards. ISA hardware is by no means the only offender.

Playing roles in making a system plug-and-play-configurable are the system BIOS firmware that resides in ROM chips on the system motherboard (BIOS stands for basic input/output system), the OS, the device drivers, the host-system hardware, the I/O card hardware and firmware, and even the application software. ISA PnP's architects carefully considered these factors in order to design a system that is backward-compatible with old hardware and, in some cases, with old software. (See, box "PnP-what does it take?")

Nevertheless, unlike systems whose elements all support PnP, most systems that contain a mixture of PnP and legacy elements offer relatively few advantages over systems that completely lack PnP support. (Certain elements are more important to PnP operation than others; for example, a system can derive significant PnP benefits without using a PnP monitor or mouse.) The danger is that resellers may unwittingly supply systems that include one or more legacy elements and that users will become frustrated or angry when they find that an installation procedure they perceived as straightforward turns ugly.

PCMCIA is a case in point. The standard for credit-card-sized storage devices and I/O adapters was billed as a plug-and-play standard almost from the outset, but purchasers of notebook PCs soon learned otherwise. Eighteen months ago, nearly all purchasers of such PCs found that, to obtain PCMCIA cards that would work in their machines, they had to select from a very short list, which was published by the PC's manufacturer. These problems haven't derailed PCMCIA; its potential value is just too great. Moreover, by now, vendors have worked out most of the kinks. Often, though, older PCs require upgrades if they are to work with more than a handful of PCMCIA peripherals.

The situation with credit-card-size peripherals will become more complex with the introduction of a new bus that, although it still has no official name, seems destined to be called Cardbus. Although current PCMCIA cards will work in Cardbus "drives" (the slots into which you plug the cards), existing PCMCIA drives won't accept Cardbus cards. These new cards, with sizes the same as those of existing PCMCIA cards, will also have 68-pin connectors, albeit ones that have been modified to meet the needs of the faster bus. Just as PCMCIA is, in effect, a miniaturized ISA bus, Cardbus will be a sort of miniature PCI. Cardbus will be faster than PCMCIA, but not as fast as PCI, because Cardbus's narrower width requires transmission of data and addresses in 16-bit chunks. A Cardbus drive will sense whether a PCMCIA card or a Cardbus card has been inserted, and it will configure itself accordingly. This dual personality adds a new wrinkle to the PnP concept.

For some, PnP was easy

Not all systems have encountered the kind of difficulties in providing plug-and-play configurability that PCMCIA has experienced. Several buses have offered plug-and-play operation from the outset-and have done so with little fuss or fanfare. Two such buses are the Macintosh's Nubus and the MicroChannel bus. These are the most widely distributed embodiments of plug-and-play technology. But many lesser-known systems-mostly ones that use proprietary buses, where a single company controls the hardware and software-have offered plug-and-play features for more than a decade.

The ISA bus differs in one important aspect from the MicroChannel bus, the Macintosh implementation of the Nubus, and the proprietary systems. In all of these systems except ISA, even where there are multiple vendors, one company controls the hardware and at least some key part of the software. For example, IBM PS/2 systems so far seem to come close to achieving full plug-and-play capability only when running the company's OS/2 OS. PC buses, on the other hand, are truly open, multivendor architectures.

Making PnP work in the multivendor PC environment requires cooperation from all of the vendors. Such cooperation is difficult to achieve because many of the companies involved are direct competitors. Microsoft, despite its dominance in the PC-software industry, does not exercise complete control over the PC business. In hardware, the number of computer and peripheral suppliers is in the hundreds-if not the thousands. Microsoft supplies very little hardware; its best-known hardware item is the Microsoft Mouse.

In software, notwithstanding Microsoft's leadership in sales of PC OSs, PC users can opt for OSs from other vendors, including IBM. (OS/2 is not restricted to PS/2 systems; it runs on most PCs that use 32-bit X86 µPs.) In PC application software, where Microsoft is also the largest player, competition is even more intense. In PC BIOS firmware, there are at least four major vendors and many smaller ones; Microsoft does not supply BIOS code.

After a long period of seeming not to care about plug-and-play, Microsoft wants PC users to have it and have it now. The reasons are clear. After many false starts, home-PC applications are finally emerging as a key area of potential growth for PCs. Among home applications, multimedia is very important, and no type of PC hardware has caused more installation headaches than multimedia hardware.

Plug-in expansion is here to stay

Despite the high risk of encountering major hassles when users or support people try to add hardware options to PCs, plug-in hardware expansion will remain a fact of life in the PC world. Installation problems (as well as fears of experiencing them) are inhibiting the next phase of PC-market growth, however. Home users can't deal with configuration hassles, and with the thin margins on PC products, vendors, including giants such as Microsoft, can't afford to hold users' hands.

Meanwhile, easily swapped hardware modules, such as PCMCIA cards and external SCSI devices, add yet another dimension to the configuration problem-the need to support dynamic reconfiguration. Similar problems arise from notebook PCs' ability-while under power-to plug into and unplug from desktop units that contain more and different system elements (higher resolution displays, for example). Hardly anyone wants to think about what happens when a user disconnects a hard disk containing the memory overlays for a currently running application. Although the situation is analogous to removing the program diskette from an old floppy-disk-based PC (something that rarely caused a crash), one developer likes PCs that can tolerate removal of their program-storage media to fault-tolerant computers of the type found in the banking industry's on-line transaction processors. Such systems aren't PC-based.

At least for now, users should be careful about unplugging removable devices that are in use. When a PC's modem is not on line-even if the communications software is running-it's probably safe to pull a PCMCIA modem out of a notebook PC. But removing a storage device that contains executable portions of the OS or of a running application invites a system crash.

Eventually, such precautions should become unnecessary. Not only OSs, but also application software will be PnP-aware. A RAM-resident portion of the OS will detect that you've removed a hardware element and will pass a message to the application. Upon receiving the message, the application will know not to access the missing element. If the removed item is a memory device containing part of the application code, enough of the application will remain in RAM to keep it from crashing, should you attempt to access the missing system element. Moreover, the OS will display a message asking you to replace the missing item. If you indicate that you do not wish to do so, the OS will suspend or shut down the application.

This is just one example of the cooperation among diverse system elements-both hardware and software-that must exist for PnP to succeed. The complexity of today's hardware and software places major obstacles in the way of PnP. As with so many aspects of today's computing systems, the possibilities that developers will overlook small, but critical, elements are virtually unlimited. In addition, the chances of figuring out in advance all of the combinations of events that must be tested to guarantee reliability seem minuscule.

PnP-what does it take?

To make PnP practical in an environment that allows unlimited numbers of board types from an almost-unlimited number of vendors, strict standards must exist on the boards' behavior. When you first install it, a PnP board isolates itself from the system. In other words, the board listens for messages intended for it, but it does not place data on the bus until asked. Until configuration is complete, that data could conflict with data sent by another system element.

In any PC, the BIOS code executes immediately after you apply power. A PnP BIOS is an important part of a PnP system. The roles of the BIOS and the OS are closely linked; in fact, they overlap. Just which functions are performed by BIOS code and which are performed by the OS depends on both the BIOS and the OS. For example, Windows 95 will run with certain limitations in PCs that lack a PnP BIOS. When Windows 95 runs in a PC that includes a PnP BIOS, the OS performs several functions that BIOS code might perform under another OS. Nevertheless, Microsoft feels so strongly about the need for a PnP BIOS in Windows 95 systems that it plans to require such a BIOS in every PC that carries the Windows 95 logo.

Under Windows 95, the BIOS's role in PnP is to identify and configure the boot devices-ones that must be present for the OS to load into RAM. Besides the hard drive or other mass-storage device, the boot devices are the display, an input device (usually the keyboard), and, on diskless workstations, a network adapter. A non-PnP BIOS makes replacing such system elements much more difficult. The following discussion applies to systems running under Windows 95.

After finding a minimal hardware configuration, the BIOS passes control to the OS, specifically to an OS module named the configuration manager (CM). The CM calls additional software modules known as enumerators to locate and identify the devices on each bus in the PC. PnP boards report what system resources they can use and inform the enumerator of their manufacturer and type. The OS needs to know a board's exact identity so it can install the correct software driver or-if it can't locate the driver in mass storage-can ask you to load the driver. The CM also checks for additional information in a registry file on the PC's hard disk or flash EEPROM. This file contains the particular PC's configuration history.

Building a tree

The CM then constructs a hardware tree reflecting the PC's current configuration and calls software modules known as resource arbitrators to resolve conflicts and dynamically reassign resources. The arbitrators need to be aware of dependencies (for example, a modem card assigned to COM1 uses IRQ4; the same card, assigned to COM2, uses IRQ3). Finally, the OS configures and installs the appropriate device drivers.

Where possible, the OS assigns the resources in a way that does not create conflicts. You can, however, install hardware combinations that create irreconcilable conflicts. When this happens, PnP eases the pain. The OS informs you of which devices conflict, and you can tell the OS which devices to ignore in the current session. Maybe you won't be using your document scanner for a few hours. If so, you can disable it and enable your sound card. Later, when you need the scanner but not the sound card, you can invoke the CM and alter your selections without rebooting.

From the preceding discussion, you probably understand that, despite the central role of software in PnP, a PnP board must incorporate some fairly complex logic. The cost of incorporating this logic is not extreme, however. The usual route is to add the logic to an ASIC you develop for the board. Several ASIC vendors offer the necessary logic in their cell libraries. At least two companies, Fujitsu and National Semiconductor, offer dedicated ISA bus PnP controller chips. Fujitsu's MB86701, in a 120-pin PQFP (plastic quad flatpack), costs $5.95 (10,000). The EVA 86701 evaluation kit, an Ethernet card with network drivers and utilities, costs $159.

With buses to which you can make external connections (two examples are PCMCIA and SCSI), hot swapping is an issue. Also, many notebook PCs support hot docking (power-on insertion of the PC into a docking station that can contain additional system elements). Where these possibilities exist, the bus controllers must poll the bus slots periodically to determine whether boards that were in the system are still present and whether new boards have been added. If a bus controller detects a change in the installed hardware, it must pass a message to the OS. In systems that permit neither hot swapping nor hot docking, polling of the slots needs to take place only when the system first powers up.

Hot swapping and hot docking require use of special connectors that first make a ground connection and then make power-supply connections. Signals are connected only after the power supplies are stable. Moreover, just before you plug a unit into a powered-up bus or docking station, the bypass capacitors in the unpowered unit are usually discharged. Unless the unit's design limits it, the flow of charging current through the impedance of power-supply and ground lines can cause voltage spikes that interfere with the operation of other system elements.

Gotchas aplenty

Implicit in the description of how a PnP system configures itself are all sorts of "gotchas." For example, suppose a plug-in board's hardware conforms to the letter of the PnP standards but the vendor hasn't yet updated the software driver. The board can use any one of three IRQs; whereas the driver, which was written for an earlier board, assumes that one particular line will be assigned. Will the OS be smart enough to assign the one IRQ that works with the driver, or will it pick a line that is compatible with the board but not with the driver?

The architects of ISA PnP foresaw situations of this type and allow you to edit the hardware tree to force a compatible selection. The problem is that editing the tree is a job for a knowledgeable user. Even the name-Plug-and-Play-implies that this kind of playing around won't be necessary.

Legacy hardware developed before the advent of PnP standards presents a huge challenge, and the standards address it. For the ISA bus, Intel has developed a database that, at last report, listed the resource requirements of 280 of the most popular legacy boards. If your system includes one of these boards, all you must do is inform the CM of the board's presence. The OS determines what resources you should assign. You may have to reset jumpers or switches, but, to make the board work, you shouldn't have to do so more than once.

PnP also handles another obvious problem-your system can easily include a legacy card that isn't in the database. Because some 10,000 types of ISA bus cards exist and the database covers fewer than 3% of them, handling cards not in the database is quite important. If you have the card's documentation, you can describe its resource requirements to the CM, and Windows 95 will allocate appropriate resources. In some cases, software may even determine the resource requirements of unknown boards. The ability to handle cards that aren't in the database is important for another reason: Many such cards are similar enough to ones in the database to be confused with them, yet different enough to require different resources.

Even boards for relatively new buses, such as PCI, can be troublesome. A widely held misconception is that all PCI boards support PnP. In fact, only boards that conform to Revision 2.0 or higher of the PCI spec support PnP. Some well-known vendors are still shipping PCI boards designed before PCI Rev 2.0 existed. PnP protocols don't configure these boards automatically. Nevertheless, PCI presents far fewer problems than ISA does and not only because there are relatively few legacy PCI boards. A PCI bus accommodates fewer boards than an ISA bus does. Moreover, because of PCI's greater speed and burst-mode transfer capabilities, a smaller percentage of PCI boards use interrupts and DMA. Thus, PCI reduces competition for these scarce resources.

PnP SCSI—terminating the misery

The SCSI bus is a high-speed bus that can connect to peripheral devices both within a computer's systems unit and external to it. For proper operation, the bus lines must be terminated at both ends; otherwise, reflections interfere with the bus signals. An unusual feature of the SCSI bus is that you can place the unit that originates the bus-the SCSI host adapter-anywhere on the bus; you needn't place it at one end.

Making sure that the terminations are at the two ends of the bus and only there has proven to be a nightmare for many computer users. Apple's Macintosh systems were the first PCs to use SCSI. According to one Apple supplier, 50% of the customer-support calls to Apple resellers relate to SCSI. Of those, 75% relate to improper termination.

In a generic sense, a SCSI bus has three possible physical arrangements:

• It can connect only to devices within the systems unit (hard-disk controllers, for example).
• It can connect only to devices outside the systems unit.
• It can connect to devices both within and outside the systems unit.

In the first two cases, one end of the bus is on the host adapter, so the host adapter must terminate its end of the bus. In the third case, neither end of the bus is on the host adapter, and the host adapter must not terminate the bus.

A single ribbon cable links the host adapter to all internal peripheral devices. A SCSI ribbon cable includes one connector for each internal device you might connect. In older SCSI systems, you had to plug a bus-termination network onto the last internal device in the chain. Older device boards include a place to plug in the network. Users who tried to reconfigure their systems (say, to add a peripheral) would often either forget to remove the termination from a device that was no longer at the end of the chain or were unable to locate a network to add to a device they were moving from the middle of the chain to the end.

Switchable terminators

Switchable termination networks improve on this situation somewhat. They are a permanent part of the peripheral device, so you can't lose them. But, until PnP, you still had to switch them into or out of the circuit. In PnP SCSI systems, the ribbon cables solve the termination problem for all internal SCSI devices except the host adapter. PnP ribbon cables include a termination network permanently attached to the cable's distal end (the end farther from the host adapter). With such a cable, you remove or switch off all of the internal SCSI devices' termination networks, except possibly the host adapter's. If the bus does not leave the systems unit, the host adapter must terminate its end of the bus.

The situation for external SCSI peripherals is a little different. Outside the systems unit, the SCSI bus uses round cables. Each external device includes a pair of connectors. One brings the bus to the device; the other accepts either a cable that carries the bus to the next device or (in older devices) a plug-in bus-termination network. If an external device that includes a switchable terminating network is the last in the chain, the network is switched on, and the second connector is unoccupied.

PnP SCSI systems make concern over correct termination obsolete. Each external device determines whether it has one or two cables connected to it. The same is true of the host adapter. (The host adapter accommodates one external cable and one internal cable.) If two cables are connected, the terminator switches off automatically; if one cable is connected, the terminator switches on.

Termination networks are not SCSI PnP's only concern, however. The peripheral devices must be designed so that the host adapter can assign their bus addresses. In SCSI systems that contain older devices, you must assign the addresses yourself, using switches. If you assign the same address to two or more devices, the system will crash. PnP SCSI host adapters solve this problem using a facility in their firmware unhappily named SCAM (SCSI Configured AutoMatically). SCAM works even on SCSI buses to which you attach non-PnP devices. If you assign nonconflicting addresses to those devices and then add PnP devices, SCAM automatically assigns nonconflicting addresses to the PnP devices.

Plug-and-play and the VMEbus
John Rynearson, VME Industry Trade Association (VITA)

Plug-and-play has come a long way since the early days of the VMEbus. Most early VMEbus boards required careful manual configuration before they were ready for installation in a system. Usually, switches or jumpers had to be set and various options selected manually. The installer's choices among options were not always clear and often caused inadvertent selection of conflicting options. In addition, the jumpers proved to be unreliable and susceptible to shock and vibration.

Several key features make play-and- play feasible. First, circuit boards must be designed with programmable registers instead of jumper blocks or manual switches. Then, as the system starts up, software can configure them. This approach transforms system configuration from a hardware problem to a software problem that is solvable by programming. Software programmability offers many advantages. Once a programmer determines the proper sequences, the software performs them the same way every time. Boards that are swapped in the field will automatically be configured correctly. Eliminating jumper blocks improves system reliability. Board test during manufacture can be more thorough and accurate: Software-rather than time-consuming, error-prone manual operations-can exercise all options.

Because of these advantages, board designers have moved away from jumper blocks and manual switches to programmable registers. In so doing, they have made plug-and-play possible. Many VMEbus interface chips provide a set of registers that are usable for setting various board options.

However, plug-and-play at this level requires unique software for each module, and it requires that the system integrator know, in advance, what boards will go into a system. The ultimate goal of plug-and-play is to dynamically determine if a particular board is present and, if it is, to provide the proper configuration.

The most common method a system uses to configure itself is to provide a unique address space that contains configuration ROM (CR) and command and status registers (CSR) for each module. During system boot, the software probes each module's CR/CSR space. If a module responds, the host CPU reads information from the ROM that indicates what board is present and how to configure it.

CR/CSR space holds the key to true plug-and-play operation. To make plug-and-play possible, the developers of the new VME64 specification include the concept of CR/CSR space. This unique address space provides a mechanism for manufacturer and board identification and automatic board initialization, configuration, and test. CR/CSR space is a also a key element in hot swapping of boards.

Many applications, such as telecommunications, require replacing suspect modules while the system remains under power. The new module must be initialized, and CR/CSR space allows the software to configure the board properly.

A goal of the VMEbus's open-bus technology has always been to make system integration as simple and as straightforward as possible. By adding CR/CSR space, the new VME64 specification serves this goal. The VITA 1-1994, VME64 specification is in the final stages of balloting and will be in the hands of ANSI for official recognition by the time you read this.

Two places to turn for help

The purpose of this article is to make you aware of the issues involved in PnP. If your job is to create a Plug-and-Play hardware or software product, the material here is just the beginning of what you need. The companies listed in the box, "For free information..." are a good place to begin, but there are many other companies to contact. Another place to collect information is on Compuserve. If you type "GO Plugplay" at the main system prompt, you will enter the Plug-and-Play forum, which contains many specifications and correspondence. If you post messages in this forum, you will probably receive replies from the most knowledgeable people in the PnP community.

My experience with GO Plugplay wasn't entirely satisfactory, however. Although I successfully downloaded and unZIPped (decompressed) a file that purportedly contains a specification, none of our word processors could recognize the format. A look into the file with a utility program revealed a line near the beginning containing the phrase "Microsoft Word for Windows 6.0." Presumably, that word processor was used to create the file, so I don't understand why our word processors can't open the document when they can read files from Word for Windows V6.0.

Another source of help is the Plug-and-Play Association (PnPA). Contact information for this group appears in the box, "For free information...." PnPA holds semiannual "PlugFests." These meetings are not trade shows and are not open to the public, but they are open to product developers by invitation. PnPA developed the PlugFest concept because requests from developers to verify products' PnP compatibility were swamping the interoperability labs at Intel and Microsoft. The two companies have developed a suite of tests that products must pass before their vendors can label them with the Windows 95 logo. Developers who bring a product to a PlugFest can perform compatibility tests there.

You can reach Senior Technical Editor Dan Strassberg at (617) 558-4205, fax (617) 558-4470, EDN BBS EDNStras, or via Internet at ednstrassberg@mcimail.com

References

1. Devoney, Chris, "Plug 'N' Play: the first generation," Windows Sources, October 1994, pg 96.
2. Hebert, Vincent, "PCMCIA troubleshooting tips," EDN Products, November 21, 1994, pg 12.
3. Panacea Inc, "Plug 'n' Pray," Panacea Perspective, Fall 1994, pg 1.
4. Shanteau, Bob, "The hardware handyman," PC Report, December 1994, pg 39.