April 10, 1997

New from CardBus: an easier, faster ride

Stephen Kempainen, Technical Editor

Mobile professionals want their notebook computers to be as powerful and easy to use as their desktop systems. Developments in CardBus ICs and software are making that possible.

As any business traveler knows, you can’t take all your desktop-computing capabilities with you. Even if you have a pretty good notebook computer, you usually have to leave behind some capabilities you’d really like to have along. A 100-Mbps LAN connection, high-speed storage and backup, and videoconferencing are just some of the things you’re likely to miss. But you just can’t pack all that desktop power (not to mention ease of use) into your briefcase.

Or can you? Developments in CardBus technology and products are poised to make notebook computers a lot more capable and easier to use. New CardBus ICs, for example, enable the design of notebooks and PC Cards that let plug-in-card peripherals connect to a notebook’s high-speed PCI bus. In addition, the inclusion of CardBus software in operating systems and BIOS modules will give new, high-performance PC Cards plug-and-play (PnP) and hot-swap capabilities, plus tools for resolving compatibility issues. The CardBus host-controller ICs are available now from various vendors (Table 1), and the OS software is in beta testing.

CardBus’ introduction of PCI’s 32-bit bus width and 33-MHz operating frequency to PC Cards gives a big boost to notebook capabilities (see box, "CardBus, PCMCIA, and PC Card 16"). By increasing a card’s maximum throughput from the theoretical 20 Mbytes/sec of a 16-bit PC Card to 132 Mbytes/sec, CardBus enables mobile applications that wouldn’t otherwise be possible. Videoconferencing, 100-Mbps Ethernet connections, and high-speed SCSI II connections are some obvious examples.

Increased bus throughput isn’t CardBus’ only way to enhance performance, however. CardBus also boosts performance by taking over some tasks from the CPU and the PCI bus. CardBus’ bus mastering and DMA, for example, offload some of the CPU’s data-movement chores, freeing the CPU to perform other tasks. In addition, new CardBus host-side controller ICs include zoomed-video (ZV) buffers that allow video-input signals to completely bypass the PCI bus. ZV doesn’t use the CardBus protocol but instead allows a PC Card 16 to write video data directly to a system’s VGA controller by reallocating CardBus signals.

CardBus software

Just as important as performance to CardBus users is ease of use. Notebook-computer users are starting to appreciate the conveniences that CardBus offers—hot-swapping, PnP, and universal compatibility. As they do, demand for those conveniences will likely reach into other product areas, and manufacturers will add the CardBus interface to products other than notebooks.

CardBus’ ease-of-use capabilities still need improvement, however. Early CardBus implementations were plagued with compatibility problems, and CardBus must resolve these problems before it can become a mainstream technology. In particular, it must accommodate the two interfaces that systems can use to configure CardBus: the legacy PC Card 16 registers and the CardBus Socket registers. To support both legacy and CardBus software, CardBus must maintain consistency of interrupt control, power control, the host controller’s status, and card status, automatically reflecting changes to one in the other. In addition, combining PC Card software and PCI software has created difficulties that developers of CardBus products must overcome.

A basis for solving the CardBus-software problems appears to exist in OSR2 (OEM Release Version 2), Microsoft’s (Redmond, WA) September 1996 update to Windows 95. OSR2 has general support for most CardBus features, including PnP, hot-swap, and power management but excluding ZV until the next upgrade release. With the addition of OSR2, Windows 95 can tie up the loose ends in the dynamic configuration of the PCI-to-CardBus bridge. One such loose end is the unique interrupt-routing problems that the backward compatibility to PC Card 16 and ISA interrupts cause.

Windows 95 OSR2 combines aspects of both PC Card and PCI software to resolve the backward-compatibility problem. For example, OSR2 uses PC Card software to allocate a bus enumerator (a bus device driver that detects devices on CardBus and loads the relevant information from a Card Information Structure (CIS) into the current system-configuration record) for enabling PnP and hot-swap. The bus enumerator accesses a PC Card like it accesses any other PnP device during initial configuration and adds capability for a dynamic-configuration event, such as hot-swapping. During dynamic configuration, OSR2 can allocate and reclaim resources. It also enables applications to automatically adjust to live insertion or withdrawal of devices.

