Inside PC Card: Cardbus and Pcmcia Design (Edn Series for Design Engineers)

INSIDE PC CARD CardBus and PCMCIA Design The EDN Series for Design Engineers F. Imdad-Haque, Inside PC Card: CardBus ...

Author: Faisal Imdad-Haque

90 downloads 1037 Views 10MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!

Report copyright / DMCA form

DOWNLOAD PDF

INSIDE PC CARD CardBus and PCMCIA Design

The EDN Series for Design Engineers F. Imdad-Haque, Inside PC Card: CardBus and PCMCIA Design J. Lenk, Simplified Design of lC Amplifiers J. Lenk, Simplified Design of Micropower and Battery Circuits J. Williams, The Art of Analog Circuit Design J. Lenk, Simplified Design of Switching Power Supplies V. Lakshminarayanan, Electronic Circuit Design Ideas J. Lenk, Simplified Design of Linear Power Supplies M. Brown, Power Supply Cookbook B. Travis and I. Hickman, EDN Designer's Companion J. Dostal, Operational Amplifiers, Second Edition T. Williams, Circuit Designer's Companion R. Marston, Electronics Circuits Pocketbook: Passive and Discrete Circuits, Volume 2 N. Dye and H. Granberg, Radio Frequency Transistors: Principles and Practical Applications Gates Energy Products, Rechargeable Batteries: Applications Handbook T. Williams, EMC for Product Designers J. Williams, Analog Circuit Design: Art, Science, and Personalities R. Pease, Troubleshooting Analog Circuits I. Hickman, Electronic Circuits, Systems and Standards R. Marston, Electronic Circuits Pocket Book: Linear ICS, Volume 1 R. Marston, Integrated Circuit and Waveform Generator Handbook I. Sinclair, Passive Components: A User's Guide

INSIDE PC CARD CardBus and PCMCIA Design Faisal Imdad-Haque

Newnes Boston Oxford Melbourne Singapore Toronto Munich New Delhi Tokyo

Copyright 9 1996 by Butterworth-Heinemann -~,

A member of the Reed Elsevier group

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. Recognizing the importance of preserving what has been written, Butterw o r t h - H e i n e m a n n prints its books on acid-free paper whenever possible.

Library of Congress Cataloging-in-Publication Data Imdad-Haque, Faisal, 1960Inside PC Card : CardBus and PCMCIA design ! Faisal Imdad-Haque. p. cm E (EDN series for design engineers) Includes index. ISBN 0-7506-9747-4 (hc) 1. PCMCIA cardsEDesign. 2. Microcomputers~Buses. I. Title. II. Series. TK7895.P38145 1996 621.39'81--dc20 96-11118 CIP

British Library Cataloguing-in-Publication Data A catalogue record for this book is available from the British Library. The publisher offers discounts on bulk orders of this book. For information, please write: Manager of Special Sales Butterworth-Heinemann 313 Washington Street Newton, MA 02158-1626 Tel: 617-928-2500 Fax: 617-928-2620 For information on all Newnes electronics publications available, contact our World Wide Web home page at: http://www.bh.com/bh/

1098 7 65432

1

Printed in the United States of America

To my wife Shazia, my children, and my parents. My wife for the endless nights and weekends she tolerated my being on the computer and for her support during that time. My parents for the love of books and learning that they gave me.

This Page Intentionally Left Blank

TAB LE O F CO NTENTS

PREFACE

xiii

PCMCIA OVERVIEW 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11

2

1 Introduction 1 PCMCIA Background 1 PC Card Technology 2 Applications 2 PCMCIA Products 3 Types of Cards 3 PC Card Standard 3 PC Card Interface Bus 5 PC Card Design Issues 6 Scope of this Book 8 Key Terms 9

PC CARD: THE 1 6-BIT BUS 2.1 2.2

2.3

2.4

2.5 2.6

11 Overview 11 W h a t Is a Bus? 11 2.2.1 I m p l e m e n t a t i o n of 16-bit PC Card Bus 12 2.2.2 16-bit PC Card Enhancements over ISA Bus 12 16-bit PC Card: An Overview 14 2.3.1 Differences Between Release 1.0 and Release 2.0 and PC Card 95 Release 15 16-bit PC Card Address Spaces 15 2.4.1 Attribute Memory Address Space 16 2.4.2 C o m m o n Memory 16 2.4.3 I/O Addresses 16 Word or Byte Alignment in 16-bit PC Card 17 Bus Signals 18 2.6.1 Definition of Terms 19 2.6.2 Address 19 2.6.3 Data D0-15 19 2.6.4 Status Signals 20

vii

viii

TABLE OF CONTENTS

2.7

2.8 2.9

2.6.5 Cycle Definition Signals 24 2.6.6 Execution Control Signals 26 2.6.7 DMA Signals 28 2.6.8 Power Signals 29 Transfer Protocols 31 2.7.1 Memory Data Transfer 31 2.7.2 I/O Data Transfer 32 2.7.3 Delaying Cycle Completion 32 2.7.4 16-bit Transfers 36 Electrical Characteristics of 16-bit PC Card 36 2.8.1 Voltage Levels 37 Summary 38

CARDBUS" THE 32-BIT BUS 39 3.1

3.2 3.3 3.4 3.5

3.6 3.7

3.8 3.9

Overview 39 3.1.1 History 39 3.1.2 CardBus Applications 40 3.1.3 CardBus Capabilities Overview 40 3.1.4 CardBus Definition of Terms 41 Pin Assignment Table 41 CardBus Pin Summary 41 3.3.1 CardBus Signal I/O Driver Types 45 Cardbus Host Implementation Overview 47 Cardbus Differences from PC Card 48 3.5.1 Multiplexed Address and Data Bus 48 3.5.2 PCI-based Transfer Protocols 48 3.5.3 Bus Master Support 48 3.5.4 Clock Management 49 3.5.5 Slew Rate Control on Signal Drivers 49 3.5.6 Reflective Wave Signaling 49 3.5.7 Hierarchical Bus Structure 50 3.5.8 Point-to-Point Bus 51 Differences Between CardBus and PCI 51 Address Spaces 52 3.7.1 Configuration Space 52 3.7.2 Locating the Configuration Information Structure 53 C o m m a n d Definitions 54 CardBus Transfer Protocols 55 3.9.1 CardBus Basic Bus Cycle 55 3.9.2 Byte Packing During Writes 56 3.9.3 Turnaround States 56

TABLE OF CONTENTS 3.10 CardBus Read Cycle 56 3.10.1 CardBus Write Cycle 58 3.11 CardBus Bus Master Support 59 3.12 Terminating a Cycle in Cardbus 59 3.12.1 Normal Termination Initiated by Master 60 3.12.2 Target Initiated Termination 61 3.12.3 Master Abort 62 3.12.4 Target Abort 62 3.13 Interrupts 62 3.13.1 CmNT#--General Purpose Interrupt 62 3.13.2 CSTSCHG--Card Status Interrupt 63 3.14 Clock Management 63 3.15 Error Detection 64 3.15.1 Parity Rules 64 3.15.2 CPERR# 65 3.16 Summary 65

4

INSERTION AND CONFIGURATION ISSUES 67 4.1 Overview 67 4.2 Insertion Issues 68 4.2.1 Supplying Voltage And Power 68 4.2.2 Power Consumption Restrictions on Supply Current 68 4.2.3 Configuration 70 4.3 Card Insertion Interface 70 4.3.1 Using Voltage Keys 71 4.3.2 Detecting Card Type 71 4.3.3 Voltage Sensing 71 4.4 Configuration 73 4.4.1 Configuration Information Structure Overview 74 4.4.2 Changes from PCMCIA Release 2.1 75 4.4.3 Tuple Structure 77 4.5 KeyTuples 78 4.5.1 Overview 78 4.5.2 Device Information Tuple (01h) 79 4.5.3 Other Conditions Tuple: 3.3V Characteristics (1Ch) 80 4.5.4 Configuration Tuple (1Ah) 81 4.5.5 CISTPL_CFTBL_ENTRY- Configuration Table EntryTuple (1Bh) 83 4.5.6 Function ID Tuple 125 90 4.5.7 Function Extension Tuple (22h) 90 4.5.8 Version and Product Information Tuple (15h) 92 4.6 Supporting Multiple Tuple Chains 92

ix

x

TABLEOF CONTENTS

4.7 4.8 4.9 4.10

Interpreting Tuples 94 CIS Structure 96 Sample CIS Parsing Routines 97 Configuring 16-bit PC Card 101 4.10.1 16-bit PC Card Configuration Registers 101 4.10.2 Configuration Option Register 101 4.10.3 Configuration and Status Register 103 4.10.4 Pin Replacement Register 104 4.10.5 Socket and Copy Register 104 4.10.6 Extended Status Register 105 4.11 Configuring CardBus Cards 105 4.11.1 CardBus Address Space Mapping Mechanisms 4.11.2 CardBus Configuration Space 107 4.11.3 Configuration Space Header 110 4.12 Summary 114

106

MULTIFUNCTION CARDS 115 5.1 Overview 115 5.1.1 Types of Multifunction PC Cards 115 5.2 16-bit Multifunction PC Cards 116 5.2.1 Detecting a Multifunction PC Card 117 5.2.2 Multifunction Hardware Implementation 118 5.2.3 Sharing the 3REQ# Line 122 5.2.4 Multifunction Interface: Example 123 5.2.5 Multifunction Interface Solutions 126 5.3 Cardbus Multifunction PC Cards 126 5.3.1 Accessing Multiple Functions in CardBus 127 5.3.2 Determining Multiple Functions 127 5.3.3 Managing Interrupts 129 5.3.4 Arbitration Between Two Master Functions 130

6

PCMCIA SOFTWARE: AN OVERVIEW 133 6.1 Overview 133 6.1.1 PCMCIA Software Models 135 6.2 Socket Services: An Overview 136 6.2.1 Overview of Services 138 6.3 Card Services: An Overview 142 6.3.1 Functionality 144 6.3.2 Basic Architecture 150 6.3.3 Fundamental Issues 152 6.3.4 Enabler Issues 155

TABLE OF CONTENTS PC CARD: THE MECHANICAL ISSUES 157 7.1 Overview 157 7.2 PC Card Dimensions 157 7.3 Host Connector 158 7.4 PC Card Connector 160 7.5 PC Card Frames 160 7.6 PC Card Input-Output Connectors 161 7.7 Height Analysis 161

PC CARD HOST DESIGN 165 8.1 Overview 165 8.2 Basic Bridge Architecture 165 8.3 Basic Design Issues for a PC Card Bridge 168 8.4 Types of PC Card Hosts 168 8.4.1 PC-based Hosts 168 8.4.2 Embedded Hosts 170 8.5 16-bit PC Card Host Interface 170 8.5.1 Basic Issues 170 8.5.2 Support of PC Card Events 172 8.5.3 Interrupt Steering 172 8.5.4 Mapping 172 8.5.5 Reset Control 175 8.5.6 Detecting Card Insertion and Removal 175 8.5.7 Switching Interface 176 8.5.8 Register Overview 177 8.5.9 Reading Status and Events 178 8.5.10 Using Memory and I/O Windows 179 8.5.11 DMA I m p l e m e n t a t i o n 181 8.5.12 Power Switching 182 8.5.13 Key Host Controller Vendors 184 8.6 CardBus Host Interface 184 8.6.1 Hierarchical Buses 187 8.6.2 Cardbus Host Mapping Issues 189 8.6.3 Interrupts 192 8.6.4 16-bit PC Card Support 193 8.6.5 Handling Parity 193 8.6.6 Bridge Configuration and Status Registers 194 8.6.7 Arbitration 195 8.6.8 Latency Timer 195 8.6.9 CardBus S u m m a r y 195 8.7 Embedded Systems Host Interface 195

xi

xii

TABLE OF CONTENTS

9

DESIGNING PCMCIA CARDS 199 9.1 9.2

9.3

9.4

9.5

9.6

9.7

9.8

Overview 199 16-bit PC Card Design 200 9.2.1 Mechanical Requirements 200 9.2.2 Interface Design 201 9.2.3 Electrical Requirements 208 9.2.4 Selecting Connectors and Frames 210 9.2.5 PCB Layout Considerations 211 9.2.6 16-bit PC Card Design 211 16-bit Input-Output Card Design Example: Fax/Modem 212 9.3.1 Interface 212 9.3.2 Input-Output Decoding 214 9.3.3 Configuration Information Structure 214 9.3.4 Input-Output Connection 220 16-bit Memory Card Design Example 220 9.4.1 Interface 221 9.4.2 Register Implementation 224 9.4.3 Configuration Information Structure 224 Cardbus PC Card Design 225 9.5.1 Interface Logic Issues 228 9.5.2 Electrical Issues 232 Cardbus Master Card Design Example: LAN Card 232 9.6.1 Signals 234 9.6.2 Bus Transactions 235 9.6.3 Configuration Space 235 9.6.4 I/O Registers 239 9.6.5 Block Diagram 241 9.6.6 Interface Design 241 9.6.7 Critical Timing 243 9.6.8 Configuration Information Structure Design 244 Test and Debug of PC Cards 244 9.7.1 Extenders 244 9.7.2 Debugger-Exerciser 248 9.7.3 Socket Tester 248 9.7.4 CIS Development 248 Summary 248

INDEX

249

PREFACE

PCMCIA PC Card has been one of the fastest growing interfaces in the computing market. It is now the de facto expansion bus for laptops and notebooks. The size and ruggedness of the PCMCIA PC Card form factor also make it appealing in applications and markets that have traditionally shunned peripheral expansion. When I first started working with PCMCIA products three and a half years ago, I assumed that the PCMCIA PC Card was a very simple technology with very little complexity. I was wrong. PC Card technologies require understanding m a n y different skills from mechanical design to power supply design. Noise considerations play an extremely important role in card design. All these issues need to be considered in PCMCIA designs. The 1995 release of the PC Card standard also encompasses many new technologies and capabilities. CardBus, multifunction cards, media storage formats, and power management capabilities are some of the new technologies. PCMCIA intentionally kept m a n y aspects of the PC Card standard optional. This leads to some uncertainty, especially about implementation and compatibility. My purpose in writing this book is to try to minimize some of the confusion arising from the optional capabilities and to illustrate the different design approaches through practical examples. I have attempted to provide a clear path for designers and engineers so that the implementation is clear. I hope this book will serve its purpose and become a useful tool for engineers involved with PCMCIA. My thanks and appreciation go to the people who put their time and effort into reviews and suggestions for this book. These people are, in no particular order, Jauher Zaidi, Scott Williams, and Tom Newman.

~Faisal Imdad-Haque

xiii

This Page Intentionally Left Blank

Everything that can be invented has been invented. ~ C h a r l e s H. Duel Commissioner U.S. Office of Patents, 1889

Try to learn something about everything and everything about something. ~T. H. Huxley

This Page Intentionally Left Blank

1 PCMCIA OVERVIEW

1.1

INTRODUCTION The PCMCIA PC Card interface is one of the fastest growing interfaces in the computing world. Today this interface is the expansion bus of choice for laptop, notebook, and palmtop computers. The acceptance of the PCMCIA interface in other markets is also increasing rapidly. These markets include desktop personal computers (PCs), embedded systems, communications, and consumer electronics. The PC Card interface has been accepted in applications that normally shunned any peripheral expansion capability. These applications include platforms as diverse as medical instrumentation, set-top boxes, electronic test instrumentation, and digital cameras. The increasing popularity of PCMCIA standards makes it essential for engineers to understand the basis for and the application of this technology.

1.2

PCMClA BACKGROUND PCMCIA is an acronym for Personal Computer and Memory Card International Association. The association was formed in 1989 by DuPont, Fujitsu, and Poqet Computer to define and promote a standard interface for m e m o r y cards in handheld machines. The m e m o r y cards replaced floppy drives, which because of their bulk and power requirements could not be used in smaller handheld machines. In November 1990, release 1.0 was published. The standard later evolved to support input/output (I/O) cards. PCMCIA defined a standard interface for the 68-pin memory card form factor. This form factor is now referred to as the PC Card form factor. The 68-pin connector was originally defined by the Japan Electronics Industry Development Association (JEIDA) for the various incompatible IC cards being marketed within Japan. Since then, PCMCIA has worked closely with JEIDA to ensure that JEIDA and PCMCIA specifications are compatible. In fact, the

2

PCMCIA OVERVIEW

1995 release of the PCMCIA standard is a joint release between PCMCIA and JEIDA. Technically, the proper reference to the standard is PC Card standard; the term PCMCIA is supposed to be used only in reference to the association. However, in the industry the term PCMCIA has come to be used to refer to the standard. In this book the terms PCMCIA and PC Card standard are used interchangeably.

1.3

PC CARD TECHNOLOGY The term PC Card 1 as defined refers to a 85.6-mm by 54.0-mm card with a 68-pin connector. A PC Card plugs into a host slot or socket. Besides peripheral expansion, the PC Card technology also provides for the following capabilities: 9 C o m p a c t F o r m Factor PC Cards are in a credit card form factor measuring 85.6 m m by 54.0 mm. There are three heights: 3.3-mm (Type I), 5-mm (Type II), 10.5-mm (Type III). All three types use the 68-pin connector. 9 H o t I n s e r t i o n Most of the c o m p o n e n t s of the standard are defined to allow the PC Card to be inserted or removed from a host w i t h o u t powering down or rebooting the machine. This is different from insertion into a hot socket, in which case the socket Vcc is on. The hot insertion capability requires the Vcc to be switched and requires a host software layer to manage insertion, removal events, and resource allocation for PC Cards. 9 A u t o m a t i c C o n f i g u r a t i o n A PC Card is automatically configured u p o n insertion and allocated the resources it requires. PCMCIA has defined configuration space, configuration registers, and tuples that are used to describe the resource requirements and capabilities of the card. Together these three items allow a host to automatically configure the PC Card u p o n insertion. 9 Ruggedness All PC Cards are required to perform under environmental and physical conditions defined in the standard.

1.4

APPLICATIONS Although the PC Card standard was aimed at palmtop computers, m a n y other types of platforms have begun to include support for PC Cards.

1. In this book, PC Card, card, and IC card refer to a PCMCIA card.

1.5

Table 1.1

PCMCIA PRODUCTS

3

PC Card key platforms.

Computing

Embedded computing

Communications

Consumerelectronics

Laptops Notebooks Sub-notebooks Palmtop computers Desktop PCs

Medical instrumentation Oscilloscopes Logicanalyzers Aircraft black boxes

Personal communicators Network hubs Network routers PBX Smart and cellular phones Cellular base stations

Digital cameras Set-top boxes Electronic organizers Personal financial organizers Video games Audio recorders

The list of platforms is very long. Some of the key applications are listed by market segments in Table 1.1.

1.5

PCMClA PRODUCTS PCMCIA is i m p l e m e n t e d in both the PC Cards and host platforms. PC Cards can be I/O or m e m o r y cards such as fax/modem, local area network (LAN), ATA, SRAM, or flash cards. PCMCIA hosts are machines that i m p l e m e n t either a 16-bit PC Card interface or a CardBus interface. PCMCIA hosts are typically either computer systems or other machines. PC Card sockets can be found in portable machines such as notebook PCs, laptops, sub-notebook PCs, and h a n d h e l d computers.

1.6

TYPES OF CARDS PC Cards are classified by height and functionality. There are three types of height classifications (see 1.3). Functionally the cards are classified as m e m o r y or I/O cards. Memory cards use m e m o r y interface signals from the PCMCIA bus and i m p l e m e n t a linear m e m o r y card. I/O cards use an additional set of signals from the bus and i m p l e m e n t devices m a p p e d into the PCMCIA I/O address space.

1.7

PC CARD STANDARD The 1995 release of the PCMCIA PC Card standard defines electrical, mechanical, and software specifications for support of m e m o r y and I/O expansion with PC Cards. The standard supports two interfaces:

4

PCMCIA OVERVIEW

9 16-bit PC Card Interface

A 16-bit slave only bus originally defined in release 2.0 9 CardBus A 32-bit high speed bus with support for bus masters

Along with CardBus, the 1995 version of the PC Card standard adds support for multifunction cards, DMA on 16-bit interfaces, and media storage formats, especially partitioning for ATA and memory card. The PC Card standard also defines physical and mechanical characteristics and software standards. The 1995 version of the PC Card standard consists of the following volumes: 1. Overview a n d G l o s s a r y Introduction to the PC Card standard 2. Electrical Specifications 16-bit interface and CardBus interface 3. Physical Specifications Mechanical and environmental specifications 4. M e t a f o r m a t Specifications A binary image used to describe the PC Card 5. Card Services Specifications Description of the Card Services Applications Programming Interface (API) 6. Socket Services Specifications Description of the socket services API 7. Media Storage F o r m a t Specifications Description of partitioning schemes for storage 8. PC C a r d ATA Specifications Description of the ATA implementation on PCMCIA 9. XIP Specifications Execute in Place (XIP) API 10. Guidelines Implementation suggestions 11. PCMCIA Specific Extensions PCMCIA-defined extensions of the standard 12. JEIDA Specific Extensions JEIDA-defined extensions of the standard Release 1.0 supported only memory Cards such as flash, SRAM cards, and read-only memory (ROM) cards. Release 2.0 of the standard supported both memory and I/O cards (also referred to as PC Cards). The standard also allows for hot insertion and removal as well as software configuration of PCMCIA cards. Figure 1.1 shows the timelines of the standards defined by PCMCIA. Besides meeting hardware specifications the designer of a product that conforms to PCMCIA also must consider the software components of the PC Card standard. These software components manage the insertion and removal of the PC Cards and allow the host system to recognize and

1.8

Figure 1.1

PC CARD INTERFACE BUS

5

PC Card standard revision history.

automatically configure the card. Figure 1.2 illustrates the software components of PCMCIA.

1.8

PC CARD INTERFACE BUS The PC Card interface is an important c o m p o n e n t of the standard. It defines the PC Card electrical specifications and bus protocols. In the 1995 release, the PC Card interface supports two types of busesm16-bit PC Card and CardBus. The 16-bit interface is similar in m a n y ways to an Industry Standard Architecture (ISA) bus, also known as the PC-AT bus. It differs in supporting event m a n a g e m e n t capabilities on the bus and autoconfiguration u p o n insertion by implementing a Card Information Structure (CIS) and the corresponding function configuration registers. The 1995 release of the standard introduces the concept of a function as opposed to a card. A function is a single I/O or m e m o r y capability. This interface also now supports DMA and will eventually also support Zoom Video and DVB c o m m o n interface standards once these are approved.

6

PCMCIA OVERVIEW

Figure 1.2

Software components of the PC Card standard.

] ClientsDeviceDriverI J

1

Generic Enabler

Resource Management Table

L

J

Technology

CardServices

1

4,

SocketServices

!

1

PCMCIABridgeHardware I iii[~~' ii!i!i!~i!iCardPC iii!iiii~i ii~:!iil ~

\ Socket

The CardBus standard is a higher performance standard than the 16bit interface. It is very similar to Peripheral C o m p o n e n t Interconnect (PCI), except for the form factor and the event m a n a g e m e n t capabilities. Table 1.2 summarizes the key features of CardBus and 16-bit PC Card. PCMCIA also defines a CIS. This structure defines the resources needed by the card for it to be configured by the host. Typically a host reads the CIS when a card is inserted into the PCMCIA socket, and then configures the card.

1.9

PC CARD DESIGN ISSUES The form factor and the nature of the PC Card requires attention to certain aspects of the design of the PC Card. The main issues are as follows: Host bridge design CardBus host design

1.9

Table 1.2

PC CARD DESIGN ISSUES

7

S u m m a r y of 16-bit PC Card and CardBus differences.

16-bit PC card

CardBus

8-, 16-bit interface Non-multiplexed address and data Slave only bus Asynchronous bus

8-, 16-, and 32-bit interfaces Multiplexed address and data Slave and master capabilities supported Synchronous bus 33-MHz clock with dynamic clock management capability Memory, I/O, and configuration spaces

Memory, attribute memory, and I/O spaces 64 MB of address space Fastest cycle time of 100 ns, 20 MB/sec transfer rate Type I, II, and III form factor Function configuration registers to configure and control the PC Card interface Pulse or level-triggered interrupts Switched Vcc and Vpp lines recommended No error checking Separate memory-only and I/O interface Event management support for STSCHG# and WP, BVD1,BVD2,Ready, and Wakeup events Audio binary tone support Noncacheable and nonexclusive transfers 3.3V and SV Vcc Voltage sensing to detect Vcc threshold

4 GB of address space 133 MB/sec peak transfer rate using burst mode Type I, II, and III form factor Configuration header and function event registers to configure and control the PC Card Level triggered interrupts only Switched Vcc and Vpp lines required Parity based error checking Single interface Event management support for CSTSCHG for various card and socket events Audio, binary, and PWM support Support for cacheable, and exclusive transfers 3.3V Vcc only Uses CVS1-2 and CCD1-2# to determine 16-bit PC Card or CardBus PC Card

WP, write protect; BVD,battery voltage detect; PWM,pulse width modulation

16-bit PC Card interface host design Voltage regulator design PC Card design 16-bit PC Card design CardBus PC Card design M u l t i f u n c t i o n PC Card design Electrical design of PC Card to m i n i m i z e s w i t c h i n g noise. G r o u n d b o u n c e is an i m p o r t a n t issue in PC Card design. M e c h a n i c a l d e s i g n m U n d e r s t a n d the m e c h a n i c a l c o m p o n e n t s of card design Power m a n a g e m e n t issues

8

PCMCIA OVERVIEW

9

1.10

CIS design--Essential for compatibility with Card Services 9 Card Services and Socket Services interaction with host and PC Card

SCOPE OF THIS BOOK This book provides design and development guidelines for designers of PCMCIA products. It discusses the PC Card standards from an implementation point of view and provides design examples. It is not a reference for standards; readers should refer to the PC Card Standards for the necessary standard information. The book is divided into the following nine chapters: 1. 2. 3. 4. 5. 6. 7. 8. 9.

PCMCIA Overview PC Card: The 16-bit Bus CardBus: The 32-bit Bus Interface and Configuration Issues Multifunction Cards PCMCIA Software: An Overview PC Card: The Mechanical Issues Designing PCMCIA Hosts Designing PC Cards

C h a p t e r 1 provides background on PCMCIA and an overview of the various specifications provided by PCMCIA. It is an introduction to PCMCIA. C h a p t e r 2 discusses the 16-bit PC Card bus and brings out the relevant implementation issues associated with the bus. C h a p t e r 3 discusses CardBus and provides a discussion of the key features and capabilities. C h a p t e r 4 looks at the insertion and configuration issues in PC Card implementations. It covers CIS design and the programming model for both 16-bit and CardBus interfaces. C h a p t e r 5 discusses implementation of multifunction PC Cards. C h a p t e r 6 provides an overview of the software issues in PCMCIA. It discusses Card Services, Socket Services, and other PCMCIA client software. C h a p t e r 7 discusses mechanical design issues for a PC Card and discusses the general options. C h a p t e r 8 discusses requirements for a PCMCIA host and discusses the various design options and issues. It covers both CardBus and the 16-bit PC Card interface.

1.11

KEY TERMS

C h a p t e r 9 discusses PC Card design issues and presents examples. It also presents a detailed description of interface design, Printed Circuit Board (PCB) design, c o m p o n e n t selection, and electrical design for both CardBus and 16-bit PC Card.

1.11

KEY TERMS A d a p t e r ~ A bridge from a host to a bus C a r d B u s ~ T h e high-performance bus recently added to the PC Card standard CardBus PC C a r d m A n 8-, 16-, or 32-bit card designed to work with the CardBus interface Card i n s e r t i o n ~ T h e process of inserting a PC Card into a host socket so that it mates with the host connector Card r e m o v a l ~ T h e process of removing a PC Card from the host socket Card S e r v i c e s ~ A host software layer that interfaces with Socket Services to provide event notification to PC Card-aware software. It also manages resource conflicts between multiple PC Cards and PC Card clients. Client s o f t w a r e - - P C Card-aware software that is a client of Card Services F u n c t i o n ~ A single instance of a m e m o r y or I/O capability; examples are Ethernet interface, fax/modem, and SCSI interfaces. H o s t ~ A digital platform that supports an interface to PC Cards H o t i n s e r t i o n w l n s e r t i o n of a PC Card into a host w i t h o u t requiring the host to be shut down or rebooted I/O cardsmA type of PC Card that provides I/O capability and may be m a p p e d into the I/O space M e m o r y c a r d m A type of PC Card that contains only memory; examples are flash m e m o r y cards, SRAM cards M e m o r y - o n l y i n t e r f a c e m A unique interface mode within 16-bit PC Card bus that supports only the m e m o r y space. It is essentially the release 1.0 interface with WAIT# and RESET added. M u l t i f u n c t i o n cardsmA PC Card that contains two or more separate functions

9

10

PCMCIA OVERVIEW

PC C a r d - - A n I/O or m e m o r y board in the 68-pin credit card form factor PC Card ATA AT a t t a c h m e n t interface modified to operate in the 16bit PCMCIA e n v i r o n m e n t PCMCIAmAn association that defines and promotes PC Card standards 16-bit i n t e r f a c e - - T h e slave bus originally defined by PCMCIA as the PC Card interface S o c k e t m A n external host slot into which PC Cards are inserted to connect to the host Socket Services--A hardware (H/W) transparent software interface to the socket 16-Bit PC C a r d m A n 8 - o r 16-bit card designed to work with the 16-bit bus originally defined by PCMCIA

2 PC CARD: THE 1 6-BIT BUS

2.1

OVERVIEW This chapter is intended to be a designer's guide to the 16-bit PC Card bus. It discusses the electrical characteristics and transfer protocols of the bus as well as physical and logical functions. Timings for input and output (I/O), m e m o r y and attribute m e m o r y are discussed in detail. This chapter also discusses the differences between 16-bit PC Card and other buses and points out the new features of 16-bit PC Card.

2.2

W H A T IS A BUS? A bus is a set of electrical signals used to transfer data. It typically consists of address, data, cycle definition, status and control signals. Newer buses provide some configuration pins, which are used to configure a card inserted in a slot on the bus. Address pins provide the address of the device being accessed. Data pins are used to transfer data back and forth between the system and the peripheral on the bus. A bus is defined by its data transfer protocol, event m a n a g e m e n t capabilities, address spaces, topology, and whether it supports master or slave operations. The data transfer protocol is the mechanism used to transfer data across the bus. Cycle definition pins define the cycle and thereby the transfer protocol being used. Cycle timing, start, and completion are defined by cycle control signals. A bus may be either synchronous or asynchronous. Its cycle timing may be (1) synchronous to a clock provided by the system or (2) asynchronous to the clock or no clock provided. The control signals affect execution in the system, for example, a reset pin could force reset on the bus. Event management signals, such as interrupts and status pins, provide information about the various events that can take place on the bus, such as an interrupt to indicate an incoming packet of data.

11

12

PC CARD: THE 16-BIT BUS

Most buses have predefined address spaces. The address spaces m a p the various devices that are added to a particular bus. Typically a bus has a m e m o r y address space and sometimes an I/O address space. In some buses there is also a configuration space. This space is used to configure any devices that are added to the bus. The topology of a bus is the physical i m p l e m e n t a t i o n used to connect devices to the bus. In a "bus" topology all devices access a c o m m o n set of signals. In a point-to-point topology each device has its own unique set of signals duplicated. Master and slave capabilities define whether a device on the bus can directly access system address space. A bus m a y support Slave m o d e only, Master mode only, or both. In Slave mode the bus cannot be used to directly access system resources. It is completely d e p e n d e n t on the processor to transfer data to main memory. In Master mode, the bus m a y arbitrate with the CPU for access to the system resources. W h e n the bus wins the arbitration, it directly accesses the system m e m o r y and transfers data.

2.2.1

Implementation of 16-bit PC Card Bus The 16-bit PC Card bus is usually i m p l e m e n t e d in hosts by means of a host bridge. The host bridge has to provide a m e c h a n i s m to m a p the host address spaces to the three PC Card address s p a c e s - - C o m m o n Memory, Attribute Memory, and I/O Address Space. The host bridge must also provide card insertion and removal detection m e c h a n i s m s and control m e c h a n i s m s for both Vcc and p r o g r a m m i n g voltage (Vpp). Popular imp l e m e n t a t i o n s for PC Card bridges are ISA to PC Card and PCI to PC Card. Because PCMCIA hosts can be of m a n y different types, the detailed discussion of this topic is provided in Chapter 8. Figure 2.1 shows a typical i m p l e m e n t a t i o n of an ISA to a PC Card bridge.

2.2.2

16-bit PC Card Enhancements over ISA Bus 16-bit PC Card is a slave-only, asynchronous bus. Like most buses it defines data transfer protocols and address maps. In addition to the functionality provided by other slave buses, PC Card has a few additional capabilities. These e n h a n c e m e n t s are as follows: 1. Enhanced event m a n a g e m e n t capabilities for events unique to PC Card. These include signals such as Card Detect 1,2 for detection of card insertion or removal.

2.2 WHAT IS A BUS? F i g u r e 2.1

13

A n ISA t o 1 6 - b i t PC C a r d b r i d g e .

CPU

Cache

I

I

ISA Bus Controller

DRAM

PCMCIA Bridge

I I

I

I I

I

I I

I IIIIi~,:~~,o,o;,~o~ IIIII1

PCMClA Socket

2. Switchable Vcc and p r o g r a m m i n g voltages. It provides separate prog r a m m i n g voltages for flash cards defined as Vpp. The Vcc on the bus can be turned on or off dynamically and may be configured to SV or 3.3V. The voltage-sensing scheme is discussed in more detail later in this chapter. 3. A separate configuration space k n o w n as Attribute Memory. This space is used to configure a card automatically and to store configuration information about the card. Most of these e n h a n c e m e n t s are provided to support the hot insertion capability (insertion of card w i t h o u t powering down the system). A PC Card can be inserted into the PCMCIA socket (a PCMCIA slot) at any time. Because a PC Card can be removed and a new PC Card added to the socket at any time, the bus has a mechanism to detect card insertion or removal and configure t h e m automatically at insertion.

14

PC CARD" THE 16-BIT BUS

PC Cards were initially designed to support m e m o r y cards such as flash cards and SRAM cards with batteries. These types of cards require support for certain events, such as battery status on SRAM cards or card ready or busy for programming or erasure of flash devices.

2.3

16-BIT PC CARD: AN OVERVIEW 16-bit PC Card is an 8- or 16-bit slave bus. It is an asynchronous bus (no clock is defined on the bus). PCMCIA release 1.0 was a m e m o r y card only bus and did n o t support an I/O space or I/O devices. Release 2.0 added support for I/O devices. This was done by providing two modes for the b u s - - a m e m o r y - o n l y mode and an I/O-memory interface mode. The Memory-only mode is the bus originally defined in release 1.0 to support m e m o r y cards and some additional signals; the I/O address space is not available in Memory-only mode. Memory-only mode is the default interface for both the 16-bit PC Card sockets and the PC Card. It is the interface available whenever a card is inserted into the socket or w h e n the card is powered up or reset. In the I/O-Memory Interface mode some of the control signals are mult i p l e x e d m t h e y change to support I/O functionality. The differences between release 1.0 and release 2.0 are outlined in section 2.3.1. The I/O-Memory Interface becomes available only u p o n configuration of the card and the socket. 16-bit PC Card defines three separate address spaces: 9 Attribute m e m o r y space 9 C o m m o n m e m o r y space 9 I/O space

Attribute memory space is used to configure a PC Card. It also contains configuration information about the card. Attribute m e m o r y is 8-bit only and only even bytes of the address space are used. The attribute m e m o r y contains the card configuration registers (CCR) and the card tuples, which define the various attributes (configuration information) of the card.

Common memory space is used for direct access to m e m o r y devices on the card. Accesses to c o m m o n m e m o r y space can be either 8 or 16 bits wide and provides up to 64 MB of address space. I/0 space in 16-bit PC Card is 64 MB and is used for I/O devices such as f a x / m o d e m s and Ethernet cards. I/O devices can be either 8 or 16 bits

2.4

16-BIT PC CARD ADDRESS SPACES

15

wide. All cards (including I/O cards) must come up in the m e m o r y - o n l y interface and once configured can be changed to support I/O interface.

2.3.1 Differences Between Release 1.0, Release 2.0, and PC Card 95 Release PCMCIA release 1.0 defined signals that were strictly for m e m o r y cards. It did not provide an I/O space or control signals for I/O cycles. Release 2 . 0 added two signals to Memory-only modemRESET and WAIT. It added I/O control signals to the I/O interfacemIREQ#, 3 o i s 1 6 # , IORD#, IOWR#, INPACK#, SPKR#, and STSCHG#. Most release 1.0 cards also do not provide configuration information in attribute memory. Therefore, release 1.0 cards usually do not provide an attribute m e m o r y space. Release 2.1 added support for voltage sensing. PC Card 95 adds support for DMA, 3.3, and 5-V cards, and some registers for I/O event control as well as support for multifunction cards. Table 2.1 illustrates the changes to the 16-bit PC Card bus from release 1.0 to the PC Card 95 release.

2.4

16-BIT PC CARD ADDRESS SPACES 16-bit PC Card provides three distinct address spaces each of 64MB. These spaces are decoded by the card to provide various types of data.

Table 2.1 Summary of electrical changes to 16-bit PC Card standard. PC Card Release 1.0

PC Card Release 2.0

PC Card 95

Memory-only interface

Added I/O interface IOWR#, IORD#, IREQ#, STSCHG, SPKR# Added RESET signal Added WAIT # signal Added card configuration registers. Added voltage sensing scheme (release 2.1)

Added DMA support

No support for reset No wait support No card configuration registers 5V-only operation specified

Added 3.3V specifications Added one optional I/0 event register Added support for multifunction cards

16

PC CARD: THE 16-BIT BUS

2.4.1 Attribute Memory Address Space The attribute m e m o r y space is a separate space of up to 64MB. The REG# signal along with OE# or WE# and the CEI # or CE2# signal is used to define an attribute m e m o r y access. The attribute m e m o r y space is divided into the following sections: Card I n f o r m a t i o n Structure (CIS) Tuples that contain the configuration information about a particular card. W h e n it detects insertion of the card, the host software parses these tuples and automatically configures the host and the card for the appropriate resources. Card C o n f i g u r a t i o n Registers (CCR) These are used to configure the card's port addresses and interrupt lines. CCRs are described in more detail in chapter 4. Reserved Space A reserved portion of the attribute memory. The size of the attribute m e m o r y depends on the card. However, most cards that use Level 1 tuples reserve 256 bytes for attribute memory.

2.4.2 Common Memory C o m m o n m e m o r y is the data memory. Memory cards typically are mapped into this space. C o m m o n m e m o r y can support up to 64MB of memory. The following types of m e m o r y cards are supported by PCMCIA. Masked ROM OTPROM EPROM Flash EEPROM

EDO DRAM (JEIDA 4.2) SRAM EEPROM Flash EPROM

C o m m o n m e m o r y can be accessed as either 8- or 16-bits wide and supports five different speeds (see section 2.7). All PC Cards that use the Memory-only interface are required to support 16-bit accesses.

2.4.3

I/O

Addresses

16-bit PC Card supports a separate I/O space of 64 MB. Both 8- or 16-bit accesses are supported. I/O space is available only when the bus is in the I/O-Memory mode. In I/O-Memory mode, some of the m e m o r y - o n l y m o d e signals change personality to support the I/O functionality. Comm o n m e m o r y and attribute m e m o r y space is still available in I/O-Mem-

2.5 WORD OR BYTEALIGNMENT IN 16-BIT PC CARD

17

ory m o d e , so I/O a n d m e m o r y c o m b i n a t i o n s can be s u p p o r t e d in 16-bit PC Card.

2.5

WORD OR BYTE ALIGNMENT IN 16-BIT PC CARD A host m a y access either 16 or 8 bits in a card. M e m o r y cards, cards t h a t d e c o d e a n d r e s p o n d to host accesses to the c o m m o n m e m o r y space, m u s t s u p p o r t 16-bit accesses. I/O cards can be either 8- or 16-bits. I/O cards u p o n d e c o d i n g the address m a y assert 3 o 3 s 1 6 # if the port can support 16-bit accesses. 16-bit PC Card forces all 16-bit accesses to be aligned o n e v e n byte boundaries. 16-bit m e m o r y accesses ignore bit A0. So e v e n if a host a t t e m p t s a 16-bit access starting at an o d d address (A0 - 1), the PC Card m u s t n o t d e c o d e A0 a n d m u s t return the lower even byte as well as the o d d byte. Note: This is a difference from the ISA bus. In ISA systems, a w o r d access

t h a t crosses the w o r d b o u n d a r i e s is b r o k e n u p into two separate accesses. Because of the definition of o d d byte accesses in PCMCIA, m o s t 16-bit cards have to i m p l e m e n t byte-steering logic to steer the o d d byte to the lower 8 bits (D7-0) of the data bus. Figure 2.2 shows the various byte a n d word access a l i g n m e n t scenarios.

Figure 2.2

Word and byte accesses.

High Byte

Low Byte

Access Type

I Valid Data I

Byte, Even Address

]Valid Data I IValid Data[

Word, Even Address

I Valid Data I

Byte, Odd Address I Valid Data I

Byte, Even Address

18

2.6

PC CARD: THE 16-BIT BUS

BUS SIGNALS Table 2.2 s h o w s t h e 16-bit PC Card signals. T h e signals can be d i v i d e d i n t o t h e f o l l o w i n g categories: 9 Address 9 Data 9 Cycle d e f i n i t i o n 9 Status 9 Cycle c o n t r o l 9 Execution control Memory-only mode

READY

I/O-Memory mode

REG#

Table 2.2

16-Bit PC Card signals.

Name

Type

Function

Polarity

A0-25 DO- 15

Output Bidirectional Output Output Output Output Output Output Input Output Input Input Input Input

Address bus Data bus Cycle definition Cycle definition Cycle definition Cycle definition Cycle definition Cycle definition Execution control Execution control Cycle control Cycle control Cycle control Status Status Status Status Status Status Status Programming voltage Supply voltage Ground

Active high Tristateable Active low Active low Active low Active low Active low Active low Active low Active high Active low Active low Active low Active high Active high Active high Active low Active high Active low Active low Power Power Ground

REG#

IORD# I OWR# OE# WE# CEI #- 2 # IREQ# RESET INPACK# IOISI6# WAIT# READY* wm BVD 1 - 2 CDI #- 2 #

VSI-2

STSCHG#

SPKR#

VP P 1 - 2 vcc GND

Input

Input Input Input Input Input Power Power Power

*Note READYwas originally referred to as the RDY/BSY#signal.

2.6

2.6.1

BUS SIGNALS

19

Definition of Terms O u t p u t ~ S i g n a l that is an output from the host connector (socket) to the card. 16-bit PC Card defines output relative to the card. The o u t p u t may be driven high or low by the host. I n p u t m S i g n a l that is an input to the host socket. It is an o u t p u t from the card to the host. The card may drive this signal high or low. O p e n Drain--Signal that is only driven low. If it is a card o u t p u t such as READY, it is actively driven low by the card. For a transition to the high state, the signal's driver tristates, floating the signal. A pull-up is required to bring the signal back to a high level. Active HighmSignal that is recognized as being active w h e n it is at the Input High Voltage (V1H) threshold of the card or the socket. Active LowmSignal that is recognized as being active w h e n it is at the Input Low Voltage (Vm) threshold of the card or the socket. All active low signals have a # after the name, for example, 3REQ#

2.6.2

Address Address lines AO-A25 are used to provide the address being accessed on the current socket. This allows up to 64MB of address space on the socket. A0 is not used in 16-bit mode. In traditional ISA DOS/Windows machines, most I/O cards are restricted to 384 bytes of I/O space and 16 MB of m e m o r y space. In 16-bit PC Card this is a c c o m m o d a t e d in two ways: 1. For m e m o r y addresses b e y o n d 16MB, the host adapter provides an offset address that is added to the 24-bit address to generate a 26-bit address 2. For I/O space compatible with ISA software, the card may decode only the first 10 bits of address.

2.6.3

Data D0-15 The data bus is 16 bits wide and is bidirectional. Each pin on the data bus may be tristated. For hot insertion each socket must have a fully buffered data bus. Otherwise conflicts on the data bus at insertion may cause the host to lock up.

20

PC CARD: THE 16-BIT BUS

2.6.4

Status Signals The status signals are used to manage card events and monitor status. They consist of the following pins: CD1-2#, V S l - 2 # , STSCHG#, WP, BVDI-2#, and SPKR#.

2.6.4.1 CDI-2#: Card Detect Card detects are one of the card status signals in 16-bit PC Card. They enable the host to detect insertion or removal of a card. Both card detects are grounded in the card. On the host side, the card detects are pulled up. It is r e c o m m e n d e d that all hosts implement hysteresis and debounce circuitry on these inputs. Figure 2.3 shows the physical pin contacts during insertion and removal. Figure 2.3 also illustrates the different lengths of 16-bit PC Card pins. Typically w h e n the card is inserted, the first pins to make contact are the Vcc and the ground pins. As insertion is continued, the other 16-bit PC Card pins except Card Detect make contact. The card detect pins make contact last.

2.6.4.2 VS1-2: Voltage Sense Pins The voltage sense pins were added in release 2.1 of 16-bit PC Card. They allow the host to determine the power-up voltage. VSl was originally

Figure 2.3

16-bit PC Card pins contact length.

2.6

BUS SIGNALS

21

RFSH a n d v s 2 was RFU. VS1 a n d v s 2 along with m e c h a n i c a l k e y i n g o n the card frame p r e v e n t lower-voltage cards from b e i n g inserted in 5V o n l y sockets. Table 2.3 shows the voltage c o m b i n a t i o n s .

READY: Card Ready (RDY/BSY#)

2.6.4.3

READY is a status signal g e n e r a t e d by the card. It is used to indicate delay or c o m p l e t i o n of o p e r a t i o n s m a n a g e d by the host software. These operations are usually fairly long in d u r a t i o n a n d include the following:

9

Power-up initialization 9 Erase o p e r a t i o n o n a flash device 9 Program o p e r a t i o n o n a p r o g r a m m a b l e device 9 Reset initialization

READY is m o n i t o r e d by the host, w h i c h generates a s t a t u s - c h a n g e interrupt u p o n a transition o n this signal. This signal is m u l t i p l e x e d a n d is available o n l y in the M e m o r y - o n l y m o d e . It b e c o m e s IREQ# in I/OM e m o r y mode. In I / O - M e m o r y mode, the ready/busy functionality is provided b y the READY status bit in the card's pin r e p l a c e m e n t register. It is driven low by the card to indicate t h a t the card is busy a n d u n a b l e to transfer data. It is set high w h e n the card is able to transfer data. In some early machines,

Table 2.3

Usage of voltage sense pins.

Card Vcc

VS1

VS2

Mechanical key on card

Socket Vcc

5V 5V 5V 3V

H* H H L

H* H H H

5V key 5V key 5V key Low voltage key

5V 3V 5V/3V 5V

3V 3V 3/5V 3/5V 3/5V

L L L L L

H H H H H

Low voltage key Low voltage key 5V key 5V key 5V key

3V 3V/5V 5V 3V 3V/5V

Power-up

5V Card not supported 5V LV key prevents card insertion 3.3V 3.3 V 5V 3.3V 3.3V

*For 5V only, card VSl and vs2 are left floating on the card side. A pull-up on the host side brings these pins to a high level.

22

PC CARD: THE 16-BIT BUS

such as the HP95LX, use of READY m a y cause system lock up. The following very specific timing r e q u i r e m e n t s are associated with READY: 9 F r o m p o w e r - u p o r n e g a t i o n o f RESET a card is allowed 20 msec to be ready for host operations. If the card c a n n o t be ready w i t h i n the specified 20 msec, t h e n it m u s t negate READY. The READY signal m u s t be n e g a t e d w i t h i n 10 ~tsec of reset or power-up. It m u s t be driven h i g h w h e n the card is ready to accept h o s t transfers. 9 To e n t e r o r w a k e u p f r o m the power d o w n m o d e cards t h a t require m o r e t h a n 10 [xsec m u s t deassert READY w i t h i n 10 ~tsec of t h e p o w e r - d o w n bit in the CCR a n d status register b e i n g c h a n g e d . Table 2.4 lists the different t i m i n g requirements. Because 16-bit PC Card did n o t specify a m a x i m u m busy time (Not READY) s o m e cards keep READY in the busy (BSY) state for an e x t r e m e l y long period of time. This causes p r o b l e m s with some 16-bit PC Card Card Services, so it is n o t r e c o m m e n d e d t h a t a n y card keep READY in the busy state indefinitely. In t h e n e x t release of the s t a n d a r d PCMCIA m a y limit the a m o u n t of time a card can be kept in the busy state.

2.6.4.4 WP: Write Protect Write protect (WP) is a M e m o r y - o n l y m o d e signal. It is active high. It reflects the state of the WP switch o n the card. W h e n asserted, this signal indicates to the host t h a t the card is write protected. It is available o n the

Table 2.4

READY timing requirements.

Event

Card

READY

Vcc applied or RESET is asserted

Meets 20/msec power-up delay requirements

Vcc applied, or RESET is asserted

Does not meet 20/msec power-up delay requirement Meets 10-[xsec requirement to come out of or go into power down Does not meet 10-1xsec requirement on powerdown or resume

Must be in READY state within 10 lxsec of Vcc, or RESET negation Must be in BSY# state within 10 lxsec of Vcc, or RESET negation READY must be in READY state within 10-[xsec of bit being changed READY must be in BSY# state within lO-lxsec of bit's being changed

Power-down bit is set or reset Power-down bit is set or reset

2.6

BUS SIGNALS

23

bus only in the Memory-only mode. If no WP switch is i m p l e m e n t e d on the card, then WP m a y be pulled low by tying it to ground for cards that allow writes. In cards that are read only, WP m a y be pulled up to Vcc. In I/O-Memory mode, the WP status of a card m a y be obtained from the pin-replacement register. In I/O-Memory mode, this pin is IOmSl6# and is used to indicate 16-bit I/O capabilities on the part of the card.

2.6.4.5

BVD1 and BVD2: Battery Voltage Detect 1 and 2

BVD1 and BVD2 are Memory-only mode signals. They are active high. W h e n asserted they indicate that a battery is in good condition (if available on the card). If the battery is low and should be replaced, BVD2 is deasserted, and data retention is guaranteed. If data retention c a n n o t be guaranteed, BVD1 must be deasserted. These signals were included primarily to support m e m o r y cards such as SRAM cards. 16-bit PC Card does not require both BVD1 and BVD2 to be supported; only BVD1 is required and only if the card uses a battery. However, for compatibility reasons, it is r e c o m m e n d e d that a card support both BVD1 and BVD2.

2.6.4.6

STSCHG#: Status Change

STSCHG# is an I/O-Memory mode only signal. It becomes available in I/O-Memory mode and is used to indicate the change in status of various socket or card conditions. The primary purpose is to m o n i t o r events and provide an indication of these changed events to the host. In some hosts it m a y be used to generate an interrupt (Card Status Changed interrupt), which allows the host to track card events such as READY, Ring Indication, and Battery Voltage Low.

Compatibility Note: Although the 16-bit PC Card standard states that it is an optional signal, it is strongly r e c o m m e n d e d that this signal be implem e n t e d in the host. In I/O cards that support status change events, it should be implemented. In general, if the Pin Replacement register is implemented, the BVD pins are required. 2.6.4.7

SPKR#: Binary Audio

S P K R # is an I/O-Memory mode signal added in release 2.0. It is used pri-

marily to provide a binary audio tone for fax/modems.

Compatibility Note: 16-bit PC Card has made this signal optional. But f a x / m o d e m cards are one of the most popular in 16-bit PC Card. For users of fax/modems, this signal provides feedback about connection activities. It is r e c o m m e n d e d that hosts support this signal.

24 2.6.5

PC CARD: THE 16-BIT BUS

Cycle Definition Signals The cycle definition signals define the cycle occurring on the bus. T h e y are typically used to decode a n d to initiate a n y state m a c h i n e s w i t h i n the card.

2.6.5.1 REG# R E G # is used to define attribute m e m o r y accesses. It is also active d u r i n g

I/O cycles. It becomes active at the start of the cycle a n d stays active for the d u r a t i o n of the cycle. It is available in b o t h M e m o r y - o n l y a n d I/OM e m o r y modes. REG# m u s t be kept inactive for all accesses to c o m m o n m e m o r y . It also m u s t be kept inactive during DMA cycles.

2.6.5.2

IORD# and TOWR#

IORD# and IOWR# are available only in I/O-Memory mode. They define an access to I/O address space. REG4 and one of the cE14, CE2 4 signals must be active for a valid I/O cycle. Because all PC Cards power up in M e m o r y mode, I/O cycles are not acknowledged until the card is configured.

2.6.5.3 CEI# and CE2#: Card Enable CE1 # a n d CE24 are used to indicate an access to the card a n d thus enable the card. e E l 4 indicates an access to an even address, a n d CE2 # indicates an access to an odd address. 16-bit PC Card supports b o t h 8-bit and 16-bit wide I/O a n d c o m m o n m e m o r y accesses. Attribute m e m o r y is byte-wide only. For 16-bit cards e E l 4 a n d CE2# d e t e r m i n e w h e t h e r the cycle is an 8-bit or a 16-bit access. A 16-bit I/O access requires the card to assert I o m s 1 6 4 for 16-bit cycles. If x o z s 1 6 4 is not asserted by the card w i t h i n 3S nsec of the address, the 16-bit access is split into two 8-bit cycles. For 8-bit cycles, all accesses m u s t be 8-bit only. This requires b o t h even a n d odd bytes to be transferred on D0-7. D8-1S are used only in cards for h i g h byte in 16-bit accesses and odd-byte in 8-bit accesses. Table 2.S illustrates the e E l and CE2 4, A0 decodes for c o m m o n m e m o r y accesses. For attribute memory, only 8-bit accesses on even addresses are allowed. Data are always provided on D0-7. Table 2.6 shows the attribute m e m o r y accesses. Note: Even t h o u g h attribute m e m o r y accesses are even addresses, byte only, a 16-bit cycle m a y provide valid data on D0-7 only.

For I/O cards, an extra signal I O I S 1 6 # is used to indicate 16-bit I/O capability in the card (Table 2.7).

2.6

BUS SIGNALS

Table 2 . 5

25

C o m m o n m e m o r y accesses.

Access

CE2 #

CEI #

A 0

D 8 - ~i5

DO - 7

Standby

High

High

X

High-Z

High-Z

8-bit access 8-bit access 16-bit access Odd-byte access

Table 2 . 6

High High Low Low

Low Low Low High

Low High X X

Don't care Don't care Odd byte Odd-byte

Even byte Odd byte Even byte Don't care

A t t r i b u t e m e m o r y accesses.

Access

REG #

CE2 #

CEI #

A 0

D8 - 15

DO - 7

Standby 8-bit access 8-bit access 16-bit access Odd-byte access

X Low Low Low Low

High High High Low Low

High Low Low Low High

X Low High X X

High-Z High-Z High-Z Invalid Invalid

High-Z Even byte Invalid Even-byte High-Z

AO

D8-15

DO- 7

X

High-Z

High-Z

Table 2 . 7

I / O accesses.

Access

REG#

CE2#

CEI

Standby

X

High

High

8-bit access 8-bit access 16-bit access I/O inhibit Odd-byte access

Low Low Low High Low

High High Low X Low

#

Low Low Low X High

Low High X X X

High-Z High-Z Odd-byte High-Z Odd-byte

Even-byte Odd-byte Even-byte High-Z High-Z

The CEI#, CE2# signals m u s t be pulled u p to Vcc by the cards. The value of the pull-up m u s t be greater t h a n IOK o h m s . Typically a g o o d value is a b o u t 33K o h m s .

2 . 6 . 5 . 4 0 E # : Output Enable O u t p u t enable is an active low signal used to initiate a read from the c o m m o n or attribute m e m o r y space of the card. This signal is i g n o r e d if o n e of the card enable signals (c~.l#, c~,2 #) is n o t active. The card is required to provide a pull-up resistor greater t h a n 10K o h m s o n this signal.

26

PC CARD: THE 16-BIT BUS

2.6.5.5

WE#1PGM: Write Enable

Write Enable is an active low signal used to write to c o m m o n or attribute memory. It is required to be high during m e m o r y read cycles and I/O cycles. This signal is ignored if Card Enable is not active. The card is required to provide a pull-up resistor greater t h a n 10K o h m s on this signal.

2.6.5.6

Cycle Control Signals

The cycle control signals are used to control the bus cycle in progress.

2.6.5.7

INPACK#: INPUT ACKNOWLEDGE

I N P A C K # is available only in the I/O-Memory mode. It is an output from the card and is asserted by the card on decode of a valid I/O address. It is n o t widely i m p l e m e n t e d and m a y be eliminated in future revisions of the standard.

2.6.5.8 WAXT#: Add Wait States WAIT# is a cycle control signal added in release 2.0. It is used to delay

c o m p l e t i o n of a cycle. 2.6.5.9

~oms16#

ioisl 6# is not available in the Memory-only mode. It is returned by the card to indicate if the current I/O cycle can be 16 bits. If a host attempts a 16-bit I/O access, the card must assert z o I s 1 6 # within a certain time period for the 16-bit cycle to be valid. Otherwise the host is required to break the cycle into two 8-bit accesses.

2.6.6

Execution Control Signals The execution control signals are used to influence the state of execution of either the host or the card. These consist of the following:

2.6.6.1

X~Q#: Interrupt Request

Interrupt Request is an active low signal available only in the I/O-Memory mode. It is used to indicate an interrupt request by the card. It is reco m m e n d e d that a host system be able to route the IREQ# to any of its n o n d e d i c a t e d interrupt lines. 16-bit PC Card supports b o t h level- and pulse-mode interrupts. For compatibility reasons it is r e c o m m e n d e d that I/O cards support both level- and pulse-mode interrupts.

2.6

BUS SIGNALS

27

2.6.6.1.1 Level Mode Interrupts In level mode, IREQ# is detected as active when low. The IREQ# line for a particular socket should go low and stay low until cleared by the interrupt service routine (ISR). A level-mode interrupt allows one interrupt line to be shared by m a n y different peripherals. In pulse-mode interrupts, the interrupt line pulses. If the edge-detection latches of the interrupt controller are already set, the system may lose the new interrupt. PCI, Microchannel and most non-ISA machines support only level-mode interrupts. 16-bit PC Card requires that cards support level-mode interrupts.

2.6.6.1.2 Pulse Mode Interrupts In pulse mode, IREQ# goes low to indicate an interrupt and then returns to high. This is the mode used by machines that provide 16-bit PC Card from ISA bus-based hosts. Figure 2.4 shows the pulse- and level-triggered modes. 2.6.6.2

RESET

RESET is a signal that was added in release 2.0 of PCMCIA. Hosts de-

signed for release 1.0 do not provide a reset signal. A sample power-on reset circuit is shown in Chapter 8. RESET is in high impedance for at least 1 msec after Vcc is at a valid level. Cards are recommended to implement a weak (about 100K ohms) pull-up on this line. Typically this signal is asserted by hosts on powerup or by the host software whenever the card is to be to reset.

Figure 2.4

Pulse-mode versus level-mode interrupts.

First Interrupt Event

~k

.......

Second Interrupt Event

....... PulseModeInterrupts

~

~

eve_l_Mode_/nte_rrupts. . . . . . . . . . . . . . . . . . . . . . . . . . .

28

PC CARD: THE 16-BIT BUS

Compatibility Note: Release 2.0 cards t h a t are to run in release 1.0 hosts m u s t i m p l e m e n t a power-on reset circuit a n d should n o t c o n n e c t the RESET pin. This m a y cause problems with some Card Services t h a t assert RESET on certain internal events.

2.6.7

DMA Signals DMA support was added in the 1995 release of the PC Card s t a n d a r d a n d is optional. If DMA is i m p l e m e n t e d , the following signals m u s t be supported: DREQ#, DACK, a n d TC (OE#/WE#). DMA is useful in applications in w h i c h data are transferred in large blocks; it frees up CPU b a n d w i d t h for code execution. Examples of applications in w h i c h this signal can be i m p l e m e n t e d are m u l t i m e d i a cards (audio, video), floppy controller cards, local area n e t w o r k (LAN) controller cards, a n d ATA cards. Typical b a n d w i d t h t h a t can be supported by DMA is as follows: 9 5 MB/sec for 8-bit transfers 9 10 MB/sec for 16-bit transfers DMA transfers are similar to I/O transfers except t h a t one of INPACK#, SPKR#, or IOISI6# becomes DREQ#; REG# becomes DACK; and OE#, in the case of writes, or WE#, in the case of reads, becomes TC#. The main differences between a n o n - D M A I/O access to the P C Card and a D M A based I/O access are as follows: 1. Address lines on the socket are ignored during DMA operation. This m e a n s t h a t at a n y given time only one I/O port w i t h i n the PC Card can support DMA transfers. 2. mEG# is deasserted while 3OWR# or 3ORD# is asserted. 3. WAIT# is n o t supported. DMA capable PC Cards m u s t support 165 nsec of access time. 4. 16-bit transfers should be s u p p p o r t e d because I O I S l 6 # m a y n o t be available. 5. Either OE#, if IOWR# is low, or WE#, if IORD# is low, m a y be asserted at the same time as the I/O read or write signal to indicate c o m p l e t i o n of the current DMA transaction. Because DMA is an optional interface, a PC Card socket m u s t be configured to support DMA. For ISA compatibility, the 16-bit PC Card bridge m u s t allow the socket to select a particular DMA channel. This is d o n e in

2.6

BUS SIGNALS

29

a m a n n e r similar to i n t e r r u p t selection. The h o s t bridge m u s t i m p l e m e n t DMA c h a n n e l - s t e e r i n g logic. DMA transfers are allowed o n l y from the I/O space of a PC Card to the m e m o r y space of the host. DMA transfers can be either of the following: 9 M e m o r y read from the host followed by an I / 0 write to the PC Card 9 I/O read from the card followed by a m e m o r y write to the host M e m o r y - t o - m e m o r y a n d I/O-to-I/O transfers are n o t s u p p o r t e d by PCMCIA. Basically, a DMA I/O access to the card is similar to n o n - D M A I/O access to the card except t h a t REG# is deasserted.

Compatibility Note: Becuase IOISI 6# can be used as DREQ#, all cards t h a t s u p p o r t DMA m u s t be capable of s u p p o r t i n g 16-bit transfers in t h e I/O space. 2.6.7.1

DREQ#: DMA Request

DREQ# is used to initiate a DMA transfer by the card. INPACK#, SPKR#, or

TOTS3 6# m a y be used as DREQ#. The actual pin used is d e f i n e d by the PC Card in the CIS.

2.6.7.2

DACK: DMA Acknowledge

DACK is used to a c k n o w l e d g e a DMA request a n d is active high. REG# bec o m e s DACK w h e n the socket is configured for DMA operations. Basi-

cally, REG# is deasserted d u r i n g a DMA cycle. Figure 2.5 shows a DMA bus transaction.

2.6.7.3 Tc#-Terminal Count TC# is an active low signal used to indicate the e n d of the c u r r e n t DMA transaction. In the case of DMA writes to the PC Card WE# is used to indicate a t e r m i n a l count. In the case of a DMA read from the PC Card OE# is used to indicate t e r m i n a l count. TO# is o n l y asserted o n the last DMA bus cycle (Figure 2.5).

2.6.8

P o w e r Signals 2.6.8.1 Vpp I and Vpp 2 Vpp pins are used to supply a p r o g r a m m i n g voltage such as 12V to the PCMCIA card.

30

PC CARD: THE 16-BIT BUS

Figure 2.5 PC Card.

D M A transaction. M e m o r y read f r o m host-IO w r i t e to

DREQ# REG# (DACK) __/

k

D15-0

{

)

{

CEI-~ --~ IOWl~

~\

/ /

}

\

{ /

\

/

\

/ \

/

.

OE# RESET / WE# (TC#)

,

lORD#

Compatibility Note: Although 16-bit PC Card does not require a specific voltage for Vpp, it is r e c o m m e n d e d that a host should support at least Vcc and 12V on Vpp. For card designers it is i m p o r t a n t to note that there are some platforms which have chosen to not support 12V on Vpp. Therefore if functionality is desired across those platforms it is better to i m p l e m e n t a Voltage-Converter circuit on the card. There are, however, trade-offs for such a circuit. This circuit is discussed in Chapter 8. 2.6.8.2

Vcc: Power Supply

There are two Vcc pins in 16-bit PC Card. 16-bit PC Card to date has identified four possible Vcc voltage levelsm5.0 volts, 3.3 volts and as yet unspecified X.X, Y.Y volt. 16-bit PC Card provides both an electrical and a mechanical scheme to allow hosts to determine the Vcc voltage required by the card. Chapter 9 provides further detail about these schemes.

2.6.8.3

GND: Ground

There are a total of four ground pins. This n u m b e r is very small compared to the total n u m b e r of outputs (bidirectional pins on the bus). This increases the a m o u n t of ground bounce on the card during data transfers.

2.7 TRANSFER PROTOCOLS

2.7 2.7.1

31

TRANSFER PROTOCOLS Memory Data Transfer 16-bit PC Card is an asynchronous bus, so there are no clocks to provide cycle timing. All peripherals on the PC-Card-16 in n o n - D M A m o d e are accessed as slaves. Figure 2.6 shows b o t h a read a n d write from C o m m o n Memory, the attribute m e m o r y Read/Write is very similar except t h a t REG# is low during the cycle. The cycle is initiated w h e n the CEI# a n d / o r CE2# (for 16-bit accesses) are asserted. Address a n d mEG# also m u s t be valid at t h a t time. The cycle finishes with deassertion of OE# or WE# a n d CE:# or CE2. For 16-bit accesses, the host asserts b o t h c g : # a n d CE2#.

The cycle time in 16-bit PC Card is d e p e n d e n t on the host a n d w h e t h e r WAIT# is asserted by the card to e x t e n d the cyle. 16-bit PC Card allows four different read cycle times for C o m m o n M e m o r y m 2 5 0 - , 200-, 150-, a n d 100 nsec. This m e a n s t h a t the m a x i m u m b a n d w i d t h available for data transfer in the m e m o r y cycle is: 9 20-MB/sec for word accesses 9 10-MB/sec for byte accesses

Figure 2.6 Memory read/write cycle timing without wait states. .

.

.

.

.

.

.

.

.

.

.

.

.

.

.....::::::?................................... i.......................................... o~.~......::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: o:~.~......================================================================================= o:.~..................... :::::::::::::::::::::::::::.......................................... w:.~......:::::::::::::::::::::::::::::::::::::::::::: ......:::::::::::::::::::::::::::::::::: l

w~":~::::::-/. ................................... I.......................................... l i

32

PC CARD: THE 16-BIT BUS

These b a n d w i d t h numbers assume back-to-back cycles on the bus. That is very difficult to achieve on a sustained basis, so in practice, the actual b a n d w i d t h used by the host is less t h a n the m a x i m u m bandwith. With the standard timing (100-, 200-, 250-, 150-) it is assumed WAIT# is not asserted during the cycle. A 600-nsec cycle is allowed for 3.3V cards only. The most critical timing specifications in the read cycle are the Address access time, the card enable access time, and WAIT# valid from OE#. The address access time and the card enable access time depend on the speed of the m e m o r y device used. The WAIT# valid from OE# is critical because it allows a m a x i m u m of 35 nsec for a card to decode the address and generate W A I T # (see Figure 2.6).

2.7.2

I/O Data Transfer An I/O transfer occurs w h e n the 16-bit PC Card socket is put into the I / O - m e m o r y mode. In this mode, the IORD# and IOWR# become available. An I/O cycle is initiated w h e n 3ORD# or IOWR# is asserted and the card enables (CEI# and/or CE2#) and REG# are asserted. The minim u m cycle time (WAIT# not asserted) is calculated by adding the Address Setup to IORD#, IORD# pulse width, and Address Hold from IORD# (70+165+20=255 nsec). This means that the m a x i m u m b a n d w i d t h available on the I/O cycle is: 9 3.92 MB/sec for byte accesses 9 7.84 MB/sec for word accesses As the numbers show, m e m o r y space b a n d w i d t h is m u c h higher in 16-bit PC Card t h a n I/O space bandwidth. So applications such as Video and high speed networking which require the higher b a n d w i d t h m a y be forced to operate in the m e m o r y mode. Figure 2.7 shows the timings for I/O Read and I/O Write cycles.

2.7.3

Delaying Cycle Completion Delaying cycle completion in 16-bit PC-Card is accomplished with WAIT#. WAIT# is a signal i m p l e m e n t e d in 16-bit PC Card release 2.0. The m i n i m u m cycle the host will run is 255 nsec in I/O interface. In m e m o r y accesses the host can run 100- to 250-nsec cycles at 5V. The cycle time supported by the card is stored within the CIS. To extend the cycle bey o n d 255 nsec in I/O accesses, the card must assert WAIT#. In m e m o r y

2.7 TRANSFER PROTOCOLS

33

Figure 2.7 I / 0 Read and I / 0 Write cycle timing.

, , , : 9 .....

iiiiii<

....... ~

R E G #

............................

}iiiiiiiiiiiii(

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

)iiiiiiiiiii

/: ...... ::::::::::::::::::::::::::::::::::::::

lORD#

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

,o~,, .... ::::::/

...................................

I

[ ...... :::::::::::::::::::::::::::::::::: I

W A I T #

. . . . . . .

.............

:::::::::::::::::::::::::::::::::::

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

..........................................

I

oo_~5 ..... ii12111222111121122111~

}iiii[12111222~

.>2 .....

I

I

accesses a card can extend the cycle by using WAIT#. However, because wait-state generation circuitry requires the use of a clock, which would affect standby power c o n s u m p t i o n of the card, most m e m o r y interfaces on the card try to work within one of the four cycle times supported by PCMCIA by defining it in the CIS of the card. This approach m a y not work if the card's data access time varies by m e m o r y address or if the card's data access time is slower than 250 nsec. Figure 2.8 shows an extended I/O cycle using WAIT#. PC Card requires that the data must be valid w h e n WAIT# is deasserted. The actual length of the extended cycle m a y not be exactly identical to the access time of the device because of the granularity of the clock used to insert the WAIT# delay. A higher granularity would bring the cycle time closer to the access time of the device; however, it m a y increase the standby power c o n s u m p t i o n considerably because it would require a higher frequency oscillator circuit. For example, consider the block diagram shown in Figure 2.9. The access time of the device is 400 nsec. The prop delay through the address and data buffers is 15 nsec. An example is a bus r u n n i n g at 100-nsec cycle time with a 10-MHz clock in wait-state generator logic. For the sake of brevity, the analysis is

34

PC CARD: THE 16-BIT BUS Figure 2.8

Extending an I / 0 cycle w i t h WAIT#.

A2S-0

(

t

-~ tdr(W~

D15-0 CEI#

\

REG#

\

OE#

\

RESET -~

dtd(WT) -1 \

WAIT#

/

Figure 2.9 Block d i a g r a m of slow m e m o r y device-based card.

Data Memory Device

Decode

2.7

TRANSFER PROTOCOLS

35

limited to m e m o r y read operation. Figure 2.10 shows the t i m i n g diagram of the m e m o r y read cycle. The t i m i n g equations are as follows" WATT A s s e r t i o n

WAIT# m u s t be asserted w i t h i n 35 nsec. The decode

logic m u s t decode address a n d cycle definition signals a n d assert WAIT# w i t h i n 35 nsec of the address's b e c o m i n g valid. OE# or WE# is being asserted. Therefore Decode time ___t v ( W T - OE) Decode time _<35 nsec WATT# is deasserted as soon as the data are g u a r a n t e e d to be valid on the bus. The t i m i n g e q u a t i o n is as follows:

WAXT# D e a s s e r t i o n

tpd Addr + tacc Device + tpd Data ___395 N o w tw(WT) -- N u m b e r of clocks x 100 N u m b e r of clocks >__3.95, w h i c h rounds to 4 The cycle starts with assertion of the Card Enable; t h e n W A I T # is asserted. WAIT# is kept asserted for four clocks t h e n deasserted.

Figure

2.10

Timing

0ns Clock /

I

waveform

I

\

/

-~tpd

buffer

I \

for slow memory 250ns

I /

\

I /

I \

read. I

1500ns

I

/

\,

/

I

I

\.

/---

A25-0 _

Int Addr _

/

data

D15-0 tacc device

Int Data CEI#

\

REG#

\

OF.#

WAIT#

7

(

)

f

---tsu(A)--~

j

\

tv(WT-OE)

Tw(W'r)

36

PC CARD: THE 16-BIT BUS

2.7.4

16-Bit Transfers 16-bit PC Card supports both 8- and 16-bit transfers. All c o m m o n memory accesses must be able to support 16-bit cycles. In I/O space, 16-bit support is optional, z o z s l 6 # if asserted allows a 16-bit cycle to continue as 16-bit. If IOZSl6# is deasserted, then the host must break the cycle into two 8-bit accesses. In c o m m o n memory, 16-bit cycles are indicated w h e n the host asserts b o t h CEI# and r In I/O space 16-bit cycles occur w h e n the host asserts C E I # and C E 2 # and the card asserts I O I S I 6 # . I O I S I 6 # is designed to be generated purely off the decode of the address. The card is required to assert I O I S l 6 # within 35 nsec of the address's becoming valid. Figure 2.11 shows the timing of 16-bit I/O cycles. The first cycle is a 16-bit I/O transfer in which the card asserts I O I S 1 6 4 . The second cycle is also initiated as a 16-bit transfer, but deassertion of I O I S l 6 # forces the transaction to be split up into two 8-bit cycles--an 8-bit access for the low byte and an 8-bit access for the high byte. Table 2.8 shows the control for 16-bit accesses in c o m m o n memory, I/O, and DMA cycles.

2.8

ELECTRICAL CHARACTERISTICS OF 16-BIT PC CARD The electrical characteristics in 16-bit PC Card are very important. Key issues in PC Card design are: 9 9

Vcc Voltage--5V or 3.3V Voltage levels for inputs and outputs--CMOS versus TTL levels

Figure 2.11

IOISl6# transfers.

A2S4) __ DlS-0 CEI#

~

)

~

... 9 ,,

/-

CE~

/---

_

REt~

IOWR~ lORD#

I
,olslu ~ \

/-

\ \.

/"

IOIS16(ADR)

-~tdr IOISIG(ADR)

/

~tdr IOIS16(ADR)

2.8 ELECTRICALCHARACTERISTICS OF 16-BIT PC CARD

37

9 Capacitive loading 9

P o w e r - u p restrictions

9 Power c o n s u m p t i o n 9 Power m a n a g e m e n t 9 Slew rate c o n t r o l to m i n i m i z e g r o u n d loop c u r r e n t 9 L i m i t i n g state of c h a n g e of c u r r e n t (di/dt)

2.8.1

V o l t a g e Levels PC Card s u p p o r t s b o t h CMOS a n d TTL levels. A PC C a r d m a y use either. For m a x i m u m c o m p a t i b i l i t y a h o s t m u s t i m p l e m e n t CMOS levels o n all o u t p u t s a n d accept TTL levels o n all inputs. T h e DC specifications are de-

Table 2.8

PC Card access decodes.

Cycle

REG #

A0

CEI #

CE2#

D7-O

D15-8

IOISl 6 #

Memory-Word Memory-Low byte Memory-High byte Memory-Odd byte I/O-Word I/O-Word (Split into byte accesses) I/O-Low byte I/O-High byte I/O-Odd byte DMA-Word DMA-Byte Attribute m e m o r y Low byte Attribute m e m o r y Odd bytet Attribute m e m o r y Words Attribute m e m o r y High bytet

H H H H L L

X L X H L X(L)

L L H L L L

L H L H L L (H)*

Low byte Low byte High-Z High byte Low byte Low byte

High byte High-Z High byte High-Z High byte High-Z

WP WP WP WP L H

L L L H H L

L X H X X L

L H H L L L

H L L L H H

Low byte High-Z High byte Low byte Byte Low byte

X X X X X WP

L

H

L

H

X

L

X

L

L

Low byte

High-Z High byte High-Z High byte X X; High-Z in Read X; High-Z in Read X

WP

L

X

H

L

X; High-Z in Read

X

WP

WP

*CE2# is deasserted when IOISl6# is sampled high. tA high-byte or odd-byte access to attribute memory is ignored on writes and provides invalid data. tin a Word access to attribute memory the high byte is ignored. H, high state; X, don't care; L, low state; WP, write protect; Z, high impedance.

38

PC CARD: THE 16-BIT BUS

Table 2.9 TTL voltage levels. Vih Vil Voh Vol

Table 2.10 Vih Vil Voh Vol

Table 2.11

2.0 V min 0.8V max 2.4 V min 0.4V max

CMOS voltage level. 0.7Vcc min 0.8V max 0.9 Vcc min 0.1Vcc max

Capacitative loading.

Signals

Host

Card

Data bus Address Control Status

100 pf Max -m 50 pf Max

100 pf Max 100 pf Max 50 pf Max

fined in PCMCIA b u t o n l y as guidelines. For actual voltage levels PCMCIA has referred designers to JEDEC. For the reader's c o n v e n i e n c e , t h e JEDEC tables are i n c l u d e d here for 5V a n d 3.3V devices. Generally acc e p t e d TTL levels are p r e s e n t e d in Table 2.9, CMOS levels in Table 2.10, a n d capacitative l o a d i n g in Table 2.11.

Note: Power c o n s u m p t i o n u n d e r TTL levels increases substantially.

2.9

SUMMARY 16-bit PC Card is an a s y n c h r o n o u s slave bus. It uses a p r o t o c o l similar to t h e ISA bus with e n h a n c e m e n t s for card a n d socket e v e n t d e t e c t i o n a n d s o m e specific status i n f o r m a t i o n . Electrically 16-bit PC Card requires c o n s i d e r a b l e a t t e n t i o n to the driver circuits a n d to slew rate. G r o u n d b o u n c e is an i m p o r t a n t consideration in card design.

3 CARDBUS: THE 32-BIT BUS

3.1

OVERVIEW CardBus is the next-generation high-performance 32-bit bus with a bus master PC Card interface. The 199S release of the PC Card standard provides full support for CardBus in all c o m p o n e n t s of the standard. It provides bus mastering and high bus b a n d w i d t h - - 1 3 3 MM/sec. 16-Bit PC Card is 20 MB/sec.

3.1.1

History The original motivation for CardBus was a proposal by Apple C o m p u t e r to PCMCIA, in November 1991, for adding bus master capability to PCMCIA. This resulted in a formation of a bus master s ubc ommitte e by PCMCIA. The bus master co mmittee was re na me d the CardBus subcommittee. The first subcommittee meeting was held in March 1992. The CardBus proposal was formally adopted as a PCMCIA standard in October 1994. The following three proposals were considered for CardBus: 9 Original CardBus proposal by Apple 9 PCI specifications by the PCI Special Internet Group (PCI SIG) 9 ANET specification by C o m p a q C o m p u t e r The PCI specification was chosen as the basis for the CardBus implem e n t a t i o n for the following three reasons: 9 Shorter time to develop the standard 9 Better compatibility with desktop systems that were expected to be PCI-based 9 O p p o r t u n i t y to use c o m m o n silicon for PCI and CardBus

39

40

CARDBUS: THE 32-BIT BUS

3.1.2 CardBus Applications CardBus enables applications such as video, high-speed networking, high-performance graphics, and SCSI on mobile platforms. Applications have exceeded ISA bus capabilities on desktops, leading to the developm e n t of PCI- and VESA-based platforms. The same applications are expected to exceed the capabilities of 16-bit PC Card in mobile platforms. CardBus is expected to be implemented on hand-held machines (PDAs), notebooks, and desktops. For the low-end platforms such as PDAs and low-end notebooks, a single CardBus socket implementation is expected. For high-end notebooks and desktops, a multiple-socket CardBus implementation is expected.

3.1.3

CardBus Capabilities Overview A simple way to describe CardBus is PCI electrical protocols with enhancements for card event management, status, and PCMCIA mechanical form factors. The basic capabilities of CardBus are as follows: 32-bit multiplexed address/data bus with parity Support for the following types of cards in any combination: 32-bit bus master cards 32-bit slave memory cards 32-bit slave I/O cards 0-33 MHz clock with 133-MB/sec throughput PCI data transfer and arbitration protocols Burst Transfers Bus locking Parity based error detection Cache snooping support Support of up to eight functions on a PC Card (a function is an individual instance of a specific I/O or memory capability) Recognition and support of 16-bit PC Card-based cards Supports both CardBus and 16-Bit PC Card-based cards Enhanced card detection and voltage sensing capability to differentiate CardBus cards from 16-bit PC Cards Supports PCMCIA form factors such as Types I, II and III. Uses the same 68-pin connector Power management support Limitation on m a x i m u m power-on current

3.2

PIN ASSIGNMENT TABLE

41

Clock rate m a n a g e m e n t Remote interface wake-up capability E n h a n c e d audio capabilitymSupports b o t h pulse-width m o d u l a t e d (PWM) a n d binary tone

3.1.4

CardBus Definition of Terms A g e n t m A device or card on the bus that either initiates a bus transaction or is the target of a bus transaction. Bus C y c l e - - S a m e as bus transaction. Bus T r a n s a c t i o n m A bus cycle that m a y be used to transfer i n f o r m a t i o n or messages b e t w e e n different agents on the bus. This term is used int e r c h a n g e a b l y with the term bus cycle.

I n i t i a t o r ~ A n agent that initiates a bus transaction. This term is used i n t e r c h a n g e a b l y with the term master. M a s t e r - - A n agent that initiates a bus transaction. This term is used int e r c h a n g e a b l y with initiator. Examples are a local area n e t w o r k (LAN) card t h a t transfers a packet of data to host m e m o r y by initiating multiple bus transactions. A master could also behave as a slave in a different bus transaction. S l a v e ~ T e r m used i n t e r c h a n g e a b l y with target. A slave at a different time m a y be the initiator of a bus transaction. T a r g e t ~ A n agent that is the target of the current bus transaction.

3.2

PIN ASSIGNMENT TABLE Figure 3.1 shows the pin a s s i g n m e n t for PCMCIA on the connector. It shows the i m p l e m e n t a t i o n for 16-bit PC Card in M e m o r y - o n l y mode, 16-bit PC Card in I / O - M e m o r y mode, a n d CardBus.

3.3

CARDBUS PIN SUMMARY Table 3.1 describes the electrical signals supported by CardBus. Tables 3.2 a n d 3.3 list the differences and similarities b e t w e e n 16-bit PC Card a n d CardBus.

Figure 3.1

('b >

C o n n e c t o r pin o u t for CardBus, PC Card I / 0 , and PC Card m e m o r y .

E~ C oo

i

.-.4 -'r"

I

m

&,

CARDBUS

,

PC Card I/O-Memory PC Card Memory-Only

,...,,.,

)

1

,.

I

~~~~~~

~~NN~~N~~N~NNNN~N~NNNNNNNNNN

16-bitPc Car~

% % ,~, ~, ,~ ,".,.

c,,Ro,,os

~ % ~.. % % % ~

o

-4

3.3

CARDBUS PIN SUMMARY

43

Table 3.1

Overview of CardBus signals.

Signal

Buffer type

CCLK

Clock Clock for bus transactions Address/data Multiplexed address and data bus. Each bus cycle on CardBus consists of an address phase followed by one or more data phases. Control CFRAME#is asserted to indicate the begini/o-s/h/z ning of a bus cycle. It is negated for the last data transfer. Control Device select. It is driven by a device on ilo-slh/z the bus to indicate a valid decode. Control C o m m a n d and byte enables. These are i/o-s/h/z multiplexed signals. During the address phase of the bus cycle they define the type of cycle being executed. During the data phase they act as a byte enable. Control Initiator ready. Indicates the master initi/o-s/h/z iating the current cycle is able to complete the current data phase. Control Target ready. Indicates the slave* device i/o-s/h/z selected for the current cycle is ready to complete the current data phase. i/o-s/h/z Control Resource lock. Indicates exclusive atomic access to a particular address. Exclusive accesses may be obtained with a separate resource-locking protocol. i/o-h/z Address/ Parity. The parity bit provides parityData based error detection for b o t h the address and data buses. i/o-s/h/z Parity Parity Error. Reports an error on the data bus. Output open Parity System parity error. Reports a catastrophic drain parity error, such as on address, or data parity error in the special c o m m a n d . Output, h/z Arbitration Bus request. Indicates to the CardBus output for Arbiter that the master asserting this card signal is requesting the bus. Output, h/z for Arbitration Bus grant. Indicates to master that the socket output bus has been granted. i/o-o/d output Control Clock run. Used by the card to control card the clock. The card asserts the signal w h e n it requires the host to start or accelerate the clock.

CAD

31-0

CFrame#

CDEVSEL CC/BE3-0#

CIRDY#

CTRDY#

CBLOCK#

CPAR

CPERR# CSERR#

CREQ#

CGNT

CCLKRUN#

Type

Description

Input i/o-h/z

(continued)

44

CARDBUS:THE 32-BIT BUS

Table 3.1 ( c o n t i n u e d )

Signal

Buffer type

Type

Description

CCD2-1#

Static

Event

CVS2-1

Static

Event

CSTSCHG

O u t p u t h/z for card

Event

CSTOP#

i/o-s/h/z

Control

CRST#

Input to card O u t p u t from card

Control Event

CINT#

Output, o/d from card

Event

VP P 2 - 1

--

Power

vcc

--

Power

GND

--

Power

Card detect. Allows the host to detect insertion of a card. Also indicates w h e t h e r the card is a 16-bit PC Card or a CardBus card. For CardBus cards supporting 3.3V only, Cr # is shorted on the card to c v s l #. Table 3.2 shows CCD2-1 # and c v s 2 - 1 / . (See C hapt er 2.) Card voltage sense. These pins allow a socket to d e t e r m i n e the power-up Vcc r e q u i r e m e n t s of the card and allow the socket to differentiate a 16-bit PC Card or CardBus card. Card status change. Used to indicate changes in card status or to wake up system or card. Stop. Used by the target to t e r m i n a t e the bus transaction. Reset. Used to reset the card. Card audio. Digital audio o u t p u t from card. CardBus supports the binary audio originally supported in PCMCIA release 2.1 and pulse-width m o d u l a t e d audio. Card interrupt. Active low, level-triggered interrupt. P r o g r a m m i n g voltage. Up to 35 V m a y be generated, a l t h o u g h 12V is more common. Card supply voltage. CardBus supports 3.3V or X.XV and Y.YV Vcc. X.X and Y.Y are to be defined. Ground. CardBus supports four g r o u n d pins. A shielded c o n n e c t o r provides additional grounding.

CAUDI O

*A slave device is a slave only for the duration of the current cycle. It may be capable of behaving as a master in another cycle.

3.3 CARDBUS PIN SUMMARY

45

Table 3.2 Summary of differences between CardBus and 16-bit PC Card. CardBus

16-bit PC card

32-bit multiplexed address and data

16-bit data, 26-bit address non-

PCI-based transfer protocols Up to 133 MB/sec data throughput Synchronous bus up to 33-MHz clock Support for bus master-slave operation Level-triggered interrupt Parity-based error detection on address and data buses Burst-mode data transfers Memory, I/O, and configuration spaces 3.3V-, X.XV-, or Y.YV-only Vcc No support for RDY/BSY# Cache snooping and invalidation support Resource locking for exclusivity of accesses Reflective wave signaling Pulse-width modulated and binary audio Single interface for memory and I/O Memory space support required Slew rate control required on output drivers Card register interface based on configuration space defined by PCI Byte alignment--No byte swapping, all bytes appear on their natural byte lanes Power-up CIS read current restricted to 70-mA Supports hierarchical bus structure

multiplexed Transfer protocols similar to ISA Up to 20 MB/sec data throughput Asynchronous bus l O0-nsec memory cycle time Slave operation only Pulse-triggered and level-triggered interrupt No parity support Non-burst transfers only Attribute, c o m m o n memory, and I/O space 3.3V, 5V, or X.X Vcc RDY/ BSY# signal supported No support for cacheable memory No resource locking supported Incident wave signaling Binary audio only Separate memory-only and I/O-memory interface modes Slew rate control not specified Card register interface uses up to five card configuration registers Byte swapping is required for odd byte accesses Power-up CIS read current restricted to 100 mA for 5V and 70 mA for 3.3V Hierarchical bus structure not defined

3.3.1 CardBus Signal I/O Driver Types A CardBus signal is defined by two attributes: direction (input, output, or bidirectional) and driver type, for outputs and bidirectional signals. Directional Attributes

9 i n p u t I n p u t is a s t a n d a r d i n p u t signal d r i v e n b y an o u t p u t or bidir e c t i o n a l signal

46

CARDBUS:THE 32-BIT BUS

Table 3.3

Similarities between CardBus and 16-Bit PC Card.

CardBus

16-bit PC card

Uses 68-pin connector to provide host interface to card (connectors use a shrouded implementation to provide additional grounds) Point-to-point bus Supports Type I, II, and III form factors as defined by PCMCIA Supports card status and event signals Status change Card detect Card voltage sensing Vpp

Uses 68-pin connector to provide host interface to card

Point-to-point bus Supports Type I, II, and III form factors as defined by PCMCIA Supports card status and event signals Status change Card detect Card voltage sensing Vpp

9 i / o Bidirectional signal m a y be driven by either the host or the card 9 o u t p u t A standard t o t e m pole o u t p u t buffer that is always active and drives the signal either active high or active low Driver Type 9

High-Z (h/z) Can be disabled to so that it is in the high-z or high i m p e d a n c e state w h e n disabled. 9 O p e n D r a i n (o/d) Drives the signal active low. To b e c o m e inactive, the o u t p u t is disabled and a pull-up typically is used to drive the signal high. Basically an open drain driver has an active p u l l - d o w n capability but must be pulled up with an external resistor. 9 o u t p u t A standard t o t e m pole o u t p u t buffer that always drives the signal either low or high. The o u t p u t is actively driven w h e n it is driven high or w h e n it is driven low. 9 Static A direct current (DC) signal. A static signal is n o t actively driven. It is basically either pulled high or pulled low. Its state does n o t change. An example of a static signal is the card detects--CDl# a n d C D 2 #. 9 S u s t a i n e d A sustained high-Z (s/h/z) signal that is a special PCI (and CardBus) driver type. Basically a modification of the open drain driver type. This type of driver is used in active low outputs. The output before being disabled is required to drive the signal high for at least one clock before disabling and going to high-Z.

3.4 CARDBUS HOST IMPLEMENTATION OVERVIEW 3.4

47

CARDBUS HOST IMPLEMENTATION OVERVIEW A CardBus host typically implements a CardBus bridge between one of its buses and CardBus. The bus master support and the b a n d w i d t h of CardBus require a h i g h - t h r o u g h p u t bus. In personal c o m p u t e r (PC) systems, CardBus bridges should be i m p l e m e n t e d on PCI or on the host CPU bus. Figure 3.2 shows the CardBus host i m p l e m e n t a t i o n . Typically a CardBus host consists of a CardBus arbiter and a controllermthe CardBus bridge. The CardBus bridge, because of the high bandwidth requirements and the multimaster support, has to be based on either the CPU bus or on a high b a n d w i d t h multimaster bus such as PCI. By definition, each CardBus bridge must support both 16-bit PC Cards and CardBus cards. The bridge also must include voltage switching and regulation circuitry to turn-on Vcc and Vpp or to switch the voltages to support SV or 3.3V cards. SV support is not required by the standard but is strongly recommended.

Figure 3.2 A CardBus bridge implementation.

DRAM

Arbiter CardBus Bridge

Voltage Switching/ Regulation

48

3.5

CARDBUS: THE 32-BIT BUS

CARDBUS DIFFERENCES FROM PC CARD CardBus shares some capabilities with PC Card but is different in terms of electrical signals a n d data transfer protocols. The key differences are as follows.

3.5.1

Multiplexed Address and Data Bus CardBus uses m a n y of the PCI electrical characteristics. Like PCI, CardBus uses a m u l t i p l e x e d 32-bit address a n d data buS--CAD3 3-0. The address appears on the CAD3 3 - 0 pins on the first phase of the bus transaction. The data appear on these pins in the second a n d s u b s e q u e n t phases. Similarly the r signal provides c o m m a n d s in t h e first p h a s e a n d byte enables in s u b s e q u e n t phases.

3.5.2

PCl-based Transfer Protocols As m e n t i o n e d earlier, CardBus uses PCI protocols, w h i c h are very differe n t from the 16-bit PC Card protocols. The CardBus protocols are defined later in this chapter.

3.5.3

Bus Master Support 16-Bit PC Card is a slave-only bus. The host issues read a n d write transactions to the resources on the card. The card can r e s p o n d to these readwrite t r a n s a c t i o n s only by accepting data on a write or by p r o v i d i n g data o n a read. CardBus allows either the host or the card to initiate a bus t r a n s a c t i o n . The e n t i t y t h a t initiates the bus t r a n s a c t i o n is k n o w n as the initiator or t h e bus master. A bus m a s t e r m a y read or write to any resource on the CardBus or on the host. The entity (host or card resource) b e i n g targeted by the t r a n s a c t i o n is k n o w n as the target. A resource is a n y I/O m e m o r y , or c o n f i g u r a t i o n space on any of the a f o r e m e n t i o n e d entities. The following are examples of transactions s u p p o r t e d by CardBus: 9 Host read or write to a resource on the card 9 A bus m a s t e r card read or write to a resource on the host 9 A bus m a s t e r card read or write to a resource on a n o t h e r card on CardBus 9 A bus m a s t e r card read or write to a resource on a n o t h e r card on a separate bus on the host. For example, a CardBus card m a y read data from a m e m o r y card on the PCI bus

3.5

CARDBUS DIFFERENCES FROM PC CARD

49

Bus master support has the following two implications: 1. Because either the card or the host m a y initiate a transaction, m o s t of the signals on CardBus are bidirectional. Some signals such as arbitration signals, clock, or reset are fixed and m a y be driven in only one direction. 2. The CardBus bridge must i m p l e m e n t a bus arbiter, w h i c h allows various CardBus masters to arbitrate for the right to initiate a transaction on CardBus.

3.5.4

Clock Management PCI supports up to a 33-MHz clock. However, there is no m e c h a n i s m in PCI to slow the clock dynamically. CardBus supports an optional signal called CCLKRUN#, w h i c h is used by the host to indicate s h u t d o w n of the clock. A CardBus card m a y request the host to start the clock or accelerate it to the operational frequency by m e a n s of assertion of CCLKRUN#. Clock m a n a g e m e n t is one of the i n n o v a t i o n s i n t r o d u c e d with CardBus. It is i n t e n d e d to allow the host to m i n i m i z e power c o n s u m p t i o n by m a n a g i n g the clock.

3.5.5

Slew Rate Control on Signal Drivers In CardBus up to 40 signals can switch simultaneously. The desire to use the same 68-pin c o n n e c t o r as 16-bit PC Card limits the n u m b e r of grounds available to CardBus. This has resulted in a very high signal-tog r o u n d ratio (10:1) in CardBus a n d places limitations on o u t p u t s t h a t switch on CardBus. This requires edge rate control on the o u t p u t drivers that restricts edge rates to 1 V/nsec m a x i m u m . The CardBus host connector also provides g r o u n d c o n n e c t i o n s externally to the card frame to c o m p e n s a t e for the limited n u m b e r of g r o u n d pins on the connector.

3.5.6

Reflective Wave Signaling CardBus, like PCI, uses reflective wave signaling on C C L K . Most system e n v i r o n m e n t s are designed to work in incident wave signaling. In an incident wave signal, the source of the signal completely drives the signal to its desired state (high or low). The desired signal-level propagates to the input, where the input voltage changes to the value driven by the o u t p u t driver. In reflective wave signaling, the o u t p u t driver is still driving the signal to the desired voltage level w h e n the reflection of the wave from an un-

50

CARDBUS:THE 32-BIT BUS

t e r m i n a t e d e n d comes back a n d pushes the signal level up to the desired voltage level. This requires t h a t the affected signal (CCLK in this case) trace be carefully laid out a n d designed so t h a t the reflected wave comes back at the correct phase a n d time to e n h a n c e the signal's driver.

3.5.7

Hierarchical Bus Structure A hierarchical bus structure is one in w h i c h one instance of a bus m a y lie u n d e r a n o t h e r instance of the same bus. Figure 3.3 illustrates a hierarchical bus structure for CardBus. CardBus has a special configuration access cycle defined for CardBus PC cards that lie on a bus other t h a n the local bus. The cycle is called the Type 1 configuration access cycle.

Figure 3.3 CardBus hierarchy.

3.5

3.5.8

CARDBUS DIFFERENCES FROM PC CARD

51

Point-to-Point Bus In bus topology there are two configurations--a bus configuration and a point-to-point configuration. In a bus topology all the signals are shared between each socket or slot. Every cycle is broadcast (visible to every device) on the bus. In a point-to-point topology, most or all the signals are unique to each socket or slot. A cycle on a given socket or slot does not appear on any other socket or slot.

3.6

DIFFERENCES BETWEEN CARDBUS AND PCI CardBus is very similar to PCI in m a n y ways. Because of the need to adapt to PCMCIA, however, it has taken on some differences. These include features for power m a n a g e m e n t such as clock shutdown, event m a n a g e m e n t signals such as card detect, voltage sense, and status change to detect insertion, removal, and other events occurring in a PCMCIA card. Table 3.4 summarizes the differences between CardBus and PCI.

3.7

ADDRESS SPACES Each CardBus PC Card may contain up to eight functions. A single function is defined as a unique instance of a specific I/O or storage-memory capability. Examples of I/O functions include fax/modems, Ethernet interface, SCSI interface, and ATA interface. Examples of storage-memory functions are flash memory, static SRAM, and Erasable Programmable read-only m e m o r y (EPROM). For each function, CardBus defines three different address spaces-memory, I/O and configuration space. Up to 4GB of m e m o r y and I/O space and 2S6 bytes of configuration space is supported. The configuration space is used to configure the CardBus card. Each CardBus card must support a configuration space. Each CardBus card must respond to a configuration space access as a slave (target). Each CardBus card with I/O registers must support m a p p i n g these registers into the host's m e m o r y space. Each I/O space access indicates the starting byte being accessed. The data size of the access is defined by the byte enables that come in a later phase. If the target acknowledges the cycle by means of the byte decode and the byte enables indicate a data size not supported by the card, the cycle is aborted with a target abort. Memory space accesses may be either byte, word, dword, multiple dwords, or a full cache line in size. If the card does any prefetching, it must ensure coherency by invalidating any unread data from its buffers once the transaction is complete.

52

CARDBUS:THE 32-BIT BUS

Table 3.4

Differences b e t w e e n PCI and CardBus.

CardBus

PCI Bus Revision 2.0

Support for additional signals

No support for these signals

CSTSCHG# CAUDIO Vpp CCD2-1# CVS 2-1# 32-bit address and data only

No support for snoop backoff or snoop done No JTAG support C C L K R U N # signal to stop, slow, or accelerate clock Single interrupt line per card 3.3V operation only for CardBus cards Uses 68-pin connector for host-card interface Card supports PCMCIA Type I, II, and Type III form factors Vcc switched on/off at insertion and removal Insertion and removal at-will High SSO/ground ratio forces slew rate control on drivers Point-to-point topology

Support for 64-bit address and data Supports both SBO# and SDONE signals JTAG support built-in No support for a CCLKRUN# signal Up to four interrupt lines per card 5V/3.3V operation supported Uses a 120-pin edge connector (32-bits) Uses a 64-bit extension connector for a total of 184 pins An ISA style form-factor specific to PCI Vcc not switched Insertion or removal requires system shutdown Slew rate restrictions not as severe as in CardBus Bus topology

3.7.1 Configuration Space Each f u n c t i o n provides o n e or m o r e of the following spaces: configuration space, m e m o r y space, I/O space, e x p a n s i o n ROM. C o n f i g u r a t i o n space is required for each function; o t h e r spaces are optional. The configuration space is a 256-byte m e m o r y region accessed by a configuration cycle. It is divided into two logical sections: (1) a required 64-byte p r e d e f i n e d c o n f i g u r a t i o n header a n d (2) a function-specific space. The configuration header is a 64-byte region t h a t m a y c o n t a i n c o n t r o l a n d configuration registers for the function. A function-specific space is used to c o n t a i n tuple chains a n d o t h e r function-specific i n f o r m a t i o n . Table 3.5 shows the c o n f i g u r a t i o n h e a d e r for CardBus.

3.5

CARDBUS DIFFERENCES FROM PC CARD

Table 3.5

D31-24

53

Configuration space header fields.

D15-8

ID23-16

JD7-O

Allocated

Allocated

Status Header type

, BIST

00h

Commands Allocated

Allocated Cache line size

ILatency timer

04h 08h 0Ch

Base address register

1Oh

Base address register

.14h

Base address register

18h

Base address register

1Ch

Base address register

20h

Base address register

24h

CIS pointer

28h

Reserved

2Ch

Expansion ROM base address

30h

Reserved

34h

Reserved Allocated

Offset

Allocated

Interrupt pin

38h I

I

Allocated

3Ch

Beginning of Function Specific Space Tuple

40h

Tuple Tuple Tuple Tuple

End of Function Specific Space

FFh

3.7.2 Locating the Configuration Information Structure Each CardBus card is required to provide a tuple chain to provide inform a t i o n about the card and the function. The configuration information structure (CIS) m a y be located either in the function-specific region of the configuration space or in the m e m o r y space. The actual location is defined by the CIS pointer register in the configuration header.

54

3.8

CARDBUS: THE 32-BIT BUS

C O M M A N D DEFINITIONS C a r d B u s c o m m a n d s are d e f i n e d b y t h e CB1<.3- 0# p i n s d u r i n g t h e a d d r e s s p h a s e . Table 3.6 p r o v i d e s t h e c o m m a n d b y t e e n c o d i n g .

Table 3.6 CardBus command byte encoding. CC/BE3

0000

0001

0010 0011 0100 0101 0110 0111 1000 1001 1010

1011 1100

1101 1110 1111

-0#

Description Allocated. Used by PCI for interrupt acknowledge. To maintain compatibility with PCI environments, CardBus cards must not respond to this command. Special Cycle. A broadcast mechanism for communication with other CardBus cards or devices on the system. It can be used to broadcast various messages between devices. I/O Read. Indicates that a read is being initiated from an address mapped into the PCI I/O address space. I/O Write. Indicates that a write is being initiated to an address mapped into the PCI I/O address space. Reserved. Reserved. Memory Read. Indicates that a read is being initiated from an address mapped into the PCI memory address space. Memory Write. Indicates that a write is being initiated to an address mapped into the PCI memory address space. Reserved Reserved. Configuration Space Read. Reads the configuration space of the selected agent. An agent is selected when its r signal is asserted. Configuration Space Write. Writes to the configuration space of the selected agent. Memory Read Multiple. Similar to Memory Read except that it indicates that the initiator will read more than one cache line. Allocated. Used as dual-address cycle by PCI. Must not be used by a CardBus agent. Memory Read Line. Similar to Memory Read except the initiator may read up to the cache line boundary. Memory Write and Invalidate. Similar to a Memory Write, except that in this case the master writes a complete cache line. The size of the cache line is defined by the cache line size register.

3.9

3.9

CARDBUS TRANSFER PROTOCOLS

55

CARDBUS TRANSFER PROTOCOLS The basic CardBus bus cycle is a burst. A burst consists of an initial address phase followed by one or more data phases. CFRAHE# is active on the clock edge during which data is sampled that indicates another data phase. On the last data phase, CFRAHE# is deasserted. CardBus supports burst read and writes in both the I/O and memory spaces as well as in the configuration space. All signals are synchronous except event management signals and CCT,KRUN#. The synchronous signals are sampled on the rising edge of CCT,K. Each signal has a defined 7-nsec m i n i m u m setup and a 0-nsec m i n i m u m hold time. Signal values outside the setup and hold times are not valid.

3.9.1

CardBus Basic Bus Cycle Figure 3.4 shows the basic CardBus cycle. The CardBus cycle is initiated by the master (also k n o w n as the initiator) by means of assertion of CFRAHE#. The first rising edge of clock on which CFRAHE# is asserted is the address phase. In this phase CAD31-0 provides a valid address and the CCBE# signals provide the valid bus c o m m a n d . The next clock edge begins the first of the data phases. A CardBus cycle may have one or more data phases.

Figure 3.4 CardBus basic cycle. 50ns

0ns I CCLK

I

I

I

lOOns

I

I

I

- ~

CFRAME#

Phase

~

.

i i i

Address~--

CCBE#

I

I I$Ons I

I

200ns

I

t

I

I

]

/---2 Address

CAD314)

I

i

Bus Cmd ~

Data

-

Phase

Data

Phase

i i I

Day-1

~, I

i

l

Byte Enable #s

CIRDY# CTRDY# CDEVSEL#

--~

-

I t i i i i

Ii i

J

;

56

CARDBUS: THE 32-BIT BUS

During the data phase, data transfer occurs on the clock edge in which CTRDY# and CIRDY# are asserted. Idle clocks (wait states) m a y be inserted by the master by means of deassertion of r or by the target by means of deassertion of CTRDY#. In Figure 3.4 the first data phase has a wait-state inserted by the target, which does not assert r until the second clock of the data phase. CardBus requires that the source of the data indicate valid data by asserting its r signal. For reads as in Figure 3.4 the target is providing the data so CTRDY# indicates valid data, for writes the master is the source so C I R D Y # indicates valid data. CDEVSEL# is driven by the target to indicate that the address decode points to a resource within the target. The bus cycle is completed w h e n the master deasserts CFRAME#.

3.9.2

Byte Packing During Writes CardBus allows a host bridge to produce bursts on the bus by packing together m e m o r y writes. M e m o r y writes m a y be packed together into a single burst transaction as long as the following rules are obeyed: 1. No re-ordering of writes is allowed 2. A write to an address is declared as non-packable during configuration 3. The write is to an I/O or configuration space

3.9.3 Turnaround States Because CardBus is a multimaster bus with multiplexed signals, some signals m a y be driven by different agents at different times. A signal m a y have to be turned around either within a bus transaction or between bus transactions. Frequently, w h e n a signal is being turned around a turnaround state is added in the cycle. A turnaround state is required on all signals that m a y be driven by multiple agents. It is required to prevent c o n t e n t i o n w h e n one device stops driving and another device starts driving the signal. In future discussions, a turnaround state is represented by the symbol shown in Figure 3.5.

3.10 CARDBUS READ CYCLE Figure 3.6 shows the basic CardBus Read cycle. The Read cycle is very similar to the basic CardBus cycle described earlier. Because the target is

3.10

CARDBUS READ CYCLE

Figure

3.5

Turnaround

57 state.

,_j providing data, CTRDY# indicates valid data. There is also a t u r n a r o u n d state after the address phase to allow CAD3 l - 0 to turn around from address, driven by the master, to data, driven by the slave device. In the CardBus Read cycle a t u r n a r o u n d state is inserted between the address phase and the first data phase. Clock edge 2 is the address phase. The data phase begins after clock edge 2. However, the first data phase does not take place until clock edge 4, w h e n CIRDY# and CTRDY# are both asserted. This is because the target forces an idle cycle to turn around the CAD [31:0] lines. A wait state is inserted by the master on the third data transfer by means of deassertion of CIRDY# before clock edge 7. The master terminates the cycle by deas-

Figure

3.6

CardBus

read cycle.

;

i

;

i

i

1 CFRAME# - ~

Z

S ,

4 ,

5

i

I

CAD31-0

Addre i s

CCBE#

(Bus CmdX

i

I

Datail' )

(

6I II

T

Da{l:a-2X

Byte Enable #s

i

r/

8

Data-3

1 I

/--

CIRDY# '

CTRDY#

I'

I I I

CDEVSEL#

iI

I

I I

'

F

58

CARDBUS: THE 32-BIT BUS

serting C F R A M E # after clock edge 7 and once C I R D u has been asserted. W h e n the target detects CFRAME# deasserted on clock edge 8 it also deasserts CTRDY# and CDEVSEL#. Once the cycle is complete, the clock after the completed cycle is idle and used as a t u r n a r o u n d state for CFRAME#, CAD and CCBE# signals.

3.10.1

CardBus W r i t e Cycle

Figure 3.7 shows the basic CardBus write cycle. A write cycle is similar to a read cycle except that there is no t u r n a r o u n d between the address and the data phases, because the address and data are both driven by the initiator. The cycle starts with assertion of CFR~E#. CFRAME# is deasserted just before the last data is written. Because the master is the source of data in this case, CIRDY# when asserted indicates valid data. W h e n the transaction is complete, CIRDY# is deasserted in the cycle after the last data is written. The master can insert wait states in any of the data phases by deasserting CIRDY#. This indicates to the target that valid data are not available and forces the target to wait for the next clock. Similarly the target can insert wait states by deasserting CTRDY#.

Figure 3.7

CardBus basic write cycle.

1 CFRAME# ,

\

Z ;

~ i

4 I

5 ,

I

I

I

I

I

I

r

6 :

I'

r

CAD31-0 , (Aadre~ }( Data'~X Data-:~ X~Data-~ X Dat~-4 ) I

CCBE# ," (BusC

I

CIRDY# ~

\

CTRDY# ~

\

I

CDEVSEL# ~ ,

,~

I

BE#-ilx BE#-2~ X BE#-:~' X BE#--4 ' ) I

r

/

/ \

tl

/

,

i,

3.11 CARDBUS BUS MASTER SUPPORT

3.11

59

CARDBUS BUS MASTER SUPPORT CardBus supports cycles being initiated by the host as well as cards on the bus. Each a g e n t before initiating a t r a n s a c t i o n m u s t request a n d be g r a n t e d the right to b e c o m e a master on the bus. CardBus uses a central arbiter t h a t arbitrates b e t w e e n requests from all masters on the bus. Each m a s t e r has a u n i q u e request signal (CREQ#) a n d grant signal CGNT#. An initiator requests the bus by asserting its CREQ# signal. W h e n the central arbiter d e t e r m i n e s t h a t the r e q u e s t i n g a g e n t m a y initiate a cycle o n the bus, it asserts the initiator's CGNT# line. Arbitration on CardBus is pipelined. The arbitration for the n e x t cycle occurs d u r i n g the previous cycle so t h a t n o additional latency is a d d e d to a cycle because of arbitration. The following c o n d i t i o n s apply to the initiator's use of CREQ#: 9 C R E Q # m a y be asserted by the r e q u e s t i n g a g e n t on a n y clock. 9 CREQ# s h o u l d be asserted only w h e n there is an actual n e e d to use a

resource lying on CardBus. 9 If only a single t r a n s a c t i o n is desired the a g e n t m u s t deassert its C R E Q # on the same clock it asserts CFRAME#. The following c o n d i t i o n s apply to the C G N T # signal as used by the central arbiter: 9 A m a s t e r can assert CFRAME# only if its CGNT# line is asserted on t h a t clock edge. If the CGNT# signal is n o t asserted, the m a s t e r m u s t n o t assert CFRAME#. 9 O n e CGNT# m a y be deasserted in the same clock in w h i c h a n o t h e r CGNT# is asserted if the bus is n o t in the idle c o n d i t i o n . If the bus is n o t idle, t h e n a one-clock delay is required b e t w e e n deassertion of one CGNT# a n d assertion of a n o t h e r CGNT#. 9 CGNT# m a y be deasserted on any clock. 9 CGNT# deassertion while CFRAHE# is asserted does n o t invalidate the bus cycle. It indicates t h a t the next t r a n s a c t i o n has b e e n g r a n t e d to a n o t h e r master. Figure 3.8 shows arbitration occurring on CardBus.

3.12

TERMINATING A CYCLE IN CARDBUS A CardBus t r a n s a c t i o n m a y be t e r m i n a t e d by either the m a s t e r or the slave device. The master has the u l t i m a t e responsibility to bring the bus

60

CARDBUS" THE 32-BIT BUS

Figure 3.8

A r b i t r a t i o n on CardBus.

CCLK

aster#1 R,./

CREQI#

\

CREQ2#

\

/

\

CGNT2#

--

CFRAME#

/

MasIerg2 Request

--~Ma~ ter#1 -R i ~q. Grar t~d

CGNTI#

2~ 1 Reques From #1

~Maste; #1 -Req, Grante

\

Mast, ~r#2 Re I Grantt d

I

~dMaste r#2 Tral isactior Starte( i Mast -~ Mast ~r#1 Cy~:le starl / , ~--~ \

~r#1 Cyq:le star1 d

/

t r a n s a c t i o n to a p r o p e r t e r m i n a t i o n . The transaction m a y be t e r m i n a t e d u n d e r the following conditions: .

N o r m a l T e r m i n a t i o n I n i t i a t e d b y t h e M a s t e r C F R A M E # is asserted a n d CTRDY# is deasserted. Used w h e n a cycle c o m p e t e s n o r m a l l y or the latency timer expires. 9 T a r g e t I n i t i a t e d T e r m i n a t i o n CFRAME# is deasserted a n d CSTOP# is asserted. 9 M a s t e r A b o r t No target responds to the bus cycle. The master is forced to abort. 9 T a r g e t A b o r t CDEVSEL# is deasserted a n d CSTOP# is asserted.

3.12.1

Normal Termination Initiated by Master

A n o r m a l t e r m i n a t i o n is used in the following conditions: 1. A t r a n s a c t i o n is c o m p l e t e d n o r m a l l y w h e n a master has completed its t r a n s a c t i o n as i n t e n d e d . The final data transfer is indicated w h e n C F R A M E # is deasserted a n d C I R D Y # a n d C T R D Y # are asserted. CIRDY# a n d CTRDY# are deasserted in the clock after the data transfer. 2. A transaction is t e r m i n a t e d w h e n the master's internal laten/:y t i m e r has expired a n d CGNT# is deasserted. The full t r a n s a c t i o n m a y n o t h a v e b e e n c o m p l e t e d in this case, b u t the t e r m i n a t i o n still follows n o r m a l cycle c o m p l e t i o n protocols as defined in 1.

3.12 TERMINATING A CYCLE IN CARDBUS

61

3.12.2 Target-Initiated Termination Target-initiated t e r m i n a t i o n is used u n d e r the following conditions: The target is u n a b l e to r e s p o n d to the bus cycle a n d requests a retry. The target is u n a b l e to r e s p o n d w i t h i n the latency guidelines of CardBus a n d is requesting a disconnect. Retry is used w h e n the t r a n s a c t i o n is t e r m i n a t e d w i t h o u t data transfers. Retry occurs u n d e r the following conditions: 9 Deadlock possibilities 9 Resource busy 9 Exclusive access locked c o n d i t i o n A d i s c o n n e c t usually occurs if the target is u n a b l e to m e e t the eightclock i n c r e m e n t a l latency r e q u i r e m e n t for N+I data phase. It usually occurs after o n e or m o r e data phases have b e e n c o m p l e t e d . The target m a y assert CSTOP# o n a n y clock before or after a data phase. The target can indicate the n e e d for o n e m o r e data transfer by s i m u l t a n e o u s l y asserting CTRDY#. Data transfer occurs o n the clock o n w h i c h b o t h CIRDY# a n d CTRDY# are asserted. A m a x i m u m of o n e data p h a s e is allowed after CSTOP# is asserted. The transaction is t e r m i n a t e d o n c e CFRA_ME# has b e e n deasserted, followed by deassertion of CIRDY# a n d CTRDY#. There are four possible d i s c o n n e c t scenarios based o n the state of CTRDY# a n d CIRDY# w h e n CSTOP# is asserted. The t e r m i n a t i o n is handled differently for each of the following scenarios. 1. CTRDY# a n d CIRDY# are active o n the same clock edge o n w h i c h the target asserts CSTOP#. In this case the target is i n d i c a t i n g o n e m o r e data transfer before t e r m i n a t i o n . The master deasserts CFR/MME# in the n e x t clock, transfers data, a n d t e r m i n a t e s the t r a n s a c t i o n in the following clock edge. The target m u s t also deassert CTRDY# in the clock t h a t follows the data transfer. 2. CIRDY# is active a n d CTRDY# is deasserted o n the same clock edge t h a t the target asserts CSTOP#. In this case n o further data transfer is required. The master deasserts CFP4~HE# in the n e x t clock a n d CIRDY# in the following clock, t e r m i n a t i n g the transaction. 3. CIRDY# is inactive a n d CTRDY# is asserted o n the same clock edge o n w h i c h the target asserts CSTOP#. In this case the target indicates o n e m o r e data transfer before t e r m i n a t i o n . O n c e the master is

62

CARDBUS: THE 32-BIT BUS

ready to complete the data transfer, it asserts CIRDY# a n d deasserts CFRANE#, indicating this to be the last data phase. In the next clock, b o t h CIRDY# a n d CTRDY# are deasserted, indicating t e r m i n a t i o n . 4. Both CIRDY# a n d CTRDY# are deasserted on the same clock edge on w h i c h r is asserted. In this case no further data transfer is needed. The master should assert CIRDY# in the next clock (regardless of w h e t h e r it is able to complete a data transfer). In the same clock the master also deasserts CFRAME#. In the next clock C I R D Y # is deasserted, t e r m i n a t i n g the transaction.

3.12.3

Master Abort

Master abort is used if no target responds to a bus transaction, forcing the m a s t e r to t e r m i n a t e or abort the cycle p r e m a t u r e l y w i t h o u t c o m p l e t i n g the transaction. A lack of response from the target is d e t e r m i n e d if CDEVSET,# has not been asserted by the master w i t h i n the sixth clock of the bus cycle. Once the master has m a d e that affirmation, CFRAME# is deasserted in the next clock, followed by CIRDY# in clock 8. For a single data phase transaction, CFRAME# is n o r m a l l y driven inactive before clock 6. In this case CIRDY# is deasserted in clock 7.

3.12.4 Target Abort Target abort is used to t e r m i n a t e a transaction in w h i c h a fatal error has occurred or to w h i c h the target is unable to respond. A target abort is indicated by the target by m e a n s of assertion of CSTOP# a n d deassertion of CDEVSEL#. CDEVSEL# m u s t be asserted for one or m o r e clocks a n d CTRDY# m u s t be deasserted before target abort can be signaled.

INTERRUPTS

3.13

There are two types of interrupts on CardBus. One is a general purpose interrupt l i n e - - t i N T # , w h i c h is a level-sensitive, active low, asynchronous signal. The other is CSTSCHG, w h i c h is used to notify the host about specific card events such as change in READY, write protect, or battery voltage conditions.

3.13.1

CINT#: General Purpose Interrupt

CardBus allows one interrupt per socket. CardBus hosts may assign a socket i n t e r r u p t to a n y available interrupt line. Therefore the interrupt

3.14

CLOCK MANAGEMENT

63

h a n d l e r should be written i n d e p e n d e n t l y of interrupt vector a n d interrupt line. O n l y one interrupt line is defined for all the CardBus PC Card functions.

3.13.2

eSTBe~G: Card Status Interrupt

CSTSCHG is an active high signal, unlike STSCHG# in 16-bit PC Card. It is a level-sensitive interrupt and is asserted asynchronously. This interrupt is supported by four 32-bit registers--function event, function mask, function present state, and function force event. Each function on the card is required to support one complete set of these registers. C S T S C H G can be used to wake the system while interface is powered off. During the power-off state, if CSTSCHG is used to wake the host, it m u s t be powered by an external source, such as a p h o n e line or an oncard battery. To wake the host CSTSCHG m u s t be driven high or pulsed c o n t i n u o u s l y until the system is powered up. Because of potential damage to the host and the card, the CSTSCHG o u t p u t driver m u s t be designed with the following: 1. A current limiter on the o u t p u t that prevents the o u t p u t current from exceeding 1 mA 2. Electro Static Discharge (ESD) clamp diodes in the host t h a t m u s t be able to w i t h s t a n d a sustained forward biased current of 1 mA w h e n Vcc = 0V a n d i n p u t voltage (Vin) = 3.6V for an infinite a m o u n t of time

3.14

CLOCK MANAG EMENT One of the e n h a n c e d capabilities provided w i t h i n CardBus is the ability to m a n a g e clocks. The host is allowed to vary the CCLK frequency or stop the clock w i t h o u t having to notify the CardBus cards t h r o u g h software. The host changes the CCLK frequency or stops CCLK u n d e r the following conditions: 9 Bus is idle and no bus request (CREQ# inactive) is p e n d i n g 9 Bus is idle and no exclusive access is in progress (CBLOCK# deasserted) 9 CCLK m u s t be stopped in the low state only 9 CCLKRUN# is valid only while the socket has Vcc on

64

CARDBUS:THE 32-BIT BUS C C L K R U N # is an optional signal used by the host to indicate i n t e n t to

slow or stop the clock. While low, CCLKRUN# indicates that c c u < is runn i n g at n o r m a l operating frequency. If the host is going to slow d o w n or stop CCLK, it deasserts CCLKRUN# s y n c h r o n o u s l y at least four clocks before c h a n g i n g CCLK. CCLKRUN# can also be used by the CardBus card to request the host to speed, restart, or m a i n t a i n the clock. The CardBus card asserts CCLKRUN# a s y n c h r o n o u s l y a n d keeps it asserted until it detects two rising edges on CCLK. Because the signal m a y be driven by the host or the card, there are very strict t u r n a r o u n d rules for both, as follows: 1. The host m a y drive CCLKRUN# low or high; it can only drive the signal high for one clock before it m u s t disable its active pull-up driver. 2. The card can drive only the signal low. 3. The card m a y n o t assert CCLKRUN# if it is already low. 4. At assertion of CCLKRUN# by the card, the host m a y start driving the signal by the third clock after it detects CCLKRUN# is low. S. The host m u s t n o t drive CCLKRUN# high until five clocks after it detects the card driving it low.

ERROR DETECTION

3.15

CardBus, like PCI, uses two signals, C P E R R # a n d CSERR#, for reporting errors. Parity generation is required on all transactions on the bus. All agents on the bus are required to be able to generate parity a n d detect a n d report parity. CPERR# is used to report data parity errors on all transactions except special cycles. CSERR# is used to report address parity errors a n d data parity errors on special cycle. It also m a y be used to report other types of n o n p a r i t y or system errors.

3.15.1

Parity Rules 9 Parity is based on even parity calculations 9 Parity covers CAD3 3 - 0 a n d CCBE3-0#. Byte lines t h a t do n o t transfer data still m u s t be included in the parity calculation. 9 The agent t h a t drives CAD3 3 - 0 is responsible for driving even parity on r r is driven one clock after the data or address phase. 9 For data r is valid two clocks after the data phase.

3.16

9

9

SUMMARY

65

For address C S E R R # is used, but no timing relation has been defined by CardBus. CSERR# m a y be asserted or checked by any agent on the bus, w h e t h e r or not it was involved in the transfer.

CPERR#

3.15.2

The assertion of C P E R R # is controlled by the parity error response field in the configuration header. If the field is set, the agent is required to assert CPERR# u p o n detection of a parity error. CPERR# is valid two clocks after the clock edge on which the data are sampled. Figure 3.9 shows a bus transaction with a parity error.

SUMMARY

3.16

CardBus brings m a n y additional capabilities to the PC Card form factor. Its 32-bit, 33-MHz cycle with burst support improves data throughput. Its support for bus masters provides a m e c h a n i s m to reduce the data transfer burden on the CPU. These added capabilities, however, put a trem e n d o u s burden on the connector grounds. The switching scheme used in CardBus requires careful printed circuit board (PCB) layout on the part of the PC Card designer and requires attention to output driver design.

Figure 3.9 CCLK

Parity g en er at i o n and detection on CardBus.

'

' 2r

I CFRAME#

CAD

' 3t i i r

\

/

( A~idr.

> i

' 4

' ~

' 6

t 7

, I~

, 9

, 11

--

_____q

1,?.

i 1 II

i I

( Data

: -~Address Parity

)

(Add/ Pa ity Bit

XDatl'll :

:

X Oat=~2 X Oat=~ XOata'4 ) : ,~ Par!ty Bit

', :

I: CPERR#

, lq

'

'

I

I

'

i

'

i

I

\ ~o,/

I

'

: I

I

;,

Oa~-l/

', :

I qat=-3 I

I

~

*i \ Error o~ Da~-2

No En

This Page Intentionally Left Blank

4 INSERTION AND CONFIGURATION ISSUES

4.1

OVERVIEW Card insertion and card removal events that take place in PCMCIA. removed or inserted at will. The configuring the card at the time of ing card insertion is as follows:

are two of the more i m p o r t a n t card A PC Card or CardBus PC Card can be host is responsible for automatically insertion. The sequence of events dur-

1. Card is inserted into socket 2. Card Vcc and ground pins make contact with host Vcc and ground pins 3. Other pins except Card Detect make contact 4. Card Detect pins make contact and at least one Card Detect pin is pulled low 5. Host detects card 6. Host determines card type and voltage using Card Detect and Voltage Sense pins 7. Host powers up the socket with the appropriate Vcc voltage level 8. Host waits for card to indicate it is ready 9. Host reads card configuration information structure (CIS) to determine resource requirements 10. If resources are available, host configures the card using the function configuration registers for 16-bit PC Cards or configuration header for CardBus cards. 11. If resources are not available or the host is unable to process the tupies, it rejects the card by not performing configuration and turning off socket Vcc. This chapter discusses the mechanisms needed to support the insertion and removal interface and the configuration of the card. It discusses

67

68

INSERTION AND CONFIGURATION ISSUES

both CardBus and 16-bit PC Card. It also discusses the key tuples that are normally used and describes a sample CIS for the various card types.

4.2

INSERTION ISSUES Once a card is inserted and detected by the host, four key issues need to be addressed: 9 9 9 9

Detection of removal or insertion of the card Card type--CardBus or 16-bit PC Card Card voltagem3.3V or 5V Card configuration

The PC Card standard released in 1995 places restrictions on the card, such as initial power-up current c o n s u m p t i o n and steady-state current consumption. Although not directly specified in the standard, there is a practical limit on the inrush current required by the card.

4.2.1

Supplying Voltage and Power The PC Card standard requires that Vcc be switched off if no card is present in the socket. It supports two different operating voltages for a PC Card--5V and 3.3V. For CardBus PC Cards it supports 3.3V, X.X, or Y.Y (values to be defined) voltages. W h e n a PC Card is first inserted, the host must determine the type of card--CardBus or 16-bit PC Card. r162 CCD2#, CVSI#, and cvs2 # are used to determine the card type and the operating voltage supported by the card.

4.2.2

Power Consumption Restrictions on Supply Current The supply current (Icc) is a key specification for most PC Cards. This is because some PCMCIA hosts are battery powered and extremely limited in the a m o u n t of current they can supply. This makes power consumption an i m p o r t a n t compatibility issue within PCMCIA. PCMCIA has specified supply current in two forms: (1) initial power-up current and (2) m a x i m u m average supply current. The PC Card standard indirectly provides some values for a third supply current specification, the inrush current. The initial supply current before card configuration is restricted to 70 mA for CardBus and 100 mA for 16-bit PC Cards. The average m a x i m u m

4.2

INSERTION ISSUES

69

supply current is restricted 0.5 A per Vcc pin or 1 A per socket. This specification, however, is not strictly followed by all host platforms. The battery-powered h a n d h e l d platforms tend to power m u c h lower supply current. The HP100, for example, provides only 150 mA of average supply current.

4.2.2.1

Inrush Current

W h e n the card is inserted and Vcc is switched on, the power-supply current immediately shoots up for a very short duration to a very large peak value. This initial current w h e n Vcc is being turned on is the inrush current. The inrush current is the immediate supply current used to charge up the capacitance on the card. It is usually a very high value, m u c h higher t h a n the normal supply current, but it only lasts for a very short time. Typically the inrush current values are in the 1 A to 2 A range. Figure 4.1 shows a typical waveform of the inrush current. The following equation provides the basis for the inrush current: I = C(dv/dt) The value of the inrush current depends on the Vcc rise time (dv/dt) supported by the host and the capacitance (C) of the card. The PC Card standard does not directly specify inrush current, but it does specify a Vcc rise time of 0.1 msec m i n i m u m and 300 msec maxi-

Figure 4.1

Example of Inrush current.

70

INSERTIONAND CONFIGURATION ISSUES

m u m . Therefore, depending on the value of the card capacitance, the inrush current can be calculated. For example, if card capacitance is 10 gF and Vcc rise time is 0.1 msec, then the inrush current (Iinrush) is calculated as follows: Iinrush = (10 X 10 -6) (5/0.1 x 10 -3) = 500 mA

4.2.3

Configuration Both CardBus PC Cards and 16-bit PC Cards can be automatically configured by the host. To be automatically configured a card must provide the following" 1. A configuration space, in which the card configuration registers (CCR) are located 2. A standard configuration register set to allow universal card support by a generic enabler 3. Card resource requirements. In 16-bit PC Card the attribute m e m o r y serves as the configuration space. It contains the function configuration registers (FCR) that allow the host to configure the PC Card. The CIS describes the resource requirements of the PC Card. It would normally also reside in the attribute m e m o r y space, but in some cases it may reside in the c o m m o n m e m o r y space. Every 16-bit PC Card is required to provide a CIS. In CardBus PC Cards, configuration space replaces the attribute memory. The configuration space contains a configuration header, which is used to configure the CardBus card. The CIS is also required in CardBus cards and may reside in the configuration space.

4.3

CARD INSERTION INTERFACE Card insertion affects Vcc, CCD2#, CCDI#, c v s 2 # , and CVSl#. The Vcc is normally switchedmVcc is turned off w h e n no PC Card is detected in the socket and turned on w h e n a PC Card is detected in the socket. Vcc is required to be switched for CardBus cards. The same is strongly recomm e n d e d for 16-bit PC Card. This is mostly because card insertion in a hot socket (Vcc on) has a very fast Vcc rise time on the card, resulting in a huge a m o u n t of inrush current.

4.3

CARD INSERTION INTERFACE

71

4.3.1 Using Voltage Keys The PC Card standard supports four different Vcc values: S volts, 3.3 volts, X.X volts where X.XV is less than 3.3V, or Y.Y volts where Y.YV is less than X.XV (X.X and Y.Y are Vcc levels to be defined). The standard also defines two mechanical keys--a SV key that supports SV Vcc only and a low voltage key, which supports 3.3V, X.XV, or Y.YV on Vcc. The mechanical keys are designed to prevent physical insertion in a keyed socket of incompatibly keyed cards to prevent potential damage on either the card or the host. For example, a socket keyed for SV provides SV only on Vcc and is not required to decode VSl or vs2. Such a socket would prevent insertion of a card keyed with the low voltage key. The mechanical specifications of the physical keys are described in chapter 7.

4.3.2 Detecting Card Type The PC Card standard supports two distinctly different bus protocols: 16bit PC Card and CardBus. The host socket must differentiate between the two types of cards. A CardBus host adapter that must support both 16-bit and CardBus PC Cards must have a mechanism to differentiate 16-bit PC Cards from CardBus cards. CardBus cards do not support SV operation, whereas a 16-bit PC Card may be SV only. However, a CardBus socket is required to support 16-bit cards; this requires a CardBus socket to support 3.3V Vcc and SV Vcc. A 16-bit socket is not required to support a n y t h i n g b e y o n d SV. Table 4.1 shows the interface detection keying. As Table 4.1 shows, card detect pins play a key role in determining the type of pc card inserted in the socket. For ] 6-bit PC Card both card detect pins (CCDl#and CCD2#) are grounded. For CardBus PC Cards, one carddetect pin is grounded while the other is shorted to either CVSl or c v s 2 . The socket interrogates each card-detect pin by alternately driving c v s i and c v s 2 high and then low. The card-type detection algorithm is given in Figure 4.2. Once the card type is detected, a series of steps are required to configure and identify a CardBus PC Card.

4.3.3 Voltage Sensing A 16-bit PC Card can operate at either 5V, 3.3V, or X.XV. A CardBus PC Card can operate at either 3.3V, X.XV, or Y.YV. A 16-bit PC Card socket may support SV only or SV, 3.3V, and X.XV. A CardBus socket is required

72

INSERTION AND CONFIGURATION ISSUES

Figure 4.2

Determination of card type.

Empty Socket CVS1-2 Driven Low

CCDI# and CCD2# Low

Drive CVS1 High

<,,,. or CCD2#

Yes v

Card=CardBus

Card=16-bit

Drive CVS2,1 Low

to support 16-bit PC Cards as well as CardBus cards. Therefore, it m u s t s u p p o r t b o t h 3.3V a n d 5V Vcc at least. PCMCIA has defined a m e c h a n i s m w h e r e b y the voltage sense pins are used to d e t e r m i n e the voltageon Vcc t h a t m a y be used to read the CIS from the card.

4.4

CONFIGURATION

Table 4.1

73

Detecting card type in CardBus-capable sockets.

CCD2# in card

CCDI# in card

Ground

Shorted to CVSl ( c v s l in card must be left open) Shorted to cvs2 (cvs2 in card must be left open) Ground

Key

Card type

Comments

Ground

5V or low voltage

16-bit PC Card

Ground

Low voltage

CardBus

Ground

Low voltage

CardBus

Shorted to

Low voltage

CardBus

Low voltage

CardBus

In Case of 5V, C V S I - 2 must be left open. In Case of dual voltage cards, CVl and cv2 are driven as appropriate along with either the LV or 5V keys. If card grounds CVSl pin, the card type is undefined. If card grounds CVSl pin, the card type is undefined. If card grounds CVSl pin, the card type is undefined. If card grounds CVSl pin, the card type is undefined.

cvsl (cvsl in

Ground

card left open) Shorted to cvs2 (cvs2 in card left open)

Table 4.2 provides t h e e n c o d i n g of the voltage sense pins C V S l a n d c v s 2 a n d physical keys used to d e t e r m i n e the value of t h e p o w e r - o n voltage.

4.4

CONFIGURATION O n e of t h e i m p o r t a n t features of PCMCIA s t a n d a r d is t h e s u p p o r t built i n t o t h e s t a n d a r d for a u t o m a t i c c o n f i g u r a t i o n of t h e card a n d a l l o c a t i o n of t h e n e c e s s a r y resources w i t h i n t h e host. In fact, PCMCIA has d e f i n e d software services a n d APIs to s u p p o r t card i n s e r t i o n a n d r e m o v a l at will a n d a u t o m a t i c c o n f i g u r a t i o n a n d allocation a n d d e a l l o c a t i o n of h o s t resources. The two key c o m p o n e n t s t h a t allow this capability are t h e CIS of PC Card a n d t h e CCR used to configure the cards.

74

INSERTION AND CONFIGURATION ISSUES

Table 4.2

Voltage sense encoding.

C VS2

C VS1

Key

Vcc

Comment

Open Open Ground Open Open

Open Pull down (1K) Pull down (1K) Ground Connected to

5V 5V 5V LV LV

5V 5V, 3.3V 5V, 3.3V, X.XV 3.3V 3.3V

16-bit 16-bit 16-bit 16-bit PC Card CardBus

Ground Ground

Ground Connected to

LV LV

3.3V, X.XV 3.3V, X.XV, Y.YV

16-bit PC Card CardBus

Connected to

Ground

LV

3.3V, X.XV

CardBus

Open Open

LV LV

X.XV X.XV

16-bit PC Card CardBus

Open

LV

X.XV and Y.YV

CardBus

Y.YV

CardBus

CCDI#

CCD2#

Ground Connected to CCD2#

Connected to CCDI#

CCD2#

Open C o n n e c t to CCD2# LV Ground Connect to CCDI# Reserved Connect to CCDI# Ground Reserved

4.4.1

Configuration Information Structure Overview The CIS is a variable-length chain or linked list of data blocks or tuples. A tuple is a linked-list e l e m e n t of the CIS. A c o m b i n a t i o n of linked tuples is used to form a chain. Each tuple contains an identification (ID) field, a l e n g t h field, a n d a data field. For 16-bit PC Card the CIS m u s t start at address zero of attribute m e m o r y space. For CardBus cards the CIS start location is defined by the CIS pointer defined w i t h i n the configuration space header. The tuple chains are used to provide various types of inform a t i o n about the capabilities a n d resource requirements of the PC Card. Both CardBus a n d 16-bit PC Cards are required to provide a CIS t h a t is accessible w h e n e v e r the card is powered-up a n d in a ready c o n d i t i o n (READY is asserted) (Figure 4.3). The PC Card standard supports 37 tuples. Table 4.3 shows the list of tuples. Each CIS begins with a valid tuple ID a n d m u s t end with the tuple code OFFh. Each CIS consists of one or more linked lists of tuples. If there are multiple tuple chains, each chain is linked with the next chain by m e a n s of the link-target a n d long-link tuples. Most or part of a tuple

4.4 CONFIGURATION

Figure 4.3

75

Use of CIS hierarchies in multifunction PC Card.

chain may reside either in attribute m e m o r y space or c o m m o n m e m o r y space. Hierarchical CIS chains were introduced with the 1995 release of CardBus and multifunction PC Cards (see Figure 4.3). For multiple functions typically there is a global CIS that points to function-specific CIS structures.

4.4.2

Changes in PCMCIA Release 2.1 The following changes have been made to the metaformat section in the PC Card standard release 199S: Added tuples to support multifunction cards Added tuples to support CardBus cards

76

INSERTIONAND CONFIGURATION ISSUES

Table 4.3

Tuples for PCMCIA PC Card standard.

TuplelD Name

14h 15h 16h 17h 18h

CISTPL_NULL CISTPL_DEVICE CISTPL_LONGLINK_CB CISTPLCONFIGCB CISTPL_CFTABLE_ ENTRY_CB CISTPL_LONGLINK_MFC CISTPL BAR CISTPL_CHECKSUM CISTPL_LONGLINK_A CISTPL_LONGLINK_C CISTPL_LINKTARGET CISTPL_NO_LINK CISTPL_VERS_I CISTPL_ALTSTR CISTPL_DEVICE_A CISTPL_JEDEC_C

19h

CISTPL_JEDEC_A

1Ah 1Bh ]Ch

CISTPL_CONFIG CISTPL_CFTABLE_ ENTRY CISTPL_DEVICE_OC

1Dh

CISTPL_DEVICEOA

1Eh 1Fh

CISTPL_DEVICEGEO CISTPL_DEVICEGEO_A

20h 21h 22h 23h 40h 41h 42h 43h

CISTPL_MANID CISTPL_FUNCID CISTPL_FUNCE CISTPL_SWIL CISTPL_VERS_2 CISTPL_FORMAT CISTPL_GEOMETRY CISTPL BYTEORDER

44h 45h 46h 47h 90h

CISTPL_DATE CISTPL_BATTERY CISTPL_ORG CISTPL_FORMAT_A CISTPL_SPCL CISTPL_END

00h 01h 02h 04h 05h

06h 07h 10h 11h 12h

13h

FFh

Use Null tuple Memory device characteristics Link CardBus tuple chains CardBus card configuration tuple Configuration resource definitions for CardBus cards Link multifunction tuple chains Base address register definition for CardBus Checksum Link to attribute memory Link to common memory Link from other tuple chains Indicates only one chain Revision level support Stores strings for different languages Attribute memory device information JEDEC identifiers for each programmable memory device type in common memory JEDEC identifiers for each programmable memory device type in attribute memory Describes configurable aspects of the card Describes the particulars of a specific configuration as implemented in the configuration index Describes common memory device information under various Vcc values Describes attribute memory device information under various Vcc values C o m m o n memory device architecture information Attribute memory-memory device architecture information Manufacturer information Type of function Function details Data interleaved Data organization information Data storage format Cylinder, heads, sectors information Little endian versus big endian byte ordering for disk partitions Card initialization date Battery information C o m m o n memory partitions Data format for attribute memory Program storage on card End of chain

4.4

CONFIGURATION

77

CIS b e c o m e s m a n d a t o r y in the PC Card s t a n d a r d 1995 release for all cards Defined C I S T P L

Defined C I S T P L

CONFIG and CISTPL FORMAT

A

CONFIG

CB

D e f i n e d C I S T P L _ S P C L , a special-purpose tuple used to s u p p o r t initial p r o g r a m load (IPL)

4.4.3 Tuple Structure All tuples are r e q u i r e d to follow the s a m e format. The first byte of a tuple is t h e tuple ID (TEL CODE), w h i c h is used to identify t h e tuple. The seco n d byte is t h e offset (TPB_BTNK) to t h e n e x t tuple. It is t h e n u m b e r of bytes in t h e tuple body, so if an offset has a value of 2 a n d is at byte 11 of t h e tuple chain, t h e n e x t tuple start is at byte 4 (1 + 2 + 1) of t h e chain. In general if the offset byte is at byte X of t h e c h a i n a n d has a value of N t h e n t h e n e x t tuple ID is at (X + N + 1). Table 4.4 shows t h e structure for a few s a m p l e tuples.

1. CIS in attribute memory is supposed to be on even bytes only. In this chapter, the CIS chain byte references do not use physical location. Rather, they use the logical order of the bytes. For example, byte 2 is the third byte in the chain but may physically be located at 00004h.

Table 4.4

Tuple structure.

Byte

Field type

Value

0

Tuple ID

01h (CIS_TPL_DEVICE)

l 2 3 4 S 6 7 8 9

Offset Data (first byte) Data (second byte) Tuple ID (of next tuple) Offset Data Data Data Tuple ID (next tuple)

02h 00h FFh 17h 3h 29h 00h FFh 1Sh

78

INSERTION AND CONFIGURATION ISSUES

4.5

KEY TUPLES

4.5.1

Overview Each of the tuples defined has intended uses. Some of which are as follows:

Configuration of Card These tuples are used to configure the card. Configuration tuple Configuration table entry tuple Base address tuple Function ID Function extension

Memory Device Characteristics These tuples are generally used by memory cards. Usually there is one for common and one for attribute memory. Device information tuple Other conditions tuple Geometry tuple JEDEC tuples

Data Format Information These tuples are used to provide data storage format information, such as partitions, file systems, and physical format. Format tuple Organization tuple Software interleave Special tuple

Tuple Chain Linking Information Long-link tuples Link-target tuples No-link tuple

General Purpose Tuples Null tuple End tuple CHECKSUM tuple Manufacturer ID tuple Battery tuple Date tuple

4.5

4.5.2

KEY TUPLES

79

Device Information Tuple (01h) The device i n f o r m a t i o n tuple is used t o describe the type of m e m o r y device being used, its speed, a n d its size at 5V. CISTPL DEVICE C describes c o m m o n m e m o r y devices, and CISTPL_DEVICE_A describes attribute m e m o r y devices. Cards that also support 3.3V operation m u s t describe the 3.3V characteristics in the CISTPL_DEVICE_OC tuples. Table 4.S shows the fields w i t h i n the data areas of the device information tuple. The data area consists of one or more device i n f o r m a t i o n fields. If a card contains more t h a n one type of m e m o r y device in a m e m o r y space, t h e n a device i n f o r m a t i o n field m u s t be provided for each type of m e m o r y device. Most cards contain a single type of m e m ory, so usually this contains only one device i n f o r m a t i o n field. Each device i n f o r m a t i o n field consists of two bytes. The first byte describes the type of m e m o r y device. The second byte describes the size of the address range occupied by this device (Table 4.6). D e v i c e Type C o d e m l n d i c a t e s type of m e m o r y device: null, read-only m e m o r y (ROM), one-time p r o g r a m m a b l e read-only m e m o r y (OP-

TROM), erasable read-only m e m o r y (EPROM), electrically erasable readonly m e m o r y (EEPROM), flash, SRAM, a n d DRAM. W P S m W r i t e P r o t e c t S w i t c h - - W h e n set to O, indicates the write protect switch (WPS), and the write protect (WP) pin controls writes to the indicated device. W h e n set to 1, indicates device is always writable. D e v i c e S p e e d ~ I n d i c a t e s worst-case speed of the device at 5V Vcc without the use of the W A I T # signal: null, 250 nsec, 200 nsec, 150 nsec, 100 nsec, or extended. The e x t e n d e d format is n o r m a l l y used if the speed granularity is between the standard speeds offered.

Table 4.5

Data fields for device information tuple.

Byte

Fields

0

01h (tuple code) Length Device information field: Device ID byte Device information field: Device size byte Device information field: Device ID byte Device information field: Device size byte Device information field: Device ID byte Device information field: Device size byte FFh (end of device information field)

1

2 3 4 S 6 7 8

80

INSERTION AND CONFIGURATION ISSUES

Table 4.6 7

Device information fields f u r t h e r broken down. 6

5 ......

4

3

Device type code

2 WPS

]1

10

Device speed

Extended device speed byte if necessary (device speed code=07h) I

Number of address units 1

Table 4.7 7

[

Size of address units

Extended byte. 6

EXT

5

4 Speed Mantissa

3

2

I1

Io

Speed Exponent

EXT,extended.

Extended byte is broken up as in Table 4.7. Extended speed is calculated by multiplying the mantissa by the exponent. For example if extended speed byte is 52h, then the device speed is 4.5 • 100 nsec = 450 nsec. The device size is calculated by multiplying the n u m b e r of address units minus I by the size field. If device size byte is OF8h then the device size is (1Fh • 512 = 15,872 bytes).

4.5.3 Other Conditions Tuple: 3.3V Characteristics (1Ch) This tuple is used in conjunction with the device information tuple to provide card characteristics for m e m o r y devices at 3.3V. The structure of this tuple is very similar to the structure for the device information tuple illustrated in Table 4.5. It contains other conditions information fields followed by a sequence of device information fields. There is one-to-one correspondence between the device information fields in the device information tuple and the device information fields in the other conditions tuple. The format of the device information field is also the same. All of the foregoing description applies to the other conditions tuple. Table 4.8 shows the structure of the other conditions information field.

4.5

KEY TUPLES

Table 4 . 8

81

O t h e r conditions i n f o r m a t i o n field.

7

6

EXT

Reserved must be set to 0

5

4

EXT

Additional bytes

3

2

Vcc used

1

0

MWAIT

EXT, extended.

Vcc used is decoded as follows" 9 9 9 9

SV operation 3.3V operation Reserved for X.XV operation Reserved for CardBus Y.YV operation

M W A I T is used to indicate whether W A I T # is supported by the PC Card. W h e n set to 1 this signal indicates the PC Card supports the WAIT# signal and timings given are for use with hosts that support WAIT#. Hosts that do not support WAIT# c a n n o t use these timings. W h e n reset to 0, this signal indicates that the PC Card does not support WAIT#, so the timings given are worst-case timings, which should be used by all hosts for operation at the voltage represented by the Vcc-used field.

Note: The device information tuple provides timings for m e m o r y devices at 5V and no W A I T # support.

4.5.4 Configuration Tuple (1Ah) The configuration tuple is used to identify the registers used to configure the cards and to provide the last configuration index (last configuration table entry tuple). This tuple must precede any configuration table entry tuples. The structure of this tuple is shown in Table 4.9. Size o f C o n f i g u r a t i o n Registers Present M a s k Field This field is used to describe the n u m b e r of bytes in another field within this t u p l e - - t h e configuration registers present mask field (CRPM). Because the size field is 4 bits wide, up to 16 bytes can be used to describe configuration registers. Because byte is used to indicate 8 registers, up to 128 configuration registers are allowed by the PC Card standard.

82

INSERTIONAND CONFIGURATION ISSUES

Table 4.9

Configuration tuple structure.

12 0

10

Tuple code Length Reserved

Size of configuration registers present mask field

Size of configuration registers base address field

Value of last configuration index Configuration register base address (1 to 4 bytes) Configuration register base address byte 1 (if necessary) Configuration register base address byte 2 (if necessary) Configuration register present mask field (up to 16 bytes) Reserved (must be set to 0) Subtuple fields The byte count is not preciseafter 5 and depends on the exact field used.

Size of C o n f i g u r a t i o n Registers Base Address Field This field is used to describe the size of the configuration registers base address field in n u m b e r of bytes. The actual n u m b e r of bytes is the value given here plus 1. Because this field is 2 bits wide, up to 4 bytes (32 bits) m a y be used to provide the base address. If the base address of the configuration registers were 8000h in attribute memory, 16 address lines would be needed to access the registers. Two bytes would be needed to provide the base address. If, however, the base address were 0080h, only 1 byte would be needed to provide the base address. Last C o n f i g u r a t i o n I n d e x Value Field This field uses the first 6 bits (bits 0-5) of the byte to indicate the last configuration index value as defined in the configuration table entry tuple. Once the host encounters this value in the configuration index of a configuration table entry tuple, it has encountered all the configuration indices. This allows up to 64 possible configurations for any given PC Card function. C o n f i g u r a t i o n Registers Base Address Field This field m a y be up to 4 bytes long, depending on where in attribute m e m o r y the first register (configuration register 0) is placed.

4.5

KEY TUPLES

83

Configuration Registers Present M a s k Field This field is used to indicate which of the configuration registers is present in the PC Card. Each bit represents the presence or absence of the corresponding registers at the appropriate address. For example, the first byte of this field describes the presence or availability of configuration registers 0 t h r o u g h 7. Configuration register 0 is expected to be at the base address, and configuration register 1 is at base address +2, and so on. In general, configuration register N is expected at base address +N • 2 (Table 4.10). S u b t u p l e Field This field is used for the subtuples. The only two subtuples defined in the PC Card standard are the list t e r m i n a t i o n subtuple 0FFh and the custom interface subtuple (CISTPL_CIF). C u s t o m I n t e r f a c e S u b t u p l e This tuple is used to define a custom card interface. Examples of customized versions of the interface would be the zoom video (ZV) port interface and the digital video board (DVB) interface. As m a n y as four custom interface subtuples are allowed. Each cust o m interface is identified with a unique interface n u m b e r field followed by a series of strings.

4.5.5 CISTPL_CFTBL_ENTRY" Configuration Table Entry Tuple (1Bh) The configuration table entry tuple is used to specify a possible configuration of the card, such as interface type, addressing, interrupts, and power consumption. It is used to specify different configurations. For cards with multiple configurations, multiple configuration table entry tuples are required. The first CFTBL_ENTRY tuple usually provides the default values for succeeding CFTBL_ENTRY tuples. So the succeeding entry

Table 4.10 Interpretation of byte 0 of configuration register present mask field. 7

6

5

4

3

2

1

0

ConfigConfigConfigConfigConfigConfigConfigConfiguration uration uration uration uration uration uration uration register 7 register 6 register 5 register 4 register 3 register 2 register 1 register0 present present present present present present present present Base adBaseadBaseadBaseadBaseadBaseadBaseadBaseaddress +14 dress +12 dress +10 dress +8 dress +6 dress +4 dress +2 dress +0

84

INSERTION AND CONFIGURATION ISSUES

tuples only provide values that differ from the default. Each entry tuple has an index value that is written to the configuration option register tO change the configuration of the card. An example of the default values is a CIS that has four configuration table entry tuples. The first CFTBL_ENTRY tuple provides the configuration index, interface description, feature selection, nominal voltage, average current, input and output (I/O) space descriptor, and interrupt request (IRQ) descriptors. It also sets the default bit in the index byte. The second, third, and fourth CFTBL_ENTRY tuples do not set the default bit. They provide a feature selection byte, an I/O descriptor, and an IRQ descriptor. This means that the interface, nominal voltage, and average current are taken as default from the CFTBL ENTRYtuple and remain constant for each configuration of the PC Card. Table 4.11 shows the four CFTBL_ENTRY tuples and their fields. Table 4.12 provides the basic structure of the configuration table entry tuple.

4.5.5.1

Configuration Table Index Byte

This is the first data byte in the tuple; it consists of the following fields:

Intface W h e n set indicates that the interface description byte follows

Default W h e n set indicates that this entry tuple contains default values for all the entry tuples that follow. If clear (0), this entry tuple does not provide the default values; instead the default values are prescribed by the last entry tuple encountered with its default bit set.

Table 4.11

Example of default bit usage.

1st CFTBL_ENTRY tup le

2rid CFTBL_ENTRY tup le

3rd CFTBL_ENTRY tup le

4th CFTBL_ENTRY tup le

Index byte with default bit set Interface descriptor

Index byte with default bit not set Feature selection byte I/O descriptor

Index byte with default bit not set Feature selection byte I/O descriptor

Index byte with default bit not set Feature selection byte I/O descriptor

IRQ descriptor

IRQ descriptor

IRQ descriptor

Feature selection byte Power description nominal voltage Power description average current I/O descriptor IRQ descriptor

4.5

KEY TUPLES

Table 4.12

85

Configuration table entry tuple.

Byte

. Byte name

.7

0

. Tuple code

. (1Bh)

16

14

Length

~Length

Configuration table index

Intface

Interface description

MWAH READY BVDs reactive active . quired

. Feature selection

Miscellan-

13

12

I1

Io

Configuration entry number Interface type

Memory space IRQ

I/O space

Timing Power

Power descrip- RFU tion: First pa(0) irameter selected

Power Peak I AvgI down

StaticI Max V Min V Nom V

Power descrip- EXT tion: First parameter defined

Mantissa

Power descripEXT tion: First parameter defined (EXT byte)

Extension (if necessary)

eous

1

L

Exponent

Power descrip- See bytes S through 7 tion: Next parameter defined Power descrip- See bytes 5 through 7 tion: Last parameter defined, k k+l

Configuration .timing

.WAIT# timing

Reserved scale 7

READY scale

WAIT scale

.In extended device speed code format (optional)

k+2

READY# timing

.In extended device speed code format (optional)

m

I/O space description

i Range Bus 16/8 i

m+2

I/O space-range L e n g t h description byte optional .

m+3

Start address

I/O Address lines

Size of address Number of I/O address ranges specified in (n-l)

May be 0,1,2, or 4 bytes long

m+3+ ,Length of range ,May be 0,1,2, or 4 bytes long Interrupt .request

Share i

Pulse

Level

Mask

IRQN Lines 0-15 VEND, BERR, IOCK, NMI (continued)

86

INSERTIONAND CONFIGURATION ISSUES

Table 4.12 (continued) Byte

, Byte n a m e

7

6

5

4

3

2

1

n+l

Interrupt, re'quest second .byte optional

IRQ7

IRQ6

IRQ5

IRG4

IRQ3

IRQ2

I R Q 1 IRQ0

n+2

Interrupt request third ,byte optional

IRQ15 IRQ14 IRQ13 IRQ12 IRQ11 IRQ10 IRQ9 IRQ8

Memory space

Host Card address address size

Memory space , (0-3 bytes)

Length value

p+2 Memory space or p+4 card address , (0-3 bytes)

Length value

p+2 Memory space or p+7 host address ,.(0 to 3 bytes)

Host address

p+l

|

Miscellaneous features

~RFU(0) Power Read down only

!Miscellaneous features

RFU (0)

RFU (0)

Subtuple

Subtuple code

0

Length

Number of windows

Audio

Maximum twin cards

DMA DMA request signal width

RFU (0)

RFU (0)

Subtuple length Subtuple data Next subtuple BVD,battery voltage detect; RFU,reservedfor future use.

Configuration Entry N u m b e r This is the index value written to the configuration option register (FCR0). W h e n this value is written to FCR0, the card is in the configured state described by this entry tuple.

4.5.5.2

Interface Description Byte

This is an optional byte available only if the interface bit is set in the preceding byte. It provides the specifics on the card interface. It consists of the following fields:

4.5

KEY TUPLES

87

9 I n t e r f a c e T y p e Type of interface used Oh -- m e m o r y , 0 1 h - I/O, 0 2 h a n d 0 3 h reserved 9 BVD1-2 BVD1 a n d BVD2 are available in this m o d e either from the bus or in the p i n - r e p l a c e m e n t register 9 W P Active Write protect status available a n d s h o u l d be recovered from either the WP pin or pin r e p l a c e m e n t register 9 READY Active READY status is available from either the READY# pin or the pin r e p l a c e m e n t register 9 ~ A T T R e q d WAIT# signal s u p p o r t e d for m e m o r y accesses

4.5.5.3

Feature S e l e c t i o n Byte

This byte is used to indicate the features described in the structures (a seq u e n c e of bytes w h i c h t o g e t h e r describe a specific feature) t h a t follow. The features t h a t can be described are Vcc, Vpp, timing, I/O space, IRQ, m e m o r y space, a n d miscellaneous. The individual features are described in section 4.5.5.4.

4.5.5.4

Feature D e s c r i p t i o n Structures

Each feature description structure is a s e q u e n c e of bytes t h a t describes the specific feature. The n u m b e r of bytes in each structure varies a n d dep e n d s o n the feature b e i n g described.

4.5.5.4.1

Power Description Structure

The p o w e r description structure is a s e q u e n c e of bytes t h a t describes the various c u r r e n t or voltage characteristics. The Config Table Entry tuple can c o n t a i n up to seven p o w e r description structures, o n e for each of the p a r a m e t e r s defined in the selection byte. The format of the p o w e r description structure is p r e s e n t e d in Table 4.13.

Table 4 . 1 3

Power description structure f o r m a t .

Byte

7

Power parameter selection byte

RFU (0) PrDwn I

Parameter definition byte

6

EXT

Extension byte RFU, reserved for future use.

5

4

3

Peak I

Avg I

Static I MaxV

Mantissa Extension byte

2

1

0

MinV

NomV

Exponent

88

INSERTION AND CONFIGURATION ISSUES

The first byte of the power description structure is the selection byte. It indicates the parameter the value of w h i c h is being defined. The seco n d a n d third bytes are used to define the value of parameters indicated in the selection byte (parameter definition). The third byte is the extension byte. There m a y be multiple p a r a m e t e r definitions after a selection byte. The order of the definition bytes depends on the bits set w i t h i n the selection byte. The order is lsb first to msb last. The values are given in Table 4.14. For example, if the power definition byte is 73h t h e n the value is 800 ~A or 80 mV (8 • 100 ~tA or 8 x 10 mV). The extension byte is used to describe the next two decimal digits to the right of the value defined in the definition byte. The range is 0 to 99. 4.5.5.4.2

Timing Description Structure

The t i m i n g structure is used to define the duration of READY#, a n d WAIT# timing. The first byte in this structure defines the scale (power of 10) factor to be applied to the WAIT# or READY# timing. The second byte is READY# timing, the third byte is optional a n d indicates the WAIT# timing.

Table 4.14

Power description structure values.

Mantissa

Value

Exponent

Value current

Value voltage

0 1 2 3 4 5 6 7 8 9 Ah Bh Ch Dh Eh Fh

1 1.2 1.3 1.5 2 2.5 3 3.5 4 4.5 5 5.5 6 6.5 7 8 9

0

100 nA

1

1 t~A

2 3 4 5 6 7

10 IIA 100 lxA 1 mA 10mA 100 mA 1A

10/~V 100 ~tV 1 mV 10 mV 100 mV 1V 10 V 100 V

4.5

KEY TUPLES

89

4.5.5.4.3 I/0 Space Description Structure This structure is used to define the host I/O space and decoding required (if necessary) by the card. This structure consists of an I/O description byte and one or more I/O address range descriptors. The I/O space description byte indicates whether the card implements an address decode or if the host is responsible for providing the correct address. It also indicates how m a n y I/O ports the card supports and the bus size used by the card. The field of interest is the IOAddrLine field, as follows: 9 If set to 0, a range must be specified, the card responds to all I/O addresses presented by the host. The host is required to use the range descriptor to map the card into its I/O space. 9 If set to a non-0 value less than 26, the card performs address decoding and requires the host to provide the valid address. 9 If set to 10, the card is compatible with the 1KB address space defined in the ISA architecture. The I/O range descriptor provides start and the size of the I/O ranges used by the card. The host must ensure that cE# is asserted to the card's socket w h e n an I/O address within the I/O range is generated.

4.5.5.4.4 Interrupt Descriptor Structure This is used to define the interrupt line used by the card for the configuration defined in this entry tuple. A card may use any one or more of the IRQ lines 0 through 15. The mask bit indicates if more t h a n one IRQ line is specified in this configuration. This structure also indicates the type of interrupt the card may generate: shared, level-triggered, or pulsetriggered. W h e n the mask bit is set, the host can use IRQ lines specified in the second and third bytes as well as in IRQN lines field. W h e n the mask bit is cleared, the host must use only the IRQ line specified in the IRQN lines field.

4.5.5.4.5 Memory Space Descriptor Structure This descriptor is used to indicate that the card has configurable comm o n m e m o r y space that must be m a p p e d into the host space. The mapping can be done either with or w i t h o u t translation. The host must generate a cycle to the card when the specified address is generated. This structure defines the following:

90

INSERTIONAND CONFIGURATION ISSUES 9 9 9 9

N u m b e r of m e m o r y windows Size of m e m o r y window Translation allowed If translation is allowed, the host address and the corresponding card address 9 If no translation is allowed, only the card address

4.5.5.4.6 Miscellaneous Features Descriptor This structure describes whether the card supports a power d o w n mode, audio, DMA, DMA request line used (if DMA is supported), DMA bus width (if DMA is supported), read-only, or twin cards. The m a x i m u m twin cards field indicates the m a x i m u m n u m b e r of identical cards that m a y be configured identically to this card. This allows more t h a n one card in a host to share a set of I/O addresses. The host allows the cards to differentiate a m o n g themselves by writing the copy n u m b e r to the copy fields in the socket and copy register of the card. The subtuple structure allows subtuples to be added to this tuple. The subtuples are used to specify the environments for which this particular configuration is intended, such as operating system (OS) and host.

4.5.6 Function ID Tuple This tuple is used to identify the type of function used by the card. Table 4.15 shows the functions defined in the standard.

4.5.7 Function Extension Tuple (22h) This tuple is used to provide the details of a specific function. These exist for fax/modem cards, fixed disks, and local area networks (LANs). For f a x / m o d e m s it describes the following: 9 The serial port interface used to c o m m u n i c a t e with the m o d e m : type of serial port (UART), bits per character, n u m b e r of stop bits, and the type of parity 9 Characteristics of the m o d e m interface: flow control methods, size of c o m m a n d buffers, bit rate, modulation standards, error detection and correction protocols, data compression, data encryption, comm a n d protocols, and country codes 9 Capabilities of the fax: bit rate, ITU modulation standards, data encryption, fax features and country codes

4.5

KEY TUPLES

91

Table 4.15 Types of functions specified in the standard. Code

Function name

0 1 2 3 4 5 6 7 8 09-Fdh FEh FFh

Multifunction Memory Serial port Parallel port Fixed disk Video adapter Network adapter AIMS SCSI Reserved Vendor specific Invalid code

AIMS,auto-indexing mass storage.

9 Voice data capabilities: data rate, pulse code m o d u l a t i o n (PCM) encoding, list of sample rates, sample sizes, EIA/TIA compression methods For fixed disks it describes the following: Interface type: currently only PC Card ATA is supported PC Card ATA capabilities: Vpp requirements, media type, dual drive support, sleep, standby, auto power m a n a g e m e n t , register inhibit capabilities, and index bit emulation and IOIS16# behavior in twin card mode For LAN cards it describes the following: 9 Technology type: Ethernet, Token Ring, Arcnet, Local Talk, fiber distributed data interchange (FDDI), asynchronous transfer mode (ATM), or wireless. 9 Raw bit rate: 10 Mbit/sec, 16 Mbit/sec, 100 Mbit/sec 9 LAN media: unshielded twisted pair, shielded twisted pair, coaxial, fiber, spread spectrum 902 to 928 MHz, spread spectrum 2.4 Hz, spread spectrum 5.4 Hz, infrared, or point-to-point infra red 9 LAN connector type

92

INSERTION AND CONFIGURATION ISSUES

Table 4.16 tuple. Byte

7

Structure of version and product information 6

5

4

3

2

1

0

Tuple code (15h) Length Major version number Minor version number Product information strings Name of manufacturer, terminated by null (O0h) Name of product, terminated by null (0Oh) Additional product information, terminated by null Additional product information, terminated by null FFh (marks end of data)

4.5.8 Version and Product Information Tuple (15h) This tuple describes version compliance and product manufacturer information. The structure of this tuple is given in Table 4.16.

4.6

SUPPORTING MULTIPLE TUPLE CHAINS The 1995 release of the PC Card standard supports multiple tuple chains c o m b i n e d to form one CIS. These multiple chains are linked together with link tuples. These multiple tuples are needed for the following: 9 Multifunction PC Cards to point to the function-specific CIS 9 To provide a complete CIS w h e n attribute m e m o r y space is no longer sufficient 9 In m e m o r y cards to add format and Org tuples to form partitions 9 In CardBus cards to go from configuration space to m e m o r y space The default link defined in the standard is from attribute m e m o r y to address 00h of c o m m o n memory. The default link can be overridden with a specific long-link tuple or a no-link tuple (if no additional chains are implemented). In multiple tuple chains there is a primary tuple chain, which starts at address 0 of attribute memory. The secondary tuple chain is identified with a long-link tuple. The next tuple chain m a y be identified with another long-link tuple. Figure 4.4 shows examples of tuple chains.

4.6

SUPPORTING MULTIPLF TUPLE CHAINS

Figure 4.4 Examples of tuple chains.

93

94

INSERTIONAND CONFIGURATION ISSUES

The four long-link tuples are defined as follows" 1. C I S T P L

LONGLINK

A

3. C I S T P L

LONGLINK

MFC

2. C I S T P L

4. C I S T P L

LONGLINK LONGLINK

C

CB

A long-link tuple is used to jump beyond the 256-byte limit of the link field in any tuple. CardBus PC Cards are restricted to the CISTPL LONGLINK_CB tuple. 16-Bit PC Cards are restricted to the CISTPL_LONGLINq<_A, C I S T P L _ L O N G L I N K _ C ,

and CISTPL_LONGLINK_MFC

tuples. A long-link tuple provides a 4-byte address that allows the next tuple chain to be placed anywhere in either m e m o r y space. To save attribute memory, it is assumed that every primary tuple chain has a link to a new tuple chain starting at address 00h in c o m m o n memory. If this is not the case, either a new link location must be specified by means of a long-link tuple or the absence of other chains must be indicated by means of a no-link tuple.

4.7

INTERPRETING TUPLES The main purpose of the CIS is to provide information about the devices, capabilities, compatibility, and resource requirements of the card for a particular configuration. The first thing a utility that parses the CIS must do is determine compatibility (power c o n s u m p t i o n of the card, voltage requirements, interface type, and version support). If the utility determines that the card is compatible with the host, the parser must determine configuration resource requirements. The parser does this by determining the base address for the configuration registers, the n u m b e r of configuration registers, the type of decode needed, address space needed within the host, for I/O cards the interrupt line required, and use of other status conditions such as READY#, battery voltage detection (BVD1 and BVD2), and write protect. For m e m o r y cards, the parser may also have to understand the geometry, the programming information, and the device architecture. The parser must also understand whether the card is a multifunction card or a single-function card. If the card is multifunction, the parser must determine the types of functions present and their base addresses and capabilities. Figure 4.5 provides a parser algorithm.

4.7 INTERPRETINGTUPLES Figure 4.5

95

Example of a parser algorithm.

Determine Card InterfaceType

Determine Current Requirements

Yes

No

Turn Vcc Off

If Memory Card Get Type of Memory (Device Info) Device Speed Device Type (JEDEC)

If I/O Card, Get Function Type (Function ID) Function Specific information (Function Ext)

If Configurable card, Get Base Address for CCR Memory and I/O Adddress Space and Interrupts. Configure Host and card

~--

stop

>

96

INSERTIONAND CONFIGURATION ISSUES

4.8

ClS STRUCTURE The first tuple in a CIS is required to be the device information tuple. After that depending on the type of card different tuples are implemented. If a card is configurable, the configuration tuple and the configuration entry table tuple are required. It is also strongly r e c o m m e n d e d that an end tuple be i m p l e m e n t e d at the end of the chain to indicate the end of the CIS. If only a single tuple chain is implemented, then a no-link tuple must be part of the tuple chain. Table 4.17 provides tuple requirements for various types of PC Cards.

Table 4.17

Sample CIS for different types of PC Cards. Fax~modem Lan wireless

Multifunction (primary CIS)

Device information

Device information (null device)

Device information (null Device)

Other conditions

Other conditions

VERS_I

VERS_I

JEDEC

JEDEC

CardBus

Memory

ATA

Other conditions (Device Info not required) BAR

Device information

VERS

1

Manufacturer ID Configuration (CB version) CFTBL_ENTRY_CB CFTBL_ENTRY_CB

CFTBL_ENTRY_CB No-link (ifone chain) End

Manufacturer ID Manufacturer ID Function ID VERS_I VERS_I Function extension Manufacturer ID Function ID Configuration Device GEO

LongLink (if second chain present) End

BAR,base address registers.

Manufacturer ID L ongL i nk_MF C Function ID

Configuration tuple

Function

c FTBL_ENTRY

CFTBL_Entry

Configuration Configuration table entry Configuration table entry Configuration table entry Configuration table entry Configuration table entry No-link End

CFTBL_ENTRY CFTBL_ENTRY

CFTBL_Entry CFTBL_Entry

CFTBL_ENTRY

End

extension

No-link End

4.9 SAMPLECIS PARSING ROUTINES

97

The Mobile Media CIS Generator is a useful tool for experimenting with a CIS. It takes away the painful binary conversion process and includes the m i n i m u m CIS recommended for tuples. Mobile Media may be contacted at 1-800-799-MMRI.

4.9

S A M P L E ClS P A R S I N G R O U T I N E S Following is a sample of a CIS parsing routine. It was written to work with an Intel 365SL or compatible PCMCIA controller. It reads the CIS and identifies the tuple and displays the tuple data.

#include #include #include #include

<stdlib.h> <stdio.h>

struct TupTyp tupbuf[MaxTup]; char _ f a r *cisptr; int int

ChkPcic SetPcic

(); ();

int int

RdPcicReg WrPcicReg

int int

OpenIoWind(int C h k C a r d ();

int

RdTuple

int

(int (int

OpMemWind(int

/* Uses /* Uses

HostIOSt,int

TupTyp

*pp);

v o i d m a i n () { int s t a t u s :O,k:O, m e m w a : O x d O 0 0 , s t r u c t T u p T y p *tp; u n i o n cisu{ long x; char _far *cisp; } Acis; Acis.x=0xd0000000; tp:&tupbuf[0]; status if

: ChkPcic

(status

printf

();

== Pbase)

( "PCIC

and Socket# and S o c k e t #

from G S k t P a r a m from G S k t P a r a m

*/ */

indx); /* Uses Base and S o c k e t # from G S k t P a r a m */ indx, int d a t a b y t e ) ; / * Uses Base and S o c k e t # from G S k t P a r a m */

StartAddr,int

(struct

Base Base

{

Present

s t a t u s :0; s t a t u s = C h k C a r d (); if (status == 0xff) {

at:

WindSiz,int

WiNum, int WType);

H o s t I O S t p , i n t WiNum); /* uses skt # d e f i n e d c a r d d e t e c t s */

in G S k t P a r a m

to c h e c k

for

-- w h e r e

tuples

i=O;

/* I n i t i a l i z a t i o n code */ /* sets b a s e a d d r e s s at d O 0 0 : O */ /* sets p o i n t e r to start of t u p b u f are s t o r e d */

%X\n",PBase);

p r i n t f ("\a PC C a r d Present"); s t a t u s = S e t P c i c (); status : OpMemWind(memwa,0x04,0x0,AMem); cisptr=Acis.cisp; s t a t u s =0;

98

INSERTION AND CONFIGURATION ISSUES

while ((status= RdTuple (tp)) != EndOfCis) { if (status=Valid){ printf ("tuple id = %x\t tuple name = %s \n",tp->id, tp->tpnam); printf ("tuple data = "); i=0; k=tp->len; while (k>0) { printf("%2x, ",tp->data[i++]); --k; } /* end while */ p r i n t f ("\n"); tp++; /* increment pointer to next element next tuple */ }/* end if */ else if (status == invalid) { p r i n t f ("error: Invalid Tuple Id %X", (*tp).id); break;

in tupbuf

}

} /* end while */ } /* end if status ==ff */ else { printf ("No PC Card inserted in socket %u \a", GSktParam. SocketNum); goto ErrorH; } /* end else*/ } /* end if */ else p r i n t f ("PCIC not present, p r o g r a m not executed"); ErrorH: exit (0); } /* end main */

/*ChkPcic reads register 0 at socket, it returns 0 if no socket, it returns int ChkPcic () { int n; int c=0; n=GSktParam. SocketNum*0x40; c = R d P c i c R e g (n);

if

}

Ic==ox82

II c==0x83

assumes base address is 3e0 Base Address if socket present

*/

II c==0x~4)

return GSktParam. BaseAddr; else return 0x0;

/* RdPcicReg: F u n c t i o n Reads PCIC register at index and socket defined by G s k t p a r a m and returns a byte w h i c h is the data ******/ R d P c i c R e g (int indx) { int int i=0; i=_outp(GSktParam. BaseAddr, (indx+0x40*GSktParam. SocketNum)); i=_inp ((GSktParam. BaseAddr+l)); return i;

}

/* W r i t e s to PCIC Reg. specified by indx and writes value specified by d a t a b y t e , returns value read from the register it writes to*/ int W r P c i c R e g (int indx, int databyte) {

for

4.9

SAMPLE CIS PARSING ROUTINES

99

int i=0; _ o u t p ( G S k t P a r a m . BaseAddr, (indx+0x40*GSktParam. SocketNum)); _ o u t p ((GSktParam. B a s e A d d r + l ) , d a t a b y t e ) ; i=_inp (GSktParam. BaseAddr+l); r e t u r n i; }

/* Sets Enables

PCIC to M e m o r y mode, Enable outputs, Power, sets Vpp, D i s a b l e s interrupts

int S e t P cic () { int i=0, m=0; i=WrPcicReg

i=WrPcicReg

i=WrPcicReg i=WrPcicReg

return }

i;

issues */

(PwrCtl,0x80);

/* Enable

(IntGenCtl,0x00); (IntGenCtl,0x40);

/* set card

(PwrCtl,0xB0);

/* Enable

Reset

Outputs

Vcc,

/* deassert

Put

*/

into auto mode

to m e m o r y mode,

reset

issue

*/

disable reset

*/

Vpp

*/

/**This Func. reads from s o c k e t / b a s e d e f i n e d by GSkt Param */ /** C h e c k s for C a r d D e t e c t s and returns a 1 if no card p r e s e n t */ /** or r e turns an FFh if card present*/ int C h k C a r d () { int i,indx,n; indx = GSktParam. S o c k e t N u m * 0 x 4 0 + 0x01; n = R d P c i c R e g (indx); if

((n&0x0c)==0x0c) i=0xff;

else i=0x01; r e t u r n i;

/** This f u n c t i o n sets up mem. w i n d o w regs., W i n d S i z is size of w i n d o w in Kbytes, must be m u l t i p l e

int OpMemWind(int StartAddr,int int t = 0 , n = 0 x 0 1 , p = 0 , i=0; int i n d x = 0 , o f f s e t = 0 , stop=0; char io = 0 , h i = 0 , t m p = 0 ;

WindSiz,int

StartAddr

must

be on a 64K boundary.

of 4**/

WiNum, int Wtype)

indx= W i N u m * 0 x 0 8 + 0 x l 0 ;

/* start

i=WrPcicReg(++indx,t);

/* write 00h to start h i g h byte. 8-bit */

t= S t a r t A d d r / 0 x l 0 0 ; i = W r P c i c R e g ( i n d x , t); t=0;

address

{

of m e m o r y

window

registers

/* d e t e r m i n e the v a l u e of the start low byte /* write A19-12 to Start low byte */ sets

6clk cycle,

stop=(StartAddr/0xl00)+(WindSiz*0x400)/0xl000; /* divide by 4K to get the ist digit io = stop ; /* Get low byte of Stop */ i = W r P c i c R e g ( + + i n d x , lo); /* Write to Low reg c h e c k v a l u e * / i = W r P c i c R e g ( + + i n d x , 0xC0); /* Write to Stop hi reg */ offset = (StartAddr/0xl00) +0x01; /* c a l c u l a t i n g the offset v a l u e s */ p=offset; Io = p ; i = W r P c i c R e g ( + + i n d x , lo);

/* C a l c u l a t i n g low byte */ /* w r i t i n g offset low byte */

*/

*/

*/

100 if

INSERTION AND CONFIGURATION ISSUES

(WType == Amem) hi=0x7f;

/* Set Reg

else hi = 0x3f;

i=WrPcicReg(++indx,hi); t=(n<<WiNum); i = W r P c i c R e g (AddrWinEn,t); r e t u r n i;

/** This function value **/

uses

if A t t r i b

Mem

*/

/*Write hi offset bit */ /* Adr W i n d o w s Enable m a s k */ /* enable approp m e m w i n d o w */

the tp p o i n t e r

and cisptr

to read a tuple

/** it checks the value of the tuple id against the t u p l e t a b l e the f o l l o w i n g v a l u e s on status: V a l i d = if tuple v a l i d Endof CIS = if no more tuples after this one; i n v a l i d = if tuple not v a l i d **/ int R d T u p l e (struct T u p T y p *pp) ( int x = 0 , y = 0 , n = 0 , match; (*pp).id = *cisptr; if (pp->id != EndTuple) c i s p t r +=2; (*pp).len=*cisptr; n=(*pp).len;

*/

while

((n>0)

&&

{

(pp->len

!=0xff))

cisptr+=2;

)

) cisptr

/* end whil e +=2;

{

/* read data

if

for ( n = 0 ; n < = ( n a m s t r l e n - l ) ; n + + ) pp->tpnam[n]=tuptab[y].tn[n]; m a t c h = true; break; for

((pp->id

*/

== EndTuple) ll(pp->len==0xff))

function

rdtuple

*/

for v a l i d

and put

into

tupbuf

*/

id */

/* just copy string

else if (match == true) return Valid; else if (match == false ) r e t u r n invalid; } /* end

of tuple

only

*/

= false; /* s e a r c h for ( y = 0 ; ( ( y < = 3 6 ) & & ( m a t c h != true));y++){ if (pp->id == t u p t a b [ y ] . i d ) (

)

and r e t u r n s

/* increment by two to rd next byte /* put data into b u f f e r */

match

) /* end

table

a

/* read id byte p o i n t e d at by cisptr */ /*skip odd bytes, A t t r b m e m is even bytes

pp->data[x++]=*cisptr; --n;

and r e t u r n

return

in to t u p b u f . n a m e

EndOfCis;

/* check

cis

*/

*/

for end of

*/

4.10

CONFIGURING 16-BIT PC CARD

101

4.10 CONFIGURING 16-BIT PC CARD PCMCIA in its previous release, version 2.0, defined a standard set of registers, card configuration registers (CCR), for configuring a PC Card and managing certain PCMCIA-specific events. PC Card standard release 1995 adds an additional register to manage certain I/O events. To configure a 16-bit PC Card, the host must first parse the CIS to determine if the CCR are present and if they are how m a n y of the CCR are implemented. Then it must determine the base address for the CCR in the address space of the PC Card. All this information can be extracted from the configuration tuple. The host must determine the possible configurations and their implications (this is done with the configuration entry table tuples). Then the host selects one configuration and writes that to the CCR and configures the host controller to allocate the proper resources.

4.10.1

16-bit PC Card Configuration Registers

16-bit PC Cards that are configurable are required to i m p l e m e n t at least the first configuration register (the configuration option register); the other four CCRs are optional. For PC Cards that are not configurable, CCRs are optional. The CCRs have been renamed function configuration registers in the 1995 release of the standard. In the rest of this book, the terms CCR and FCR are used interchangeably. Table 4.18 shows the different CCRs and their relative offsets. The CCRs must be placed in attribute m e m o r y space. In general they are located at an address space immediately following the end of the CIS. Popular addresses are 100h, 200h, and 4000h. For multifunction cards, the standard specifies additional registers. These registers are described in chapter 5.

4.10.2 Configuration Option Register This register must be implemented by any configurable 16-bit PC Card. It is a read-write register and is located at offset Oh relative to the base address described by the TPCC_RADR field in the configuration tuple. Table 4.19 describes the individual bits. The Configuration Option Register takes the configuration index written by the host to bits 0-5 and enables appropriate decoders. Typically the host reads the configuration index from the configuration table entry tuple (see Table 4.12).

102

INSERTIONAND CONFIGURATION ISSUES

Table 4.18

Card configuration registers for 16-bit PC Card.

CE1 #

REG #

Address

offset

Register name

Comments

L

L

XXXO

L

L

XXX2

Used to write configuration index Status and control of card

L

L

XXX4

Configuration option register Configuration and status register Pin replacement register

L

L

XXX6

Socket and copy register

L

L

XXX8

Extended status register

Use to provide status of signals, such as BVD1 and BVD2, which are not available in the I/O-memory mode. Used to differentiate two identical cards in a host Changes the state of certain events that can affect STSCHG#

Table 4.19

16-bit PC Card configuration registers. 5

SRESET

CBVD2

IOis8

Reserved Copy number Event 3

Event 2

Reserved Audio

CREADY CWProt

Event 1

Re,~ister

3

LevelIRQ Configuration index as defined by card vendor

Changed SigChg

CBVD1

4

RBVD1

Enable IREQ#

Enable base/ limit

Function Configenable uration option

PwrDwn

Intr

IntAck

RBVD2

RREADY RWProt

Socket number

Configuration and status Pin replacement

Socket and copy

Req Attn Enable 3 Enable 2 Enable 1 Request Extended attention status enabled

4.10

CONFIGURING 16-BIT PC CARD

103

F u n c t i o n E n a b l e m T h i s bit w h e n set enables the card (or function in case of multifunction cards). W h e n cleared it disables the card (or function for multifunction cards). E n a b l e B a s e / L i m i t Register~This bit has been redefined for multifunction use. For PC Cards such as multifunction cards that use base and limit registers, it allows them to qualify all addresses by means of the base and limit registers before presenting the address to the function. In single function cards, I/O base and limit usually are not implemented, and therefore addresses cannot be qualified. However, a single function card may still i m p l e m e n t base and limit registers to allow for a soft decode as opposed to a hard decode in hardware. This also is usually used to generate a chip select. Enable XR~.Q#-If the function is enabled and this bit is set, the interrupt from the function is passed through to the ZREQ# line. If this bit is cleared, the interrupt is not passed through to the ZREQ# line. C o n f i g u r a t i o n I n d e x ~ T h i s is the configuration value that sets the card to the configuration described in the corresponding configuration table entry tuple. The values are vendor specific. Level I R Q ~ T h i s bit w h e n set forces IREQ# to be level-triggered. W h e n this bit is cleared, the PC Card generates pulse on the IREQ# line. SResetmThis bit w h e n set forces reset of the card or function. This reset is equivalent to a hard reset except this bit is not cleared. This bit is cleared only w h e n the host writes an explicit 0 to this bit in the register.

4.10.3

Configuration and Status Register

This is an optional register used to control and acquire status over the card. It is a read-write register and is located at offset 02h. I n t A c k P r o t o c o l m T h i s bit affects the interrupt acknowledge protocol used with multifunction PC Cards. If the bit is set to 1, the host must clear the Intr bit to indicate that a new interrupt request may be issued. If cleared, this bit indicates that the Intr bit indicates the status of the interrupt request. I n t r m T h i s bit is used to indicate the status of the interrupt request from a function. It is set to 1 when the function is requesting service. It is cleared w h e n the IntAck bit is 0 and no interrupt request is pending. If the IntAck bit is set to 1, it must be explicitly cleared by the host.

104

INSERTIONAND CONFIGURATION ISSUES

P w r D w n - - T h i s bit is used to put a card or function into the powerd o w n state (if available). W h e n set, the function is expected to power down. It m u s t be cleared before the function is accessed. A u d i o - - T h i s bit is set to 1 to enable audio on the SPKR# line. IOis8---This bit is set by the host to indicate t h a t all I/O accesses occur as 8-bits only; 16-bit accesses are broken into two 8-bit accesses. S i g C h g ~ T h i s bit is used to enable STSCHG# transitions. W h e n set, it enables S T S C H G # to change. C h a n g e d - - T h i s bit is valid w h e n a pin r e p l a c e m e n t register is present a n d the PC Card is in the I / O - M e m o r y interface mode. It is set w h e n o n e or more of the status bits in the pin r e p l a c e m e n t register transitions or an enabled e x t e n d e d status event bit is set to 1.

4.10.4 Pin Replacement Register The pin r e p l a c e m e n t register is used to indicate status a n d transition status on the event signals, such as BVD 1-2, WP, a n d READY, t h a t are n o t available w h e n the bus is in the I / O - M e m o r y mode. It is an optional register a n d is required to be i m p l e m e n t e d only if the card needs to provide i n f o r m a t i o n on READY, WP, or BVD1-2 in the I / O - M e m o r y mode. R W P r o t - - T h i s bit indicates the state of the logical equivalent of the WP pin. It provides the status of the WP switch. RREADY--This bit indicates the logical equivalent of the READY pin. RBVD1, R B V D 2 ~ T h e s e two bits indicate the logical equivalents of the BVD 1-2 pins. C W P r o t ~ T h i s bit w h e n set indicates a transition on RWProt bit. CREADY--This bit w h e n set indicates a transition on RREADY bit. CBVD1, C B V D 2 ~ T h e s e bits w h e n set indicate a transition on the RBVD1 a n d RBVD2 bits.

4.10.5 Socket and Copy Register The socket a n d copy register is an optional general purpose register t h a t can be used to identify two or more of the same PC Cards installed in the host. At present the only identified use of this register has been with the PC Card ATA cards in twin-card mode.

4.11

CONFIGURING CARDBUS CARDS

105

Socket N u m b e r m T h i s field is used to indicate the socket n u m b e r in w h i c h the card is installed. The c o n v e n t i o n used is the n-1 scheme. C o p y N u m b e r ~ T h i s field is used to indicate that the current PC Card is the nth card configured with the same index. The n u m b e r i n g conv e n t i o n used is n-1.

4.10.6

Extended Status Register

The extended status register is an optional register added in the 1995 release of the standard. As defined, it allows various events to affect the S T S C H G # pin.

Req A t t n - - T h i s bit is set within 1 msec of the start of the ring indication cycle. It m a y also be used to indicate a n o t h e r card-specific event. Req A t t n E n a b l e m T h i s bit w h e n set enables Req Attn to affect the changed bit in the configuration status register.

4.11

CONFIGURING CARDBUS CARDS The CardBus insertion and configuration issues are similar to the 16-bit PC Card issues; however, the m e c h a n i s m for configuration is different. The insertion interface hardware issues and m e c h a n i s m s are the same as those described in section 4.2. Each CardBus-capable socket has to be able to differentiate a CardBus card from a 16-bit PC Card. So CardBus has defined a m e c h a n i s m m t o g g l i n g CVSl or CVS2 and watching if CCDI# or CCD2# togglemto detect a CardBus card. The only difference is in the value of the average power-up current. A CardBus card is required to consume no more t h a n 70 mA of average current before configuration. CardBus cards also are required to use a CIS to describe their resource and configuration requirements. Tuples CISTPL_CFTABLE_ENTRY_CB, CISTPL_CONFIG_CB, a n d CISTPL_BAR, are defined specifically for CardBus configurations. However, instead of an attribute m e m o r y space, CardBus uses a configuration space. Access to the configuration space is i m p l e m e n t e d by means of special CardBus cycles k n o w n as configuration cycles. The actual configuration registers used by CardBus cards are different from the configuration registers used in 16-bit PC Cards. CardBus uses a set of registers collectively k n o w n as the Configuration Header. The Configuration Header is used to configure and control the CardBus cards. CardBus also i m p l e m e n t s four event registers to support CSTSCHG interrupt. These registers are located in the m e m o r y space and

106

INSERTIONAND CONFIGURATION ISSUES

are located by means of the CISTPL_CONFIG_CB tuple. These event registers are used to generate and control C S T S C H G interrupts. Figure 4.6 shows the various CardBus registers and address space m a p p i n g mechanisms.

4.11.1

CardBus Address Space Mapping Mechanisms

A CardBus card m a y contain one to eight functions per card. Each function m a y m a p its physical m e m o r y or I/O ports into the I/O space or m e m o r y space of the host. Each function is required to i m p l e m e n t a configuration space and the event registers.

Figure 4.6

CardBus mapping overview.

4.11

CONFIGURING CARDBUS CARDS

107

Mapping is i m p l e m e n t e d with a c o m b i n a t i o n of base address registers (BARs) and BAR tuples. The BARs define the start of the address range. The BAR tuple defines the size and type of the address space. The CFTABLE_ENTRY_CB tuple also defines the BAR for a particular configuration. The CardBus address space is a directly mapped, uniform 32-bit address space. No translation is required between a CardBus host address and a CardBus card address. Any address in the CardBus host or card refers to a single unique location. However, CardBus cards with I/O ports must provide the capability to map the I/O ports to the host m e m o r y space. This m e m o r y - m a p p e d I/O requirement is specifically designed to a c c o m m o d a t e non-X86 architectures which do not support a separate I/O space. This requires that for I/O spaces there must be two corresponding BARs: an I/O BAR and a M e m o r y BAR. Tuples in CardBus can be located anywhere with the exception of the I/O space and the first 64 bytes of the configuration space. The first tuple is required to be the link-target tuple. The tuple chain must start on a double-word (DWORD) address boundary. To configure a card, the host must first read the CIS to locate the BARs that correspond to each card address space. The host then sets up the BARs for the proper addresses and the control registers with the necessary configurations. The process for configuring a CardBus card is as follows: 1. At card detection, toggle C V S l and cvs2. 2. Verify either C C D I # or C C D 2 # toggle to determine if the card is a CardBus card. 3. Read the CIS pointer from the Configuration Header to find the start of the CIS. 4. Read CISTPL CFTABLE CB to interpret the configuration for the socket. 5. Read the BAR tuple to learn the size and characteristics of the address space m a p p e d by the specified BAR. 6. Write an address into the BAR to set up the address space. 7. Set up any interrupts used.

4.11.2 CardBus Configuration Space The CardBus configuration space is the starting point for configuration of the CardBus card. Each function on CardBus is required to i m p l e m e n t its own configuration space. The presence and location of the physical

108

INSERTION AND CONFIGURATION ISSUES

spaces associated with that function or other functions are determined by a c o m b i n a t i o n of the CIS and the BARs. The configuration space is accessed through a special type of bus transaction known as the configuration access. A configuration access, unlike other CardBus transactions, requires the host to decode the address to determine which socket is the target for the configuration access. There are two types of configuration accesses: Type 1 and Type 0. The two different accesses are differentiated by the values on the CAD1-0 pins during the address phase. A Type 0 access, CAD1-0 = 00, is used to select a socket that lies on the local CardBus. It is generally not propagated b e y o n d the local CardBus. A Type 1 access, CAD=01, is used for sockets that lie beyond the immediate bus. It is decoded by CardBusonly-to-CardBus bridges, which decode the address sockets to determine if the target bus lies in the bus hierarchy under that bridge. If the target bus does not lie in the hierarchy supported by that bridge, it ignores the access. If, however, the bus does lie in the bus hierarchy of the bridge, the bridge acknowledges the access and forwards it to the target bus. CardBus supports hierarchical buses. This allows another CardBus bus to be added b e y o n d the current CardBus bus (Figure 4.7). Up to 256 different buses m a y be addressed directly with a Type 1 access. Figure 4.8 shows the format of the Type 0 and Type 1 accesses as defined by the C A D 3 1 - 0 lines during the address phase.

Configuration Access Field Definitions Register N u m b e r - - T h i s is an index to the appropriate DWORD in configuration space. For example, 08 in this field refers to second DWORD.

Function N u m b e r - - T h i s is a reference to a function (0-7) in a CardBus card. Device N u m b e r - - T h i s is used to select a given device, or socket, (1-32) on the CardBus bus.

Bus N u m b e r - - T h i s selects a CardBus bus (1-256) in a host.

4.11.2.1

Generating a Configuration Space Access

As previously mentioned, a configuration access is very similar to other CardBus slave-type transactions. The only difference is that the configuration space m a p p i n g for each device is performed by the host. CardBus has defined an indirect addressing m e c h a n i s m based on two registers within the CardBus bridge to map the configuration space: Config_Address at CF8h, and Config_Data at CFCh. They are 3Z-bit (DWORD) registers. To access the configuration space of a particular

4.11

CONFIGURING CARDBUS CARDS

Figure 4.7

Figure 4.8

Hierarchical busses in CardBus.

Address format for Configuration Accesses.

31 I

,,

11 10 8 7 I Function Number I

Reserved

31

1

109

23 Reserved

16 15

I

1110

!

8 7

2 1 0

RegisterNumber I 0 I 0 I 2 1

0

I Register " Number I 0 II1

Bus Device Function Number Number Number

Type0

Type 1

1 10

INSERTION AND CONFIGURATION ISSUES

Figure 4.9 Config_Address register format. 31

I

I

Reserved

23 16 15 11 10 8 7 I BusNumber[RDevice e g i s tIFuncti~ eNumber rNumber

2 1 0 Numberl 0 11 ]

card, the host m u s t write a value into the Config_Address register to define the register, function, device a n d the bus being accessed. W h e n the host reads or writes to or from the C o n f i g _ D a t a register, the bridge translates the contents of the C o n f i g _ A d d r e s s register to the selected card. Figure 4.9 shows the format of the C o n f i g _ _ A d d r e s s register. For m o r e i n f o r m a t i o n on CardBus bus hierarchies see C h a p t e r 8.

4.11.3 Configuration Space Header The configuration space in CardBus is 256 bytes. The first 64 bytes of the configuration space are defined a n d are k n o w n as the C o n f i g u r a t i o n Header. Table 4.20 shows the Configuration Header.

4.11.3.1

Command Register

This 16-bit register is used to enable or disable various attributes a n d capabilities of a bus transaction. It allows the host to enable m e m o r y or I/O accesses. The default (Oh) is configuration only accesses. The host can also enable or disable the bus master m o d e of the f u n c t i o n a n d other attributes such as the following: 9 9 9 9 9 9 9

Fast back-to-back transactions in master m o d e M e m o r y write a n d invalidate cycles in master m o d e VGA palette snoops Parity error h a n d l i n g Acceptance of special bus cycles SERR# enable Address a n d data stepping

4.11.3.2

Status Register

This register is used for bus events. Fields are i m p l e m e n t e d only on the basis of functionality supported by the card. Fields for u n s u p p o r t e d features are n o t i m p l e m e n t e d . The features in Table 4.21 are supported.

4.1 1 CONFIGURING CARDBUS CARDS

1 11

Table 4.20

Configuration header fields.

D31-24

[D23-16

D15-8

ID7-0

~set

Allocated

Allocated

OOh

Status

Command

04h

Allocated BIST

Allocated

Header type

Latency timer

Cache line size OCh

Base address register

10h

Base address register

14h

Base address register

18h

Base address register

1Ch

Base address register

20h

Base address register

24h

CIS pointer

28h

Reserved

2Ch

Expansion ROM base address

30h

Reserved

34h

Reserved Allocated

08h

IAllocated

[Interrupt pin

38h IAllocated

3Ch

Beginning of function specific space Tuple

40h

Tuple Tuple Tuple Tuple End of function-specific space

FFh

BIST,built-in self test.

4.11.3.3

Cache Line Size

This register is set by the host to indicate the line size of the host system central processing u n i t (CPU) cache. This d e t e r m i n e s the size of the burst t h a t t h e card can use while in m a s t e r m o d e . It is set to 0 if the m e m o r y spaces in the f u n c t i o n are n o t cacheable.

1 12

INSERTIONAND CONFIGURATION ISSUES

Table 4.21

Features supported by status register.

Bit

Field name

Overview

15 14 13

Detected parity error Received system error Received master abort

12

Recvd target abort

11

Signaled target abort

9-10

CDEVSEL# timing

8 7

Data parity detected Fast back-to-back transaction capable Reserved

Set whenever a parity error is detected Set whenever the CSERR# line is asserted. Set by card in master mode whenever transaction is terminated by master abort (except special cycles) Set by card in master mode when transaction is terminated with target abort Set by a card in target mode whenever it terminates transaction by means of target abort Indicates the worst-case time for card to assert CDEVSEL# for any cycle except configuration access Set by a master if CPERR# is asserted When set indicates target is capable of accepting back-to-back transactions Reserved

0-6

4.11.3.4

L a t e n c y Timer

This register is used to p r o v i d e t h e l a t e n c y t i m e r c o u n t in bus clocks for a master. It is e n a b l e d o n l y if t h e f u n c t i o n c o r r e s p o n d i n g to this Configur a t i o n H e a d e r is in the m a s t e r m o d e . O n c e t h e c o u n t expires, t h e m a s t e r t e r m i n a t e s t h e t r a n s a c t i o n . The c o u n t starts w h e n t h e m a s t e r asserts C F R A M E # . The c o u n t resets if t h e m a s t e r deserts C F R A M E # before expirat i o n of t h e c o u n t .

4.11.3.5

Header Type

Bit 7 of this register when set indicates multiple functions. Bits 0-6 must be set to 00h a n d specify t h e CardBus-specific layout.

4.11.3.6

Built-in Self Test

This o p t i o n a l register is i m p l e m e n t e d by f u n c t i o n s t h a t i m p l e m e n t a built-in self test (BIST) capability. O t h e r w i s e it m u s t be set to 0.

4.11.3.7

Base Address Register

These 32-bit registers are used to provide t h e starting address w i t h i n t h e h o s t address space for the card m e m o r y or I/O resources. There are six

4.1 1 CONFIGURING CARDBUS CARDS

113

BARs a n d o n e EPROM BAR. Figure 4.10 shows the basic f o r m a t of the BARs. A BAR is disabled if its bits 31-4 are set to O. In m e m o r y - m o d e BARs, the fields are d e c o d e d as follows: T y p e - - A O0 value indicates the card m e m o r y space can be m a p p e d anyw h e r e in the host address m e m o r y address space. A 01 value requires m a p p i n g below 1MB. Values 10 a n d 11 are n o t used. P r e f e t c h a b l e - - G e n e r a l l y the m e m o r y space of a card is c o n s i d e r e d prefetchable if it is m e m o r y rather t h a n m e m o r y - m a p p e d I/O a n d is n o t cached. In I/O m o d e BARs, bits 0-1 are read only. All I/O addresses are forced to start at DWORD boundaries. EPROM base address is n o t at a consecutive location; it is at offset 3Oh. If bit 0 is set, the h o s t m a y access an EPROM address w i t h i n the card. Bits 11-31 are used to indicate the start address.

Figure 4.10

31

Base address registers format.

Memory Base Address Register

4

3

2

1

0

1

0

Base Address Prefetchable Type Memory

I

31

I/O Base Address Register

2

Base Address Reserved

-

IIO

[

31

Expansion ROM Base Address Register

lo

Base Address Address Decode Enable

0

Reserved

1 14

INSERTION AND CONFIGURATION ISSUES

4.11.3.8

ClS Pointer

This is a read-only register that indicates the address of the CIS and the address space in which it resides. The CardBus CIS may reside in the following areas: 9 Configuration space 9 M e m o r y space 9 EPROM Space The actual address space used is indicated by the address space indicator field (bits 0-2). The bits are encoded as follows: 000 001-110

111

4.11.3.9

Configuration space. Address is between 40h and F8h. Memory space. The actual value indicates the offset of the BAR that points to the start of the m e m o r y space. The address offset (bits 3-27) contains the offset within that base address. EPROM. The address offset (bits 3-27) is actually an offset from the start address defined by the EPROM base address.

Interrupt Pin Register

This register indicates whether the function uses the interrupt pin. This register must be set if the interrupt pin is used.

4.12

SUMMARY This chapter covers two of the more important aspects of PC Card techn o l o g y m i n s e r t i o n and configuration. Many of the design choices in a PC Card are based on h o w a particular PC Card deals with these aspects of the technology.

S MULTIFUNCTION CARDS

5.1

OVERVIEW The acceptance of PCMCIA in the mobile c o m p u t i n g m a r k e t has led to i m p o r t a n t n e w d e v e l o p m e n t s in PC Card technology. Most portable a n d mobile m a c h i n e s i m p l e m e n t one or two sockets only. This prevents people from using more t h a n two PC Cards simultaneously. PCMCIA has solved this p r o b l e m by defining m u l t i f u n c t i o n PC Cards. A function is defined as a single i m p l e m e n t a t i o n of a u n i q u e I/O or m e m o r y capability with its o w n software (I/O port) interface. Examples of a f u n c t i o n include f a x / m o d e m s , Ethernet interface, flash memory, ATA, a n d SCSI. A PC Card m a y c o n t a i n one or more functions. PC Cards t h a t c o n t a i n only one function are k n o w n as single-function cards. PC Cards with two or more functions are m u l t i f u n c t i o n cards.

5.1.1

Types of Multifunction PC Cards M u l t i f u n c t i o n PC Cards can be a n y c o m b i n a t i o n of I/O or m e m o r y functions. There are three basic categories:

9

I / O - M e m o r y PC C a r d s Examples include f a x / m o d e m a n d flash m e m o r y c o m b i n a t i o n cards. 9 M e m o r y a n d M e m o r y Examples include flash m e m o r y a n d SRAM c o m b i n a t i o n cards. 9 I / O - I / O PC C a r d s Examples include f a x / m o d e m a n d Ethernet comb i n a t i o n cards.

16-bit PC Card specifically does not place a limit on t h e n u m b e r of functions on a card; however, because of space a n d power constraints, m o r e t h a n four functions in a single card would be impractical. In fact, m o s t 16-bit m u l t i f u n c t i o n PC Cards contain no more t h a n two functions. CardBus restricts the n u m b e r of functions on a card to eight. How115

1 16

MULTIFUNCTION CARDS

ever, also because of the practical constraints of space and power, most CardBus cards may not implement more than four functions. PC Card 95 has added hardware, configuration information structure (CIS), and software support (within card and socket services) to the 16bit standard for multifunction implementation. CardBus uses a different mechanism for multifunction support; it defines the function number as part of its configuration access address. The difference in the multifunction interface mechanism requires a different implementation for each bus. Combining multiple functions on a single PC Card requires attention to the following issues: . 9 9 9 9 9

Identifying multifunction PC Cards Mapping address ranges for the individual functions into the host address space Sharing interrupts on the single interrupt line Designing CIS to support tuple chains for each specific function Managing power and voltages for each function Allowing software drivers to operate the individual function without interfering with the other functions

The rest of this chapter discusses implementation of the multifunction cards on both the 16-bit bus and CardBus and how each of the aforementioned issues is addressed in each implementation.

5.2

16-BIT MULTIFUNCTION PC CARDS 16-bit PC Card support for multifunction implementations has been added to support I/O-Memory, I/O-I/O, and Memory-Memory multifunction capabilities. I/O-Memory and Memory-Memory cards can be implemented without requiring additional hardware capabilities to release 2.1 of the standard. Memory functions generally do not require interrupts, so a single interrupt line is sufficient for the extra I/O function. Memory functions generally implement a hard decode and start at comm o n memory address 00h. C o m m o n memory-mapping support within the host address support is generally provided by the host, so the memory function does not really have any specific remapping requirements. I/O-I/O multifunction cards generally require interrupt line sharing. The IREQ# line now must be shared by multiple interrupt sources. Because the I/O ports within each I/O function must be mapped into the host space, the mapping mechanism for this needs to be provided. PC Card 95 supports these capabilities by changing the card configuration

5.2

16-BIT MULTIFUNCTION PC CARDS

117

registers (CCR) to f u n c t i o n c o n f i g u r a t i o n registers (FCR). The FCRs are n o w specific to each reconfigurable function. Each reconfigurable function o n a 16-bit PC Card m u s t have its o w n u n i q u e set of FCRs. In PC Card 95, PCMCIA has a d d e d additional registers--I/O base a n d I/O limit r e g i s t e r s - - a n d redefined the f u n c t i o n a l i t y of some of the bits w i t h i n t h e existing FCR (FCR0-3) to s u p p o r t m u l t i f u n c t i o n cards. The o t h e r import a n t a d d i t i o n by PCMCIA is s u p p o r t for m u l t i p l e - t u p l e chains for multif u n c t i o n cards.

5.2.1

Detecting a Multifunction PC Card The CIS m e c h a n i s m can be used to differentiate single-function a n d m u l t i f u n c t i o n 16-bit PC Cards. All 16-bit m u l t i f u n c t i o n cards are required to i m p l e m e n t the m u l t i f u n c t i o n ID as well as LongLink_MFC tupie in the p r i m a r y tuple chain. The LongLink_MFC tuple p o i n t s to the specific CIS for each function. The locations of the FCR for each f u n c t i o n are t h e n d e f i n e d in the function-specific CIS. The f o r m a t a n d structure of a LongLink_MFC tuple are defined in Table 5.1. Figure 5.1 shows h o w the LongLink_MFC tuple is used to identify a n d locate m u l t i p l e functions o n a card a n d t h e n use the individual function-specific CIS to m a p the I/O address ranges. W h e n a host recognizes an inserted card as a 16-bit PC Card, it begins to parse the p r i m a r y CIS (CIS starting at attribute m e m o r y address O0h). If t h e p r i m a r y CIS c o n t a i n s a LongLink__MFC tuple, it is a m u l t i f u n c t i o n

T a b l e 5.1

CISTPL

LONGLINK

MFC

structure.

Byte

Field

Description

0 1 2

Tuple ID Length Number of FCR

06h Length in n-1 Number of registers in FCR used each function. Required to be same for all functions. Address space used for CIS of first function. 00h = attribute memory; 01h = common memory Target address for CIS of first function Address space used for CIS of second function. 00h = attribute memory; 01h = common memory. Target address for CIS of second function CIS address space and CIS address fields for each additional function

CIS address space

4-7 8

CIS address CIS address space

9-12 13-n

CIS address Additional fields

1 18

MULTIFUNCTION CARDS

Figure 5.1

Multifunction detection and mapping mechanism.

PC Card. The host then parses the individual function-specific CIS to identify the location of the FCR for each function. The FCR are t h e n used to control and map the I/O ports associated with that function. The m a p p i n g is i m p l e m e n t e d through additional FCR k n o w n as I/O base and I/O limit registers. These are described in the next section.

5.2.2

Multifunction Hardware Implementation To support multifunction PC Cards, PCMCIA has required that CCR be i m p l e m e n t e d for each function, so these were renamed FCR. The reason

5.2

16-BIT MULTIFUNCTION PC CARDS

1 19

for this c h a n g e was t h a t m o n i t o r i n g the status of m u l t i p l e I/O devices t h r o u g h a single set of status registers caused m a n y conflicting effects, especially in the area of e v e n t m a n a g e m e n t . PCMCIA also a d d e d I/O base a n d I/O limit registers to the FCRs. The base a n d limit registers are optional for single-function cards but are required for m u l t i f u n c t i o n cards. Tables 5.2 a n d 5.3 s h o w the FCR.

5.2.2.1

Use of I/O Base and Limit Registers in Multifunction Cards

Figure 5.2 shows the block d i a g r a m of a m u l t i f u n c t i o n PC Card. It shows t h e i m p l e m e n t a t i o n of the I/O base a n d limit registers. The base a n d limit registers define the start a n d size of the I/O address range o c c u p i e d by the I/O ports of the function. They are used to g e n e r a t e either the chip select or the read a n d write controls to the f u n c t i o n device.

Table 5.2 Function configuration registers for multifunction PC Cards. CEI

REG

#

Address offset

L

L

XXX0

L

L

XXX2

L

L

L

#

Register name

Comments

Used to write the configuration index Status and control of the card

XXX4

Configuration option register Configuration and status register Pin replacement register

L

XXX6

Socket and copy register

L

L

XXX8

Extended status register

L

L

XXX10

I/O base 0

L

L

XXX12

I/O base 1

L

L

XXX14

I/O base 2

L

L

XXX16

I/O base 3

L

L

XXX18

I/O limit

Used to provide status of signals, such as BVD 1-2, which are not available in the I/OMemory mode Used to differentiate two identical cards in a host Changes in the status of certain events that can affect STSCHG#

Starts address byte 0 for I/O ports of function Starts address byte 1 for I/O ports of function Starts address byte 2 for I/O ports of function Starts address byte 3 for I/O ports of function Describes the size of the address range 2-256 bytes

120

MULTIFUNCTION CARDS

Table 5.3

Bit map for function configuration registers. 5

4

Register

3

SRESET

Level

Configuration index as defined by card vendor

Enable

IRQ

Changed

SigChg

IOis8

Reserved Audio

PwrDwn Intr

IntrAck

Configuration and status

CBVDI

DBVD2

CREADY

CWProt

REVD2

RWProt

Pin replacement

Reserved Copy number Event 3

Event 2

Event 1

RBVDI

IREQ#

Enable baselimit

RREADY

Function Configenable uration option

Socket number

Socket and copy

Req Attn Enable 3 Enable 2 Enable 1 Req Attn Extended enabled status

Base I/O address (up to 4 bytes)

I/O base 0-3

Number of ports in I/O range using 2 n notation (2n port% n is the value written)

I/O limit

The n u m b e r of I/O base registers used depends on the expected location of the function in the host I/O address space. The locations are as follows" First 256 bytes First 64KB First 16MB Entire 4GB

I/O I/O I/O I/O

base base base base

0 only implemented 0-1 implemented 0-2 implemented 0-3 implemented

8-bit decode 16-bit decode 24-bit decode 32-bit decode

Most functions typically use two I/O base registers to allow the function I/O ports to be mapped within the first 64 KB of the host I/O space. For implementations that must be compatible with ISA software and hardware, the I/O has to be mapped within the first 1KB of host I/O space. This also requires the use of two I/O base registers. The I/O limit register is used to specify the n u m b e r of consecutive I/O ports being used in the function in a given configuration. For example, ISA serial ports use eight I/O ports. This means that the I/O limit register should set the first three bits to 1 (07h).

5.2

Figure 5.2

16-BIT MULTIFUNCTION PC CARDS

121

Block d i a g r a m of a multifunction PC Card.

HA25-0

=1

L I[

I I I

i

Controls

Address Function 1 ~ontmls

.J

Data

D15-0 w,--I Function 2

I

=

Function 2 Controls

I I I

5.2.2.2

Changes in Other Function Configuration Registers

To eliminate conflict caused by interaction a m o n g the multiple functions, each function has its own set of configuration registers. PC Card 95 changed the definitions of bits in some of the configuration registers defined in PCMCIA release 2.0. The two registers affected are the configuration option register and the configuration and status register. The changes are as follows:

Configuration Option Register Function Enable, once used by most cards as Card Enable, is now function-specific and enables and disables the function. E n a b l e B a s e / L i m i t enables function-specific base and limit registers. W h e n this bit is set, only the bus cycles within the range defined by the base and limit registers are passed through to the function. E n a b l e IREQ# enables the function'sinterrupt to be passed on to the IREQ# signal. C o n f i g u r a t i o n I n d e x is vendor-specific. It is used to put the function into a specific configuration.

122

MULTIFUNCTION CARDS

LevelIRQ is used to configure the interrupt mode used on TRY.Q#. All functions must use the same mode. SRESET is the PCMCIA soft reset. Configuration Status Register I n t r A c k affects how a function interrupt service request, as indicated by the Intr bit, is cleared or set. W h e n IntrAck is set to 0, the Intr bit is set to request service w h e n an internal function interrupt request (IRQ) occurs. The Intr bit is cleared w h e n the internal function condition that requests interrupt has been serviced. Intr is read only in this mode. W h e n IntrAck is set to 1, the Intr bit becomes read-write. The host must explicitly write a 0 to the Intr bit to acknowledge the interrupt service request. W h e n a 0 is written to Intr, the interrupt logic on the card is required to evaluate IRQ conditions from all functions and generate another interrupt to the host if an IRQ is pending. This interrupt acknowledge mode is an addition to the implicit interrupt acknowledge mode described for situations in which IntrAck is 0. I n t r is set to 1 to indicate an interrupt service request from the function. It is cleared to 0 when the condition within the function that requests service has been serviced. If IntrAck is set to 1, Intr must be explicitly cleared by the host. P w r D n , Audio, lois8, SigChg, and C h a n g e d are described in Chapter 4.

5.2.3

Sharing the IREQ# line In single-function PC Cards, the IRQ line of the function is attached directly to the PC Card 3REQ# line. The polarity may be inverted, but overall it is a simple connection. In multifunction PC Cards, however, because each function may generate interrupts, it becomes necessary to share the 3REQ# line. In this case the PC Card must i m p l e m e n t interrupt-sharing logic to allow sharing of the TREQ#1ine. Figure 5.3 shows the interrupt-sharing logic. The simplest way to share is simply to OR the interrupt sources into the TREQ# output. This works if the functions use level-mode interrupt sources. For pulse-mode interrupt sources, the IRQs have to be latched. To share interrupts on one IREQ# line, the host interrupt service routine must identify the function that caused the interrupt and the source within the function that caused the interrupt. This is accomplished with the Intr bit in the configuration status register for each function. It is

5.2

16-BIT MULTIFUNCTION PC CARDS

123

Figure 5.3 Simple interrupt-sharing logic.

Func. 1 EnlREQ

Func. 1 Int. Src.

I

Func. 2 Int. Src.

Func. 2 EnlREQ

13

~ L~' "

IREQ#

Pu Ise Mode Logic

LevlReq

strongly r e c o m m e n d e d for shared interrupts that all interrupt sources be level-mode interrupts.

5.2.4 Multifunction Interface" Example A multifunction PC Card implementation consists of a c o m m o n bus interface to the 16-bit bus, which implements the FCR, the base and limit decodes, and the interrupt-sharing-acknowledge logic. The bus interface provides a separate set of chip selects and interrupt inputs for each function. All other controls are common. The address and data may be shared if simultaneous activity will not occur on the functions. Otherwise, separate address and data paths for each function are recommended. An example is a fax/modem and Ethernet multifunction PC Card design. The fax/modem uses a serial port with eight I/O registers. For compatibility with existing ISA software, the four starting address locations for the serial port are 3F8h, 2F8h, 2E8h, and 3E8h. The interrupt is IRQ3 or IRQ4. The Ethernet device has 16 I/O ports, a local buffer accessed t h r o u g h a data port, and an interrupt line that can be connected to any available interrupt. The I/O ports can be mapped to any particular address. Figure 5.4 shows the block diagram.

124

MULTIFUNCTION CARDS

Figure 5.4 PC Card.

I m p l e m e n t a t i o n of a f a x / m o d e m , Ethernet multifunction

Fax/Modem

HA25-0 IREQ# CE2-1# OF.#,WE# REC~ lORD# IOWR# D15-0

Addre~

A4-0 F1CS# FIRD# FIWr# Fllnt < D15-0 F2CS# F2RD# F2Wr# F21nt ql

J

=IA2-O ~_1CS# IOR# lOW# ,,.1 Intr

Data

"1D7-0 Ethernet

"~J

A3 0

ClS ROM

The interface logic generates separate chip selects for each I/O device. The chip selects are asserted by the interface logic only if the address on the PCMCIA bus is within the range defined by the I/O base and limit registers for each function. For example, if the function 1 base register is programmed to 03F8h and the limit register is programmed to 07h, the function 1 cs# (FICS#) will be generated only when the address falls between 03F8h and 03FFh. The other control signals may be similarly qualified. The main reason for qualification of the control signals is to prevent unnecessary toggling of outputs, which drains power. Function 2, the Ethernet device chip selects, is generated according to the base and limit registers. The exact address for the particular configuration can be derived from the C o n f i g TabZe E n t r y tuple. In this case the base address register (BAR) for function 2 is programmed for 30Oh, and the limit register is programmed to 0Fh. The CIS is programmed into a programmable read-only memory (ROM) device. The address location within attribute memory is decoded by means of the interface logic to be at address 00h. The most complicated issue is interrupts. To operate with existing serial port drivers and software, the fax/modem must use the designated IRQ (3 or 4). The local area network (LAN) has no designated IRQs, but it

5.2

16-BIT MULTIFUNCTION PC CARDS

125

must specify an IRQ. Because there is only one IREQ# pin from the card to the host, the host can steer it to only one particular interrupt. No interrupt-vectoring mechanism is defined for 16-bit PC Card. Such a m e c h a n i s m requires that a single interrupt service routine be used to direct interrupts from each function to the appropriate interrupt handlers. Card Services is required to manage the interrupts. Interrupt handlers for each function are required to register with Card Services by use of a RequestlRQ call. Card Services then dispatches the interruPt to the appropriate handlers. Figure 5.5 shows the interrupt service and notification protocol.

5.2.4.1

Designing the ClS

There are three separate tuple chains for the multifunction card in the example. The first chain is the primary chain; it should contain a LongLink_MFC tuple. It may also contain other general purpose tuples, such as MANID and VERS_I. The L o n g L i n k _ M F C tuple points to two other tuple chains. The first chain is for the fax/modem function and begins with a L i n k T a r g e t tuple. It also contains other function-specific tuples, such as FUNCID,

CONFIG, and CFTABLE_ENTRY. The

FUNCE,

second tuple chain is for the Ethernet function and also begins with a L i n k T a r g e t tuple. It also contains function-specific tuples such as FUNCID,

FUNCE,

CONFIG, and CFTABLE_ENTRY.

Figure 5.5 Interrupt handler dispatching in multifunction PC Cards.

/

T Fax/Modem \

\

Ethernet 1 j

126

5.2.5

MULTIFUNCTION CARDS

Multifunction Interface Solutions There are three suppliers of m u l t i f u n c t i o n interface s o l u t i o n s - - N a t i o n a l S e m i c o n d u c t o r , Tokyo Electron, a n d Mobile Media Research. N a t i o n a l has two m u l t i f u n c t i o n interface devices t h a t in c o n j u n c t i o n with o t h e r m e m o r y or I/O devices can be used to build m u l t i f u n c t i o n cards. Tokyo Electron has a m u l t i f u n c t i o n device t h a t supports ATA a n d o n e additional function. Mobile Media provides a m u l t i f u n c t i o n interface core based o n field p r o g r a m m a b l e gate arrays (FPGAs). It also provides a CIS g e n e r a t o r for m u l t i f u n c t i o n CIS d e v e l o p m e n t . The N a t i o n a l m u l t i f u n c t i o n devices are the p r e d o m i n a n t m u l t i f u n c t i o n interface solutions in use today. There are two offerings: PCM16CO0 a n d PCM16C02. Table 5.4 provides an overview of the differences bet w e e n the two devices.

5.3

CARDBUS MULTIFUNCTION PC CARDS CardBus m u l t i f u n c t i o n cards use a d e t e c t i o n a n d f u n c t i o n access s c h e m e different from t h a t of 16-bit PC Card. CardBus is designed f r o m t h e

Table 5.4

Difference between multifunction interface devices.

Feature

PCM16C00

PCM16C02

Package Attribute memory

144 TQFP 2KB of SRAM buffers 2KB EEPROM Supported through EARD pin

100 TQFP 1KB of SRAM buffers 1KB of 2KB EEPROM No None 16Kbit read-write

I/0 address space

Programmable 16Kbit read-write 4Kbit read only 8- or 16-bit organization Supports NSC DP83902A or generic ISA LAN 16-address lines decoded 64KB

Unique features

4-bit bidirectional digital port

DMA

No DMA support

Buffers

16-bit buffer for data and address

Extended attribute memory Bus arbitration EEPROM interface

LAN interface

16-bit organization Supports generic ISA LAN

13 address lines decoded 8KB NAND flash support on function 0 Single-channel DMA support for function 1 16-bit buffer for data

5.3 CARDBUS MULTIFUNCTION PC CARDS

127

ground up to a c c o m m o d a t e multiple functions in a single card. The access m e c h a n i s m for multiple functions is predefined and built into the CardBus addressing scheme. The issues w h e n multiple functions share a CardBus socket are: 9 9 9 9

Detecting multiple functions on a card Interrupt m a n a g e m e n t Arbitration between multiple master functions Hierarchical function i m p l e m e n t a t i o n

5.3.1 Accessing Multiple Functions in CardBus Support for specific function access in CardBus is provided within the configuration space address (Figure 5.6). Every configuration space access has a 3-bit field (CAD IO-8) within its address to indicate the function n u m b e r being accessed. During the address phase of the configuration space access, CAD 10-8 selects the function. For example function O, register 3 in a type 0 access would be OOCh. The binary form of the address is shown in Figure 5.7. If function 3, register 26 (1Ah) is being accessed, the address is 0368h. Figure 5.8 shows the binary form for this example.

5.3.2

Determining Multiple Functions Every function on CardBus is required to i m p l e m e n t its configuration space, A multifunction CardBus card must decode all of CADIO-O. The first function is required to respond as function O; the remaining func-

Figure

5.6

Function

field within

31

1110

a configuration

8 7

address.

2 1

0

Type 0 31

23

16 15

11 10

8 7

2 1

0

Type 1

128

MULTIFUNCTION CARDS

Figure 5.7 Binary form of configuration address.

30 29 2 8 2 7 0

0

0

0

26 25 24 23 0

0 0

0

22002112~

19

18

17 16

0

0

0

0

05114 0

13 12

11 10

9

8

0

0

0

0

0

0

Function ,

,11 sl41312

0

0

0

0

0

1

Register

3

1

, i

,

Figure 5.8 Binary form for function 3, register 26 (1Ah).

30 29 0

0

281o2o'12s"J:o 0

17 16

1918 0

0

0

0

13 12 0

0

0

0

"1':,i . i , l ~ i

, ,

01 1413L2 =,

01

t

03h

, ,

1Ah

, ,

tions m a y use any function n u m b e r between 1 and 7. The host determines the existence of multiple functions by polling function 0, accessing the header field bit 7 within the configuration header. If bit 7 is set, the card is a multifunction card. To determine the n u m b e r of the functions the host must poll the configuration space of each function. If a function does not exist, there is no response, and the cycle is terminated with a master abort. If the function is present and a value is returned, the host m a y parse the CIS to obtain information about the function. It can then proceed to configure the function. The algorithm is shown in Figure 5.9. Because each function is a modular i m p l e m e n t a t i o n , the CIS for each function does not have to

5.3 CARDBUS MULTIFUNCTION PC CARDS

129

Figure 5.9 Determining multiple functions in CardBus.

I Rd CIS Pointer Function 0

I

Parse CIS to determine I Function Type, Configuration

I

I

"-I Increment Function Number

I

Rd CIS Pointer for current function Function Not Present

I Yes [ Parse CIS to determine Function Type, Configuration

~Function

Number =

No

be linked. Each CIS chain can be independent and is used only to identify the type of function and the configuration. 5.3.3

Managing

Interrupts

In CardBus all interrupts are level sensitive. Any interrupt from a CardBus card may be steered to any interrupt input in the interrupt controller of the host CPU. This means all CardBus device drivers are required to support interrupt sharing whether single-function or multifunction. Therefore, in CardBus hosts there is a central interrupt dispatcher. The interrupt dispatcher manages all incoming interrupts, determines the source of the interrupt, and dispatches it to the appropriate interrupt handler.

1 30

MULTIFUNCTION CARDS

For CardBus one determines the interrupt source by looking at the function event register Intr bit or the function present state Intr bit. This bit is set w h e n a function-specific event causes r to be asserted.

5.3.4

Arbitration Between Two Master Functions Another issue that must be addressed involves CardBus PC Cards with two or more master functions. There must be local arbitration on the PC Card to arbitrate between the master functions and to issue a bus request to the central CardBus arbiter. A more sophisticated approach to the local arbitration scheme is to i m p l e m e n t a local CardBus on the PC Card. In the bus hierarchy, the local CardBus would be one level below the host CardBus. This approach provides a complete protocol for arbitration, interrupts, C S T S C H G management, and modularity. However, it is not a true multifunction implementation. Each function is treated as a separate device, rather t h a n as a function. This approach also makes possible an application that has previously been extremely difficult to i m p l e m e n t in 16-bit PC Card, socket expansion. In this approach a CardBus-to-CardBus bridge is all that is needed to increase the n u m b e r of CardBus sockets. The software, however, has to be designed to allow for this modularity and must take this modularity into account when addressing or enumerating sockets. Figure 5.10 shows the block diagram of a CardBus multifunction PC Card interface.

5.3

CARDBUS MULTIFUNCTION

Figure 5.10

PC CARDS

131

Multifunction interface for CardBus PC Cards.

Config Header Function 0

L Local Arbiter

Address/Data

breq0

I bgntOl~nfl E breql

== v

funcn 0 controls

Function 0

L FOirq Controls

ClNT# CSTSCHG

Function 0 Decode

Interrupt ~ FOcstschg CSTSCHG Flim multiplexor E Flcstschg

(D

_J

o =

==

Address

Latency Timer

Function 1 Decode

...,, Data

Parity Generation and Detection Logic

Function funcn 1 controls

Config Header Function 1

o=E

I I

f Oclk fl clk

y

1

This Page Intentionally Left Blank

6 PCMCIA SOFTWARE: AN OVERVIEW

6.1

OVERVIEW Like most other add-in cards for expansion buses, PC Cards need a device-driver software c o m p o n e n t to manage data flow into and out of the card. In addition to a device driver, the plug-and-play nature of PC Cards necessitates a software c o m p o n e n t that automatically configures the card at insertion. This software c o m p o n e n t is known as an enabler. An enabler can be a point enabler or a generic enabler. A point enabler is designed to work with a specific card and does not recognize or service other PC Cards. A generic enabler recognizes all types of cards and uses the configuration information structure (CIS) on a PC Card to determine the configuration requirements of the card and set up the host to meet those requirements. In most c o m p u t e r platforms, addition of a card requires the following steps by the user: 1. Power-off system 2. Manually set jumpers on the card to use, for example, a specific address or interrupt 3. Installed card in the system 4. Power-up system 5. Manually install device driver or application software for the card 6. Rebooted system to load the device driver with the operating system. W h e n the card is removed, the process is repeated in reverse. In a PCMCIA platform w i t h o u t Card Services the user also has to m a n u a l l y install or remove the client drivers for the PC Card. The user t h e n must power-off or reboot the system to load the device driver into the system memory. This process must be repeated every time the user removes a PC Card and inserts a new PC Card. This process becomes 133

1 34

PCMCIA SOFTWARE: AN OVERVIEW quite cumbersome and prevents users from inserting or removing cards at will. The PCMCIA solution to this problem is Card Services. Card Services manages the host socket and PC Card events, notifies all clients of a card insertion or removal, and provides services to read the CIS. At card insertion, Card Services notifies all host clients of the insertion and links the clients, such as drivers or enablers, to the card. Card Services also manages allocation and deallocation of system resources for PC Cards and provides a central service to manage the state of the host PCMCIA bridge. Because there are a variety of h o s t - t o - P C Card bridges that present different software interfaces, PCMCIA defined a Socket Services layer, which abstracts the bridge hardware from the rest of the host software. Socket Services presents a universal software interface to the host bridge. Figure 6.1 shows the PCMCIA software components.

F i g u r e 6.1

PCMCIA

software

Application . I

I

model.

Universal Enabler I

I

OperatingSystem

I

I

ClientDevice Drivers

Resource Management Table CardServices

Memory Technology "] Driver

SocketServices

' !

I ,

PCMCIA Bridge Hardware

j

6.1

OVERVIEW

135

In addition to Socket Services, PCMCIA software i m p l e m e n t s m e m o r y t e c h n o l o g y drivers (MTDs) a n d specific drivers for certain PC Cards, such as ATA PC Cards. MTDs are designed to abstract the i m p l e m e n t a t i o n of a specific m e m ory device from the other host software. For example, flash m e m o r y devices c o m e in various erase block sizes a n d require different p r o g r a m a n d erase algorithms. MTDs provide specific p r o g r a m m i n g a n d erase services for such devices so t h a t a higher-level software c o m p o n e n t is n o t required to u n d e r s t a n d the specific p r o g r a m a n d erase a l g o r i t h m of the m e m o r y device in use. MTDs m a y be e m b e d d e d w i t h i n the Card Services or m a y register as separate clients. A configurable PC Card necessitates that the host allocate specific resources during the configuration process. To allocate resources, the host has to u n d e r s t a n d w h a t resources are available and w h a t resources are allocated. Card Services typically includes either an e m b e d d e d or a separate resource enumerator. The resource e n u m e r a t o r at start-up searches the m e m o r y space, i n p u t - o u t p u t (I/O) space, interrupts, and DMA channels of the system to identify resources available for allocation to a PC Card.

6.1.1

PCMClA Software Models The PCMCIA software c o m p o n e n t s as defined in the 1995 release of PC Card are designed to support the following capabilities: 9 Hot insertion a n d removal of PC Cards 9 Use of multiple PC Cards in the same socket at different times (time shared) 9 Interface to the operating system a n d applications software These capabilities are useful, in fact essential, for n o t e b o o k a n d subn o t e b o o k e n v i r o n m e n t s , in w h i c h PC Cards are r e m o v e d a n d inserted at will, because the systems do n o t have to be powered down. However, in n o n c o m p u t i n g applications ( e m b e d d e d systems) in w h i c h h o t insertion is n o t required or needed, the sophisticated software model t h a t supports h o t insertion a n d removal is not necessary. Instead one m a y use a m u c h simpler software model by e l i m i n a t i n g Card and Socket Services a n d imp l e m e n t i n g a simple PCMCIA socket interface, if needed.

6.1.1.1

Requirements for the Computing Model

In the mobile c o m p u t i n g model, one is expected to use PC Cards as exp a n s i o n c a r d s m t o e x p a n d their I / 0 a n d storage capabilities. In this envi-

1 36

PCMCIA SOFTWARE: AN OVERVIEW

r o n m e n t , a user may have m a n y more PC Cards than sockets. So each socket may contain different PC Cards at different times. This requires the host software to support the following capabilities: 9 The host software must i m p l e m e n t the mechanisms to support timesharing of the host sockets by different PC Cards. 9 The PC Card must be automatically configured at insertion, and system resources must be automatically allocated for the specific socket. 9 Software drivers that manage a particular PC Card must be connected to the particular PC Card if it is inserted in the socket. The host must provide a way to connect the driver to the PC Card. 9 For multifunction PC Cards, the host software must provide a m e c h a n i s m to share interrupts between PC Cards.

6.1.1.2

Embedded Systems Software Model

The term embedded system refers to n o n c o m p u t e r applications. These applications use a central processing unit (CPU), but the CPU is an embedded device, that is, it is not reprogrammable. Some examples of these applications are network routers, digital cameras, oscilloscopes, and medical instrumentation. These applications are usually restricted to one or two different PC Cards. Some of the applications require insertion or removal of the card at will, w i t h o u t powering down of the system, but of only one or two specific cards. This makes the problem m u c h simpler and the solution easier to implement. Because the cards are known, the card-specific software can set up the resources and configure the card. Card Services and even Socket Services are not required. In this case, the embedded code includes specific routines to support the one or two PC Cards supported. Figure 6.2 shows the software model for an e m b e d d e d system.

6.2

SOCKET SERVICES: AN OVERVIEW Socket Services is the lowest layer of the PC Card software hierarchy. It abstracts the PC Card interface hardware (PC Card bridge) from the higher levels of the host software. Socket Services breaks d o w n the interface into various hardware components: A d a p t e r s - - T h e hardware needed to interface with a PC Card. An adapter is defined by its windows, power state, sockets, and error detection (EDC) generators. An adapter may contain one or more sockets.

6.2 SOCKET SERVICES: AN OVERVIEW

137

Figure 6.2 Embedded system PC Card software model.

Embedded System Software

Point Enabler and Card Driver

Simlple PCMCIA Bdidge

I PC Card

S o c k e t ~ A single i m p l e m e n t a t i o n of the PC Card (16-bit or CardBus) interface. Each socket is defined by the state of its Vcc, Vpp, statusevent signals, memory, I/O windows, and type of interface, that is, 16bit I/O-Memory, Memory-only, CardBus, or DMA. EDC G e n e r a t o r s m C o m p o n e n t used to detect and generate error detection fields. EDC generators are not universally i m p l e m e n t e d in 16-bit PC Card. I/O a n d M e m o r y W i n d o w s m W i n d o w s are used to m a p 16-bit PC Card address m e m o r y and I/O address spaces into the host address spaces. For CardBus, the CardBus PC Card is required to provide a m e c h a n i s m to m a p the host address to its address space, so no I/O or m e m o r y windows are required in the host socket. However, a different window, which is needed to map the current CardBus bus to another CardBus lower in the hierarchy, is implemented. M e m o r y P a g e m T h e m e m o r y area on the PC Card being m a p p e d into the host space. (The m e m o r y - m a p p i n g hardware in the adapter for 16bit PC Cards is k n o w n as a memory window.)

1 38

PCMCIASOFTWARE: AN OVERVIEW Bridge W i n d o w s - - W i n d o w s used to map PC Card. They lie on buses below the hierarchy of the current adapter. Figure 6.3 shows the concept of a bridge window. Figure 6.4 shows the objects that constitute the interface and how they relate to Socket Services.

6.2.1

O v e r v i e w o f Services Socket Services provides the capabilities to manage the host hardware that interfaces to PC Cards. It manages access to windows, status and

Figure 6.3 Concept and application of bridge windows in CardBus.

6.2

Figure 6.4

SOCKET SERVICES: AN OVERVIEW

139

PC Card interface hardware objects in Socket Services.

event indicators on the bus, and PC Card interrupts. Socket Services provides the following broad types of accesses to a host: GetmType of call used to determine the current state of the hardware object. It is used in such a way that a particular parameter can be changed and written back by means of the Set call. I n q u i r e m T y p e of call used to obtain information about the capabilities of a particular object. SetmType of call used to write, or set, the state of a particular hardware object. For example, if a w i n d o w is to be set to a particular base address, one uses the Set call to write the specific values into the various registers. EDC-specific~Calls used in addition to Get, Set, and Inquire and specifically used to read and write from the EDC generator. OthersmMiscellaneous calls such as Acknowledge Interrupt Figure 6.5 shows the types of services provided for the key hardware components.

140

PCMCIA SOFTWARE: AN OVERVIEW

Figure 6.5

6.2.1.1

Socket Services calls by object.

Summary of Calls to Socket Services

A detailed list of services is provided in Table 6.1.

6.2.1.2

Making a Socket Services Call

Making a Socket Services call is specific to the host platform. The PC Card Standard defines an implementation for x86 DOS-based platforms. Socket Services requests are made by inserting parameters in the registers

6.2

SOCKET SERVICES: AN OVERVIEW

Table 6.1

141

Summary of Socket Services calls.

Name

Code

16-bit CardBus

Ac c es sCon f i gSpa ce

A2H

CardBus

Acknowledge

9EH

Interrupt

GetAccessOf fsets

AIH

GetAdapter

85H

GetAdapterCount GetBridgeWindow

80H A4H

GetEDC

96H

GetPage

8AH

GetSetpriorHandler

9FH

GetSetSSAddr

A0H

GetSocket

ADH

GetSSinfo

A3H

GetStatus

A5H

GetVendorInfo

9DH

GetWindow

88H

InquireAdapter

84H

InquireBridgeWindow

83H

InquireEDC

95H

InquireSocket

8CH

Description

Allows Read/Write to configuration space in CardBus Gets information about which Both sockets generated a status change interrupt Gets pointers to routines that use 16-Bit indirect addressing for memory on PC Cards Returns power down and status Both change info about the specified adapter Gets total number of adapters Both Gets current configuration of the Mainly CardBus specified bridge window Gets current configuration of the Both specified EDC generator Gets current configuration of the 16-bit page specified the offset Gets or replaces the entry point for Both the previous handler for the specific adapter Provides data or code descriptors to Both a Socket Services handler Gets current configuration of the Both specified socket Provides compliance level of the Both Socket Services Provides status information about Both Card and socket Both Provides information about the vendor of the socket services 16-bit Gets current configuration of the specified window Both Provides information about the capabilities of the specified adapter Primarily Provides information about the CardBus capabilities of the specified bridge window Both Provides information about the capabilities of the specified EDC generator Both Provides information about the capabilities of the specified socket

(continued)

142

PCMCIA SOFTWARE: AN OVERVIEW

Table 6.1 (continued) Name

Code

InquireWindow

87H

PauseEDC

99H

ReadEDC

9CH

Reset Socket ResumeEDC SetAdapter

90H 9AH 86H

SetBridgeWindow

A5H

SetEDC

97H

SetPage SetSocket

8BH 8EH

SetWindow

89H

StartEDC StopEDC

98H 9BH

VendorSpeci fic

AEH

16-bit CardBus

Description

Provides information about the capabilities of the specified window Both Pauses EDC generation on the specified EDC generator Reads EDC value computed by the Both EDC generator specified Resets PC Card Both Resumes EDC generation Both Sets configuration of specified Both adapter Primarily Sets configuration of specified CardBus bridge window Both Sets configuration of specified EDC generator 16-bit Sets offset of specified memory page Both Sets configuration of specified socket Both Sets configuration of specified window Both Starts EDC generation Both Stops EDC generation on specified generator Both Reserved for vendor-specific extensions 16-bit

indicated and issuing INT1AH in real mode (Table 6.2). Socket Services calls are blocked once Card Services is installed.

6.3

CARD SERVICES: AN OVERVIEW Card Services is the software layer above Socket Services. It provides the following capabilities and functions: Allocation and deallocation of system resources, such as m e m o r y and I/O addresses, interrupts, and DMA channels, for configuration of PC Cards for multiple clients

6.3

CARD SERVICES: AN OVERVIEW

Table 6.2

143

Socket Services parameter passing conventions.

Register

Parameter

AH AL BH BL CX DX DS:(E)SI ES:(E)DI

Service desired Adapter Window Page or socket Count Attributes Data pointer to Socket Services data areas Pointer to a buffer for information being returned by Socket Services Two possible values: Offset--Used by S e t P a g e for offset values Base--Used by SetWindow for base address of window in host address space

DI

Status Returned by Socket Services

CF

AH

Status: Set=error Cleared=success Returns error code if CF is set Returns s u c c e s s return code if CF is clear

9 Socket a n d PC Card e v e n t n o t i f i c a t i o n to registered clients. PC Card device drivers, enablers, a n d PC Card a p p l i c a t i o n s p r o g r a m s are C a r d Services clients. 9 M a n a g e m e n t a n d p r e v e n t i o n of resource conflicts b e t w e e n clients 9 M a n a g e m e n t of access to PC Cards a n d sockets f r o m m u l t i p l e clients 9 H a r d w a r e - i n d e p e n d e n t v i e w of socket a n d PC Card resources 9 C o n v e n t i o n a l view of b o t h CIS o r g a n i z a t i o n a n d PC Card resource a l l o c a t i o n i n d e p e n d e n t of w h e t h e r t h e PC Card is 16-bit or CardBus 9 A resource e n u m e r a t o r , u s u a l l y e m b e d d e d w i t h i n Card Services, t h a t identifies available system resources 9 At insertion, p a r s i n g of a PC Card CIS to d e t e r m i n e its capabilities In a d d i t i o n to t h e capabilities listed, Card Services interacts w i t h MTDs to read a n d write from m e m o r y devices in m e m o r y cards. MTDs are n e e d e d to a c c o m m o d a t e t h e different a l g o r i t h m s n e e d e d to erase a n d p r o g r a m n o n v o l a t i l e m e m o r y such as flash m e m o r y . Card Services provides an M T D - h e l p e r interface to p r o v i d e low-level r o u t i n e s to access t h e

144

PCMCIA SOFTWARE: AN OVERVIEW

PC Card. These low-level routines are listed in the media access table (MAT) a n d include the following capabilities: 9 9 9 9

6.3.1

Read byte, word, or words to PC Card Read byte, word, or words with a u t o i n c r e m e n t to PC Card Write byte, word, or words to PC Card Write byte, word, or words with a u t o i n c r e m e n t to PC Card

Functionality Card Services m a n a g e s accesses t o PC Cards, sockets, a n d system resources a m o n g multiple clients. These clients include PC Card device drivers, enablers, operating system-specific file systems, a n d PC Card applications. Card Services also provides notification of card a n d socket events to its clients a n d file system services to the operating system.

6.3.1.1

Client Registration

Typically a Card Services client at initialization registers with Card Services by use of the m e g i s t e r e l i e n t call. Before registration the client m u s t check the version c o m p l i a n c e of Card Services. This step is necessary because earlier releases of Card Services used socket addresses in w h i c h socket 1 was the first socket. In PC Card 1995 release, the first socket is socket 0. In the m e g i s t e r C l i e n t call, the client indicates the type of events a b o u t w h i c h it m u s t be notified, identifies itself ( m e m o r y or I/O client), a n d indicates w h e t h e r it m u s t be notified about specific types of card insertion events. Once the client is registered a n d a card is present in a socket, Card Services generates an artificial card insertion event a n d notifies the client. If a card is not present, no event notification is sent to the client. Once a card insertion event is detected by Card Services, it notifies all clients. The notification order is as follows: 1. I/O clients in last in, first out (LIFO) order 2. MTD clients in first in, first out (FIFO) order 3. M e m o r y clients in FIFO order O n c e notification is complete, the client m u s t start the process of card identification a n d configuration, if necessary.

6.3

CARD SERVICES: AN OVERVIEW

145

In addition to card insertion, other events may interest a client. These events, which Card Services processes and notifies its clients about, are described in the next section.

6.3.1.2

Event Notification

Card Services recognizes m a n y types of card and socket events. It allows clients to mask events that are not of interest. W h e n a particular event occurs, Card Services notifies the appropriate clients. It notifies only clients that do not mask this event during registration. There are three types of events--events generated by Card Services, card events, and socket events.

6.3.1.2.1

Events Generated by Card Services

The following events usually occur in response to a service request made by a client: R e g i s t r a t i o n C o m p l e t e Generated by Card Services to indicate to the client that the registration process is complete MTD Request Generated by Card Services to an MTD client w h e n a m e m o r y client requests a m e m o r y operation PM Resume Indicates Card Services has received a power resume notification from the host. Normal resume occurs w h e n the client was notified before the system was suspended. Critical resume is sent to clients not notified before the system was suspended. PM S u s p e n d Generated by Card Services to notify clients that a suspend (power down) notification has been received from the host power m a n a g e m e n t software. There are four types of suspend events, as follows: Q u e r y Request A query from the system w h e t h e r it is appropriate to suspend the system S n a p s h o t Request Similar to Query Request, except the system may be suspended despite a negative response from clients C o n s e r v e P o w e r System is being suspended but PC Card power will be left on No P o w e r System is removing power from all sockets SS U p d a t e d Indicates that Socket Services has been replaced or additional Socket Services has been added Exclusive C o m p l e t e Indicates that an exclusive access request is granted

146

PCMCIA SOFTWARE: AN OVERVIEW

E x c l u s i v e R e q u e s t Indicates a client is requesting exclusive access to a PC Card C a r d Reset Indicates occurrence of a hardware reset on a f u n c t i o n of a PC Card C l i e n t I n f o A request to a client to provide i n f o r m a t i o n about itself Reset C o m p l e t e Indicates c o m p l e t i o n of processing of a ResetFunction request Reset P h y s i c a l Indicates a reset is about to occur on the specified function a n d socket Reset R e q u e s t Indicates a client has requested a hard reset T i m e r E x p i r e d Indicates a timer registered by the client has expired C a r d I n s e r t i o n (artificial) An artificial event generated by Card Services in response to R e g i s t e r C l i e n t call while a PC Card is present in a n y socket. It is also generated in response to a R e q u e s t E x c l u s i v e if it is granted. It is also generated w h e n 0 ReleaseExclusive is processed. 6.3.1.2.2

C a r d Events

Card events are generated by the hardware on the PC Card. These events occur while the card is inserted in the socket. The events are as follows:

B a t t e r y D e a d Indicates a dead battery on a PC Card B a t t e r y L o w Indicates a weak battery on a PC Card C a r d R e a d y Indicates a READY signal transition from busy to ready W r i t e P r o t e c t Indicates the write protect (WP) status of the PC Card has c h a n g e d R e q u e s t A t t e n t i o n Indicates a PC Card has set the REQ_ATTN bit of the e x t e n d e d status configuration register

6.3.1.2.3

Socket Events

C a r d I n s e r t i o n One of the most i m p o r t a n t events for the socket. Indicates a PC Card has been inserted and CCD1 # and CCD2 # pins have been asserted. C a r d R e m o v a l Indicates a PC Card has been r e m o v e d from the socket. One Card Removal event is allowed per function. E j e c t i o n R e q u e s t Indicates a user is requesting ejection of a PC Card by m e a n s of a motor-driven m e c h a n i s m E j e c t i o n C o m p l e t e Indicates the m o t o r c o m p l e t e d ejection of the PC Card

6.3

CARD SERVICES: AN OVERVIEW

147

I n s e r t i o n R e q u e s t Indicates an end-user request for PC Card insertion into a socket by m e a n s of a m o t o r - d r i v e n m e c h a n i s m I n s e r t i o n C o m p l e t e Indicates the m o t o r c o m p l e t e d insertion of the PC Card Card Lock

Indicates a m e c h a n i c a l latch has b e e n closed to p r e v e n t

r e m o v a l of a PC Card C a r d U n l o c k Indicates a m e c h a n i c a l latch has b e e n o p e n e d to allow r e m o v a l of a PC Card

6.3.1.2.4

Callback M e c h a n i s m

Client notification of the aforedescribed events is d o n e with a special m e c h a n i s m k n o w n as the callback mechanism. A client is called back for a n y of the aforedefined events. Every Card Services client is required to i m p l e m e n t a callback handler. The callback h a n d l e r e n t r y p o i n t is passed to Card Services in the ClientEntry p a r a m e t e r of the RegisterClient call. A callback passes the following p a r a m e t e r s to the callback handler:

Status = CallbackHandler (Service, Socket, Info, MTDRequest, Buffer, Misc, ClientData) w h e r e the Service p a r a m e t e r indicates the e v e n t for w h i c h the callback h a n d l e r is b e i n g called. Table 6.3 summarizes the events, their causes, and the client's response.

6.3.1.3

Resource Allocation

O n e of the o t h e r i m p o r t a n t f u n c t i o n s of Card Services is to m a n a g e a n d c o o r d i n a t e access to various resources for the various clients. These resources include the following: 9 9 9 9

DMA c h a n n e l s I n t e r r u p t lines I/O address ranges M e m o r y address ranges

These resources are allocated with the RequestDMA, Request lO, RequestWindow, and RequestIRQ services.W h e n finished with the resource, the client releases the resource by using the c o r r e s p o n d i n g Release service. Card Services m a i n t a i n s an internal resource m a n a g e m e n t table. This table is used to track available, allocated, a n d free resources.

148

PCMCIA SOFTWARE: AN OVERVIEW

Table 6.3

Summary of events, causes, and client responses.

Event

Cause

Registration_Complete Card Services generates this upon completion of the registration process. Request_Attention

ResetComplete

Reset_Physical

A PC Card has set the REQ_ATN bit of the Extended Status Register. Card Services generates this upon completion of processing of ResetFunction request. Issued by Card Services to indicate a reset is about to

Client Response Gives control back to the client's foreground processes that originally made the register client request. PC Card and client specific. It could be used as a wake-up request. The client process that made the request will resume processing. Save hardware states if they may be lost upon a reset.

occur.

Reset_Request

$ $_Updated

Timer_Expired

Write Protect

Battery_Dead Battery_Low

A Client requesting ResetFunction service, causes Card Services to generate this event. A request for AddSocket Services or Replace SocketServices has been made. Card Services generates this event to indicate a timer has expired. Write Protect switch on the PC Card has been changed. BVD1 signal on a PC Card has been negated. BVD2 signal is negated.

Card Insertion

A PC Card is inserted into the socket. Artificially generated by Card Services during the processing of a RegisterClient request.

Card Lock

Indicates mechanical latch has been put into the lock position to prevent removal of the card. The PC Card's Ready line was asserted.

Card_Ready

If reset is not acceptable at this time then the client may prevent the reset by responding to this event. Client can react but generally there is no action expected from client. Client may perform any timer dependent processing. Client may check to determine the write protection state of the PC Card. Warn user that PC Card is not safe for storage of data. Warn user of the need to replace the battery. Clients may read CIS and then do a GetConfigurationInfo to determine if they wish to use the PC Card. An I/0 client can also Configure the PC Card using RequestConfiguration. If a Card is locked, the client can perform direct execution from the card. An MTD might respond to Ready to determine if Erase or Program has been completed.

6.3 CARD SERVICES" AN OVERVIEW

149

Event

Cause

Client Response

Card Removal

PC Card removal.

Card_Reset

A Reset has been completed in response to a Client requesting the ResetFunction. Mechanical latch has been unlocked. Card Services was requested to return information about a Client. The socket's ejection m o t o r has completed the card election. An end-user requests ejection of the PC Card in a motorized socket. A Client's erase request has been processed.

Release resources that were requested during configuration of the PC Card. Re-initialize the PC Card Function to the saved hardware state. Client must not perform any direct execution from the Card. Copy client i n f o r m a t i o n into the buffer provided by Card Services. Update any graphic showing the state of the socket.

Card Unlock Client_Info

Ejection_Complete

EjectionRequest

Erase_Complete

ExclusiveComplete

Exclusive_Request

Insertion_Complete Insertion_Request

PM Resume

PM_Suspend

The client requested exclusive access to a PC Card and has been granted exclusive access. Indicates a client has requested exclusive access to a PC Card. A motorized socket has completed insertion of a PC Card. An enduser is requesting a motorized socket to insert the PC Card. The power m a n a g e m e n t software indicates that the socket should resume n o r m a l operation. Power m a n a g e m e n t software has sent notification of the system power being Put in Suspend mode.

A Client m a y prevent or allow the ejection. Client verifies erase and t h e n m a y perform writes to initialize the erased block. Client m a y n o w access the PC Card on an exclusive basis. The client m a y prevent another client from gaining exclusive access to a PC Card. Update the status of the socket to the end user. A client m a y choose to prevent insertion of the PC Card. Client prepares for artificial Card Removal and Card Insertion events. D e p e n d i n g on the type of suspend the client m a y react: a) to save state i n f o r m a t i o n (Snapshot_Request) b) prevent or allow suspension (Query_Request) c) place PC Card in a reduced power m o d e (Conserve_Power) d) perform processing to allow orderly shut d o w n of system (No_Power)

150

PCMCIA SOFTWARE: AN OVERVIEW

At initialization either an embedded enumerator or an external resource enumerator indicates all the host resources available for use by a PC Card.

6.3.1.4

Bulk Memory Services

Another important function of Card Services is to provide memory access services that hide the details of the various memory technologies from clients. Card Services allows operations on the following types of m e m o r y objects: Regions A range of memory addresses consisting of the same device or device types M e m o r y Partitions A file system-specific area. There may be multiple partitions on a PC Card, one partition for each file system supported. Erase Queue A list of entries organized as a queue. Each entry identifies the region to be erased. Tuples The components of the CIS that describe the capabilities and requirements of the card At card insertion, Card Services identifies memory regions by reading the device information from the CIS. Card Services also supports access to the CIS by providing services to read tuples.

6.3.2

Basic Architecture Card Services provides the five following functional services: Client Services Allow registration of clients and client initialization

Resource M a n a g e m e n t Allow a client to obtain access to and manipulate available system resources Client Utilities Service basic capabilities used by all clients for generic operations such as tuple processing Bulk M e m o r y Services Provides memory access to higher-level clients such as file systems and isolates the client from the details of the memory technology involved. These services interface directly with MTDs to perform the memory operations. A d v a n c e d Client Services These services provide specialized capabilities for some types of clients.

6.3

CARD SERVICES: AN OVERVIEW

151

Figure 6.6 shows the functional architecture of the Card Services. Table 6.4 summarizes the Card Services calls by functional group.

6.3.2.1

Making a Card Services Call

Certain parameters are passed for each Card Services service call. These parameters are passed in a m a n n e r specific to the operating system a n d platform. The presence of Card Services is also tested in a m a n n e r specific to each platform. PC Card defines Card Services bindings for the following platforms: 9 9 9 9

DOS real m o d e OS/2 16-bit protect m o d e W i n d o w s 16-bit protect m o d e W i n d o w s flat 32-bit protect m o d e

For clients w h o use real-mode DOS, a service call to Card Services is m a d e by placing p a r a m e t e r values in the registers defined, placing AFh in register AH, a n d issuing an INTIAH. The parameters are defined in Table 6.5.

Figure 6.6

Functional architecture of Card Services.

152

PCMCIA SOFTWARE: AN OVERVIEW

Table 6.4

Card Services calls by functional group.

Call name

Code

Client Services DeRegisterClient GetCardServicesInfo GetEventMask GetStatus RegisterClient ResetFunction SetEventMask Resou~eManagem~Tt GetConfigurationInfo GetFirstWindow GetMemPage GetNextWindow MapMemPage ModifyConfiguration ModifyWindow ReleaseConfiguration ReleaseDMA ReleaseIO ReleaseIRQ ReleaseSocketMask ReleaseWindow RequestConfiguration RequestDMA RequestIO RequestIRQ RequestSocketMask RequestWindow

6.3.3

02h OBh 2Eh 0ch 10h 11h 31h

04h 37h 39h 38h

14h

27h 17h

1Eh 3Bh 1Bh ]C h

2Fh

IDh 30h 3Ah

1Fh 20h

22h 21h

Call name

Client Utilities GetFirstPartition

GetFirstRegion GetFirstTuple GetNextPartition GetNextRegion GetNextTuple GetTupleData Bulk M e m o ~ Se~ices CheckEraseQueue CloseMemory CopyMemory DeRegisterEraseQueue OpenMemory

ReadMemory

RegisterEraseQueue

WriteMemory

Advan~d ClientSe~ices AccessConfigurationRegister AddSo cke t S ervi ces Adj us tRes ourc eInf o GetClientInfo GetFirstClient GetNextClient MapLogSocket

MapLogWindow MapPhySocket

MapPhyWindow

RegisterMTD RegisterTimer ReleaseExclusive ReplaceSocketServices Request Exclusive ReturnSSEntry SetRegion ValidateCIS VendorSpecifc

Code

05h 06h 07h 08h 09h 0Ah 0Dh 26h 00h 01h 25h 18h 19h 0Fh 24h 36h 32h 35h 03h 0Eh 2Ah 12h 13h 15h 16h 1Ah 28h 2Dh 33h 2Ch 23h 29h 2Bh 34h

Fundamental Issues For software d e v e l o p m e n t t h e i m p o r t a n t issues are (1) h o w t o register t h e client software w i t h Card Services; (2) h o w to process a card i n s e r t i o n ; a n d (3) h o w to h a n d l e callbacks.

6.3

Table 6.5

CARD SERVICES: AN OVERVIEW

153

Card Services service call parameter description.

Register

Parameter

Description

Value

AH

Identifies call to Card Services Service being requested Handle for a specific object

AFh

AL DX

Card service call ID Service code Handle

DhSI

Pointer

CX

ArgLength

F,S-BX

ArgPointer

Some services request an additional pointer. For example, RegisterClient provides a pointer to its callback handler by means of this field. Length of the additional Depends on the service call. arguments field being For example, RegisterClient provided by client has four additional arguments, adding to 14 bytes, so the value is 0Eh. Pointer to the data buffer Determined by client that contains the additional arguments.

6.3.3.1

See Table 6.4 This value is typically obtained by performing a Request call Determined by client

Client Registration

Before registering with Card Services, a client m u s t verify the version c o m p l i a n c e of Card Services to identify the socket addressing scheme. The client m u s t also provide a callback handler, w h i c h u p o n i n v o c a t i o n e x a m i n e s the event field a n d takes appropriate action before r e t u r n i n g to the client. U p o n c o m p l e t i o n of the registration, the client t h e n m u s t wait for a card insertion event. The client t h e n processes the insertion, waits for the card removal event callback, a n d releases a n y resources it has taken.

6.3.3.2

Card Insertion

At a card insertion callback event, a client tries to d e t e r m i n e if it is interested in a card by obtaining the CIS i n f o r m a t i o n from Card Services. The client d e t e r m i n e s the configuration resources required by reading the configuration T a b l e E n t r y tuple. The client t h e n verifies availability of resources by issuing resource requests to Card Services. If all the resources are available, the client requests t h a t Card Services configure the

154

PCMCIA SOFTWARE: AN OVERVIEW

socket and the card. Figure 6.7 shows the entire process from registration through insertion and removal. At card insertion, Card Services also parses the CIS for the following tuples: 9 Device 9 JEDEC

Info ID

Figure 6.7 Use of Card Services for registration and insertion process.

6.3 CARD SERVICES: AN OVERVIEW 9 Function

155

ID

9 Manufacturer

ID

These tuples are used t o build device i n f o r m a t i o n a n d card i n f o r m a tion. Card Services is n o t required to p e r f o r m a u t o m a t i c c o n f i g u r a t i o n d u r i n g card insertion. However, each Card Services i m p l e m e n t a t i o n m a y c h o o s e to do that. 6.3.3.3

Callbacks

The callback e v e n t h a n d l e r can be i m p l e m e n t e d in m a n y ways. Basically, Card Services calls to notify the client of an event. The p a r a m e t e r s used in the callback are as follows:

Status = CallbackHandler (Service, Socket, Info, MTDRequest, Buffer, Misc, ClientData) For clients w h o use real-mode DOS, Card Services passes the p a r a m e ters by m e a n s of the CPU registers s h o w n in Table 6.6. For a card insertion event, Card Services provides the Service, Socket, Misc a n d Client Data parameters. A client usually exerts G e t C o n f i g u r a t i o n T n f o to learn the current state of the socket a n d PC Card.

6.3.4

Enabler Issues An enabler is a PCMCIA utility p r o g r a m used to enable or configure PC Cards. There are two types of enablers:

Table 6.6

Callback event parameters.

Register

Parameter

Value

AH AL BX ES:BX CX DX SI DI DS

Reserved EVENT Misc Buffer Socket Info Client data Client data Client data

Cleared to zero Event code Event-specific value Pointer to event buffer Socket and function number Event-specific value From R e g i s t e r C l i e n t From R e g i s t e r C l i e n t From R e g i s t e r C l i e n t

156

PCMCIA SOFTWARE: AN OVERVIEW

Generic Enabler Interprets the entire CIS to determine the configuration resource requirements of the PC Card. It then configures the PC Card for the appropriate resources. P o i n t E n a b l e r Enables a single PC Card. A point enabler normally does not read most of the CIS but relies on an identification mechanism to be sure that the PC Card is the specific one it is supposed to configure. The enabler then allocates the resources and configures the host and the socket. A generic enabler always works with Card Services, whereas a point enabler generally does not use Card or Socket Services. Instead it sets up the host automatically. A generic enabler is usually the more popular implementation. Enablers allow the PC Card to work with ISA legacy software, by configuring the card appropriately. They configure the PC Card so that it may work with existing DOS-type platforms. A generic enabler has to parse and interpret the CIS completely. It has to be able to interpret the basic tuples as well as the configuration tuple and the configuration table entry tuples. In PC Card 1995 release, a generic enabler also has to deal with multifunction PC Cards, configuring b o t h functions. An enabler typically does not know the host resources available. It must query Card Services by requesting the specific resource, for example, requesting interrupt 9. If the resource is available, the enabler must move to the next resource for the given configuration until resources for the entire configuration have been granted. It then configures the PC Card and socket by using the R e q u e s t C o n f i g u r a t i o n service call.

7 PC CARD: THE M EC HAN ICAL IS SU ES

7.1

OVERVIEW PC Card 1995 release defines three types of PC Cards. The three card types are the same in length and width but differ in thickness. The h o s t to-PC Card interconnect system consists of a female connector and a male fixed-pin socket connector. The female connector is located on the PC Card and connects to the male socket connector on the host system. PC Card 95 defines mechanical keys to prevent lower-voltage cards from being inserted into a socket that supports 5V only. These mechanical keys are used in conjunction with the C V S l and c v s 2 signals. The thickness restrictions of Type I and Type II cards require the PC Card designer to pay particular attention to the Z height of all the c o m p o n e n t s . This chapter covers Z-height calculations and takes the user t h r o u g h an example. PC Card also requires that frames contain the printed circuit board (PCB) and that covers enclose the PCB. For inputo u t p u t (I/O) cards, there m a y be I/O connectors to connect to external devices or cables.

7.2

PC CARD DIMENSIONS PC Cards use a form factor similar to that of credit cards. The three types of PC Card are the same in length and width but differ in thickness. The thicknesses are as follows: Type I, 3.3 m m Type II, 5 m m Type III, 10.5 m m Figure 7.1 shows the three PC Card form factors. Table 7.1 shows the dimensions of the three types of PC Cards. 157

158

PC CARD: THE MECHANICAL ISSUES

Figure 7.1

7.3

PC Card form factors.

Table 7.1

PC Card Dimensions

Card t y p e

Length in inches (mm)

Width in inches (mm)

Height in inches (mm)

Type I Type II Type III

3.37 (85.6) 3.37 (85.6) 3.37 (85.6)

3.37 (85.6) 3.37 (85.6) 3.37 (85.6)

0.13 (3.3) 0.196 (5.0) 0.413 (10.5)

HOST CONNECTOR The male fixed-pin socket c o n n e c t o r is m o u n t e d o n the host a n d mates with a PC Card. PC Card 1995 release defines a s h r o u d e d c o n n e c t o r for CardBus a n d an u n s h r o u d e d c o n n e c t o r for 16-bit PC Card. Each of these c o n n e c t o r s comes in v a r y i n g m o u n t i n g configurations. A user m a y c h o o s e from the following features:

7.3

HOST CONNECTOR

159

D u a l (stacked) c o n n e c t o r s Usually two Type II or one Type III connector E j e c t i o n m e c h a n i s m An ejection b u t t o n ejects the card R i g h t - a n g l e m o u n t A PCB m o u n t i n g o p t i o n S u r f a c e m o u n t A PCB m o u n t i n g option The s h r o u d e d c o n n e c t o r provides additional g r o u n d contacts to reduce the g r o u n d return current. Figure 7.2 shows the cross section of a s h r o u d e d connector. Three of the more critical specifications for the PC Card i n t e r c o n n e c t system are the following: 9 Contact 9 Ground 9 Number m u m of

r e s i s t a n c e Indicates voltage drop across i n t e r c o n n e c t r e t u r n i n d u c t a n c e Indicates g r o u n d b o u n c e effect o f i n s e r t i o n s or e j e c t i o n s PC Card 95 requires a mini10,000 insertions-ejections

Figure 7.2

Cross section of shrouded ground connector.

160

7.4

PC CARD: THE MECHANICAL ISSUES

PC CARD CONNECTOR Figure 7.3 shows the front view of a female 68-pin connector. This connector m o u n t s on the PC Card and mates with the 68-pin fixed-pin male socket to interconnect the PC Card and the host system. This connector is available as either a straddle-mount or a single-side m o u n t . The stradd l e - m o u n t is usually available only at center, whereas the single-side m o u n t is available in varying degrees of offset from center. Designers use the offsets to adjust for c o m p o n e n t heights within the PC Card. Figure 7.3 also shows the low-voltage and 5V mechanical keys. The main purpose of these keys is to prevent misinsertion of a low-voltage PC Card into a 5V socket (to avoid damaging the PC Card). These keys are used in conjunction with VSl and vs2 to determine the voltage requirements of the PC Card.

7.5

PC CARD FRAMES A PC Card assembly consists of a PCB placed inside a frame and covers placed on the top and bottom. The frames and covers c o m b i n e d are k n o w n as the frame kit. Many different types of frame kits are available

Figure 7.3

68-pin female card connector.

7.6 PC CARD INPUT-OUTPUT CONNECTORS

161

for PC Cards. There are snap-on covers, which have a separate plastic frame, sonic-welded kits, in which a horn is used to assemble the frames, and laser-welded frame kits. The best quality and the most expensive of these are the laser-welded frame kits. Sonic-welded frame kits offer good quality at a reasonable price. Snap-on frame kits are the least expensive and have to be h a n d assembled, which increases m a n u f a c t u r i n g costs. Frame kits are sold by m a n y different vendors. The best resources to find vendors are either the PCMCIA Reference Directory or Mobile Computing Technology magazine.

7.6

PC CARD INPUT-OUTPUT CONNECTORS I/O PC Cards must connect to external devices or cables. For example, a f a x / m o d e m card must be connected to a telephone line. This external I/O connection is i m p l e m e n t e d with I/O connectors. An I/O c onne c tor usually connects to an external cable assembly that connects to the external device or cable. Various types of I/O connectors are available for PC Cards. Some of the more c o m m o n l y used I/O connectors are the following: 9 - p i n I/O c o n n e c t o r Typically used for f a x / m o d e m s 15-pin I / O c o n n e c t o r Originally designed for Ethernet 2 5 - p i n c o n n e c t o r General use M u l t i f u n c t i o n c o n n e c t o r Two-in-one I/O connectors This is not a comprehensive list of I/O connectors. New connectors are introduced frequently by vendors. It is best to contact the manufacturers for details.

7.7

HEIGHT ANALYSIS The low height of the PC Card form factor requires careful attention to package selection and an analysis of the various c o m p o n e n t s that take up some of the vertical space. The c o m p o n e n t s that generally affect height analysis are: 9 9 9 9

PC Card label (front and back) Metal covers (front and back) PCB IC or other c o m p o n e n t packaging

162

PC CARD: THE MECHANICAL ISSUES

9 I n s u l a t i o n b e t w e e n PCB a n d metal covers 9 68-pin female c o n n e c t o r offset from center Figure 7.4 shows a cross section of two cards for height-analysis purposes. Figure 7.4A shows a s t r a d d l e - m o u n t , center-offset connector. This assembly provides equal offsets for c o m p o n e n t s o n the top a n d the bott o m of the PCB. The top-side a n d b o t t o m - s i d e offsets are calculated as follows: Top side offset = (Card Height + 2) PCB thickness above center line - Label thickness - Cover thickness Insulation thickness PCB thickness above center line = Total PCB thickness + 2 -

-

This allows for a p p r o x i m a t e l y 1.94 m m above a n d b e l o w the PCB surface. T h a t h e i g h t w o u l d require a t h i n profile package such as TQFP or TSOE Figure 7.4B shows an offset connector, offset 0.9 m m b e l o w the center line. For this card o n e increases the top-side offset by reducing the bottom-side offset. The top-side offset is calculated as follows: Top side offset = (Card Height + 2) - Label thickness - Cover thickness Insulation thickness + C o n n e c t o r offset, w h i c h is 0.9 m m . This provides for a top side offset of a p p r o x i m a t e l y 3.41 m m , w h i c h is usually e n o u g h to a c c o m m o d a t e a PLCC package. The b o t t o m side offset is calculated as follows: B o t t o m side offset = (Card Height + 2) - Label thickness t h i c k n e s s - Insulation thickness -

C

o

v

e

r

-

PCB thickness - Offset, w h i c h is 0.9 m m .

For this card the b o t t o m - s i d e offset is a p p r o x i m a t e l y 0.8 m m , w h i c h is useful o n l y for discrete devices such as resistors a n d capacitors. This effectively restricts the b o a r d designer to a single-sided b o a r d for very large scale i n t e g r a t i o n (VLSI) c o m p o n e n t s . By varying the type of c o n n e c t o r s t h e designer can make tradeoffs in vertical space above a n d b e l o w the PCB.

7.7 HEIGHTANALYSIS Figure 7.4 Trade-offs in package height.

163

This Page Intentionally Left Blank

8 PC CARD HOST DESIGN

8.1

OVERVIEW There are m a n y issues in PC Card host platform design. The host has to provide full PC Card capability in hardware, operating system-specific drivers, and read-only m e m o r y (ROM)-based interface services in software. Mechanical issues related to the PC Card connectors and Vcc and Vpp switching must be solved. Figure 8.1 illustrates the building blocks required in a PCMCIA host implementation. A PC Card host must provide the following capabilities: 9 A hardware bridge (adapter) to convert from the host bus to PCMCIA 9 A software abstraction layer (Socket Services) to provide a hardwareindependent interface for low-level functions. Socket Services is designed to be located in ROM. 9 A software layer (Card Services) to support event management, interpretation of card configuration information structure (CIS) and interface to software clients 9 A generic enabler to configure the host adapter and the PC Card The software c o m p o n e n t s of the host are discussed in Chapter 6. This chapter focuses on the implementation of the bridge hardware and its application in support of PC Cards.

8.2

BASIC BRIDGE ARCHITECTURE The function of a bus bridge is to generate address, data, and control signals for a secondary bus from the host bus. If the address space of the host and the second bus are different, the bridge must also provide an address mapping mechanism. The bridges are of the following types: A bridge between a central processing unit (CPU) and an expansion bus (ISA bus controller)

165

166

PC CARD HOST DESIGN

Figure 8.1

Building blocks in a PCMCIA host implementation.

9 A bridge between an VESA Local (VL) bus 9 A bridge between an (ISA bus to SCSI) 9 A bridge between an SCSI)

expansion bus and a secondary expansion bus to ISA bus expansion bus and an input-output (I/O) bus I/O bus and an expansion bus (Centronics to

Figure 8.2 illustrates the various types of bridges. A PC Card bridge (host adapter) is placed at either the CPU bus, an expansion bus such as the ISA bus, or an I/O bus such as SCSI or Centronics. However, because all 16-bit PC Card bus cycles run at less t h a n 10 MHz, a typical 16-bit PC Card bridge is placed at an expansion bus or an I/O bus. For CardBus, the most appropriate place for a bridge is at the CPU or at a high-speed bus such as PCI.

8.2

Figure 8.2

BASIC BRIDGE ARCHITECTURE

167

Types of bus bridges.

CPU

Primary Bus

b..=

Bridge Bridge

Second Bus

Second Bus Primary Bus

Primary Bus

Bridge

0 Bridge

0

I/0 Bus (SCSI)

Second Bus

The PC Card interface is implemented on multiple platforms, ranging from personal computers (DOS machines, Apple Macintosh), to consumer electronics equipment (PDAs, digital cameras), to embedded systems (touters, oscilloscope). This requires implementation of many different types of bridges. Today in the personal computing world, VLSI implementations of 16-bit PC Card bridges are available for the ISA bus, Centronics (parallel port) and the CPU bus [such as one implemented on the Chips & Technologies (C&T) PC/Chip].

168

8.3

PC CARD HOST DESIGN

BASIC DESIGN ISSUES FOR A PC CARD BRIDGE There are some fundamental issues that all PC Card bridges, w h e t h e r 16bit or CardBus, must address. These are as follows: 9 9 9 9 9 9 9 9 9 9 9

8.4

Data transfer protocol conversion from host bus to PCMCIA Support of PC Card events such as card insertion and removal Support for byte steering to align data on the proper byte lanes Mapping of m e m o r y on a PC Card to the host space Mapping of configuration space (for CardBus) or attribute m e m o r y (for 16-bit PC Cards) to host space Mapping of I/O in host space Interrupt routing Voltage sensing Support for Vcc and Vpp switching For CardBus bridges, implementation of bridge windows to a hierarchy of buses Reset control

TYPES OF PC CARD HOSTS There are m a n y different types of hosts for PC Cards. They are divided into three broad categories--desktop and portable personal computers (PCs); h a n d h e l d computers such as PDAs; and embedded systems such as network routers and digital cameras. Desktop and portable PCs support both CardBus and 16-bit PC Card. For h a n d h e l d and embedded systems, 16-bit PC Card is the popular choice. I m p l e m e n t a t i o n of 16-bit PC Card interface on PCs varies a great deal from i m p l e m e n t a t i o n of a 16-bit PC Card interface in e m b e d d e d systems. For example, m e m o r y mapping in PC hosts is done by means of the w i n d o w i n g concept. In embedded systems, m e m o r y m a p p i n g may be i m p l e m e n t e d with an indirect access scheme. Both these schemes are explained in this chapter. Because CardBus i m p l e m e n t a t i o n is very different from 16-bit PC Card implementation, it is covered in a separate section.

8.4.1

PC-based Hosts Figure 8.3 is the block diagram of a PC host. PC-based hosts offer m a n y options. The PCMCIA bridge can be placed at the CPU bus, the PCI bus, or the ISA bus. For 16-bit PC Cards, an ISA-based PC Card interface is the

8.4 TYPES OF PC CARD HOSTS

Figure 8.3

169

Host block diagram.

most logical choice, although there are implementations for PCI to 16bit bridges. For CardBus a PCI-based bridge is the most logical choice, alt h o u g h a CardBus bridge on the CPU bus is also a possibility in non-PCI platforms.

8.4.1.1

16-bit Interface

An ISA to PCMCIA bridge implementation is the most c o m m o n 16-bit PC Card bridge. The host designer can choose from VLSI solutions from Intel, Cirrus Logic, Vadem, Data Book, and Fujitsu. The Intel, Cirrus, and

1 70

PC CARD HOST DESIGN

Vadem solutions are all software compatible with the Intel 82365SL ExCA implementation.

8.4.1.2

CardBus Interface

For CardBus the most logical implementation is a PCI to CardBus bridge. As in the 16-bit hosts, VLSI solutions for this implementation are available from m a n y different vendors. Most of the implementations are expected to be compatible with the Yenta specification. (Yenta is an organization that published a CardBus Bridge implementation specification.)

8.4.2

Embedded Hosts The 16-bit PC Card interface is the most c o m m o n implementation in embedded systems. Because PCMCIA is the expansion bus for the embedded systems, the 16-bit PC Card bridge usually lies directly on the bus of the embedded CPU.

8.5 8.5.1

16-BIT PC CARD HOST INTERFACE Basic Issues A c o m m o n implementation of the 16-bit PCMCIA interface provides a PCMCIA bridge on the ISA bus. There are VLSI solutions for a 16-bit PC Card bridge on the ISA bus from various vendors. The most popular of these devices are based on the Intel 365SL architecture. Figure 8.4 shows the schematic of a 16-bit PCMCIA bridge based on the Intel 365SL. The Intel 82365SL PCMCIA Interface Controller (PCIC) supports the PC Card interface. It provides the data transfer protocol conversion from ISA to 16-bit PC Card, byte steering capability, address mapping capability, event m a n a g e m e n t capability, and control over Vcc and Vpp.

8.5.1.1

Data Transfer Protocol Conversion

Although ISA and 16-bit data transfer protocols are similar, there are some differences, for example, in how 16-bit memory cycles are generated. The PCIC still has to convert a cycle on the ISA bus to a cycle on the appropriate socket. I/O cycles are fairly simple. If the address falls w i t h i n the enabled I/O window, it simply asserts the appropriate controls on the socket.

Figure 8.4

16-bit PC Card implementation on ISA.

c~

!

N N

I

Z

N

9

1 72

PC CARD HOST DESIGN

8.5.1.2 Byte Steering The 16-bit interface forces all 16-bit accesses to be aligned on even byte boundaries. However, odd byte ( A 0 - 1) accesses, in which CV.l# is asserted rather than CE2#, the data must be provided on the D7-0 byte lane. This requires the host to steer the odd byte from D7-0 to the appropriate byte lanes on the host bus.

8.5.2 Support of PC Card Events The PCIC can generate an interrupt w h e n STSCHG# becomes active. It also provides the ability to enable and disable interrupts on the following conditions: 9 9 9 .

Transitions on card detects Transition on READY Transition on write protect (WP) Transition on BVDI# and BVD2#

All these conditions collectively are called the status change interrupts. The status change interrupts may be steered to any of the interrupt lines on the ISA bus.

8.5.3 Interrupt Steering PCMCIA requires interrupts on the socket IREQ# line to be routed to any of the available interrupt lines. In an ISA-to-16-bit PC Card bridge, interrupt steering logic must be implemented to allow the IRV.Q# line to be steered to any of the available ISA interrupts, IRQ15, 14, 12-9, 7, or 5-2. The status change interrupts likewise may be steered to any of the available ISA interrupt lines. The logic for interrupt steering is shown in Figure 8.5.

8.5.4 Mapping M e m o r y can be mapped to the host address space in two ways: windowbased or indirect register-based access. In a windows based approach, the PC Card m e m o r y is mapped into a m e m o r y address range ( m e m o r y window) within the host address space. The m e m o r y w i n d o w is defined by a start or base address, a stop address, and an offset. If a host m e m o r y cycle lies within the m e m o r y range defined by the window, the cycle is passed to the appropriate socket.

8.5

16-BIT PC CARD HOST INTERFACE

1 73

Figure 8.5 Interrupt steering logic.

The indirect m e m o r y access approach relies on an address register p r o g r a m m e d with the m e m o r y address of the PC Card. Any access to that register results in a m e m o r y access to the current m e m o r y location as defined by the contents of the register. This can be e n h a n c e d by a u t o i n c r e m e n t or autodecrement at consecutive accesses. The address register may be m a p p e d into either the m e m o r y or the I/O space of the host. PCIC uses the m e m o r y w i n d o w mapping implementation. Figure 8.6 illustrates the m e m o r y w i n d o w concept. The start and stop registers define a window. The w i n d o w must be on 4KB boundaries. If the upper address A23-12 lies within the start and stop addresses, the cycle is assumed to be within the m e m o r y window. A23-12 then are added to the contents of the offset register, and the cycle is forwarded to the socket. The other issue in ISA-based hosts is that the ISA bus supports only 16MB of m e m o r y space, whereas 16-bit PC Card supports up to 64MB of

1 74

PC CARD HOST DESIGN

Figure 8.6 Memory window implementation.

m e m o r y address space. This requires a bridge, the PCIC, to provide a m e c h a n i s m to generate A25-24. The PCIC supports that m e c h a n i s m by providing an offset register, which is added to the base address to generate the PC Card 26-bit address. The offset register contains values for A25-12. The contents of the offset register are added to the host address A23-12 to obtain card address CA25-12. The lower 12 bits A l l - 0 are passed directly from the host to the card.

8.5.4.1

Mapping of Attribute Memory

Attribute m e m o r y is m a p p e d in a m a n n e r similar to that for c o m m o n memory, except that in the offset register a bit is used to set REG. W h e n the bit is set, the host asserts REO# for a m e m o r y cycle passed to the PC Card through this window.

8.5.4.2 Mapping of I/O Space in Host The I/O space is m a p p e d with an I/O window. The i m p l e m e n t a t i o n is similar to that for the I/O window. The only differences are that the offset register is not i m p l e m e n t e d and the I/O window can be located on any byte boundary. A software compatibility issue prevents the I/O ad-

8.5

16-BIT PC CARD HOST INTERFACE

1 75

dresses from being offset and requires that I/O w i n d o w s be based on a n y byte boundaries. 16-Bit PC Card allows two types of I/O d e c o d e s m a n overlapping I/O decode a n d a contiguous I/O decode. In an overlapping I/0 decode, the PC Card performs a hard decode of the address. The decode is configured by the configuration index. In contiguous I/0, the PC Card does n o t imp l e m e n t a hard decode; it relies on the host to forward the cycles for the correct address to the socket. The contiguous I/O r e q u i r e m e n t forces the host to align I/O w i n d o w s on byte boundaries.

8.5.5

Reset Control The card reset line m u s t be controlled by software. The PC Card R e s e t # bit is used to control the RESET signal on the 16-bit PC Card bus. W h e n cleared to 0, the bit asserts RESET. W h e n set to 1, the bit deasserts RESET. The host bridge automatically asserts RESET at power up a n d at card insertion.

8.5.6

Detecting Card Insertion and Removal 16-bit PC Card uses the card detect signals to detect card insertion. In the host, the card detects CDI# a n d CD2 # are pulled high by m e a n s of a weak (100K o h m ) pull-up. In the PC Card the CDI#, CD2# signals are grounded. W h e n the PC Card makes contact with the host, there is a high to low transition on b o t h the CD3# a n d CD2 # signals. The host can generate a status change interrupt at a transition on the card detects. The CD3 # a n d CD2# states are also readable from the host t h r o u g h the interface status register. W h e n the PC Card is removed, the CD3#, CD2# signals transition from low to high. Again a status c h a n g e interrupt m a y be generated or the state of the two signals can be m o n i t o r e d from the interface status register. The detection circuitry for card insertion a n d removal m u s t include a d e b o u n c i n g circuit to filter out the glitches on the card detects. The host also m a y automatically switch on Vcc at card insertion. The value of Vcc d e p e n d s on the VSl a n d v s 2 inputs. These inputs are pulled up weakly on the host side. On the card side they are treated as follows: 9 Floating 5V Vcc 9 vsX low, v s 2 floating 3.3V 9 v s l or v s 2 shorted to a C D x pin CardBus The logic for a card detection circuit is s h o w n in Figure 8.7.

176

PCCARDHOSTDESIGN

Figure 8.7

Card detection and voltage sensing logic.

Ic~ D Icol D

,

0

!~

~~--~ _~

i

Cardlns (Status Change)

SYSCLK

II ~

i

n

,

~

II_3 H

~

Vcc5V Vcc3V

[~

VccEn_5V

[~

VccEn_3V

8.5.7 Switching Interface In 16-bit PC Card, three similar but different interfaces are supported. Memory-only, I/O-Memory, and DMA. This requires that the bridge logic support two bits that can be used to set the interface mode. The interface m o d e is used to select the mode of the pins that change their functionality with the interface. The pins affected by the interface change are summarized in Table 8.1.

Table 8.1

Switching the interface.

Pin no.

Memory-only

I/O-memory

DMA

9 15

OE# WE#

OE# WE# IREQ# IOISl 6# IORD# IOWR# INPACK# REG # SPKR# STSCHG#

TC# (for DMA read) TC# (for DMA write)

16

33 44 45 60 61 62 63

READY WP RFU RFU

RFU REG# BVD2 BVD1

RFU,reservedfor future use.

DREQ# (optional 1 of 3)

DREQ# (optional 1 of 3) DACK DREQ# (optional 1 of 3)

8.5

8.5.8

16-BIT PC CARD HOST INTERFACE

1 77

Register Overview The PCIC has five m e m o r y windows, two I/O windows, a n d a set of general control-status registers per socket. For each m e m o r y window, there are three pairs of registers: Stop (high byte a n d low byte), Start (high byte a n d low byte), a n d Offset (high byte a n d low byte). For each I/O window, there are a pair of Start registers a n d a pair of Stop registers. For each socket, there are 10 control-status registers. Table 8.2 s u m m a r i z e s the PCIC registers available for each socket.

Table 8.2

Summary of PCIC registers.

Register name

Socket offset

Identification and revision

00H

Interface Status Power and ResetDRV Control Card Status Change

01H 02H 04H

Address Window Enable

06H

Card Detect and General Control

16H

Global Control Interrupt and General Control Card Status Change Interrupt Configuration

1Eh 03H 05H

Description Revision ID and allows control over type of interface (Memoryonly versus I/O-memory) State of the status and event pins Vcc control Status change interrupt sources (enable-disable) Enable and disable Memory/I/O windows Interrupts based on various card detect conditions Miscellaneous control Interrupt steering and socket reset Steering of card status change interrupts

I/0 Window Registers I/O Control I/O I/O I/O I/O

Window Window Window Window

07H 0 Start Low/High 0 Stop Low/High 1 Start Low/High 1 Stop Low/High

Bytes Bytes Bytes Bytes

08H/09H 0AH/0BH 0CH/0DH 0EH/0FH

Data width, wait states, 16-bit cycle configuration Start address A 15-0 Stop address A 15-0 Start address A 15-0 Stop address A 15-0

Memory Window Registers Memory Window 0 Start Low/High Bytes

10H/11H

Start address A23-12, data width, 0 wait states (continued)

1 78

PC CARD HOST DESIGN

Table 8.2 (continued) Socket offset

Register name Memory Window Bytes Memory Window Bytes Memory Window Bytes Memory Window Bytes Memory Window Byte Memory Window Byte Memory Window Byte Memory Window Byte Memory Window Byte Memory Window Byte Memory Window Byte Memory Window Byte Memory Window Byte Memory Window Byte

0 Stop Low/High

12H/13H

0 Offset Low/High

14H/15H

1 Start Low/High

18H/19H

1 Stop Low/High

1AH/1BH

1 Offset Low/High

1CH/1DH

2 Start Low/High

20H/21H

2 Stop Low/High

22H/23H

2 Offset Low/High

24H/25H

3 Start Low/High

28H/29H

3 Stop Low/High

2AH/2BH

3 Offset Low/High

2CH/2DH

4 Start Low/High

30H/31H

4 Stop Low/High

32H/33H

4 Offset Low/High

34H/35H

Description Start address A23-12, additional wait states Offset address A25-12, write

protect and REG# Start address A23-12, data width, 0 wait states Start address A23-12, additional wait states Offset address A25-12, write protect and REG# Start address A23-12, data width, 0 wait states Start address A23-12, additional wait states Offset address A25-12, write protect and REG# Start address A23-12, data width, 0 wait states Start address A23-12, additional wait states Offset address A25-12, write protect and RNG# Start address A23-12, data width, 0 wait states Start address A23-12, additional wait states Offset address A25-12, write protect and REG#

8.5.9 Reading Status and Events A host provides two m e c h a n i s m s to m o n i t o r the state of 16-bit PC Card status signals. The first is to read the status from the interface status register. WP, BVD1, BVD2, READY, r CD2# all are available in the interface status register. This requires the host software constantly to poll the register. The second m e c h a n i s m is to generate an interrupt at a transition in the state of status signals of interrupt. This procedure is performed with the card status change interrupt configuration and card detect and gen-

8.5

16-BIT PC CARD HOST INTERFACE

1 79

eral control registers. This m e c h a n i s m allows the host to process events only as t h e y occur; it does, however, introduce some latency in servicing these conditions. In m o s t cases the latency is n o t an issue.

8.5.10 Using Memory and I/O Windows M e m o r y w i n d o w s can be m a p p e d a n y w h e r e in the ISA m e m o r y space. The only r e q u i r e m e n t is that t h e y be aligned on a 4KB b o u n d a r y a n d start above the first 64KB of m e m o r y in the host. Each m e m o r y w i n d o w can be configured for the following:

9

9 D a t a b u s w i d t h 8 bits or 16 bits 9 W i n d o w size 4KB to 64MB, a l t h o u g h 4KB, 16KB, a n d 64KB are the preferred w i n d o w sizes 9 Cycle w a i t states M e m o r y w i n d o w for 16-bit cycles; can run at zero wait states (two ISA bus clocks typically run at 8 MHz). This allows the fastest 16-bit cycle to be c o m p l e t e d in 250 nsec (2 x 125 nsec) for an 8-MHz ISA bus. The 8-bit cycles can be c o m p l e t e d in one wait state, three bus clocks. This allows the fastest 8-bit cycle to be c o m p l e t e d in 375 nsec (3 x 125 nsec). Additional wait states can be configured with the stop high registers. 9 S o f t w a r e w r i t e p r o t e c t Write protects the m e m o r y space E n a b l e - D i s a b l e Enables or disables the m e m o r y w i n d o w

Typically m o s t ISA-based m a c h i n e s m a p the PC Card m e m o r y space below the 1MB m e m o r y address. The PC Card m e m o r y is m a p p e d into one of the three spaces t h a t are generally available. These spaces are s o m e t i m e s referred to as DOS holes. The following spaces are classified as DOS holes: D0000-DFFFFH E0000-EFFFFH C8000-CFFFFH A PC Card t h a t needs to m a p its attribute m e m o r y can use a n y of these spaces. For example, with the D0000H address, the attribute m e m ory is generally used to read the CIS a n d access the f u n c t i o n configuration registers. The CIS does not occupy m o r e t h a n 512B, a n d the f u n c t i o n configuration registers (FCRs) follow at the e n d of the CIS. The attribute m e m o r y of the PC Card m a p is s h o w n in Table 8.3. A m e m o r y w i n d o w of 4KB is sufficient to cover b o t h the CIS a n d the FCRs of the

180

PC CARD HOST DESIGN

Table 8.3 Example PC Card attribute memory addresses. Item

Attribute memory address

CIS FCR0 FCR1 FCR2 FCR3 FCR4

00h-FFh 100h 102h 104h 106h 108h

card. Therefore, the start address is D0000H, a n d the stop address is D0100H. The address p r o g r a m m e d into A23-12 of the start address register is 0DOH. The bit m a p is as follows" A23 A22 A21 A20 A19 A18 A17 A16 A15 A14 A13 A12 0 0 0 0 1 1 0 1 0 0 0 0 The address p r o g r a m m e d into the stop address register is 0 D I H . The bit m a p is as follows: A23 A22 A21 A20 A19 A18 A17 A16 A15 A14 A13 A12 0 0 0 0 1 1 0 1 0 0 0 1 The use of the offset register is more complicated t h a n the use of the start address register. The offset register can be p r o g r a m m e d with a simple value to add or increase the address or with a 2 c o m p l e m e n t value to subtract or decrease from the start address. The 2 c o m p l e m e n t addition is especially useful for access of the CIS. The CIS m u s t start at PC Card address 00H. Typically the attribute m e m ory w i n d o w is located at an address higher t h a n 00H of the host space. In this example, it is m a p p e d into the host address space D00000H. The bridge logic has to take a base address of 0DOH a n d present t h a t as 000H to the PC Card. All -0 are passed directly from CPU so t h e y m u s t be set to zero. The address 000H is achieved by m e a n s of subtraction of the difference b e t w e e n 0DOH a n d 000H from the base address. The difference is 0DOH. To subtract 0DOH from the base address, one takes the 2 complem e n t by c o m p l e m e n t i n g 00DOH (the extra zero represents A25-24) a n d a d d i n g 01H to the c o m p l e m e n t . Figure 8.8 shows the m e c h a n i s m . The c o m p l e m e n t of 00, 0000, 1101, 0000b (00DOH) is 3F2FH. Adding 01H re-

8.5 16-BIT PC CARD HOST INTERFACE

Figure 8.8

181

Setting the offset for attribute memory.

A23 A22 A21 A20 0

0

0

0

A19 A18 A17 1

1

0

A16 A15 A14 A13 1

0

0

0

A12 0

Start Address

0DOH

PC Card A25-12 0000H

Offset Logical -00DOH Actual Value is 2s Complement of 00DOH=3F30H A25 A 2 4 A23 A22 A21 A 2 0 0

0

1

1

0 1

0 1

A19 A18 A17

A16 A15 A14 A13

0

0

1

1

0

1

0

0

0

1

1

0

0

1

1

0

0

0

A12 0 0

Logical 2s Complement

suits in 3F30H. The value in offset for A25-12 is written as 3F30. For attribute memory, the R~.G# is set. To access the address OOH in PC Card attribute memory, the host accesses address ODOOOOH in the host m e m o r y space. To access the FCRO (configuration o p t i o n register) at 0100H in PC Card attribute m e m o r y , the host accesses ODOIOOH in its m e m o r y space.

8.5.11

DMA Implementation

The 16-bit bus in the PC Card standard released in 1995 has the o p t i o n of s u p p o r t i n g a card I/O to host m e m o r y DMA capability. The register m o d e l for DMA was n o t specified in the PC Card standard. To support DMA, the socket m u s t allow the PC Card to be c o n n e c t e d to an ISA DMA c h a n n e l . This step m a y be done in a m a n n e r similar to interrupt request (IRQ) steering, in w h i c h the DMA request a n d acknowledge from the

182

PC CARD HOST DESIGN card is steered to the appropriate DMA channel on the ISA bus. Support m u s t also be provided for the host to configure the bus to DMA m o d e (switch the signals) and to enable and disable DMA. A DMA control register must be i m p l e m e n t e d that configures enable DMA mode and select DMA channel on the ISA bus.

8.5.12

Power Switching

In 16-bit PC Card and CardBus, the Vcc must be off (0V) w h e n no card is inserted. If a card is inserted, the Vcc must be at either 3.3V or 5V. The value is determined by VSl and vs2 pins for 16-bit PC Cards. The value is always 3.3V for CardBus PC Cards, and 5V or 3.3V for other 16-bit PC Cards. The 16-bit PC Card bridge or the CardBus bridge both must provide a 5V Vcc enable and a 3.3V Vcc enable signal. They also must provide a 5V Vpp enable or a 12V Vpp enable. Although both CardBus and 16-bit PC Card support two i n d e p e n d e n t Vpp signals, in most hosts and PC Card i m p l e m e n t a t i o n s these are treated as a single voltage supply source. There are m a n y possible approaches to providing Vcc and Vpp for b o t h 16-bit and CardBus interfaces. The next few sections discuss these approaches.

8.5.12.1 Simple Hard-wire Implementation This is a basic, simple connection of the 5V supply to the Vcc pins. However, CardBus requires Vcc to be always switched off until a PC Card is inserted. 16-Bit PC Card does not specifically require the Vcc to be switched, but it is still strongly recommended that Vcc be designed as switched. This is because of concerns about inrush current and potential damage to the interface on the PC Card caused by forward biasing of the electrostatic discharge (ESD) protection diodes. However, even if hardwired 5V Vcc implementation were provided, the designer must contend with the issue of Vcc rise and fall times. PCMCIA specifies the following parameters for Vcc and Vpp (Table 8.4). The Vcc rise and fall specifications are designed primarily to support battery-backed SRAM cards. In a simple hardwired 5V solution, the fall time is violated because Vcc instantly goes to 0V when the contacts break. This approach forces insertion and removal of the PC Card only when the system power is off. The inherent limitations in rise and fall in the system power supply circuits probably allow the Vcc rise and fall specifications to be met.

8.5

16-BIT PC CARD HOST INTERFACE

Table 8.4

183

Vcc and Vpp parameters. Parameter

Minimum

Maximum

Tolerance Tolerance Rise time Fall time

100 Bsec 3 msec

+5% +5% 300 msec 300 msec

Tolerance Tolerance

---

+5% +5%

Vcc

5V 3.3V 5-3.3V 5-3.3V vpp

5v (default at power-up) 12V

8.5.12.2 Switched Vcc Implementation The next simplest approach is to i m p l e m e n t a high-side switch, a power MOSFET, to switch off Vcc at host c o m m a n d . This has three benefits: 9 R e d u c e d power consumption Vcc is off; even standby current is not flowing 9 C o n t r o l l e d rise t i m e s Limits inrush current 9 C o n t r o l l e d fall t i m e s Prevents data corruption in SRAM cards The disadvantage of this approach is that the MOSFET introduces a voltage drop in Vcc. This drop is usually proportional to the MOSFET onresistance and the supply current. If the system power supply is at +_5%, any voltage drop violates the PCMCIA specifications. This requires the system power supply tolerance to be at most +4%, allowing for a +1% drop in the switching circuit. Figure 8.9 shows a simple i m p l e m e n t a t i o n of a 3.3V-5V switch.

8.5.12.3 Vpp Implementation A Vpp switching circuit can be i m p l e m e n t e d by use of a preexisting 12V*5% supply voltage and addition of a high-side p-channel MOSFET clamped to Vcc with a Schottky diode. The other option is use of a VLSI IC designed for PCMCIA applications that can switch Vcc and Vpp. Figure 8.10 provides an example of one such device, the Maxim 780 powerswitching device. Devices also are available from Linear Technology and Micrel Semiconductor.

184

PC CARD HOST DESIGN

Figure 8.9

A simple Vcc switching circuit. +12V

510K

510K

+5V

Vcc Output 5V Vcc En

3.3V Vcc En

l

+3.3V

8.5.13

Key Host Controller Vendors

Quite a few vendors provide 16-bit PCMCIA bridge controllers for ISA bus. These vendors include Intel Corporation, Cirrus Logic, Vadem, Omega Micro, Texas Instruments, Fujitsu, RICOH, VLSI Technologies, and Databook. The vendors can provide more information about the controllers.

8.6

CARDBUS HOST INTERFACE A CardBus bridge can be implemented either at the CPU bus or from a high-speed bus such as PCI. A PCI to CardBus bridge is expected to be the most popular implementation for desktop and portable computing platforms. Functionally, CardBus protocol and signals are similar to those of PCI. They differ from PCI in mechanical and physical characteristics; these are based on the PC Card form factor. CardBus uses a 68-pin interconnect system, whereas PCI uses 108 pins. CardBus also retains the hot

8.6

CARDBUS HOST INTERFACE

185

Figure 8.10 A VLSI implementation of a combined Vcc-Vpp switching circuit. +12V +5V A

Z

T

3.3V

T

T

I

VREF

_1_

T

PCIC AVccEn0 AVccEnl AVppEn0 AVppEnl

< o ADrv3

DO

ADrv5

AVpp AGPI#

v

PRI#

[

T

I

i1"_

Vcc

VFP 3_ T

--o

8

~

1

I

_I_

-

I

i n s e r t i o n I a n d a u t o c o n f i g u r a t i o n at i n s e r t i o n capabilities of PCMCIA. T h e hierarchical bus structure s u p p o r t e d by PCI also is s u p p o r t e d by CardBus. This allows s i m u l t a n e o u s data transfer o p e r a t i o n s o n different levels of t h e bus hierarchy. Figure 8.11 shows t h e block d i a g r a m of a C a r d B u s - P C I - b a s e d h o s t system. T h e basic issues w i t h i m p l e m e n t a t i o n of a CardBus Bridge are as follows: Bus Hierarchy

Support

CardBus s u p p o r t s a hierarchical bus structure.

This allows m u l t i p l e CardBus buses to be i m p l e m e n t e d in a h o s t a n d ar-

1. The term hot insertion is frequently misused. In this discussion, hot insertion refers to the ability to insert a card into a socket without powering down the system. This is different from inserting a card in a hot socket, in which the socket Vcc is on.

186

PC CARD HOST DESIGN Figure 8.11 Block diagram of a PCI-CardBus host system.

I CPU Local CPU Bus

-I DRAM

VC~

PCI Bridge

I

Primary PCI Bus

I "

CardBus PCI Interface Configuration Space Target/ Master CardBus 16-bit PC Card Interface Interface Arbiter

. . . . . . . . . . . . . . . . . . . . . .

, ,

,,

vc_~

i

,

CardBus Bridge CardBus

CardBus116-bit

f

f

--~

i i

~

J

~

J

ranged in a hierarchical manner. Each of these buses is isolated from its contiguous buses by means of a CardBus-to-CardBus bridge. A CardBus bridge must i m p l e m e n t a bridge window to allow addresses to be forwarded to another bus. Address M a p p i n g CardBus implements a positive decode. All I/O or m e m o r y cycles are passed to the CardBus PC Card. The PC Card is required to decode the full address to determine if it can respond to the bus transaction. A CardBus bridge therefore does not have to i m p l e m e n t any I/O or m e m o r y space mapping. The CardBus PC Card addresses and the

8.6 CARDBUS HOST INTERFACE

187

host system addresses are identical. The CardBus bridge does, however, have to provide m a p p i n g support for the configuration space and bridge windows to buses lower in the hierarchy. M a p p i n g C o n f i g u r a t i o n Space CardBus bridges must provide a mapping scheme to map the configuration space of CardBus PC Cards and the configuration space of the bridges and devices below the current bus. Bridge C o n f i g u r a t i o n A PCI-to-CardBus bridge must i m p l e m e n t a PCI configuration header and configuration space. This is used to configure and control the bridge. M a n a g i n g PC C a r d Events Like the 16-bit bus, CardBus also has to provide m e c h a n i s m s to m o n i t o r status signals and to generate C S T S C H G # interrupts. M a n a g i n g I n t e r r u p t s This is a complicated issue. The CardBus-PCI interrupt scheme is different from the 16-bit PC Card-ISA interrupt scheme. 16-bit PC C a r d S u p p o r t A CardBus socket is required to support 16-bit PC Cards if inserted. This requires that a CardBus bridge include 16-bit PC Card bridge logic. CardBus Arbiter To support bus master operations on CardBus devices, a bridge must i m p l e m e n t a local CardBus arbiter. This arbiter must arbitrate accesses to resources b o t h on the local CardBus and on other buses above and below the current bus. Error H a n d l i n g

CardBus, like PCI, has support for parity errors on address and data. Parity generation and parity error detection both must be i m p l e m e n t e d in the bridge.

S w i t c h e d P o w e r S u p p l y CardBus sockets are required to turn off Vcc w h e n no PC Card is present. This necessitates that the CardBus Vcc supply be switched. This issue is discussed in section 8.5.12.

8.6.1

Hierarchical Buses CardBus supports a hierarchical bus structure. This allows one or more buses to be placed below any given CardBus. There can be as m a n y as 256 different buses in a CardBus host. The buses within a hierarchy are identified by bus number. The t o p m o s t CardBus bus, the one closest to the CPU, is bus n u m b e r 0. The bus immediately below bus n u m b e r 0 is bus n u m b e r 1, and so on. Figure 8.12 shows the concept of a bus hierarchy in CardBus.

188

PC CARD HOST DESIGN Figure 8.12

Bus h i e r a r c h y .

Primary PCI Bus r

I CardBus Bridge

CardBus 0

f

CardBus 1

CardBus Bridge

CardBus2

CardBus Bridge

t

CardBus3 CardBus4

Ca c: us,CariU::r r

t

CardBus5

1l tt r

CardBuslOt CardBus12 3us91 CardBus11 CardBus13

't

t

In a host i m p l e m e n t i n g hierarchical buses, a PCI-to-CardBus bri,dge provides the primary CardBus interface. CardBus-to-CardBus bridges provide access to secondary buses or another level of CardBus-to-CardBus bridges. In Figure 8.12 CardBus-to-CardBus bridges on CardBus 0 and CardBus 1 are peer bridges, but bridges on CardBus 0 and CardBuses 2 and 3 and CardBuses 6, 7, 8, and 9 are arranged in a hierarchy. A hierarchical bus configuration allows for concurrence, especially if most of the accesses tend to be between CardBus devices. A peer bus configuration makes sense if most of the accesses tend to be between a CardBus device and the system memory. Hierarchical designs that i m p l e m e n t more t h a n two levels of hierarchy do not provide m u c h benefit and should be avoided.

8.6 CARDBUS HOST INTERFACE

8.6.1.1

189

Deadlocks

Issues with i m p l e m e n t a t i o n of a hierarchical bus structure m u s t be considered before i m p l e m e n t a t i o n . The most i m p o r t a n t issue is deadlock. W h e n there are two or more buses in a system, bus i n d e p e n d e n c e m u s t be restricted to avoid deadlock situations. A deadlock occurs w h e n a device on a given bus tries to access a resource on a second bus while a device on the second bus is requesting access to a resource on the first bus. Neither access can be c o m p l e t e d a n d n e i t h e r bus can be released w i t h o u t c o m p l e t i n g the access, so a deadlock occurs. There are two possible solutions to avoiding deadlock: (1) implem e n t a t i o n of tightly coupled hierarchical buses to eliminate concurrence or (2) i m p l e m e n t a t i o n of a back-off m e c h a n i s m while concurrence is allowed on the hierarchical bus configuration. In tightly-coupled bus structures, concurrence b e t w e e n multiple buses is e l i m i n a t e d a n d only one bus is allowed to be active at any time. This simplifies system design at .the expense of performance. If a c o n c u r r e n t bus configuration is desired, at least one device m u s t i m p l e m e n t a backoff m e c h a n i s m before two buses can be allowed to run concurrently.

8.6.1.2 Implementing Bridge Windows To support hierarchical bus structures, a bridge s u p p o r t i n g a secondary bus m u s t forward t h r o u g h a bridge w i n d o w I/O or m e m o r y cycles m e a n t for the secondary bus. A bridge w i n d o w m a y be i m p l e m e n t e d t h a t is similar to m e m o r y or I/O w i n d o w s in 16-bit PC Card adapters. In m o s t systems, however, CardBus is expected to be the lowest bus in the hierarchy a n d therefore does not need to i m p l e m e n t bridge windows.

8.6.2

CardBus Host Mapping Issues A typical PCI-to-CardBus bridge is expected to provide two sockets. Each socket is addressed as a separate function. Each socket also has its o w n configuration space. Each CardBus bridge is assigned its range of address space, w h i c h is m a p p e d into the host space. The bridge is expected to have a p r i m a r y bus, the PCI bus, and a secondary bus, the CardBus, for each socket. At initialization the host assigns address space to each of the secondary buses of the bridge. Subsets of those address spaces are t h e n available to be assigned to CardBus PC Cards. CardBus uses same addressing as the host address space, so no address translation is n e e d e d for m e m o r y and I/O addresses. For configuration space accesses to a CardBus card, however, a CardBus bridge m u s t provide a m a p p i n g m e c h a n i s m . The m a p p i n g scheme defined is based on

190

PC CARD HOST DESIGN

use of an indirect access scheme. Two 32-bit I/O ports at 0CF8H and OCFCH have been defined. The port at 0CF8H is k n o w n as the CONFIG__ADDRESS register. The port at 0CFCH is k n o w n as the CONFIG_DATA register. If the CONFIG ADDRESS register is enabled, access to 0CFCH translates into access to the configuration space of the CardBus PC Card. The PCI bridge, however, i m p l e m e n t s the same registers at the same I/O space. In a PCI environment, the PCI bridge already i m p l e m e n t s these two registers. In this case, access to the configuration space on the CardBus bridge is local access and uses type 0 configuration access. Access to the configuration space on a CardBus card is treated as an access to a seco n d a r y bus, so it is initiated as type 1 access to a secondary bus. Figure 8.13 shows configuration space m a p p i n g m e c h a n i s m s for PCI and CardBus.

8.6.2.1 Configuration Space Mapping The CPU-to-PCI bridge uses the same m a p p i n g m e c h a n i s m as PCIto-CardBus bridge. The CONFIG_ADDRESS register is at 0CF8h, and the CONFIG_DATA register is at 0CFCh. The CONFIG_ADDRESS in PCI has to point to the CONFIG DATA in CardBus. So an access to PCI's CONFIG DATAwill result in an access to CardBus CONFIG_DATA which in turn will result in an access to CardBus PC Card Config Header.

8.6.2.2 I/O Mapping A CardBus bridge must support at least m e m o r y - m a p p e d I/O. It m a y optionally support both m e m o r y - m a p p e d I/O and an I/O space. The decode for the I/O spaces is performed in the PC Card. This simplifies the I/O space support in the CardBus bridge. A CardBus bridge should provide at least two I/O m a p p i n g register pairs for each socket. The I/O base registers assign an I/O range to the bridge and its secondary buses. For each I/O base and limit register, there must be a corresponding m e m o r y base register to allow the I/O ports to be used as m e m o r y - m a p p e d I/O. Figure 8.14 shows the m a p p i n g of the bridge.

8.6.2.3 Memory Mapping The CardBus bridge does not have to i m p l e m e n t a special m e m o r y - m a p ping scheme. CardBus m e m o r y addresses are physically the same as host m e m o r y addresses. However, each socket on the bridge is allocated its m e m o r y address range, some of which m a y be allocated to CardBus PC Cards. The m e m o r y is allocated with m e m o r y base registers, which m a y be used for m e m o r y - m a p p e d I/O. M e m o r y space is classified as follows:

8.6 CARDBUS HOST INTERFACE

191

Figure 8.13 Configuration space mapping for CardBus bridge.

C a c h e a b l e Transfers between resources on CardBus that involve cacheable m e m o r y must be presented to the CPU caches for snooping. The bridge must be able to forward addresses of cacheable m e m o r y transactions on CardBus to the PCI bridge, which then is required to run cache-snooping cycles to the CPU caches.

192

PC CARD HOST DESIGN

Figure 8.14

Host I / 0 mapping mechanism.

Prefetchable This type of m e m o r y is not cacheable but may be read without any side effects. Typically the CardBus bridge would prefetch this type of m e m o r y into a read first in, first out (FIFO). N o n c a c h e a b l e This type of m e m o r y may not be cached nor prefetched. It is typically used for buffering data from I / 0 devices.

8.6.3 Interrupts Interrupt support is probably the most interesting subject as far as host implementations are concerned. CardBus uses a level-triggered interrupt, tINT#, from the PC Card. It also generates a status change interrupt by means of the r signal. PCI allows up to four interrupt lines for a multifunction device, so a CardBus bridge with two sockets may imple-

8.6 CARDBUS HOST INTERFACE

193

m e n t four interrupt lines. The PCI bridge then redirects these interrupts from the CardBus bridge to any one of the 15 IRQ lines available from the interrupt controller, although some of those lines are allocated to other devices and may not be used. Figure 8.15 illustrates the interrupt hierarchy.

8.6.4

16-bit PC Card Support The CardBus bridge is required to provide support for a 16-bit PC Card interface. Each socket is required to implement registers to support the 16-bit interface. The most popular approach is implementation of the 365SL register set for each socket. The only issue is the mapping of these registers. These registers could be mapped either as memory-mapped I/O or I/O only. Because of the number of these registers, they are more suited to memory-mapped I/O.

8.6.5

Handling Parity The CardBus bridge must generate parity for (1) all data being provided by its internal registers and spaces and (2) all addresses on both the pri-

Figure 8.15

I

I

I n t e r r u p t hierarchy in a CardBus host.

1 C,NTq

PCI Bridge

NTA#1~ CardBus CSTSCHGI NTB#.~ PC Card j "-I CardBus INTC#] Bridge INTD#~ CardBusj c SC Tadrs C H G P c I_ INTA# ,,~ PCI Device [INTB# I INTA# INTB# ~ PCI Device LINTC#...._~ " NTD# ~.

L I

"

_IRQ0~I~ _IRQ1~ System -IRQ2~I~ Interrupt Controller _IRQ3__Ip4 _IRQ4~I~ _IRQ5~I~ _IRQ6~ _IRQ7__~ _IRQ8.~ _IRQ9~4 _IRQ10_.I~ _ IRQ11

_IRQ12.~ _IRQ13_I~ _IRQ14_~ _IRQ15IJ

"1

CPU INTR

194

PC CARD HOST DESIGN

m a r y and the secondary buses. The bridge m u s t check parity o n data parity during transactions on b o t h primary and secondary buses. Parity h a n d l i n g is controlled by the bridge control register.

8.6.6 Bridge Configuration and Status Registers Each function (or socket) on the bridge must i m p l e m e n t a configuration header and event registers. W h e n configured for two sockets, the bridge has two separate configuration spaces. Table 8.5 lists the registers for each configuration header.

Table 8.5 CardBus bridge configuration registers. Device ID

Vendor ID

00h

Status

Commands

04h

Class Code = 060700h Latency timer

Header type = 82h

BIST

Revision ID

08h

Cache line size

0Ch

PC Card socket and status control registers Secondary status CardBus latency timer

Reserved

Subordinate bus # CardBus bus #

PCI bus number

10h 14h 18h

Memory base 0

1Ch

Memory limit 0

20h

Memory base 1

24h

Memor~ limit 1

28h

I/O base 0 (upper 16-bits optional)

I/O base 0 (lower 16 bits)

2Ch

I/O base 0 (upper 16-bits optional)

I/O limit 0 (lower 16 bits)

30h

I/O base 1 (upper 16-bits optional)

I/O base 1 (lower 16 bits)

34h

I/O base 1 (upper 16-bits optional)

I/O limit 1 (lower 16 bits)

38h

I

Bridge control

Interrupt pi n

IInterrupt line

Subsystem vendor ID

Subsystem ID

16-bit PC Card register base address

3Ch 40h 44h

Reserved

48-7Fh

User defined

80-FFh

8.7

8.6.7

EMBEDDED SYSTEMS HOST INTERFACE

195

Arbitration A CardBus bridge must provide arbitration for b o t h secondary buses. Typically the primary bus has higher priority t h a n the secondary buses. The bridge arbitrates for access to resources on its secondary buses and access to resources on the primary bus from the secondary buses. One typically conducts arbitration by using CREQ# on the secondary bus and looking at FRAME# on the primary bus. If the bridge or secondary bus resources are unavailable to the primary bus, the bridge must indicate a retry to the primary bus access.

8.6.8

Latency Timer Every Cardbus bridge must i m p l e m e n t a latency timer. This is used to ensure that a master does not exceed its hold on a bus beyond the specified limit. A good i m p l e m e n t a t i o n for m e a s u r e m e n t of a latency timer is units of 4, 8, or 16-PCI clocks.

8.6.9

CardBus Summary A CardBus interface is i m p l e m e n t e d either as a bridge from PCI or a bridge on the CPU bus directly. A typical bridge i m p l e m e n t s two sockets; each socket interface is treated as a separate function. The m a p p i n g issues with CardBus primarily involve m a p p i n g of configuration space. I/O and m e m o r y m a p p i n g is fairly simple. The interrupt implementation in CardBus is different from that for 16-bit PC Card because of the PCI interrupt-handling schemes. This produces compatibility issues for 16-bit PC Cards in CardBus sockets. Overall, CardBus bridges are expected to be primarily PCI-to-CardBus i m p l e m e n t a t i o n s and offer support for 16-bit PC Cards as well as CardBus PC Cards.

8.7

EMBEDDED SYSTEMS HOST INTERFACE Embedded systems usually provide a single PCMCIA socket either for storage or for peripheral function expansion. They generally do not require support for hot insertion or several different PC Cards. Embedded systems usually i m p l e m e n t a simple 16-bit PC Card interface with a cust o m software interface. Card Services or Socket Services are not implemented. Examples of embedded applications are laser printers, fax machines, routers, and set top boxes. The requirements of e m b e d d e d applications dictate a different PCMCIA interface, m u c h simpler in imple-

196

PC CARD HOST DESIGN

mentation and lower in cost than a PC interface. Vcc switching, interrupt routing, I/O and memory mapping, and PC Card and socket event management also are much simpler. Figure 8.16 shows the block diagram of an embedded system. Most embedded systems are expected to use 16-bit PC Card interface. The 16bit PC Card interface bridge is expected to be implemented directly on the CPU bus of the embedded system. It provides the following capabilities. Data Transfer Protocol Conversion f r o m CPU Bus to 16-bit PCMCIA This procedure still has to be done. The only important issue is wait-state generation to match the speeds supported by the 16-bit interface. This necessitates a programmable wait-state generator and depends on the frequency of the CPU clock. M a p p i n g of M e m o r y o n a PC Card to the Host Space The m e m o r y mapping mechanism can be implemented in two ways: memory windows and indirect memory accesses. Because embedded CPUs typically do not have a large memory space, the indirect memory approach is bet-

Figure 8.16 Block diagram of an embedded system.

8.7

EMBEDDED SYSTEMS HOST INTERFACE

197

ter suited to this purpose. The indirect m e m o r y m a p p i n g m e c h a n i s m also takes up less logic.

M a p p i n g of I/O in CPU Space Most embedded-system CPUs do not support a separate I/O space, so the PCMCIA bridge would probably map it into the m e m o r y space of the CPU. In this situation an indirect access scheme is useful. M a p p i n g of Attribute M e m o r y to Host Space This application should use the same mechanism as m e m o r y mapping but also include a bit in the indirect address register to set REG#. Support of PC Card Events Such as Card Insertion and Removal This requires card detect logic to detect that CDI# and CD2# are becoming low. If the application supports hot insertion, it should provide logic to automatically turn on Vcc at card insertion and turn off Vcc at card removal. Support for Byte Steering to Align Data on the Proper Byte Lanes This feature depends on the CPU implementation. It may be required in some systems and may not be required in others. Interrupt R o u t i n g The bridge logic must support two interrupts: IREQ# and STSCHG#. These interrupts can be mixed into a single CPU interrupt line or can be connected to the I/O ports that most microcontrollers implement. The bridge also must provide enable-disable logic for each interrupt line. For STSCHG#, it must implement logic to enable interrupts for specific events such as READY and Battery Low. Reset Control The bridge must provide software control over the PC Card reset line. This can be done through a bit in a register. Status M o n i t o r i n g The bridge must provide a means to monitor all the status signals on the bus. This monitor can be implemented by means of a status register. Vcc S w i t c h i n g If hot insertion is not required, the bridge does not have to implement a power supply switching circuit. If hot insertion is desired, the bridge must implement a power supply switching circuit, which can be enabled and disabled under software control. The embedded i m p l e m e n t a t i o n of 16-bit PC Card is a fairly simple bridge. A typical bridge implements the following registers:

General Control Register Power control, reset control, interrupt enables, interface mode, and enable/disable for indirect access registers.

198

PC CARD HOST DESIGN 9 Status Register VS2, a n d W P

Status of READY, BVD1, BVD2, CDI#, CD2#, VSI,

9 S T S C H G Interrupt Control

Enable a n d disable for the various

events which may generate a S T S C H G # interrupt 9 I n d i r e c t M e m o r y Address Register 0 - 4 The actual n u m b e r of these registers depends on the address space of the CPU and the address space supported. It also includes bits for REG# and autoincrem e n t and autodecrement modes as well as wait states. 9 I/O Access Register 0-4 Same as indirect m e m o r y address registers These registers may be mapped into the I/O space if available. They can also be treated as m e m o r y - m a p p e d I/O. Mobile Media Research markets an embedded PCMCIA interface core that provides the aforedescribed functionality. For more information, the reader may contact Mobile Media.

9 DESIGNING PCMCIA CARDS

9.1

OVERVIEW This chapter focuses on PC Card design. It covers b o t h 16-bit PC Card design a n d CardBus PC Card design. The key issues for a PC Card designer are: 9 Height analysis to make sure height constraints are n o t violated. This requires analysis of c o m p o n e n t package heights, a n d c o n n e c t o r a n d PCB thickness to ensure t h a t the card stays w i t h i n the specified h e i g h t of 3.3 m m , 5 m m , or 10.5 m m . 9 Interface design to provide a bus interface to the I/O or m e m o r y device. This necessitates providing the proper interface to the host, imp l e m e n t i n g the registers, a n d h a n d l i n g reset, interrupt, a n d status signals. 9 Electrical design to m i n i m i z e power c o n s u m p t i o n a n d g r o u n d bounce. G r o u n d b o u n c e is an i m p o r t a n t issue in PC Card design. The designer m u s t take steps to m i n i m i z e g r o u n d b o u n c e even with the slow 16-bit PC Card bus. Driver sizing is an issue for b o t h 16-bit a n d CardBus PC Card. Clock m a n a g e m e n t a n d a u t o m a t i c wake-up by m e a n s of C S T S C H G are i m p o r t a n t issues for CardBus PC Cards. 9 Electrical design to m i n i m i z e inrush current. Inrush current can be a compatibility issue, especially for h a n d h e l d devices. 9 C o n f i g u r a t i o n i n f o r m a t i o n structure (CIS) design. This is an import a n t compatibility issue for PC Cards. 9 Selection of frame kit a n d connector. A m e c h a n i c a l issue. 9 PCB design. CardBus puts certain restrictions on PCB layout. 9 Test a n d debug. Extremely i m p o r t a n t in PC Cards. Selection of proper tools can be the difference b e t w e e n success a n d failure.

199

200

9.2

DESIGNING PCMCIA CARDS

16-BIT PC CARD DESIGN The design of a 16-bit PC Card requires careful thought to mechanical dimensions, such as card height, connectors, and frame. Squeezing the functionality into the credit card type form factor requires integration at the silicon level and compact packaging technologies for ICs and boards. Electrically the designer must also pay attention to the live insertion and dual voltage operating capabilities of a PC Card. The PCMCIA interface includes function configuration registers (FCRs) and the CIS. Both require careful thought to ensure proper conformance to the standard. Multifunction PC Cards also require careful consideration of decoding and interrupt handling.

Mechanical Requirements

9.2.1

PCMCIA has defined three different card typesmType I, Type II, and Type III. Each type shares the same basic form factor but varies in height. Type I slots are 3.3 mm, Type II slots are 5 mm, and Type III slots are 10.5 m m high. Most PC Cards are designed with a Type II configuration. Figure 9.1 shows the profile of a Type II PC Card.

Figure 9.1

Type II PC Card profile.

9.2

16-BIT PC CARD DESIGN

201

The height restriction of a Type II card requires the use of an extremely thin PCB, such as an 18-rail PCB. It also requires the use of lowprofile IC packages such as Thin Quad Flat Pack (TQFP), SSOP, or TSOP. The frame on the card must be keyed to prevent improper insertion. The 68-position connector (receptacle) must be carefully chosen to provide the m a x i m u m height while allowing for ease of assembly and a high degree of reliability.

9.2.2 Interface Design Most PC Cards are designed with standard off-the-shelf m e m o r y or I/O devices. The 16-bit PCMCIA interface is i m p l e m e n t e d in either a programmable device or a gate array (ASIC) and is eventually expected to be integrated into the m e m o r y or I/O device. Figure 9.2 shows a simple block diagram for a PC Card implementation. Type I and ~[ype II form factors require a low-profile package such as a TQFP. An ASIC device in a TQFP package is more cost effective t h a n a FPGA. VLSI devices used in a 16-bit PC Card if clocked should be static and should also use low-power o u t p u t drivers with slew-rate control.

9.2.2.1 Implementing Configuration Information Structure (ClS) in Memory A 16-bit PC Card has to support a CIS for storage of the configuration tupies. A designer can i m p l e m e n t the CIS store in three different ways: 1. Storage in a parallel programmable m e m o r y device such as EEPROM 2. Storage in a serial programmable device such as a serial EEPROM 3. Hard coding into read-only m e m o r y (ROM) e m b e d d e d within the interface logic A ROM approach provides the least expensive solution and can be easily integrated into the interface logic if a gate array is being used. However, the CIS must be frozen. Experience shows that m a n y PC Card vendors have faced compatibility problems because of an incorrectly designed CIS and have been forced to modify their CIS. It is r e c o m m e n d e d that CIS be stored in a writable m e m o r y such as EEPROM. Serial EEPROMs are generally about one third of the price of a parallel EEPROM; they also use a m u c h smaller footprint package. However, serial EEPROMs require a more complex interface and a separate r a n d o m access m e m o r y (RAM) to load the CIS into the interface. Reading the CIS directly from serial EEPROM is extremely slow and severely slows pro-

202

DESIGNING PCMCIA CARDS

Figure 9.2

Block diagram of a 16-bit PC Card.

cessing of the CIS, making configuration of the PC Card an extremely slow (noticeable by the end user) process. Typical CIS size is 256 bytes. This requires a 256 x 8 RAM as CIS buffer in the interface logic. The designer must make the cost trade-offs. 16-bit PCMCIA defines two interface modesmMemory-only interface and I/O-Memory interface. At power-up or reset, a 16-bit PC card must

9.2

16-BIT PC CARD DESIGN

203

Table 9.1 Outputs that must be multiplexed to the host. Memo~/-only mode

I/O-memo~/ mode

READY BVDI BVD2 WP

STSCHG# SPKR#

IREQ#

IOISI 6 #

be in the M e m o r y - o n l y interface. An I/O card that uses the I/O interface also must come up in the Memory-only mode. It m a y change to the I/O interface at configuration. This requires that the 16-bit PC Cards multiplex some Of the outputs to the host. The outputs affected are shown in Table 9.1. Figure 9.3 shows the multiplexed output circuits. At power-up, 5V PC Cards must restrict their Vcc current to less t h a n 100 mA and 3.3V PC Cards must restrict their current to less t h a n 70 mA until the card has been configured. This requirement is i m p l e m e n t e d by r u n n i n g the card at a very slow clock at power-up and then changing the clock for the I/O devices at configuration. Flash cards that support PC Card ATA support a programmable power mode that allows the host to set the power c o n s u m p t i o n of the card.

Figure 9.3 Multiplexor circuit for the two interface modes. IREQ# READY Mode Select

BVD1 STSCHG# BVD2 SPKR# WP IOIS16#

204

DESIGNING PCMCIA CARDS

If the design does not allow for variation in the clock, the other approach is for the interface and CIS circuit only to power up, the I / 0 or Memory devices are kept powered down until the card is configured. This requires the interface to provide a Vcc enable control to a switched power supply circuit. The disadvantage of this approach is that there will be a voltage drop on the Vcc across the switching circuit. This drop can be minimized with careful attention to the on-resistance of the field effect transistor (FET). Figure 9.4 shows the implementation for a switched power supply scheme. Figure 9.5 shows the block diagram of the interface logic for a 16-bit PC Card.

9.2.2.2 Memory Card Design Issues Memory cards typically are not configurable for addresses but may have other configuration options, such as use of READY. Memory cards tend

Figure 9.4 Switched power supply controlled by interface.

9.2

Figure 9.5

16-BIT PC CARD DESIGN

205

Data and address paths for the interface logic.

D15-0

FCRDecodeand Control

l

l

D7-0

Address Decode

FCRO l

FCR1

l

FCR2

l

FCR3 FCR4

to operate in the Memory-only interface. A m e m o r y card has a write protect (WP) switch, which is used to control the state of the WP pin. Because a m e m o r y card can consist of multiple m e m o r y devices, the issues with m e m o r y cards are address decodes, bus drive, and byte steering. All m e m o r y cards are required to support the 16-bit interface.

206

DESIGNING PCMCIA CARDS

9.2.2.3

I/O Card Design Issues

I / 0 cards are typically configurable and support no more t h a n one or two I/O devices in a single function. The address decode issue for an I/O card is w h e t h e r to use i n d e p e n d e n t I/O mode or overlapping I/O mode. This determination is made primarily on the basis of the natures of the client drivers and applications software of the PC Card. If the client software can adapt to any I/O range within the host address space at run time and the host can guarantee a unique I/O address for the I/O card, t h e n the i n d e p e n d e n t I/O decode is recommended. If the client software of the I/O card relies on only certain addresses, typical of fax/modems, t h e n the card should use the overlapped decode. In i n d e p e n d e n t I/O decode, the chip selects of the I/O device m a y be directly connected to the e E l # and CE2 # signals from the bus. The system guarantees the I/O card a unique I/O space. This is the most flexible and straightforward implementation. In overlapped I/O decode, the PC Card has to i m p l e m e n t a hard decode. The card m a y provide multiple sets of I/O ranges, which can be decoded. The host m a y then select one of the I/O ranges, but it does not guarantee exclusivity for the entire range. Figure 9.6 shows the i m p l e m e n t a t i o n of both I/O decodes in I/O cards.

Figure 9.6 Implementation of overlapped and independent I / 0 decodes.

I

iii (3

f

I/O Decode I

,nte ace

Logic

!1

Interface

Logic =1:1= :1:t= :1:1= an"

I/O Device

I

I/O Device Independent I/O Decode

Overlapping I/O Decode

9.2

16-BIT PC CARD DESIGN

207

9.2.2.4 Multifunction Design Issues The issues with multifunction PC Cards are interrupt sharing, $TSCHG# interrupt sharing, and handling reset. The CIS space is c o m m o n and logically separated by the use of a CongLinkM~C tuple. The 16-bit PC Card has a single interrupt line that is used to multiplex two interrupts, one from each function. To share the IREQ# line, the functions must use a level-triggered interrupt. This allows a simple multiplexor (mux) to be used to multiplex the interrupts. As long as the function interrupts are level triggered, a simple m u x is all that is needed. If the function interrupts are pulse mode, the function interrupts must be latched before being fed to the mux. Figure 9.7 illustrates level-triggered function interrupts. For STSCHG# interrupts the same scheme is needed, except in this case the STSCHG# line is enabled by the individual functions based on the s i g c h g bit of the configuration status register of each function. Figure 9.8 shows the i m p l e m e n t a t i o n of the STSCHG# circuit. A multifunction card has two types of resets. A card global reset occurs w h e n either the bus reset line is asserted or a power-up reset occurs. A fimction-specific reset is usually forced by the SRESET bit of the configuration option register. It only resets the specific function. However, PCMCIA requires that a card return to its unconfigured state, normally the M e m o r y - o n l y interface. In a multifunction e n v i r o n m e n t , however, returning to the Memory-only interface m a y not be possible unless the other function is also reset or disabled. Otherwise there would be contention on the multiplexed signals. At a soft reset a function would return to its unconfigured state but would not return the multiplexed outputs to a Memory-only mode.

Figure 9.7 Interrupt Functio-n- O-Interrupt Function 1

Interrupt sharing in multifunction PC Cards. _

~ 1. . . . . . . . . . . . . . . . . . . . . ~

! , .................................

Function 0 ISR Function 1 ISR

/"

i

Acknowledge Function 0 Interrupt Acknowledge Function I Interrupt

I

208

DESIGNINGPCMCIA CARDS

Figure 9.8

STSCHG# circuit for multifunction cards.

CBVD1 CBVD2 CREADY- CWProt -~

~SigChg

ReqAttn- ~ SigChg ReqAttnEn

STSCHG#

CBVD1

CBVD2 CREADY CWProt~

1

SigChg

SigChg

ReqAttn

~

m

ReqAttnEn

9.2.3 Electrical Requirements Besides allowing for mechanical constraints, a PC Card must be designed carefully to meet the power constraints of the host platforms. Power cons u m p t i o n is an important concern. Although PCMCIA specifies 0.5A m a x i m u m current on each Vcc pin, on m a n y PCMCIA hosts, the power available to each PCMCIA slot is less than 1 A. For example in the HP100/200 LX the m a x i m u m current provided for the socket is 100 mA; in the Casio Zoomer the m a x i m u m current supported is 50 mA. The de-

9.2 16-BIT PC CARD DESIGN

209

signer must be aware of the supply current available per socket in the targeted platforms. Another power specification of concern is standby current. A large portion of the operational time of a PC Card is spent in the standby mode. In standby, most PC Cards turn off their clocks and deassert any outputs. A third issue is inrush current. Inrush current depends a great deal on the rise time of the Vcc during power-up and on the capacitive load (Figure 9.9). The rise time of the Vcc varies with each host that depends on the switching circuit implementation. Card designers must try to minimize the capacitive load offered to the Vcc plane. For example, if the Vcc rise time is 0.1 msec (the m i n i m u m allowed by PCMCIA) and the capacitive load on Vcc is 10 ~f, the inrush current is 0.5 A. To minimize the inrush current, PC Card designers must minimize the capacitive load on Vcc, for example by reducing the values of the decoupling caps. A designer forced to use large capacitive loads on Vcc, for example to implement a 5V-to-12V regulator, must implement an inrush limiter circuit.

Figure 9.9

Inrush current for different rise times and capacitances.

0! 1

0.

0

- x - o . I m~l

0 ~o

lm

0 0 Capacttance (gf)

20gf

210 9.2.4

DESIGNINGPCMCIA CARDS

Selecting Connectors and Frames Designers of PCMCIA cards must select the appropriate 68-pin connectors for the card. The 68-position connectors vary in terms of being stradd l e - m o u n t e d or single-side mounted. The single-side m o u n t connectors are typically available in various offsets from the center. The offset connectors are used to increase Z-height on one side of the board by decreasing Z-height on the other. There are a large variety of connector vendors, including AMP, Methode, Berg, Elco, Fujitsu, Hirose, DuPont, Molex, and Robinson-Nugent. Selection of the frame kit is important, because the frame kit supports the connector and the PCB. Typical connectors have ears that mate with the appropriate spaces in the frame kit. There are various types of PC Card frame kits. The variations are as follows: ASSEMBLY PROCESS Glued to PCB necessitating m a n u a l assembly Snap-on frame kits Sonic-welded frame kits Laser-welded frame kits CARD FORM FACTOR Type I Type II Half-size card form-factor CARD Frame Frame Frame

INTERFACE kits for m e m o r y cards w/write-protect switch kits for m e m o r y cards w/o write protect-switch kits for I/O cards with an I/O connector

LABEL AREA Frame kit with recessed areas for labels Frame kits w/o a recessed area for labels

Frame kit vendors include AMP, Dual, Berg, Elco, Methode, Molex, ITT-Cannon, and Hirose. Card designers must make sure the connector mates properly with the frame kit. For PC Cards that have gaps between the c o m p o n e n t s and the frame cover, a designer m a y have to use a filler to provide rigidity to the card.

9.2

9.2.5

16-BIT PC CARD DESIGN

211

PCB Layout Considerations Designers must pay special attention to the thickness of the PCB for height reasons. Typical PC Cards are 18 to 24 mil thick with vias of 10 rail dropped into a 25-rnil pad and 25-rail pitch surface m o u n t technology (SMT) with 5/5 line width and spacing. Boards built according to these specifications must handle 2- and 3-rnil core materials. To put this into perspective, one might imagine trying to handle playing cards made of tissue paper. The manufacturing issues and yield problems with 18-mil PCBs are enormous. A better choice is to use 24-mil PCBs. These PCBs still provide considerable challenges, but they can improve efficiency greatly. If a 24-mil thickness is not acceptable, the designer should consider relaxing the tolerances on the PCB. A flat plating finish applied in a m a n n e r that does not stress the PCB is preferred. Some examples of plating finish are Entek 106 and a solderable gold flash finish. PCMCIA PCBs are typically supplied in a minipanel with a four per panel configuration. The PCB feature size also is i m p o r t a n t (Table 9.2). The sensitivity of the PC Card connector to ground bounce dictates the need to provide separate ground and Vcc planes on the PCB. It is also r e c o m m e n d e d that if possible the designer place a large ground surface on the routing layers under the connector.

9.2.6

16-bit PC Card Design PC Card, although similar in m a n y ways to ISA bus, requires careful attention to mechanical and electrical design. For the PCMCIA interface, some FPGA or an ASIC integrating the FCRs and I/O or memory-specific

Table 9.2

PC Card f e a t u r e densities.

Feature

Preferred

Minimum

Comments

Via pad size

29 rail

25 mil

Teardrop shape to line is recommended

Line width and spacing SMT pitch SMT pad width Soldermask feature

6/6 25 rail 15 rnil 10 rail

5/5 20 mil 12 rail 6 rnil

Silk-screen legend feature line width

10 rnil

8 rail

Soldermask between 0.020 pitch SMT is not recommended Minimize silk-screen features

212

DESIGNING PCMCIA CARDS

functionality is required. It is expected that most designs currently implemented on the ISA bus will migrate down to PCMCIA. Conformance to the PCMCIA standard is critical, and the designer must pay special attention to the CIS and card configuration registers (CCRs), which will increase the acceptance of the individual card in host platforms.

9.3 16-BIT INPUT-OUTPUT CARD DESIGN EXAMPLE: FAX/MODEM This section covers the design of a fax/modem PC Card. It discusses the interface logic, address decoding, and CIS design. Figure 9.10 shows the block diagram of a PCMCIA fax/modem card.

9.3.1

Interface The host communicates with a fax/modem device through the standard 8-bit ISA serial port interface. The serial port interface uses eight 8-bit registers to control data flow to and from the fax/modem. All the fax/modem applications software on the ISA platform is written to use the serial port at one of four address locations: 3F8h-3FFh, 2F8h-2FFh, 3E8h-3EFh, 2E8h-2EFh. These address ranges are known as COM1, COM2, COM3, and COM4. COM1 and COM3 typically use interrupt request 3 (IRQ3) and COM2 and COM4 typically use IRQ4 on the ISA bus. The fax/modem PC Card implements five FCRs. They start at attribute m e m o r y address 200h, allowing an address space of 512 bytes or up to 256 bytes of CIS (attribute memory exists on even bytes only). In the example, the fax/modern PC Card implements the following FCRs: C o n f i g u r a t i o n O p t i o n Register To enable the fax/modem, select the COM port, manage reset, and select the interrupt mode C o n f i g u r a t i o n Status Register To manage audio, power down, and STSCHG#

P i n R e p l a c e m e n t Register To support READY and STSCHG#

Socket a n d Copy Register To differentiate multiple fax/modem PC Cards on the host E x t e n d e d Status Register To support the ring indicator The The terface enable

I/O base and limit registers are not implemented. m o d e m audio is provided to the host via the SPKR# line. The inlogic enables audio output on the SPKR# line based on the audio bit in the Function Configuration and Status register.

9.3 Figure 9 . 1 0

16-BIT INPUT-OUTPUT CARD DESIGN EXAMPLE: FAX/MODEM Block d i a g r a m o f a 1 6 - b i t f a x / m o d e m

213

PC Card.

d

-

/

J Jr-:1:1:

f

_

w

_

L

16-bit PCMCIA Interface Logic E

r-:l~ -r- 8 0

....... I--[-

CIS

ciswe# F cisoe#~ CS# ~_. d7-0~

-]--

o

~

readyin# ',~

"O

c-

-f..... 1........

L

111

"o ~ >.

intrq

Fax/Modem

"~ d7-0

DAA

\

f

I

I

The power-down bit may be implemented in the FCR and status register if the fax/modem chipset supports power-down modes. If a fax/modem device is powered down, it usually takes some time to become ready when it is brought out of the power-down mode. This requires implementation of the pin replacement register to indicate changes in the READY condition of the fax/modem.

214

DESIGNING PCMCIA CARDS PCMCIA has specified STSCHG# to indicate changes in the B V D 1 , B V D 2 , READY, and W P pins. Most m o d e m PC Cards originally connected their ring indicator output to the STSCHG# line. In the PC Card 1995 release, the addition of the extended status register provides a formal control mechanism to allow ring indication events to be forwarded to the host by means of the STSCHG# signal.

9.3.2 I/O Decoding The f a x / m o d e m PC Card allows the host to configure it for COM1, COM2, COM3, or COM4. This configuration is done with the Function Configuration Option Register as shown in Table 9.3. Figure 9.11 shows the decode logic associated with the configuration option register.

9.3.2.1 AddressMapping Decode For CIS and FCR accesses, which are located in the attribute m e m o r y space, REG# and r must be asserted along with OE# or WE#. For I/O accesses REG# and r must be asserted along with IORD# or IOWR#. Within t h e attribute m e m o r y space, a CIS access is defined as being within the addresses 00h-lFFh. The cycle is decoded as an FCR access if the address range is 200-20A. Table 9.4 shows the decode equations for the address spaces of the fax/modem card.

9.3.3 Configuration Information Structure The fax/modem CIS contains the tuples listed in Table 9.5.

Table 9.3 Mapping of configuration option register for fax/modem. Bit 7

Bit 6

Bit 5

Bit 4

Bit 3

Bit 2

Bit 1

Bit 0

0

Enable fax/ modem

Configuration Index Soft reset Level IRQ

Port Select COM1--001 (0Dh) COM2--O10 (15h) COM3--011 (1Dh) COM4--100 (25h)

Enable IREQ#

9.3

16-BIT I N P U T - O U T P U T CARD DESIGN EXAMPLE: F A X / M O D E M

Figure 9.11

Configuration option register decoding logic.

7

6

5

sreset

IntLvl

PS2

4

3

PS2

PS1

\7

\7

2

!

1

IntEn L

0

0 FuncEn

\7 COM1Sel

C,)M2Sel Hint

reset

IREQ#

>

COM3Sel

I

RESETO

I

(2. M4Sel

!ModemCS= COMlSel&COM1Addr + COM2SeI&COM2Addr + COM3SeI&COM3Addr + COM4SeI&COM4Addr COM1Addr = A9&A8&A7&A6&A5&A4&A3 COM2Addr = !A9&A8&A7&A6&A5&A4&A3 COM3Addr = A9&A8&A7&A6&A5&!A4&A3 COM4Addr = A9&!A8&A7&A6&A5&!A4&A3

215

216

DESIGNING PCMCIA CARDS

Table 9.4

Fax/modem address space decodes.

Address space

Decode equation

Comments

I/O Ports

IOCYC=!CEI&!REG&(!IORD + !IOWR)

CIS

!CISCS# = !CEI& !REG & (!OE+!WE) &CISAddr CISAddr = !A9 & !A8 FCRAcc = A9 & !A8

IOCYC is internal signal CISCS# is CS for ROM

FCR access

Table 9.5

FCRAcc is internal signal

CIS tuples required for fax/modem card.

Tuple ID

Tuple name

Comment

01h 15h 20h 21h 22h 22h 22h 22h IAh IBh

CISTPL_DEVICE CISTPL_VERS_I CISTPL_MANFID CISTPL_FUNCID CISTPL_FUNCE CISTPL_FUNCE CISTPL_FUNCE CISTPL_FUNCE CISTPL_CONFIG CISTPL_CFTABLE_ENTRY

IBh

CISTPL_CFTABLE_ENTRY

1Bh

CISTPL_CFTABLE_ENTRY

1Bh

CISTPL_CFTABLE_ENTRY

14h FFh

cI STPL_NO_LINK CISTPL_END

Indicates not m e m o r y device Product information Manufacturer ID Identifies PC Card as fax/modem single function Serial port extension Modem extension Data m o d e m extension Fax extension Configuration information Configuration resource description for the first configuration index Configuration resource description for the second configuration index Configuration resource description for the third configuration index Configuration resource description for the fourth configuration index Indicates signal tuple chain End of CIS

9.3

16-BIT INPUT-OUTPUT CARD DESIGN EXAMPLE: FAX/MODEM

21 7

T h e d e t a i l e d t u p l e d e s c r i p t i o n is as follows:

Byte #

Value

Description

1

Olh 03h 00h OOh FFh 15h 1Dh 04h 01h 45h 58h 41h 4Dh 50h 4Ch 445h OOh 46h 41h 58h 20h 4Dh 4Fh 44h 45h 4Dh OOh 50h 43h 20h 43h 41h 52h 44h OOh FFh 2Oh 04h XXh XXh XXh XXh 21h 02h

Tuple Id - CISTPL_DEVICE Link Device Info - Null Device - No m e m o r y device in C o m m o n Device I n f o - Block 512B size End of Device Info field Tuple Id - CISTPL_VERS_I Link Major Revision Number Minor Revision Number E X A M P L E TERMINATOR F A X. SPACE M O D E M TERMINATOR P C SPACE C A R D TERMINATOR END OF LIST CISTPL MANFID link Manufacturer Ic LSB Manufacturer Id MSB C o m p a n y Specific Information C o m p a n y Specific Information CISTPL_FUNCID Link byte

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

218

DESIGNING PCMCIA CARDS Byte #

Value

Description

45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91

02h 01h 22h 04h 00h 01h 0Fh 7Fh 22h 09h 01h 1Fh 09h C8h 00h 00h C8h 00h 00h 22h 0Ch 02h 00h 80h 3Bh 00h 03h 03h 08h 07h 00h 00h B5h 22h 08h 13h 00h 80h 06h 00h 22h 00h B5h 1Ah 05h 01h 23h

Function t y p e - Serial I/O Fax/Modem Initialization- Configure at POST CISTPL_FUNCE- for Serial Port Identification Link Extension type - Serial Port Serial Port type - 16450 UART All types of Parity Supported All C o m b i n a t i o n s of Sop bits and character sizes supported CISTPL_FUNCE- M o d e m Link Discrete M o d e m All Flow Control Methods 40 Character DCE C m d Buffer 200 Character DCE to DCE C m d Buffer DCE to DCE Buffer MSB OF LSW DCE to DCE Buffer MSB OF LSW 200 character DTE to DCE C m d buffer DTE to DCE MSB of LSW DTE to DCE LSB of MSW CISTPL_FUNCE Data M o d e m Link Function Extension type = M o d e m DTE to UART Max. Data Rate MSB DTE to UART Max. Data Rate LSB Modulations V.22bis, Bell212A, V.22A and B,V.21, Bell 103 Not supported ECC using MNP 2-4 Compression Using MNP5 C o m m a n d Protocol is MNP AT User Defined Escape M e c h a n i s m No Data Encryption No Caller Id C o u n t r y Code (USA) CISTPL_FUNCE Fax Link Fax Class 1 DTE to UART Max. Data Rate MSB DTE to UART Max. Data Rate LSB Modulation Supported Reserved Fax features polling and T.4 Reserved C o u n t r y Code USA CISTPL_CONFIG Link Two Bytes of Address (0200h) 25h is last entry in CFTABLE Entry

9.3

16-BIT INPUT-OUTPUT CARD DESIGN EXAMPLE: FAX/MODEM

219

Byte #

Value

Description

92 93 94 95 96 97 98 99

OOh 02h 3Fh 1Bh 13h CDh 41h 99h

100

71h

101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136

55h 86h 26h 86h 61h 64h AAh 60h F8h 03h 07h 50h 1Oh OOh 28h 1Bh OAh 15h 18h AAh 60h F8h 02h 07h 50h 08h OOh 1Bh OAh 1Dh 18h AAh 60h E8h 03h 07h

FCR Base address LSB FCR Base Address MSB Five FCRs present CISTPL_CFTBL_ENTRY Link Default, COM1 index (ODh), Interface byte follows Ready active (in Power down mode), I/O interface Feature Selection: IRQ, I/O Space, Power Description and MISC Power Description- Power Down, Peak, Nominal Current and Nominal Voltage are described Nominal Voltage =5V Avg. Current = 138 ma Extension of avg. current to describe the complete value Peak Current = 197ma Extension byte for complete description of I peak Power Down Current - 6 ma I/O Description: 8-bit I/O, lO-bit Address 1 range, I/O address=2 bytes Start of I/O Addr LSB Start of I/O Addr MSB (03F8h) Length of range (8 bytes) Interrupt Request Descriptor: pulse, use mask that follows IRQ4 only No other IRQ lines specified MISC: Power Down and Audio are supported CISTPL CFTBL ENTRY COM2 Link COM2 Index (15h), not default, no interface byte follows Feature Selection: I/O Space, IRQ I/O Description: 8-bit I/O, lO-bit Address 1 range, I/O address-2 bytes Start of I/O Addr LSB Start of I/O Addr MSB (02F8h) Length of range (8 bytes) Interrupt Request Descriptor: pulse, use mask that follows IRQ3 only No other IRQ lines specified CISTPL_CFTBL_ENTRY COM3 Link COM3 Index (1Dh), not default, no interface byte follows Feature Selection: I/O Space, IRQ I/O Description: 8-bit I/O, 10-bit Address 1 range, I/O address=2 bytes Start of I/O Addr LSB Start of I/O Addr MSB (03E8h) Length of range (8 bytes) i

220

DESIGNING PCMCIA CARDS

Byte #

Value

Description

137 138 139 140 141 142 143 144 145

50h 1Oh 00h 1Bh OAh 25h 18h AAh 60h E8h 02h 07h 50h 08h 00h 14h 00h FFh

Interrupt Request Descriptor: pulse, use mask that follows IRQ4 only No other IRQ lines specified CISTPL_CFTBL_ENTRY COM4 Link COM3 Index (25h), not default, no interface byte follows Feature Selection: I/O Space, IRQ I/O Description: 8-bit I/O, lO-bit Address 1 range, I/O address-2 bytes Start of I/O Addr LSB Start of I/O Addr MSB (03E8h) Length of range (8 bytes) Interrupt Request Descriptor: pulse, use mask that follows IRQ3 only No other IRQ lines specified CISTPL_NO_LINK Link (0 bytes) CISTPL_END (end of CIS Chain)

146

147 148 149 150 151 152 153

154

9.3.4

I/O Connection The other issue for a fax/modern PC Card is the connection to the telephone line. Most PC Cards have an I/O connector that connects to an I/O cable, which provides an RJ-11 jack for the telephone line. The designer can use various types of I/O connectors in the PC Card form factor. They vary from 7-pin to 15-pin connectors with or w i t h o u t locking m e c h a n i s m s to hold the cable.

9.4

16-BIT MEMORY CARD DESIGN EXAMPLE This section covers the design of a flash m e m o r y card that uses Intel 28F008SA-100 flash m e m o r y devices. It discusses the interface, decoding, a n d timing issues for a m e m o r y array and the CIS. Figure 9.12 shows the high-level block diagram of a flash m e m o r y card. As in the f a x / m o d e m PC Card, the flash m e m o r y card also has interface logic. Flash m e m o r y cards generally are not reconfigurable for address range. Therefore, in this design example, no FCRs are b e i n g i m p l e m e n t e d . The c o m m o n m e m o r y addresses start at address O000h. However, control registers are used to control READY, WP, a n d powerdown. Because m e m o r y cards are required to support 16-bit accesses, flash devices are paired. The CIS device in this case is external but m a y be i m p l e m e n t e d as ROM; m o s t of the CIS is kept on the flash device itself.

9.4 16-BIT MEMORY CARD DESIGN EXAMPLE

221

Figure 9.12 High-level block diagram of flash memory card.

D15-0 ~

"

Data~.

! I

I

I

I

I

,

Interface Logic

The other two i m p o r t a n t issues are byte steering and 12V Vpp voltage. All m e m o r y cards are required to provide 16-bit support. This requires logic to support byte steering for the odd-byte case. For program and erase, 28F008 flash devices require 12V Vpp. There is a compatibility issue. The designer can choose to take Vpp from the bus and connect that directly to the Vpp lines. This works in most systems, but some machines do not support 12V on Vpp, and this card does not operate in those machines. The other option is for the designer to generate 12V from the 5V Vcc on the card itself. This increases cost but improves overall compatibility. Figure 9.13 provides a detailed design schematic of a 2MB flash m e m o r y card based on the Intel 28F008SA-100 flash device.

9.4.1

Interface The following issues are addressed by the interface logic in this design: 9 Support for multiplexing Rdy/bsy from each device to the READY pin on the bus 9 Support for write protect

222

DESIGNING PCMCIA CARDS

Figure 9.13

Schematic of flash memory card. Write-Protect

Switch

Vcc

Vpp -- CS# ;lwe# -~1oe# ~1D7-0

A25-0 WE#

Flash O

REG#

OE#

RESET WP _., READY D7-0

y

I I

I

~1

D15-8

~--

I,.,

I-h ben

t

i I

CIS

- I

I

~id7-0 Ioe#

i

dirl-L dir I': eben D7-0 L~~

n,

l =lA9-0 Ics# 1 I1

CSL# fwe# LA23-0 rbsyl-0 RP#1-0 CSH# foe# CISCS# coe#

CE2# CEI#

Q.

..Q

<

CS# we# D15-8

>, (/) c~ t_

Flash

- elD#

7-0

r~ I1.

EZ.

>

9.4

16-BIT MEMORY CARD DESIGN EXAMPLE

223

9 Decodes for both CIS and flash m e m o r y 9 Byte steering to support odd-byte accesses on D7-0 9 Control registers for R d y / b s y , WP, and power-down R E A D Y support is needed because all flash devices take a relatively

long time to program and erase. The R E A D Y signal is used to indicate completion of program and erase operations. Most flash devices have a unique m d y / b s y # line, which indicates to the interface logic the completion of a program or erase cycle. The interface can mask m d y / b s y # lines of each device from being forwarded to the host on the R E A D Y line. In this example the m d y / b s y # mask and status for both devices is in the flash control register. Table 9.6 shows the flash control register. The flash control register is not an FCR; it is a unique register defined in this interface and is located at 0400h of attribute m e m o r y space. The write-protect switch controls the state of the W P pin on the interface. The ability to write protect the CIS space through software is provided in the flash control register. Because part of the CIS m a y be located in the first 64K block of c o m m o n memory, the interface also provides the ability to write protect the first 64KB of c o m m o n m e m o r y space. The other portion of the interface is dedicated to decoding the chip selects, CSL# and CSH#, for the flash devices and the chip selects for the CIS EEPROM. In this design both flash devices are paired to provide one Kbit word of c o m m o n memory. Each flash device is interleaved. Low byte accesses are on the first device, and high byte accesses are on the second device. The CIS occupies the first 256 bytes of attribute m e m o r y space. The flash control register is located in attribute m e m o r y space 400h. Table 9.7 shows the address map for this design example. The interface logic has to support both 8- and 16-bit accesses. High byte accesses in which CEI# is asserted and A0 is high, have to be returned on D7-0. This necessitates i m p l e m e n t a t i o n of byte-steering capability in which the high byte (D15-8) on the card side bus is connected to the low byte (D7-0) on the host side bus. The interface generates an

Table 9.6

Flash control register.

Bit 7

Bit 6

Bit 5

Bit 4

Bit 3

CISWP

RP 1

RP 0

CMWP

Rdy/bsy# Rdy/bsy# Rdy/bsy# Rdy/bsy# Mask 1 Mask 0 Status 1 Status 0

Bit 2

Bit I

Bit 0

224

DESIGNINGPCMCIA CARDS

Table 9.7

Address map for design example.

Address range

Address space

Device selected

Signal affected

OOh-IFFFFF 0000h-FFh 400h

Common memory Attribute memory Attribute memory

Flash device pair CIS ROM Flash control register

CSL#, CSH# cIscs#

Internal

even byte enable for access from even addressed bytes, a high byte enable for accesses on odd addressed bytes, and an odd byte enable for accesses on odd addressed bytes with CEI# asserted instead of CE2#. Table 9.8 shows the control signal decode for data.

9.4.2 Register Implementation Figure 9.14 shows the implementation of the register and the READY, 1~, and WP logic associated with it.

9.4.3 Configuration Information Structure This design example memory card requires the following tuples in the CIS: CISTPL

DEVICE

CISTPL

DEVICE

CISTPL

JEDEC

A C

CISTPL_VERS_I CISTPL_DEVICEGEO CISTPL_MANFID CISTPL

END

Describes size, speed, and type of m e m o r y device Describes size, speed, and type of attribute m e m o r y device JEDEC identification (ID) of manufacturer and device Version compliance Geometry information Manufacturer ID End of CIS chain

In addition to the foregoing tuples, a flash m e m o r y card also m a y need the format and ORG (ORO) tuples if file system storage is needed. Table 9.9 shows the CIS.

9.5

Table 9.8

CARDBUS PC CARD DESIGN

225

Control signal decode.

Cycle

REG# CE2# CEI# AO

OE#

WE# D15-8

D7-O

Signals asserted

Standby

X

H

H

X

X

X

High Z

High Z

None

High High High High

Lowbyte Low byte High byte Lowbyte

CSL#, eben# CSH#, hben#

CISCS# address 0-Ffh eben # hben#

Common Memory Cycles

Low byte read High byte read Odd byte read Word read

H H H H

H L H L

L H L L

0 1 1 X

L L L L

H H H H

Low byte write High byte write Odd byte write Word write

H H H H

H L H L

L H L L

0 1 1 X

H H H H

L L L L

Z Z Z byte

CSL#, oben# CSL#,CSH#, eben#, hben# High Z Lowbyte CSL#, eben# High byte High Z CSH#, hben# High Z High byte CSL#, oben# High byte Low byte CSL#, CSH#, eben#, hben#

Attribute Memory Cycles

Low byte read

L

H

L

0

L

H

High Z

Low byte

High byte read

L

L

H

1

L

H

High Z

Odd byte read

L

H

L

1

L

H

Invalid data High Z

Word read

L

L

L

X

L

H

Invalid data

Low byte write

L

H

L

0

H

L

High Z

High byte write

L

L

H

1

H

L

Word write

L

L

L

X

H

L

Invalid High Z operation Invalid Low byte data

9.5

Invalid data Low byte

Low byte

oben# CISCS# address 0-FFh eben#, hben# CISCS# address 0-Ffh eben # Invalid operation CISCS# address 0-Ffh eben #

CARDBUS PC CARD DESIGN CardBus PC Card design requires careful a t t e n t i o n to interface implem e n t a t i o n a n d a t t e n t i o n to electrical signals a n d t h e l a y o u t of t h e board. T h e m e c h a n i c a l design aspects of a CardBus PC Card are similar to t h o s e of a 16-bit PC Card a n d are n o t discussed in m u c h detail herein. This sect i o n discusses CardBus PC Card design a n d t h e d e s i g n of a slave a n d a m a s t e r CardBus card.

226

DESIGNINGPCMCIA CARDS

Figure 9.14

Control and register decoding logic. Flash Control Register

'

q) l gev~0Rdy~ ~ut Oev~l ~ ~ J t

CM

Write

Protect

READY

Ii, RP0 I~RP1

Decoder

A21-0 CEI# CE2#

v

Ii. CSH# 1~ F-(:E.~ 9ClSCS#

s

Ii, e3e-i#

REG#

',- ct:er~ 9 dir

All CardBus PC Cards have the following requirements: 9 Configuration space with configuration header must be supported. 9 CIS must be supported. 9 I/O m a p p e d ports must also support m a p p i n g into m e m o r y space. 9 CardBussignalsCAD31-0, CCBE3-0#, CPAR, CFRAME#, CTRDY#, CIRDY#, CSTOP#, CDEVSEL#, CPERR#, CSERR#, CCLK, CRST#, CCD2-1#, c v s 2 - 1 m u s t be implemented. Power-up current before configuration must be less than 70 mA. 9 No more than one load per CardBus signal is allowed.

9

9.5

CARDBUS PC CARD DESIGN

Table 9 . 9

227

CIS table.

Byte no.

Value in hex

Description

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

01 03 53 06 FF 1E 06 02H 11H 01 01 03 01 1A 02 89 A2 15 11 04 01 44 45 53 49 47 4E 20 45 58 41 4D 50 4C 45 00 1A 04 1F 22 01 21 02 01

CISTPL Link

DEVICE

Flash 150-nsec device Card size (2MB) End of tuple CISTPL

DEVICEGEO

Link DGTPL_BUS

DGTPL_EBS

DGT PL_RB S DGTPL_WBS DGTPL

PART

Flash device interleave CI S T P L _ J E D E C Link

JEDEC ID manufacturer (Intel) JEDEC ID device (28F008SA) C I ST P L _ V E R S _ I

Link Major revision n u m b e r Minor revision n u m b e r D E S I G N Space E X A M P L E Null CI S T P L _ D E V I C E _ A

Link ROM Speed (120 nsec) 2KB CI S T P L _ F U N C I D

Link M e m o r y card

(continued)

228

DESIGNING PCMCIA CARDS

Table 9.9 (continued) Byte no.

Value in hex

Description

45 46 47 48 49 50 51 52 53

00 20 04 XX XX 11 XX XX FF

None CI S T P L _ M A N F I D

Link Manufacturer Manufacturer 2MB Manufacturer Manufacturer

ID (LSB) ID (MSB) ID card (LSB) ID card (MSB)

CI S T P L _ E N D

LSB,least significant byte; MSB,most significant byte.

9 Trace length m u s t be less t h a n 1.5 inches (3.8 cm) for all signals except r 9 CCLK trace lengths m u s t be less t h a n 2.5 inches (6.3 cm). 9 Function event, mask present state, and force registers m u s t be imp l e m e n t e d if r and r are supported. Figure 9.15 shows the block diagram of CardBus PC Card. There is a single CardBus interface t h a t buffers, decodes, a n d demultiplexes the CardBus signals a n d provides local address, data, a n d control signals to devices on the bus. The figure also shows a CIS. The CIS is expected to be i m p l e m e n t e d in either an external device such as an EEPROM or on ROM on board the interface logic. The block diagram (Figure 9.15) also shows a local I/O device. The interface logic generates chip selects for the local I/O or m e m o r y devices as needed. It also provides the d e m u l t i p l e x e d address, data, a n d controls for the particular I/O device. The m a i n portion of the design is involved in the interface logic.

9.5.1

Interface Logic Issues The interface logic for CardBus PC Cards m u s t provide the following: 9 D e m u l t i p l e x i n g of address a n d data to the device local to the card 9 Control registers for the configuration header

9.5

CARDBUS PC CARD DESIGN

Figure 9.15

229

Cardbus PC Card block diagram.

CardBus Interface

CIS

I/0 Device

9 I m p l e m e n t a t i o n of I/O a n d m e m o r y d e c o d e s w i t h base registers as needed 9 Buffer clock 9 Parity g e n e r a t i o n a n d d e t e c t i o n 9 F u n c t i o n e v e n t , mask, present, a n d force registers 9 Slave interface state m a c h i n e for slave f u n c t i o n s 9 M a s t e r interface state m a c h i n e for m a s t e r f u n c t i o n s 9 Wait-state g e n e r a t i o n logic to s u p p o r t slower devices 9 T h e p r o p e r i n t e r r u p t h a n d l i n g p r o t o c o l for t I N T # 9 Latency timer 9 CIS p o i n t e r Figure 9.16 is a b l o c k d i a g r a m of t h e slave interface logic for CardBus.

230

DESIGNING PCMCIA CARDS

Figure 9 . 1 6

Block d i a g r a m of the slave interface logic f o r CardBus. r

o o,

i

ardBus Interface State Machine

J

1 ,a,ch Config Header Decode Logic

. Parity

Gen/Det Logic

Config Header wait-state generator

Comparators for Base Address Registers

and Memory code Logic

Function Event ~Reaisters~

r

o ~c/) -9 m O

CU

,m

O

~r

9.5.1.1

Demultiplexing of Address and Data

In CardBus, address and data are multiplexed over the CAD31-0 lines

and the command byte enables are multiplexed over the CC/BE3-O# signals. The local devices are generally nonmultiplexed address and data. This requires the interface to demultiplex the CAD31-0 and CC/BE3-0#

9.5 CARDBUS PC CARD DESIGN

231

lines. This is i m p l e m e n t e d with a latch (36 bits wide) of the address and c o m m a n d during the address phase. The address phase is the first phase during which r is asserted.

9.5.1.2

Configuration Header

In the configuration header the key registers are the c o m m a n d , status, and base address registers. The status register is a read-only register and reflects the status of various conditions on the card. The c o m m a n d register is used to control the various options available in a CardBus card. The base registers are used to set the addresses for the I/O and m e m o r y spaces. The registers are written by means of a configuration header decode and control circuit. They are read t h o u g h a mux.

9.5.1.3

Address Decoding

A target device may decode addresses in one of two possible ways. In

positive decode each device is responsible for its own address decode. In subtractive decode a device claims a cycle not claimed by any other device on the bus. Only one device on the bus can i m p l e m e n t subtractive decode. It is a very slow decode and is used only in a device that has a very fragmented address space.

9.5.1.4

Slave PC Card Design Issues

Slave-only interface-state machine design depends on w h e t h e r the interface implements positive decode or subtractive decode and whether the target supports LOCK#. Figure 9.17 shows the state diagram for a target interface that implements positive decode and does not support LOCK#.

9.5.1.5

Master Interface Design Issues

Master interface logic must support both a target interface, at least for configuration space, and a master interface. This complicates the address and data paths, because both address and data buses must be bidirectional and demultiplexed for target accesses and multiplexed for master cycles. Figure 9.18 shows the address and data path for a master interface. The address is latched for slave accesses to a target device on the card. The local address and data are multiplexed to provide CAD31-0 output w h e n the card is operating as a master device. The latches on the local address and data are needed to allow processing of a target access during a master access.

232

DESIGNING PCMCIA CARDS

Figure 9.17

Target interface state machine.

CFRAME#

~,b"~~.b~ / ~Idle ~(!tabort+tabort&l ICFRAME#&Val idAddr& IC CFRAME#&CSTOP#+ FRAME#&ICSTOP#&ICTRDY#&CIRDY# O Rdy) I ~-'~'~V ~ ,~~~.~ ~CFRAME#&CTRDY#&CSTOP# ~'~-~"-"/

9.5.2

CFRAME#NN~

,

Electrical Issues Each signal on the bus is allowed to drive only one load. For multifunction cards or cards that support master-slave operation, a single interface device is required. For decoupling purposes the m a x i m u m trace length from a pad to a Vcc or ground via must be less t h a n 0.25 inches (0.63 cm). The impedance of traces on the CardBus card must be controlled to be between 60 and 90 ohms.

9.6 CARDBUS MASTER CARD DESIGN EXAMPLE: LAN CARD This design example shows the design of a CardBus PC Card with both master and slave capabilities. It supports an Ethernet device on the card. The card can be accessed as a target w h e n the configuration space, I/O registers of the local area network (LAN) controller, and the master m o d e control status registers are accessed. This design supports the following capabilities:

9.6

CARDBUS MASTER CARD DESIGN EXAMPLE: LAN CARD

Figure 9.18 data paths.

Master interface address and

AD31-0

I Lalch A~

I' La!ch'

A~

i i

I Latch I

, Local Data

i Latch I

Local Address

CARDBUS COMPLIANT TARGET INTERFACE Configuration header M e m o r y - m a p p e d LAN I/O registers M e m o r y - m a p p e d DMA control registers Support for CIS access by means of configuration space Slave I/O port accesses that are nonburst, 8-bit accesses with two wait states

233

234

DESIGNING PCMCIA CARDS

Configuration header accesses that are nonburst, 32-, 16-, or 8-bit with two wait states Target disconnect capability Positive target address decode with 16-bit base address registers Parity generation and detection CARDBUS COMPLIANT BUS-MASTER INTERFACE Master-based transmit and receive data transfer from LAN controller to system m e m o r y Separate control and status registers 32-byte burst size to match with the first in, first out (FIFO) size in the LAN controller Full 32-bit address register Programmable transfer length for up to 256 dwords per transfer Programmable latency timer Parity generation and detection on PERR# and SERR#. Support for master abort, target abort, retry, and disconnect

9.6.1

Signals The Ethernet controller is assumed to provide two p o r t s m o n e to access its control and status registers, the other to transfer data from the first-infirst-out m e m o r y (FIFO) of the controller to the host memory. The LAN control and status register port is 8 bits wide and is accessed as a slave. The interface logic in the design example allows for up to 32 registers in the LAN controller. The access time for the control port is assumed to be 70 nsec. The signals are as follows: 1. C S d a t a 7 - 0

2. C S a d d r 9 - 0 3. C S I O C E #

4. C S W E # 5. C S O E #

The data transfer port is 32 bits wide and is used to transfer data in master mode. Its data access time is 50 nsec. The signals are as follows: 1. L d a t a

31-0

2. R x F I F O E n #

3. T x F I F O E n # 4. F I F O W E #

9.6 CARDBUS MASTER CARD DESIGN EXAMPLE: LAN CARD

235

5. F I F O E #

6. TxFI F O R d y 7. RxF I F O R d y

The interface also provides support for an external EEPROM for CIS storage. The signals share the local data and address bus. The interface must generate CISCS#, CISWE#, and CISOE#.

9.6.2

Bus Transactions Table 9.10 lists the CardBus transactions supported. The target interface supports I/O read and write and m e m o r y read and write cycles. This support is required by CardBus to allow the PC Cards to operate in host env i r o n m e n t s that do not support I/O space.

9.6.3 Configuration Space The configuration header supported is presented in Table 9.11. The CIS starts at configuration space offset 40h.

Table 9.10

CardBus transactions supported.

CCBE3-O#

Transaction

0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111

Special cycle I/O read I/O write Reserved Reserved Memory read Memory write Reserved Reserved Configuration read Configuration write Memory read multiple Allocated Memory read line Memory write and invalidate

Target interface

Master interface

Yes Yes

Yes Yes

Yes Yes

Yes Yes

236

DESIGNING PCMCIA CARDS

Table 9.11

Configuration header used in design example.

D31-24

D23-16

D15-8

D7-O

Allocated

Allocated

Status

Allocated

OOh

Command Allocated

OOh

Offset

Header Wpe

Latency timer

04h

Allocated

08h

OOh

OCh

I/0 base address register

10h

Memory-mapped I/O base address register

14h

0000,0000h (base address)

18h

0000,0000h (base address)

1Ch

0000,0000h (base address)

20h

0000,0000h (base address)

24h

CIS pointer

28h

Reserved

2Ch

0000,0000h (expansion ROM base address)

30h

Reserved

34h

Reserved

38h

]Allocated

Interrupt pin Tuple

3Ch 40h

Tuple End of function-specific space

9.6.3.1

FFh

Command Register

The c o m m a n d register is used to configure and control the ability of the interface to respond to CardBus cycles. Table 9.12 shows the c o m m a n d register fields supported.

9.6.3.2

Status Register

The status register is used to provide information about the status of busrelated conditions. Table 9.13 lists the status register bits supported. r timing can be traded for the size of address space allocated to the function. If a smaller address space is allocated, more bits are decoded, decoding takes longer, and CDEVSEL# assertion is slower.

9.6 CARDBUS MASTER CARD DESIGN EXAMPLE: LAN CARD

Table 9.12

Commands register fields supported.

Bit 17o.

Field name

Readwrite

Default value

15-10 9 8

Reserved Fast back-to-back enable SERR# enable

N/A R only R, W

OOh 0 0

7

Address and data stepping enable PERR# enable

R only

R only R only

3 2 1

VGA palette snoop Memory write and invalidate enable Special cycles Bus master enable Memory space enable

0

I/O space enable

R, W

6 5 4

237

R, W

R only R, W R, W

Comments

Not supported Enables and disables reporting of errors on SERR# Not supported Enables reporting of parity errors on PERR# Not supported Not supported Not supported Enables bus master operation Enables the card'tc respond to valid decodes in memory space Enables the card to respond to valid decodes in I/O space

R, read; W, write.

The latency timer is an 8-bit register used to c o u n t the m a x i m u m n u m b e r of bus clocks the master is allowed to keep c o n t r o l of the bus. The lower 4 bits (bits 3-0) are hard-wired to l l l l b , allowing a granularity of 16 bus clocks. The h e a d e r type register is set to 0 (00h), i n d i c a t i n g a single-function device.

9.6.3.3

Base Address Registers

The I/O base address register is used to locate the LAN c o n t r o l a n d status registers w i t h i n the host I/O space. A l t h o u g h the I/O ports can be located o n a n y 4-byte b o u n d a r y , in this example, to reduce the size of the comparator, the LAN I/O ports are placed o n 64-byte b o u n d a r i e s a n d restricted to the first 64KB of I/O space. The bits are assigned as follows: A31-16 A15-A6

Hard-wired to 0 Programmable

238

DESIGNINGPCMCIA CARDS

Table 9.13

Status register fields.

Bit no.

Field name

Readwrite

15

Parity error

R, W

14 13

System error Master abort

R, W R, W

0 0

12

Target abort received

R, W

0

11

Target abort signaled

R, W

0

10-9

CDEVSEL# timing

R only

01

8

Data parity detected

R, W

0

Fast back-to-back capable

R only

0

Reserved

R only

OOh

6-0

Default value

Comments

Indicates a parity error even if parity is disabled Indicates SERR# is asserted Indicates a master abort has occurred on a transaction initiated by this master Indicates a target abort has occurred on a transaction initiated by this master Indicates a target abort has been signaled on a transaction target to this slave Medium assertion time for CDEVSEL#

Indicates a parity error has occurred on a transaction initiated by this master Slave mode does not support fast back-to-back transactions Reserved

R, read; W, write.

A5-0

D o n ' t care (interface d e c o d e s for m a s t e r m o d e or LAN I/O) A5 = 1 i n d i c a t e s m a s t e r m o d e A5 = 0 i n d i c a t e s LAN I/O registers

This d e s i g n allows t h e c o m p a r a t o r a n d d e c o d e to be 10 bits w i d e as o p p o s e d to 27 bits wide. T h e m e m o r y base address m a y be i m p l e m e n t e d d i f f e r e n t l y b e c a u s e t h e first 64KB of m e m o r y space in m o s t h o s t m a c h i n e s is u s u a l l y allocated. T h e card m a y be a l l o c a t e d a 4KB m e m o r y space a n d restricted to t h e first 128MB of address space. T h e m e m o r y base register m u s t always be e n a b l e d to allow t h e f u n c t i o n e v e n t registers to be accessed. T h e bits are a s s i g n e d as follows: A31-A27 A26-A12

H a r d - w i r e d to 0 Programmable

9.6 CARDBUS MASTER CARD DESIGN EXAMPLE: LAN CARD A11-4

239

D o n ' t care (interface decodes for master m o d e or LAN I/O) A5 = 0 indicates LAN I/O registers AS,A4 = 10 indicates master m o d e A5,A4 = 11 indicates function event registers

The m e m o r y range is m a r k e d as being not prefetchable, a n d the type field is set to 00b. This allows i m p l e m e n t a t i o n of a 13-bit c o m p a r a t o r for m e m o r y access. The first two base registers are i m p l e m e n t e d . The other four base address registers are hard-wired to 0.

9.6.3.4 Configuration Information Structure Pointer The CIS pointer is hard-wired to point to the CIS. It is a read-only register and points to configuration space 40H. If the CIS for a card is larger than 188 bytes, it can be divided into two tuple chains. The primary chain is at configuration space and points to the second chain by means of a long-link tuple. The bit assignments are s h o w n in Table 9.14.

9.6.3.5 Interrupt Pin Register The interrupt pin register is hard-wired to Olh. It indicates t h a t the function is using the interrupt line.

9.6.4

I / O Registers The LAN controller is allowed up to 32 bytes of I/O ports. These I/O ports take up the first 32 offsets in the address space. The master m o d e control a n d status registers are placed on the next 32-byte boundary. There are four 32-bit-wide registers: Master Write Address, Master Read Address, Master Control, a n d = Master Status. I m m e d i a t e l y following the master control registers are the function event registers: Function Event, Function Mask, Function Present, a n d Function Force. Table 9.15 shows the location of these registers in the address space.

Table 9.14

CIS pointer fields.

Bit no.

Field

Value

Description

31-28 27-3 2-0

ROM image Address space offset Address space indicator

0000b 40H 000b

ROM image number Start of CIS Configuration space

240

DESIGNING PCMCIA CARDS

Table 9.15

I / 0 register offsets.

Offset

Register

Description

Comments

00h-lFh

LAN controller specific

32 8-bit-wide registers

20h-2Fh

LAN control status register Master mode registers

30h

Function event

34h 38h

Function mask Function present

3Ch

Function force

In interface logic and 32-bit wide registers used to control operation of the master mode Implements ready-busy Memory mapped only, 32 and general wake-up bits wide bits Masks events Status of interrupt, ready, and general wake-up events Hard-wired to 0

The function event registers are m a p p e d only into memory. They are i m p l e m e n t e d within the interface logic. Their offset is selected to allow the LAN control registers and the master control registers to m a i n t a i n the same offsets i n d e p e n d e n t of the specific address space. This simplifies decoder logic.

9.6.4.1

Master Mode Control Registers

The master control registers are as follows: (1) master receive address (RxAddr) at offset 2Oh; (2) master transmit (TxAddr) address at offset 24h; (3 and 4) master control and status at offset 28h. The transmit and receive address registers are used to program (1) the address location in the host from w h i c h the master reads data to write to the t r a n s m i t FIFO (TxAddr Register) or (2) the address in the host to w h i c h the master writes data from the receive FIFO. This allows 256 dwords or 1KB of data to be transferred in a single c o m m a n d . The format of the TxAddr and RxAddr registers is s h o w n in Table 9.16. The master control-status register is used to indicate the n u m b e r of dwords to be transferred, enable the transmit or receive capability, and provide the status of the transfer. The format of the master control-status register is s h o w n in Table 9.17. The enable bits are m u t u a l l y exclusive; receive and transmit c a n n o t be enabled simultaneously in this design.

9.6

Table 9.16

CARDBUS MASTER CARD DESIGN EXAMPLE: LAN CARD

241

Format of RxAddr and TxAddr registers.

31

30

29-10

9-2

1-0

EnAddr

CtrDir

Base address

O0

Enables counter

Direction of count

Base address

Offset address, automatically incremented or decremented Address of the location where the first dword is transferred

Hard-wired

Table 9.17

Master Control-Status register.

31

30

29

28-20

19-12

11

10-8

7-0

0

TxEn

RxEn

XfrCount

Rsvd

EnTCINT

XfrStat

dwords transferred

The X f r S t a t bits indicate the status of the transfer. T h e y provide the following i n f o r m a t i o n : 0000 0101 1010 1111

Idle Transfer in progress, n u m b e r of dwords transferred indicated by bits 7-0 Transfer c o m p l e t e d OK Transfer c o m p l e t e d with error

The ENTCINT bit enables the master s e q u e n c e r to generate an interrupt at the c o m p l e t i o n of a transfer. The XFRCount field is used to provide the n u m b e r of dwords to be transferred.

9.6.5 Block Diagram Figure 9.19 shows the block diagram of a CardBus LAN PC Card.

9.6.6

Interface Design Figure 9.20 shows the state m a c h i n e design for the master sequencer. The master state m a c h i n e comes out of idle o n c e its bus request has b e e n granted. It enters the address state, w h i c h is the address p h a s e of a CardBus transaction. The n e x t state is the data state, w h i c h is used to complete data transfers. At c o m p l e t i o n of data transfers, the state c h a n g e s to

242

DESIGNINGPCMCIA CARDS

Figure 9 . 1 9 f

.

.

.

Block diagram of a LAN card with CardBus. .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

I I I I

Master State Machine

Slave State Machine

Configuration Header

Parity Gen/Detect

Comparator and Decode

Function Event Registers

Master Sequencer

Register and I/O Decode

I I I I I

CIS Interface

I I :1:1=

I

8

I I I I I I I I LAN Interface

I I

. . . . . . .

-t

ii F . . . . . . .

t u r n a r o u n d state for n o r m a l c o m p l e t i o n or to the T a r _ A b state for abn o r m a l t e r m i n a t i o n . The two conditions in the state m a c h i n e t h a t cause it to m o v e to T a r _ A b are target initiated t e r m i n a t i o n or master abort. The t u r n a r o u n d state is i m p l e m e n t e d to support signal t u r n a r o u n d s . The DRBus state is n o t used in this example. It would be used if, for example, the interface involved address a n d data stepping. Table 9.18 shows t e r m i n a t i o n modes.

1

9.6

CARDBUS MASTER CARD DESIGN EXAMPLE" LAN CARD

Figure 9 . 2 0 M a s t e r s t a t e m a c h i n e w i t h o u t address s t e p p i n g .

CGNTS

_

243

LOCK# a n d

--,~~ request&!CGNT# ~~..~----._....~RA ME#&C IRDY# 4"

~"'-'l[-"~'~ I

/ !CGNT#~

CGNT# I

I~iCCLK

CFR ^, I._ore,~&~CGNT#) t'} (Scammdeo Ow~ `~)u*c~ mpiete

9.6.7

Critical Timing The critical timings in the design are m o s t l y driven by the c o m p a r a t o r time to d e t e r m i n e if the current access is a hit in the PC Card address space. The hit signal is used to drive m a n y conditions, including the slave-state m a c h i n e . The hit time to enable the latching of address a n d c o m m a n d s before the next clock edge is calculated as follows: Hit delay = Clock p e r i o d - Set-up timemin- Address o u t p u t delaymax =30-2-18 = 10 nsec The set-up time is the longer of the set-up times for the state m a c h i n e flip flops or the address latches. The value 2 nsec is used here because it is a conservative value for a gate array.

244

DESIGNING PCMCIA CARDS

Table 9.18

Termination modes.

Mode

CFRAME#

CSTOP#

CTRDY#

CIRDY#

CDEVSEL#

Normal termination Disconnect A Disconnect B Disconnect C Master abort Target abort

F F T T T T

F T T T F T

T T F T

T T T F

T T T T

F F

T T

F (for 6 clocks) F

F, false; T, true.

9.6.8

Configuration Information Structure Design This PC Card CIS is designed according to CardBus requirements. It contains the following tuples: CISTPL

LINKTARGET

CISTPL

VERS

CISTPL

M A N F ID

C ISTPL_CONF

1 IG_CB

C I S TP L_CF TB L_ENTRY_CB CISTPL_BAR C ISTPL_DEVICE_OC CISTPL

F U N C ID

CISTPL

FUNCE

CISTPL

NOLINK

CISTPL

END

Table 9.19 shows the complete CIS for this PC Card.

9.7 TEST AND DEBUG OF PC CARDS The low profile a n d extremely small size of the form factors of PC Cards m a k e it difficult to design, debug, a n d test PC Card circuits.

9.7.1

Extenders For a PC Card design, an extender card is almost a necessity. Some extenders, however, add considerable noise t h r o u g h g r o u n d b o u n c e due to a d d e d c o n n e c t o r inductance. The original suppliers of PCMCIA extenders were two companies, TWD a n d Mobile Media. TWD s t o p p e d selling extenders, a n d m a n y other vendors of extenders have entered the mar-

9.6

CARDBUS MASTER CARD DESIGN EXAMPLE: LAN CARD

Table 9.19

245

CIS i m p l e m e n t a t i o n for CardBus LAN card.

Byte no.

Value (hex)

Description

0 1 2 3 4 5 6 7 8 9 10 ]1 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

13 03 43 49 53 1C 03 02 XX FF 04 06 03 02 82 01 00 00 15 ]E 05 00 53 41 4D 50 4C 45 20 43 49 53 00 FF 20 04 XX XX XX XX 21 2 06 00 22

CISTPL_LINKTARGET Tuple ID Link "C" "I" "S" Tuple cI STPL_DEVICE_OC Link OC info field Vcc - 3.3V Device info field (null device, n o t write protected) End of device info CISTPL_CONFIG_CB tuple ID Link Size of fields (four status registers present) Last index entry (last index entry is 02h) Indicated by base address 2 Offset 30h 00h 00h ci STPL_VERS_I ID Link Major version n u m b e r (PC Card 1995) Minor version n u m b e r "S" "A" "M" "P" "L" "E" Space "C" "I" "S" Null End of tuple CISTPL_MANFID tuple ID Link Manufacturer code Manufacturer code Manufacturer info Manufacturer info CSITPL_FUNCID tuple ID Link Network adapter System initial bits (no post or e x p a n s i o n ROM) CISTPL_FUNCE tuple ID

(continued)

246

DESIGNING PCMCIA CARDS

Table 9.19 (continued) Byte no.

Value (hex)

Description

45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89

02 01 02 22 06 02 80 96 98 00 22 02 03 01 22 0A 04 8 XX XX XX XX XX XX XX XX 07 06 11 00 06 00 00 00 07 06 02 00 0A 00 00 00 05 0C 41

Link LAN Type (LAN Tech) Ethernet CISTPL_FUNCE tuple ID Link LAN_SPEED 10 MB/ser (00989680 hex)

LAN speed LAN speed LAN speed CISTPL_FUNCE tuple ID

Link

LAN_Media UTP cI STPL_FUNCE ID

Link

LAN_NID

Number of bytes in node ID (Ethernet has 8-byte ID) Node ID Node ID Node ID Node ID Node ID Node ID Node ID Node ID CISTPL_BAR ID Link First base address register is an I/O map Reserved 00h Range size (64 B 26) Range size upper bytes Range size upper bytes Range size upper bytes CI STPL_BAR ID Link Second base address register is memory mapped Reserved 00h Range size (1KB 21~ Range size upper bytes Range size upper bytes Range size upper bytes C I STPL_CFTABLE_ENTRY_CB ID Link Index byte (01h index, default values)

(continued)

9.6

CARDBUS MASTER CARD DESIGN EXAMPLE" LAN CARD

247

Table 9.19 (continued) Byte no.

Value (hex)

Description

90

B9

91

11

92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107

B5 1E 16 02 A0 F8 BF 04 59 05 02 20 04 14 00 FF

Feature selection (Vcc, I/O, memory, IRQ, and misc descriptors present) Power description structure (parameter selection, nominal Vcc, and avg current described) Nominal Vcc 3.3V (3.0 • 1V), EXT bit set Extension = 0.3V (3.3V) Avg current (200 mA) no EXT I/O base address register 01 used IRQ descriptor (share and level set) IRQ descriptor (IRQ 7, 6, 5, 4, 3 lines) IRQ descriptor (IRQ 15, 13, 12, 11, 10, 9, 8) Base address register 02 used for memory CardBus Misc field (SERR#, Parity error, bus master set) C ISTPL_CFTABLE_ENTRY_CB ID Link Index byte (Memory descriptor only) Memory base address register used is 02 only C I S T P L _ N O L I N K tuple ID Link (no bytes) CISTPL_END tuple ID (end of CIS)

UTP, Unshielded Twisted Pair.

ket. There are a b o u t a d o z e n different v e n d o r s of e x t e n d e r cards. However, o n l y a few of the products seem to consider g r o u n d b o u n c e . The following are providers of three of the best a n d m o s t used extenders: S p a r k y S o l u t i o n s The first to i m p l e m e n t s u p p o r t for Hewlett-Packard c o n n e c t o r s . Have i m p l e m e n t e d c u s t o m frames to p r o v i d e better g r o u n d i n g . A h i g h - q u a l i t y extender. M o b i l e M e d i a O n e of the first suppliers of d e v e l o p m e n t tools in the PCMCIA market. Offers two extenders, a Type C o n v e r t e r a n d a Pro series extender. Both of these are h i g h - q u a l i t y extenders. The designers have paid particular a t t e n t i o n to g r o u n d b o u n c e a n d crosstalk. The Pro series e x t e n d e r is p r o b a b l y the best e x t e n d e r in the PCMCIA market. IBM C e l e s t i c a Best m e c h a n i c a l design. A solid a n d reliable extender. Does n o t pay as m u c h a t t e n t i o n to g r o u n d b o u n c e as the o t h e r two products.

248

DESIGNING PCMCIA CARDS

Debugger-Exerciser

9.7.2

The configurable nature of PCMCIA requires a large number of registers. A PCMCIA debugger-exerciser to configure the host controller and PC Card and generate appropriate cycles on the bus is a useful tool. Most designers tend to write their own test software. However, a visual tool k n o w n as the PCMCIA Debugger/Monitor is available. It is available from Mobile Media. Cirrus Logic makes a debugger solely for Cirrus controllers.

9.7.3 Socket Tester A socket tester is a useful diagnostic and test tool for host sockets. The best k n o w n socket testers are made by Sycard Technology.

9.7.4 ClS Development CIS design is extremely troublesome for PC Card designers. Most of the problems involve compatibility. Mobile Media makes a CIS compiler available k n o w n as the CIS Generator. It is useful for playing what-if scenarios with a CIS.

9.8 SUMMARY This book covers a great deal of material, but it is not a substitute for the knowledge that comes with hands-on design of PC Cards. A good way for the designer to learn is to buy prototyping kits to experiment with PC Card interfaces, CIS, and hosts. Prototyping kits are available from m a n y vendors. Excellent sources of the vendors of developmental tools in PCMCIA are the PCMCIA Resource book and Mobile Computing Design and Mobile Media's newsletters. PCMCIA also has a bulletin board and a home page on the World Wide Web, which is an excellent source of information on PCMCIA. Other possible sources of information about vendors are the following: 9 9 9 9 9 9

Alt.peripheral.pcmcia (newsgroup in Usenet) Http://WWW.PC-Card.com PCMCIA bulletin board PCMCIA office PCMCIA Resource reference Mobile Computing Design magazine

If all else fails, one may contact the PCMCIA subcommittee chairpersons. They usually know most of the vendors and can direct designers to the appropriate sources.

INDEX

Aborts master, 62 target, 62 Addresses, I/O, 16-17 API (Applications Programming Interface), 4 ATM (asynchronous transfer mode), 91 Attribute memory space, 14

BISTs (built-in self tests), 112 Bridge architecture, 165-167 configuration, 194 Bus, 16-bit, 11-38 16 bit transfers, 36 address spaces, 15-17 attribute memory address space, 16 c o m m o n memory, 16 defined, 11-14 electrical characteristics, 36-38 enhancements over the ISA bus, 12-14 I/O addresses, 16-17 implementation, 12 signals, 18-30 address, 19 bus, data DO-15, 19 cycle definition signals, 24-26 definition of terms, 19 DMA, 28-29 execution control, 26-28 power, 29-30 status, 20 transfer protocols, 31-36 voltage levels, 37-38 word or byte alignment in, 17 Bus 32-bit 39-65; See also CardBus defined, 11-14 interface, 5-6 ISA (Industry Standard Architecture), 5, 12-14 master and slave capabilities, 12

memory-only mode, 14 PC-AT, 5 predefined address spaces, 12 signals, 18-30 topologies, 51

Calls, socket services, 140-142 Card; See also CardBus; PC Card; PCMCIA basic architecture, 150-152 defined, 2 designing a PCMCIA, 199-248 enabler issues, 155-156 functionality, 144-150 client registration, 144-145 event notification, 145-147 resource allocation, 147-150 fundamental issues, 152-155 I/O, 4 insertion interface, 70-73 detecting card types, 71 voltage keys, 71 voltage sensing, 71-73 memory, 4 services, overview, 142-156 CardBus (32-bit bus) address spaces, 52-53 configuration spaces, 52 locating the configuration information structure (CIS), 53 bus master support, 59 clock management, 63-64 command definitions, 54 configuration space, 107-110 configuration space header, 110-114 base address register, 112-113 cache line size, 111-112 CIS pointer, 114 command register, 110 header type, 112 interrupt pin register, 114 latency timer, 112 status register, 110-111

249

250

INDEX

CardBus (32-bit bus) (Cont.): configuring cards, 105-114 differences between PCI and, 51-52 differences from PC Card, 48-51 bus master support, 48-49 clock management, 49 hierarchical bus structure, 50 multiplexed address and data bus, 48 PCI-based transfer protocols, 48 point-to-point bus, 51 reflective wave signaling, 49-50 slew rate control on signal drivers, 49 error detection, 64-65 CPERR#, 65 parity rules, 64-65 host implementation overview, 47 host interface, 184-195 16-bit support, 193 arbitration, 195 bridge configuration and status registers, 194 handling parity, 193-194 hierarchical buses, 187-189 interrupts, 192-193 latency timer, 195 mapping issues, 189-192 summary, 195 interface, 170 interrupts, 62-63 CINT#: general purpose, 62-63 CSTSCHG: card status, 63 multifunction accessing multiple functions, 127 arbitration between two master functions, 130-131 determining multiple functions, 127-129 managing interrupts, 129-130 PC cards, 126-130 overview, 39-41 applications, 40 capabilities, 40-41 definition of terms, 41 history, 39 pin assignment table, 41 pin summary, 41-46 read cycles, 56-58 signal I/O driver types, 45-46 standard, 6 terminating a cycle in, 59-62 master aborts, 62

normal termination initiated by master, 60 target aborts, 62 target-initiated termination, 61-62 transfer protocols, 55-56 bus cycles, 55-56 byte packing during writes, 56 turnaround states, 56 write cycles, 58 CCR (card configuration register), 14, 16, 70, 101, 117, 212 CIS (card information structure), 5, 16, 67, 96-100 Clock management, 63-64 Common memory, 16 Common memory space, 14 Configuration, 70, 73-77 bridge, 194 changes in PCMCIA release 2.1, 75-77 information structure overview, 74-75 option registers, 101-103, 121-122 registers, 103-104 status registers, 122 tuple structure, 77 Connectors, selecting, 210 Copy registers, 104-105 CPU (central processing unit), 47, 111 CRPM (configuration registers present mask field), 81 Current inrush, 68-69 supply, 68-70 Cycle definition signals, 24-26

Data memory, 16 Data transfer protocol, 11 Debugging, 244-248 Design 16-bit input-output example: fax/modem, 212-220 16-bit memory card example, 220-225 16-bit PC Card, 200-212 electrical requirements, 208-209 interface design, 201-208 mechanical requirements, 200-201 PCB layout considerations, 211 selecting connectors and frames, 210 CardBus master card example: LAN cards, 232-244 and development guidelines, 8-9 issues, 6-8

INDEX PC Card, 225-232 electrical issues, 232 interface logic issues, 228-231 PCMCIA cards, 199-248 DMA (direct memory access) implementation, 181-182 signals, 28-29

EDC (error detection) generators, 136 EEPROM (electrically erasable read-only memory), 79 Electrical characteristics, 36-38 Embedded hosts, 170 Embedded systems defined, 136 EPROM (Erasable Programmable read-only memory), 52, 79 Error detection, 64-65 ESD (Electro Static Discharge) clamp diodes, 63 Event management signals, 11 Execution control signals, 26-28 Extended status registers, 105

Fax/modem PC Card, 212-220 configuration information structure (CIS), 214-220 input-output connection, 220 input-output decoding, 214 interface, 212-214 FCRs (function configuration registers), 70, 117-118, 200 FDDI (fiber distributed data interchange), 91 FETs (field effect transistors), 204 Flash memory cards, 220-225 Frames, selecting, 210 Function configuration registers, 101 Function defined, 115

Guidelines, design and development, 8-9

Host design, 165-198 16-bit interface, 169-184 basic issues, 170-172 detecting card insertion and removal, 175 DMA implementation, 181-182 interrupt steering, 172 key host controller vendors, 184

251 mapping, 172-175 power switching, 182-183 reading status and events, 178-179 register overview, 177-178 reset control, 175 support of PC card events, 172 switching interface, 176 using memory and I/O windows, 179-181 bridge architecture, 165-167 CardBus interface, 170, 184-195 16-bit support, 193 arbitration, 195 bridge configuration and status registers, 194 handling parity, 193-194 hierarchical buses, 187-189 interrupts, 192-193 latency timer, 195 mapping issues, 189-192 summary, 195 embedded, 170 embedded systems interface, 195-198 overview, 165 PC Card bridge, 168 PC-based, 168-170 types, 168-170

I/O (input-output), 11, 84 addresses, 16-17 card design, 206 Cards, 4 connectors, 161 registers, 239-241 I/O-memory interface, 14 IC Card; See also Card; CardBus; PC Card; PCMCIA ID (identification), 74 Inrush current, 68-69 Insertion issues, 68-70 power consumption restrictions on supply current, 68-70 supplying voltage and power, 68 Interface bus, 5-6 CardBus, 170 and configuration, 67-114, 67-68 embedded systems host, 195-198 I/O-memory, 14 logic issues, 228-231 16-bit, 169-170

252

INDEX

Interrupts, 62-63, 129-130 IPL (initial program load), 77 IRQ (interrupt request), 84 ISA (Industry Standard Architecture) bus, 5, 12-14

Mobile Computing Technology magazine, 161 MTDs (memory technology drivers), 135 Multifunction CardBus cards, 126-130 Multifunction PC cards, 115-131

JEIDA (Japan Electronics Industry Development Association), 1

OPTROM (one-time programmable read-only memory), 79 OS (operating system), 90

LAN (local area network), 28, 90 LAN (local area network) card design, 232-244 block diagram, 241 bus transactions, 235 configuration information structure (CIS) design, 244 configuration space, 235-239 critical timing, 243-244 I/O registers, 239-241 interface design, 241-243 signals, 234-235

Management, clock, 63-64 Master aborts, 62 MAT (media access table), 144 Mechanical issues, 157-163 connectors, 160 dimensions, 157-158 frames, 160-161 height analysis, 161-163 host connectors, 158-159 I/O (input-output) connectors, 161 overview, 157 Mechanical requirements, 200-201 Memory common, 16 data, 16 Memory cards, 4 design, 204-205 flash, 220-225 configuration information structure (CIS), 224-225 interface, 221-224 register implementation, 224 Memory space attribute, 14 common, 14 Memory-only mode signals, 23 Mobile Computing DesiD7 magazine, 14, 248

PC Card, 16-bit, configuring, 101-105 card configuration registers (CCR), 101 configuration option registers, 101-103 extended status registers, 105 pin replacement registers, 104 socket and copy registers, 104-105 PC Card 95, 157 PC Card; See also Card; CardBus; PCMCIA 16-bit overview, 14-15 defined, 2 design, 200-212 fax/modem, 212-220 form factor, 1 host design, 165-198 16-bit interface, 169-184 bridge architecture, 165-167 embedded, 170 overview, 165 PC Card bridge, 168 PC-based, 168-170 types, 168-170 mechanical issues, 157-163 connectors, 160 frames, 160-161 height analysis, 161-163 host connectors, 158-159 I/O (input-output) connectors, 161 issues, dimensions, 157-158 multifunction, 115-131 16-bit, 116-126 interface example, 123-125 interface solutions, 126 IREQ# sharing the line, 122-123 overview, 115-116 types, 115-116 standards, 3-5, 8 technology, 2 testing and debugging, 244-248 types, 3 PC-AT bus, 5 PC-based hosts, 168-170

INDEX PCBs (printed circuit boards), 9, 157 PCI (Peripheral Component Interconnect), 6 PCIC (PCMCIA Interface Controller), 170 PCM (pulse code modulation), 91 PCMCIA; See also Card; CardBus; PC Card applications, 2-3 background, 1-2 cards designing, 199-248 fax/modem, 212-220 mechanical requirements, 200-201 overview, 1-10 introduction, 1 products, 3 release 2.1 changes, 75-77 software, 133-156 card services, 142-156 models, 135-136 overview, 133-136 socket services, 136-142 PCMCIA (Personal Computer and Memory Card International Association), 1 PCMCIA Reference Directory, 161 PCMCIA Resource, 248 PCs (personal computers), 1, 47 Pin replacement registers, 104 Point-to-point topologies, 51 Power consumption restrictions on supply current, 68-70 signals, 29-30 supplying, 68 Protocols, transfer, 31-36

Read cycles, CardBus, 56-58 Registers configuration, 103-104 option, 101-103, 121-122 status, 122 copy, 104-105 extended status, 105 function configuration, 101 I/O, 239-241 pin replacement, 104 socket, 104-105 status, 103-104, 194 Releases, 1.0, 2.0, and PC Card 95, 1, 15 ROM (read-only memory), 79

253 Signals bus, 18-30 address, 19 cycle definition signals, 24-26 data DO-15, 19 definition of terms, 19 power signals, 29-30 status signals, 20 cycle definition, 24-26 DMA, 28-29 execution control, 26-28 IREQ#: Interrupt Request, 26 RESET, 27-28 memory-only mode, 23 power, 29-30 GND: ground, 30 Vcc: power supply, 30 VPP1-2, 29-30 status BVD1 and BVD2: battery voltage detect 1 and 2, 23 CD1-2#: card detect, 20 READY: card ready (RDY/BSY#), 21-22 SPKR#: binary audio, 23 STSCHG#: status change, 23 VS1-2: voltage sense pins, 20-21 write protect (WP), 22-23 16-bit bus, 11-38 SMT (surface mount technology), 211 Socket registers, 104-105 services, 136-142 Software, PCMCIA, 133-156 Standards CardBus, 6 PC Card, 8 Status registers, 103-104, 194 Status signals, 20

Target aborts, 62 Terms, key, 9-10 Testing and debugging, 244-248 CIS development, 248 debugger-exerciser, 248 extenders, 244-247 socket testers, 248 32-bit bus 39-65 Topologies bus, 51 point-to-point, 51 TQFP (Thin Quad Flat Pack), 201

254

INDEX

Transfers 16-bit, 36 protocols, 31-36 delaying cycle completion, 32-35 I/O data, 32 memory data, 31-32 Tuples configuration table index bytes, 84-86 configuration tuple (1Ah), 81-83 defined, 74 device information tuple (01h), 79-80 feature description structures, 87-90 I/O space description structure, 89 interrupt descriptor structure, 89 memory space descriptor structure, 89-90 miscellaneous features descriptor, 90 power description structures, 87-88 timing description structures, 88 feature selection byte, 87 function extension tuple (22h), 90-92 function ID tuples, 90 interface description bytes, 86-87

interpreting, 94-95 key, 78-92 miscellaneous conditions 3.3V characteristics (1Ch), 80-81 overview, 78 structure, 77 supporting multiple chains, 92-94 version and product information tuple (15h), 92

Voltages levels, 37-38 sensing, 71-73 supplying, 68

WP (write protect), 22-23 WPS (write protect switch), 79 Write cycles, CardBus, 58

XIP (Execute in Place), 4