To complement PC Card software, OSR2 also uses PCI software. The PCI software handles interrupt routing—PCI interrupts for CardBus and ISA interrupts for PC Card 16—and also configures the PCI-to-CardBus bridge as part of the overall PCI topology. Because CardBus is a PCI bridge that allows dynamic insertion and removal, OSR2 adds the necessary functions, such as CIS access, to comply with the special CardBus configuration. OSR2 provides only a generic, default PCI-to-CardBus driver; however, it doesn’t support specific features of the various PCI-to-CardBus bridge ICs. You can find detailed, up-to-date information on Windows OSR2 and CardBus compatibility on Microsoft’s Web site, www.microsoft.com/hwdev/busbios/cardbus1.htm.

Because OSR2 uses the same default driver to support all CardBus host-side controllers, a customized system needs a BIOS software module to coordinate the OS with a hardware implementation. This additional software, which you can get from third-party PCMCIA software developers, complements and coexists with OSR2. SystemSoft and Phoenix, for example, provide PCMCIA software modules for Card Services (CS) and Socket Services (SS). Because these companies pay specific attention to integrating each combination of card and host system, they can help you more quickly get a product to market. That kind of special attention isn’t available from Microsoft.

Essentially, CS and SS providers develop the software that differentiates your product from the competition. CS is an OS-specific module that provides a hardware-independent application-programming interface (API) for applications and configuration utilities; it provides a uniform interface to all PC Cards and bridges. SS is lower level software that interfaces a hardware implementation to CS. SS modules, developed in cooperation with chip vendors, take into account specific features in the various bridge and card-side chips during configuration.

For example, SS is aware of chip-specific features, such as power management, DMA, and ZV; it tells CS to enable these features during configuration by scanning and evaluating the bridge-configuration and CIS registers. Providers of custom CS and SS modules test their designs for compatibility and operation; you can also work with a CS and SS provider to customize an application’s user interface.

CS and SS providers also offer other standard products that add special features to your design. SystemSoft’s CardWizard software, for example, deals with some of the complexities of hot-swapping, particularly when a PC Card is incompatible with a host’s bridge chip. For instance, CardWizard helps you diagnose and troubleshoot problems such as missing card drivers, improper driver or card installation, interrupt-request (IRQ) and I/O-port resource conflicts, and incorrect allocation of memory windows. CardWizard works with SystemSoft’s CS and SS software, called CardWorks; CardWorks itself provides OSR2 compatibility, power management, and automatic configuration after a live insertion.

But even with all that help on the software side, you still might encounter configuration bugs after integrating OS, CS, SS, and hardware. To help you avoid the time and expense of having your CS and SS provider troubleshoot and rewrite modules, Standard Microsystems Corp (SMC) has added an interface for optional serial EEPROM to the SMC34C90 CardBus host controller. If a configuration bug appears, you can add code to fix it. Then, during runtime configuration, the configuration information you’ve added to EEPROM overrides the default information. An OS-resident SMC34C90 support module uses information supplied at boot time or during hot docking to configure the CardBus interface independently of BIOS or hardware peculiarities.

Scale economies for card silicon

In hardware, similarities between PCI bus and CardBus are intentional. A much-touted benefit of these similarities is the existence of common-IC designs—either for the card-side interface of a PCI adapter card or for a CardBus card. It is not necessarily true, however, despite a popular misconception, that you can use one chip to interface to either PCI bus or CardBus. You can do that only if the design of the card-side chip takes into account the differences between the two buses.

CardBus differs from the PCI bus in pin definitions, slower slew rate for bus drivers, and limited power consumption on reset (Table 2). To fully meet both the CardBus and the PCI specifications, an IC design would need dual-mode drivers, because the maximum CardBus slew rate, 1V/nsec, is equal to the slowest allowed PCI-driver slew rate. Slew-rate control and pin-assignment differences, which cause signal-routing crossovers on a pc board, are the main obstacles to dual-mode chip designs. On the other hand, the minor differences in protocol behavior and configuration space aren’t difficult to include in one chip equipped for dual-mode functionality.

Chip makers are putting the common-IC approach into practice by modifying PCI-interface chips to work with CardBus. For example, Digital Semiconductor’s card-side 21143 Fast Ethernet controller (Figure 1) uses a PCI design optimized for CardBus. The company’s 21140 PCI-to-Fast Ethernet controller core has been working in products for two years. To this core, the design for CardBus adds power-management and space-saving features, such as Ethernet Magic Packet and integrated transceivers. The 21143 provides the same 80-Mbyte/sec performance for CardBus as it does for PCI. Digital didn’t modify the PCI electrical interface to meet CardBus’ slower slew rate, however, so a PC Card 32 requires 180 ohms series resistors between the PCI pins and the CardBus socket pins. Digital plans to integrate these resistors, along with additional functions, on the next device revision.

If you’re designing with PLDs, dual-mode designs for PCI and CardBus aren’t terribly useful; it’s more efficient simply to modify a design for the mode you want. You can’t yet get a lot of help from PLD vendors for CardBus design, however. Their third-party core programs include PCI designs for bus-interface and configuration blocks but don’t yet include CardBus cores; PLD vendors cite lack of demand for the delay. In addition, the slow-slew-rate bus driver for CardBus plus the high performance that CardBus requires at 3.3V have also hampered PLD implementations. However, PLD vendors are working to develop CardBus cores like those available for PCI. For instance, Xilinx plans to make available a third-party CardBus core in the second half of this year. The core will work with the new 4000XL family of native 3.3V FPGAs, which are sampling now. However, you still need to add circuitry between PCI pins and the socket connector to comply with the slew-rate specification.

Competition in host-side chips

Although card-side chips are scarce, PCI-to-CardBus bridge chips are not. Several bridge chips are now sampling, and all offer PCI performance and power-management capabilities. In addition, they all give you options for interrupt handling and ZV-port connections. Reflecting lessons learned from the first generation of bridge controllers, the new bridge chips take similar approaches to solving problems with performance and interrupts that hampered early designs.

These new PCI-to-CardBus bridge controllers are a different type of PCI bridge chip. Unlike PCI-to-PCI bridge chips, they reduce the PCI bus to CardBus’ credit-card-sized form factor, which uses a 68-pin connector and has an electrical interface to match. In addition, backward compatibility to PC Card 16 dictates a PCI-to-PC Card 16 interface. Consequently, all PCI-to-CardBus bridges work with a PC Card 16, a CardBus card (PC Card 32), or one of each when the cards are in the two PC Card sockets that all host-side controllers provide.

These bridge chips can make or break your design’s performance. They must be able to transfer data from a CardBus card to the PCI bus—and possibly from two cards at the same time—without creating a bottleneck. Texas Instruments avoids a bottleneck by using a wraparound buffer on all three ports of the PCI1250 host controller (Figure 2). The wraparound buffers sustain a pipelined architecture that allows burst transfers to approach the theoretical maximum throughput of the PCI and CardBus interfaces. Two multifunction cards can simultaneously perform transfers in this architecture.

Another performance enhancement, the ZV buffer, targets multimedia applications. ZV buffers, now parts of most new PCI-to-CardBus bridges, aid system performance by bypassing the PCI bus for video-data transfers. The ZV operating mode uses reassigned CardBus pins to move video data from a PC Card directly to the VGA controller over the dedicated ZV bus.

The application that needs CardBus performance most is videoconferencing, which is growing in popularity with notebook users. Videoconferencing’s data transfers can clog the PCI bus, however. To solve this problem, a new controller from O₂Micro adds a third port for ZV (Figure 3), which serves as an input for a YUV video signal. This direct link frees the PCI bus from the task of carrying data to both the VGA display and the CPU for compression when you install the camera controller on the host PCI bus. The third ZV port also frees the second PC Card socket for other functions.

Other video sources—for example, TV tuners, MPEG-2, and Firewire—are also finding use in notebooks. Using the ZV bus, they can bypass the PCI bus and directly access a notebook’s video-graphics controller. Trident’s Omega 82C196 CardBus controller is one such chip that allows multiple video sources to gain access to the ZV bus; to allow busing of multiple inputs, Trident added tristate control to the ZV output.

With CardBus, even interrupt routing is a performance issue. You need to efficiently route interrupt signals through the PCI-to-CardBus bridge, but backward compatibility leads to an interrupt-routing tangle that has unraveled some designs. In early PC Cards, the PCMCIA specification allowed either pulsed or level-mode (ISA-style) interrupts, but CardBus cards use only one PCI interrupt. Adding to the tangle is the possibility of multifunction cards that must share interrupts; another possibility is a 16-bit card in one socket and a 32-bit card in an adjoining socket. Interrupt routing is the responsibility of the PC Card (CS and SS) software during configuration. The SS module sets bits in the ExCA (Exchangeable Card Architecture) registers for PC Card 16 and in the CardBus Socket registers for PC Card 32.

Interrupt routing through a PCI-to-CardBus bridge can follow any of several approaches. Direct and serialized IRQ routing and routing via PCI interrupt pins are only a few of the possibilities. The more routing choices a bridge chip gives you, the more flexibility you have. TI’s PCI1250 chip, for example, provides all the interrupt-signaling schemes just mentioned plus an eight-way legacy IRQ multiplexer. A multifunction routing block lets you select the functions of 12 pins on the controller—eight dedicated for IRQs, with the remainder for LED or general-purpose I/O—thus allowing, for example, the routing of any ISA IRQ to an output pin. The BIOS software programs the interrupt routing through the PCI1250 during initialization.

Power management

Even power management in CardBus ICs relates to ease of use: With adequate power conservation, you don’t have to change batteries in the middle of a task. Another benefit of power conservation is thermal management, because CardBus must work in an environment that contains a hot processor and has no airflow. Power dissipation is poor under these circumstances, so there’s no room for wasted current in either card- or host-side silicon.

Of course, power management is also a system-level concern, and CardBus ICs must work with an entire system. The Advanced Configuration and Power Interface (ACPI) initiative, promoted by Microsoft, Intel (Santa Clara, CA), and Toshiba America (Irvine, CA), addresses system-level power management by putting power management and PnP directly under OS control. An ACPI-enabled OS takes over these functions from legacy-BIOS interfaces to control PnP, power, and battery and thermal management according to user settings and application requests.

ACPI is part of the Microsoft PC97 standard, which specifies hardware behavior as part of OnNow requirements. OnNow covers the general definitions of device power states and refers to the PC Card Controller Device Class Power Management Reference Specification for details on CardBus ICs. The PC97 OnNow specification is in draft form and is available on Microsoft’s Web site. Microsoft’s schedules say PC Card devices should comply with OnNow by July 1, 1997, and PC Card host controllers should comply by Jan 1, 1998. Until the compliance dates, the system BIOS must support PnP requirements for system and device configuration as defined by Microsoft’s PC95a. In other words, the dates for PC97 logo certification are fast approaching, but the specifications aren’t yet solid. Consequently, chip vendors are trying to put enough flexibility into their products to adjust to last-minute changes in PC97 and ACPI requirements.

To ensure that CardBus hardware and software comply with ACPI, hardware designers and device-driver writers must refer to the PC Card Controller Device Power Management Reference Specification. This specification details three device power states:

• D3-Off—Power fully removed from device;
• D1—A partially powered state that retains enough functionality to restore full operation more quickly than from the D3 state. D1 requires preservation of context (for example, memory and I/O windows). Interrupts should function and cause assertion of PME# (power-management event pin) upon enabling of wake-up. Also, the power-management block in configuration space must be fully accessible;
• D0—Fully powered state.

An additional state, D2 (sometimes referred to as D3-Hot), is not defined for PC Card controllers.

Most CardBus ICs provide the registers and power modes needed to meet the ACPI specifications, a difficult proposition considering that the device-class specification is incomplete. In Table 1, the entry "ACPI" in a device’s power-management column indicates that the device manufacturer feels reasonably sure that it complied with requirements for the PC Card device class. A manufacturer can probably claim conformance by offering at least three power states—on, off, and a mode in which the interface is inoperable but the power-management block in configuration space is fully available. However, even if a chip’s design doesn’t completely conform to final requirements, configuration flexibility should provide a path to conformance. For SMC’s SMC34C90, for instance, the company claims that only a software work-around is necessary to satisfy any unmet power-management register requirements.

In addition to chips, software, and connectors, test tools are available to help you finish your CardBus design. The newest notebooks come equipped with CardBus slots, but slots alone aren’t much help in troubleshooting. For that, you can use FuturePlus’ CardBus preprocessor and extender card, which provides an electrical and mechanical interface to Hewlett-Packard (Palo Alto, CA) logic analyzers. Another test product, Sycard’s PCCtest CardBus socket tester, has an onboard microcontroller that automatically selects for test modes, supplies a test stimulus, and controls an onboard A/D converter to measure socket supply voltages. The PCCtest card tests CardBus, PC Card 16, and ZV modes.

References

1. Shanley, Tom, "CardBus configuration: a two-step process," EDN, May 9, 1996, pg 111.
2. Legg, Gary, "ICs and reference designs speed PC Card development," EDN, June 8, 1995, pg 79.
3. Anderson, Don, and Tom Shanley, CardBus System Architecture, Addison-Wesley, New York, 1996.
4. PC Card 95 (PCMCIA specification), PCMCIA, San Jose, CA, 1995.
5. Advanced Configuration and Power Interface Specification, Intel, Microsoft, Toshiba, Revision 1.0, Dec 22, 1996.

| EDN Access | Feedback | Table of Contents |