CA2143492A1 - Portable pcmcia interface for a host computer - Google Patents
Portable pcmcia interface for a host computerInfo
- Publication number
- CA2143492A1 CA2143492A1 CA002143492A CA2143492A CA2143492A1 CA 2143492 A1 CA2143492 A1 CA 2143492A1 CA 002143492 A CA002143492 A CA 002143492A CA 2143492 A CA2143492 A CA 2143492A CA 2143492 A1 CA2143492 A1 CA 2143492A1
- Authority
- CA
- Canada
- Prior art keywords
- card
- pcmcia
- system bus
- adapter
- hardware
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/10—Program control for peripheral devices
- G06F13/102—Program control for peripheral devices where the programme performs an interfacing function, e.g. device driver
Abstract
A portable PCMCIA interface for a host computer having a system bus. In one embodiment, the host computer is a SPARC based computer having an SBus and running the UNIX operating system. The PCMCIA interface provides a user application with access to a PCMCIA card. In this embodiment, the PCMCIA interface includes software and hardware components. The software component includes a hardware-independent portion and a hardware-dependent portion. By implementing the software in a suitable high level language such as "C", the software can be easily ported to other hardware platforms by merely adapting the hardware-dependent portion. The hardware component includes an ASIC coupled between the system bus and a couple of PCMCIA
sockets. In some embodiments, the hardware also includes a 5 volt to 12 volt DC-DC converter between the system bus and the PCMCIA sockets.
sockets. In some embodiments, the hardware also includes a 5 volt to 12 volt DC-DC converter between the system bus and the PCMCIA sockets.
Description
-Pagc: 1 RACKGROUND OF THF ~ ITION
Field of the InvPnhor~
This invention relates to an interface between a host computer and a peripheral devicc. Morc particularly, thc invention relates to an interface between the host c~,~putc,- and a Personal Computer Memory Card International Accoci~tion (PCMCIA) peripheral card.
nescript;~n Of The R~l~t~ Art Figure lA is a block diagram showing the haldware co.llponents of a conventional non x86 based host col~p~l~r, such as a scalable processor architecture (SPARC) host co~ ur~el . (SPARC~!D
is a registered trademark of SPARC International, Inc.) Host computer 10 includes a host central processor unit (CPU) 20, a memory bus ~M-bus) 35, a host memory 30, a host bus controller S0, a standardized host system bus 55 and input/output (UO) devices such as a monitor/keyboard/mouse 41 and a hard disk drive 42. System bus 55 interconnects and provides co~ nication between CPU
20 and VO devices 41, 42. In some host computers, system bus 55 is a SPARC based SBus.
Figure lB illustrates the software components of the host computer of Flgure lA. A UNIX
user application 31 is coupled to a UN~C operating system (O/S) 130 having a kernd 32 and hardware-dependent drivers 33, and system bus 55. (UN~C(!9 is a registered tradernarlc of UN~C
System Laboratones, Inc., a wholly-owned subsi~ y of Novell, Inc.) System bus 55 is coupled to UO devices 41,42. Typically, when host computer 10 is first initi~li7~. UN~ O/S 130 is loaded into host memory 30.and remains resident until co,.~put- r 10 is powered down. Consequently, VO
device drivers 33 co"~s~onding to VO devices 41,42 are loaded and user application 31 has acccss to VO devices 41,42 by making the appropriate calls to kernel 32 which C0~ `9~5 thc access via device drivers 33, system bus 55 to UO devices 41, 42.
The increase in the processing power of computers such as host computer 10 has caused a corresponding increase in the complexity of user applications such as application 31. As a resul~, there is an increasing need for additional memory, mass storage and co~".~ ic~tion devices, the most convenient form being an extemal device coupled to system bus 55. Typic~lly, adding cxtemal 21434~2 Page: 2 memory or mass-storage devices to host computer 10 involves the insertion of an adapter in the form of a printed circuit board (PCB) into an available system bus slot located inside the housing of COIl" uler 10. When inserted into the system bus slot, the PCB is electrically coupled ~o system bus 55 and the adapter is therefore capable of co.. ",~ g with host CPU 20. Hence, the ..l~ ulllll number of external devices that ean be coupled to host computer 10 is limited by the total number of system bus slots available within computer 10. Further, a typical non-technical user is not trained to insert or remove PCBs, and a trained te~hnici~n or service person is reiquired to make such an upgrade or change.
Meanwhile, in a different hardware arena of computers based on Intel's x86 farnily of 10 microprocessors, such as the IBM personal co---l,ulc., a PCMCLA specification was developed to promote both compatibility and interoperability for adding external devices. antel(~ is a le6;~te-~trademark of Intel Corporation and IBMt9 is a rcgistered tr~lem~* of International Business Machines Corporation.) Typically a PCMCIA adapter provides standardized PCMCIA socket(s) for plugging in PCMCIA cards (PC cards), and is controlled by associated interface software running on the host computer. Hence, it is now possible for an end user to easily insert and interchange a wide variety of external peripheral and memory devices implemented in the PC card format into an x86-based host computer on demand.
Initially, the x8~based PCMCIA interface was designed for relatively fast random access memory (RAM) cards and hence the specified read/write protocol between the adapter and the 20 x86-based host computer is sirnilar to that neccssd- ~ for a mery-type access operation. PC cards with memory include RAM PC cards and hard disk drive PC car~s. More reeently, the PCMCL~
specification was extended to acco~ te PC cards requiring UO type data access protocol, such as FAX modem cards.
Figure 2 is a block diagram showing both the software and hardware components of one such prior art x86-based host computer having a PCMCIA interface specifically designed for an x86-based comput~,l system bus, such as an ISA or VESA bus. The software component includes 21~3~9~
Page: 3 user application 141, Microsoft's disk operating system (DOS) 142 and an x8~bascd hardwarc-dependent PCMCIA soflw~e driver 143. (Microsoft~D is a registcred trademark of Microsoft Corporation.) The hardware component includes an x86-based system bus 145 and an x86-based PCMCIA adapter 146 having a pair of PCMCIA sockcts 147a, 147b for housing a corresponding pair of PC cards 110, 120. Two examplcs of prior art integratcd circuits (ICs) for the x86 bascd PCMCLA adapter are Intel's 82365SL PC card inte~ce controller and Cirrus Logic's CL-PD6710/20.
Uscr application 141 accesscs PC card 110 or 120 by first making a standardized system call to DOS 142. Next, DOS 142 makes the appropriate PCMCIA call to x86-based PCMCL~ software driver 143 in order to co~ u"icate the access across x86-based system bus 145 to PCMCIA adapter 146. Upon receiving the access request over bus 145, adapter 146 translates the system bus signals into standardized PCMCLA signals for PC card 110 or 120.
Onc problem associated with the conventional PCMCIA interfacc is that the PCMCIAspecification was originally devcloped for computcrs based on Intcl's x86 farnily of r~ucroprocessors running operating systems such as DOS, MS-~mdows or OS/2. (MS-Windows~D
is a trademark of Microsoft Corporation.) Consequently, the PCMCLA spccification was optimized for softwarc drivers which are coded in whole or part in an x86 assembler language which cannot be easily ported to non-x86-based computer systems.
Another problem with most conventional operating systems, such as UN~ and DOS, is that 20 they arc not designed to arbitrarily allow hardware deviccs to be connectcd and flisconnected a random while the host COlllp~t~- is operating. Traditionally, at systcm boot tirne cach device drivcr is polled once to determinc if the corresponding hardware dcvice is present. If the device has been disconnccted or is non-functional, the device driver is either unloaded from the host computer memory, or if left in the mcmory, thc drivcr is never used. This particular conYcntional operating system characteristic prevents PC cards from bcing safcly "hot-plugged", i.e., the practice of inscrting or removing PC cards from a PCMCLA socket while the host coLIJpulcr is operating.
2143~9~
-Page: 4 Hencc, there is a need for a portablc PCMCIA interface which fully supports the software and hardware PCMCLA specific~ion and is independent of the host computer's bus architecture, proccssor or operating syste~ Such a portablc PCMCIA interface will cnablc other host computers based on hardware a,ckitect~s such as SPARC, and operating systems such as UNIX, to utilize the growing bank of standaldized PC cards, while fully supporting the PCMCIA featu~es such as hot-plugging.
21~3492 Page: S
SUMMA~Y OF THF Ir~lVF~1TION
The present invention provides a portable PCMCLA interface operational on many host computer architectures to couple a user application to a PC card~
In one embodiment, the user application runs in a host computer having a host system bus.
The PCMCLA interface includes both software and h~d~e col-~ponents. The PCMCL~ interface software includes a hardware-independent portion and a h~dwd~e-dependent portion, with a defined extemal interface between the user application and the hardware-independent portion. The external PCMCLA sonw~ interface provides PCMC~A Csrd Services and Socket Services to the user application in a manner l-~nsy~nt to the underlying har~lw~e, e.g., the PC card. In addition, 10 there is a defined internal interface between the hardware-independent and haldw~e-depender.t portions of the PCMCL~ intcrface software, enabling the entire PCMCLA interface to be easily ported to other host computers by merely adapting the hardware-dependent portion.
The PCMCLA interface hardware includes a PCMCLA adapter coupled to the system bus, the adapter having at least one PCMC~A socket for acc~ od~ting the PC card. The user application initiates all data transfers to and from the PC card, as dictated by the PCMCL~
specification. The host system bus compatible PCMCLA adapter s.Jypol~s 8 bit, 16 bit and 32 bit data transfers to and from attribute memory space, common mcmory space and UO space of the PC
ca~.
In sorne embodiments, the addition of power switching circuitry between the system bus 20 power supply and PCMCLA socket(s) of the PCMCIA adapter enables the PC card(s) to be safely inserted in and removed f~m the PCMCLA socket(s) without the need for powering down the host computer. An optional S volt to 12 volt DC-DC converter provides additional compatibility for PC
cards requiring a 12 volt supply.
The PCMCLA inter~ace of the present invention has a number of advantages over the prior arL By providing a defined internal interface between the hardware-independent and hardware-dependent portions of the PCMCLA interface software, the specific characteristics of the 21~3~
Page: 6 system bus, the adapter and the PC eard be,come transparent to the user applieation soflwue running on the host co.upu~c,r. In addition, by implem~nting the software in a high level proglamrning language, the entire PCMCLA in~erface software can be ported to other host eomputers having different operating systems and ha~ ; architectures by merely adapting the hardware-dependent portion. Accordingly, the PCMCIA interface of the present invention provides a hardware and software solution which can be easily ported to other host co-upU~
Pagc: 7 I)F~CR~ION OF THF DRAW~GS
The objects, featurcs and advantages of the system of the present invention will be sppal~n from the following description in which:
Figure lA illustratcs the hardware co-l-ponellts of a convcntional SPARC host COlllputCr.
Figure lB illustrates the softwarc components of the host computer of Figure lA.Figure 2 illustrates a prior art x8~based host comruter having a PCMCIA interface.
Figure 3A illustrates a PCMCIA interface coupled to a host co,llpùle ( in accoldancc with one e.,lbo~ ent of the present invention.
Figure 3B illustrates the PCMCIA interface software running on the host Co~ Jut~r of Figure 3A.
Figure 4 is a block diagram showing the PCMCLA interface softwa,e in greater detail.
Figure 5 is a flow chart illustrating an access of a PC card by a user application running on the host co"lyuter.
Figure 6 illustrates a PCMCIA hardware adapter of the present invention.
Figure 7 is an address map showing the SBus address space of the host computer allocated to PC cards. - -Figure 8 are two timing diagrams illustrating conventional PCMCIA read and write access cycles.
Figure 9 illustrates a PC card read access of an attribute or common memory space.
Figure 10 illust~ates a PC card read access of an attribute or co~ on memory space with the WAIT feature.
Figure 11 illustrates a PC c~ write access of an attribute or common memory space.
Figure 12 illustrates a PC card write access of an attribute or common memory spacc with the WAlT featurc.
Figure 13 illustrates a PC card write access of an VO space with byte sizing, but without the WAlT featurc.
Page: 8 nF~CR~ION OF THF PRFFF,RRFI) FI~RODrl~FNT
In Figune 3A, a scalable p,ocessol architecture (SPARC) based host coll-p~te. eoupled to a PCMCIA adapter of the present invention is shown. For more information on the SPARC complJter architeet -re, see the SPARC Arehite~tllre Manual, Version 8, 1992, available from SPARC
International, Menlo Park, California As the operation of SPARC-based host computer 10 is well known, a detailed description is not provided herein.
In acco,~nce with one embodiment of the invention, host cOIl~pllle( 10 is coupled to a PCMCIA adapter 100 via system bus 55 Adapter 100 has a pair of PCMCIA sockets 107, 108 for housing a corresponding pairof PC cards 110, 120. PC cards 110, 120 are inserted into adapter 100 via a eorresponding pair of 68-pin connectors located within PCMCLA sockets 107, 108.
It should be noted that adapter 100 rnay assume a variety of physical configurations. For example, in one embodiment for a desktop computer, adapter 100 includes an application specifie integrated circuit (ASIC) mounted on a peripheral printed cireuit board (PCB), with the PCB
oecupying a physical slot in system bus 55. An eleetrical eable intereonnects the ASIC to PCMCLA
soekets 107, 108. In another embodiment for a palm-top computer, adapter 100 ineludes an ASIC
which resides, together with CPU 20 on a r~in PCB. An eleetrical cable interconneets the~ASIC
to PCMCIA soekets 107, 108 which are attached to the palm-top computer housing. Alternatively, PCMCLA sockets 107, 108 are mounted together with the ASIC and CPU 20 on the main PCB of the desktop or lap top eomputer, thereby eliminating the need for an interconneeting electrical eable.
20 Other embodiments and variations are also possible and will be apparent to one skilled in the art in view of this disclosure.
For the purpose of describing the operation of a PCMCIA interface software driver running on host eomputer 10 and controlling PCMCIA adapter 100, reference is rnade mainly to PC eard 1 10 and its associated hardware and software drivers. Sinee both PC Cards 110, 120 are electrieally and physieally eoupled to PCMCIA sockets 107, 108"~s~lively, the description of the opc-ation of 214~92 Page: 9 thc software drivcr and adapter 100 with respect to first PC card 110 is cqually applicable to sccond PC card 120.
In this emborliment, as illustrated by the block diagram of Flgure 3B, an UNIX OpCI~tL.g system 135 which includes UN~ kernel 32 ~nd device drivers 33, also includes a PCMCLA interfa~c software driver 34. A UN~ compa~ible user application 31 accesses PC card 110 via PCMCL~
interface software driver 34, system bus 55 and adapter 100. Sofltware driver 34 includes a hardware-inAfvpendent portion 34a and a ha.~l~ale-dep,nden~ portion 34b.
Interface software driver 34 is coded in a suitable high level progrq~nming language, such as the "C" language, enabling source code of driver 34 to be easily ported to other host co...yu~
10 plaffonns by merely making source code changes to hardware-dependent portion 34b and recompiling drivcr 34. Exarnples of other possible host com~ut~ . configurations include the UNIX
operating system on an x86 rnicloploc~ssor based C01l'Ulf,~ . Otller variations and mo~ific~tion~ of host computer platforms are apparent to one skilled in the art.
Figure 4 is a block diagram- showing PCMCLA interface software driver 34 in gr~ater dctail.
Hardware-independent portion 34a includes a pair of PC card drivers 260, 270, a PCMCL~ nexus driver 210, an event manager 230 and a Card Services layer 220. Hardware-dependent portion 34b comprises a system bus compatible PCMCIA adapter dliver 250 for controlling adapter 100. By clearly defining an internal interface 215 between hardware-independent nexus driver 210 and hardware-dependent system bus compatible adapter driver 250, in accordance with one aspect of 20 the invention, the entirc PCMCIA interface can advantageously be portcd to different host co_, platforrns by merely adapting hardware-dependent portion 34b of interface soflw~e driver 34.
Before user application 31 can begin aessing PC card 110, PCMC~A interface software driver 34 must first be loaded into host memory 30. Loading of the various portions of software driver 34 is accomplished during initialization of host computer 10. When PCMCIA nexus dnver 210 is first loaded, nexus driver 210 searches through a list of aD possible adapter drivers stored in a configuration file, and attempts to load each adapter driver into the configuration file. For each 2143~92 -Page: 10 ~.,ccessful load of a specifie adapter driver, e.g., adapter driver 250, nexus driver 210 loeates a co,l~t,sponding driver app~t~s strueture, e.g. structure 251, associated with eaeh adapter, e.g., adapter driver 250. Adapter driver 250 then saves a pointer to the corresponding driver apparatus structure 251.
Next, PCMCLA nexus driver 210 queries PCMCIA adapter driver 250 to obtain its basie adapter char~cterisdcs and adds PCMCLA sockets 107, 108 to the list of available logical soekets.
Nexus driver 210 then exports the logical socket list to Card Services layer220. Consequently, Card Services layer 220 has access to a hardware-independe-nt Son~e interfaee 215 located between nexus driver 210 and adapter driver 250, enabling Card Services layer 220 to cont~1 and manage the resources of adapter 100 and PCMCLA socket 107 in a har~w~re-independent rnanner. Nexus driver 210 also exports the same logical socket list to adapter driver 250 thereby establishing a one-to-one logical socket communi~a~;on channel betwe~en Card Services layer 220 and adapter driver 250.
Card Services layer 220 also includes a Card Information Structure (CIS) interpreter 220a which enables PC card 110 to be self identifying independent of the host computer architecture and operating system, by requiring PC card 110 to maintain self-indentifying inforrnation in its-CIS.
The CIS is stored in an Attribute Memory space of PC card 110 and is made up of a singly-linked list of variable-length elements called tuples. Interpreter 220a is a tuple parser which is responsible for processing all of the tuple information. As such, PC card driver 260 does not need any tuple 20 parsing code.
In this embodiment, each tuple is one byte in Iength, with up to 256 distinct tuples stored in the CIS of PC card 110. ~hen a tuple is parsed and recognized by intc.~ tc. 220a, interpreter 220a causes the tuple data from PC card 110 to be copied into a tuple entry in an interpr~ter linked list 220b. Conversely, when interpreter 220a does not recognize the tuple, a flag is set in-lie~ting that the tuple was not recognized and that tuple data from PC card 110 should not be copied into a tuple entry in interpreter linked list 220b. Upon the successful parsing of the CIS of PC card 110, linked 2~3~9~
Pagc: 11 list 220b contains the configuration pa- ~l~cte~ of PC card 110, e.g., type of PC card, memory capacity and access speed. Subsequently, Card Services layer 220 uses linked list 220b for processing card service requests from PC card driver 260.
In some embodi- Je.-b, PCMCIA nexus driver 210 does not export its private interface 215 with adapter driver 250 to PC card driver 260. Interface 225 between Card Services layer 220 and PCMCIA nexus driver 210 is also private, e.g., PC card driver 260 does not make direct calls to PCMCLA nexus driver 210. Instead, whenever user application 31 accesses PC card 110, all calls to PC card driver 260 destined for PCMCIA nexus driver 210 are serviced through Card Services layer 220. As such, Card Services layer 220 provides PC card driver 260 a single entry point with 10 a variable ar~ ~m~ei.t list based on the function requested.
Next, in order to support a PCMCLA specified event callback feature, event manager 230 is loaded as a separate STREAMS, enabling nexus driver 210 to communicate PCMCIA events, sueh as PC card insertiontremoval (hot-plugging), to user application 31. (A STREAMS is a UN~C
full-duplex connection between a process and a device driver). Hence, nexus driver 210 is provided anefficienteventcallbackme~h~nismtouserapplication3l~witheventmanager23oobservingthe evenlsand managingbothadapter 100and PCcard llOviaadapterdriver250. Eventmanager230 is an efficient solution because the number of PC cards available make it unwieldy and inefficient for user application 31 to poll for every possible PCMCIA card~ More irnportantly, event manager 230 typically provi~es the sole me~h~nism (generally ~suppo~ied by UNIX) forimplementing the 20 PCMCL~ specified charmel for unsolicited feedback to user application 31.
For eY~ple~ when PC card 110 has been successfully inserted into PCMCIA socket 107, nexus driver 210 receives a "card insertion" event notification from adapter driver 250, enabling nexus driver 210 to koep ~ack of which type of PC card is present in socket la7. Subsequently, a corlesponding PC card driver, e.g., driver 260, is loaded and nexus driver 210 updates the corresponding driver apparatus structure, e.g., structure 251, thereby forming an association between PCMCIA socket 107 and PC card 110. A discussion of the PCMCIA interface hardware ., Page: 12 for supporting this event callbaek feature is ineluded in a detailed hardware description of adapter 100 below.
Onee the loading and ini~i~li7~tion of PCMCIA interfaee software driver 34 are eompleted, user applieation 31 has aceess to adapter 100 and PC eard 110. Figure 5 is a flow ehart illustrating an aecess of PC eard 110 by user application 31 running on host co~upuler 10 in acco~ance with one embodiment of the invention.
First, user applieation 31 makes an extemal hald~e-independent PCMCIA call to PC eard driver 260. Card driver 260 responds by requesting an appropriate eard service from Card Services 220. Card Services 220 is responsible for proeessing all eard services requests from PC eard driver 260 and making the app,op.iate calls into PCMCIA nexus dnver 210. PC card driver 200 provides Card Serviees 220 with a pointer to PC card driver's device inforrnation pointer (DIP) thereby uniquely identifying PC eard 110 and providing a path to PC card driver 260's parent proeess, i.e., nexus driver 210. Card Services layer 220 then uses the DIP to locate and to make the app,op,iate ealls into nexus driver 210. Such calls include adapter hardware configuration requests destined for socket services provided by adapter driver 250.
In,~ s~onsetotheappropriatecallsfromCardServiceslayer220,nexusdriver210generateseorresponding internal hardware-independent software calls to PCMCIA adapter driver 250. (For additional information on PC Card Serviees, please refer to Appendi~ A, whieh is ineorporated herein.) Hardware-dependent adapter driver 250 then converts the internal sofhvare ealls into appropriate system bus signals for adapter 100. Adapter 100 in turn gene,~tes the appropriate PCMCLA card signals for PC eard 110 located in PCMCIA socket 107.
In sum, user applieation 31 initiates data aceesses vith PC eard 110 by co~ icatillg the re~uest in the form of a ha, iwa~e-independent external PCMCIA call to PCMCIA interfaee software d-iver 34. In turn software driver 34, resident on host memory 30, receives the external PCMCIA
eall and causes the appropriate-dependent adapter specifie signals to be assened on system bus 55.
Hence, having described the operation and services provided by the various portions of interfaee 21~3~92 -Page: 13 software dnver 34 in converting an aeeess request from user application 31 into the appropriate system bus signals, the operation of the PCMCIA interface har~ c, i.e., adapter 100 and PC eard 110 is now deser~bed in detail.
In one embodirnent as illustrated by F~gure 6, PCMCL~ adapter 100 ineludes an applieation specificlC(ASI(~)lOOahavingahostbusinterfaccbufferlOl,anadaptercorelogiclO2,andacard interfaee buffer 103. Adapter 100 also ineludes a power switeh 10S, a PROM 106, and a pair of PCMCIAsoeketslOî,108. PROM106isanopenbootPROM(OBP)whiehprovidesstandardboot ROM funetionality for host compu~er 10.
Figure 7 is an address map showing three megabytes of the system bus address spaee in host memory30alloeatedtoeachofPCcards 110,120,i.e.,asL~tmegabytesofaddressspaceisdedicated to PC cards 110, 120.
In this embodiment, address spaee 0 to ~ h and 3~ -h to 4~ h of rnemory 30, are reserved for aecessing PROM 106, and the content of control and status registers (CSRs) 102a, respectively. The PCMCIA specifeation also supports up to 64 megabytes each for attribute memory, common memory and VO memory space. However, in the described embodiment of PC
card 110 only one megabyte of system bus address space each is reserved for attribute m~mory, common memory and I/O address spaee. As such, address mapping is required for transposing the system bus address space within specified PCMCLA address space. The address map for the 8 megabyte address.space of adapter 100 is stored in PROM 106.
CSRs 1 02a are used to store p~ ~ete. ~ for eonfiguring adapter 100 to operate with various type of PC eards. In addition, CSRs 102a also eontain the address offset tables necess~y for mapping each of the one megabyte system bus address spaces within each of the 64 megabyte PC
card address space. These address offset table values can be modificd by host computer 10 to suit a particular PC eard, e.g., a FAX modem eard~ a RAM memory car~, or a Winchester disk d rive card.
Configuradon pararneters stored in CSRs 102a include the data access speed of PC eard 110 which 21~3~92 .
Page: 14 can vary a great deal depending on the card function, ranging from a relatively slow modem card to a relatively fast RAM card Figure 8 shows two basic timing diagrarns illustrating conventional PCMCIA read and writc access cycles on system bus 55 in response to read and write ae~sses of PC card 110 by user application 31. Note that data transfers are inidated by user application 31 as defined by the PCMCL~ specification Version 2.1. For example, in response to a read access of PC card 110, adapter 100 asserts card address lines ADDR and card enable line CE* of PC~CLA socket 107.
Adapter 100 then asserts the output enable signal OE*, intlic~ting a read access of PC card 110 at the location indicated by card address lines ADDR. After a specific period of time (i.c., PC card 10 read access time), PC card 110 drives the requested data onto card data lines DATA. Similarly, in response to a write access of PC card 110, adapter 100 asserts card data lines DATA, card address lines ADDR and card enablc line CE*, followed by the assertion of card writc enable linc WE.
In accordance with one embodiment of the invention, adapter 100 supports byte, halfword (16-bit)andword(32-bit)dataaccessesofPCcard 110. SincePCMCIAsocket 107canonlysupport 16-bit data transfers, any sizing is performed external to PC card 110. Although thc described embodiment of adapter 100 does not perform any data packing ~I.e., adapter 100 does not generate multiple read accesses to card 110 in response to a single system bus read request), one sl~lled in the art will be able to extend the principles of operation to othcr embodiments of adapta 100 that supports data accesses of word lengths greater than l~bits without the need for external sizing by 20 host computer 10.
In addition, when an access is initiated at an attribute memory space or at an VO addrcss spacc of card 110, card mernory select line C0_REG* is asserted low. Conversely, when an access is initiated at a common memory space, card memory select line C0_REG* is assated high.
Referring to the timing diagrarn of Figurc 9, a byte widc read initiated by computer 10 via adapter 100 of an attribute or common memory space on PC card 110 is illustrated. First, a base 'Signal is acbve low.
2i.~3 192 -Pagc: lS
address value BASE stored in a eorresponding Window Control Register of control and status register 102a and the offset address value on system bus address lines SB_PA are presented on eard - address lines C0_A thereby mapping the system bus address into a PC card address. Next, a eard output enable line C0_CE* is asserted low. L+1 elock cycles later, L being the Command_StrobePelay value ChlDDLY stored in the Window Control Register, a eard output enable line C0_OE* (shown as C0_RDCMD* in Figure 9) is asserted low. The selected PC eard, i.e., PC card 110, then retrieves the requested memory data byte intemally and presents the data value onto card data lines C0p.
After another M+l clock cycles, where M is a Command_Strobe_Length value CMDLNG
10 stored in the Window Control Register, the data byte value on card data lines C0_D is latched by adapter 100 and card output enable line C0_RDCMD* is de-asserte~ One clock later, eard output enable line C0_CE* is de-asserted. Fmally, adapter 100 asserts a byte "ACK" on system bus line SB_ACK* for host computer 10, driving the latched data byte onto system bus data lines SB_DATA
another clock cycle later, thereby completing the byte wide read cycle.
A halfword wide attribute or corrlmon rnemory read of PC card 110 is as follows. Flrst, the BASE value u the Window Control Register is applied onto card address lines C0_A, the~offset address value on system bus address lines SB_PA is applied onto card address lines C0_A, and card enable line C0_OE* is asserted low. L+ 1 clock cycles later, card output enable line C0_OE*( shown as C0_RDCMD* in Figure 9) is asserted low. Selected PC card 110 then presents the col,es~nding 20 memory data bytes onto card data lines C0_D. Aher M+1 clock cycles, the valid data b~tes on card data lines C0p are latched into adapter 100 and card enable line C0_OE* (see C0_RDCMD*) is then de-asserted. One clock cycle later, card enable line C0_CE* is de-asserted. Adapter 100 asserts a halfword ACK onto system bus line SB_ACK* and dri~es the latched data byte-swapped onto system bus data line5 SB_DATA, thereby completing the halfword read cycle.
Signal is aclivc low.
Page: 16 A word wide attribute or co~ )on memory read of PC card 110 is sirnilar to the halfword read access up to and includine the asserdon of the halfword ACK back to host computer 10. The halfword ACK on system bus 55 informs host co,nputcr 10 that the word read requires sizing. As such, computer 10 must inidate another access via system bus 55 to read the other halfword of the desired word of data. The second read cycle of the second halfword occurs in the same manner with the eYception that the value on system bus address line SB_PA [1] and also card address line CO_A
[I] are now both "1" instead of "O", so that the appropriate next halfword of data is fetched.
Asdiccuccedearlier,thePCMCIAspecificationwasoriginaUydevelopedforcxternalRAM
memory cards. However, as other slower storage m~Aill~nc, e.g., hard disk drives, were physically 10 shrunk to fit the PCMCIA forrn factors, it became neccss~ y to enhance the PCMCIA spe~ifica~ioll to support another mode of operation, i.e., aCcessing PC card 110 using a "WAlT' feature. In this embodiment,theWAlTfeatureenablesadapterlOOtoallowaslowPCcardlOOtodelayrespondingto an access by assert a card wait signal CO_WAlT$, as iUustrated by Flgure 10.
When host computer 10 initiates a read access to PC card 110 which utilizes card wait line CO_WAIT*, (a wait_re~uest bit WA~lTREQ is enabled in the Window Control Register), the BASE
value and the offset address value on system bus address lines SB_PA are is applied ont~ card address lines CO_A, and card enable line CO_OE* is asserted low. L + 1 elock cycles later, card output enable line CO_OE* (shown as CO_RDCMD* in Figure 10) is asserted low.
M + N + 2 clock cycles later, N equal to a Wait_Delay value WAlTDLY in the Window 20 Control Register, adapter 100 samples card wait line CO_WAIT$. lf card wait line Cr)_WAlT$ is asserted PC card 110 ~quires a delay in the completion of the memory access. The PC~MCIA
specification permits card wait line C~_WAll * to be asserted for a n~Yimllm of 12 _ iCI~J~Con~l5 Since the rising edge of card wait line CO_WAlT* is asynchronous with respeet a system clock of host computer 10, when PC card 110 d~-asserts card wait line CO_WAlT~, adapter 100 has to synchronize incoming card wait line C~)_WAll-$.
'Signal is active low.
Page: 17 Next, PC eard 110 asserts the requested memory data bytes onto eard data lines C0_D before de-asserting eard wait line C0_WAll'*. Adapter 100 latehes the data and de-asserts eard output enable line C0_OE* (see C0_RDCMD* of Flgure 10). One eloek cyele later, eard enable line C0_CE* is de-asserted. Finally, adapter 100 asserts an "ACK" on system bus line SB_ACK~ and a clock eycle later, presents the latched data onto system bus data lines SB_DATA.
A non-wait byte UO read access of PC card 110 is similar to that of the byte read of an attribute or common memory deseribed above with the exception that a card VO ready line C0_IORD* (shown as C0_RDCMD* in Figure 10) is asserted low instead of card output enable line C0_OE*. Similarly, a halfword VO read access begins as in the halfword read of attribute or 10 com~Don rnemory with the exception that card line C0_IORD* (see C0_RDCMD*) is used instead of card enable line C0_OE*.
If PC card 110 is capable of performing a 16-bit VO access, card 110 asserts a cand VO_is_16_bit line IOIS16 (not shown) low during the read access, and both bytes of data are presented onto card data lines C0_D, i.e., all 16 data bit lines are valid. Adapter 100 then gene,~tcs a halfword ACK to host computer 10 via system bus line SB_ACK* and presents the latched data byte-swapped onto system bus data lines SB_DATA a clock cycle later. - -Conversely, if PC card 110 is only capable of byte sized VO read access, card 110 does notassert card line IOIS16* low during the read ae~ss, and only the data byte presented on thc responding 8 bits of card data lines C0P are valid Next, adapter 100 asserts a byte ACK to host 20 computer 10 via system bus line SB_ACK$ thereby in-liea~ing that the halfword VO access requircs sizing. Host co~ uter 10 then initiates another VO access on system bus 55 to read the second byte in order to complete the halfword VO access.
An VO read of PC card 110 with the WAIT feature is also similar to the read aceess of an attribute or co,.",.on memory with the WAIT feature, with the eYception that card VO ready line C0_IORD* (shown as C0_RDCMD~ in Fgure 10) is asserted low instead of card line C0_OE~.
Signal is actiYe Ic~v.
2l43~92 Page: 18 The PCMCIA spe~ifil~ation permits a m~Yimum of 12 mic,osceon-ls delay between the bcg,~n: ~g and end of a r~ad access. However, PC eard 110 ean delay completion of the read aeeess beyond the 12 rrUcrosecQnrlc by using eard line C0_WAlT~, requiring adapter 100 to support split rea~ls on system bus 55. Once a read is initiate~d by host computer 10 on system bus 5S, a rerun ACK is asserted by adapter 100 if a time out oeeurs while eard wait line C0_WAlT~ is asserted by PC eard 110. The split read aceess is eompleted during a subsequent read retry by host eomputer 10 on system bus SS. Next, PC eard 110 de-asserts eard wait line C0_WAIT~ with the read data is presented system bus data lines SB_DATA.
Conversely, if PC eard 110 asserts but fails to de-assert eard wait line C0_WAIT* within the 20 mieroseconds du~ing a read aeeess eycle, adapter 100 terrninates the read aceess eycle and generates an interrupt on system bus 5S. The interrupt signals to host computer 10 that 8 WAIT
time-out has oeeurred.
In aecoldance with this embodiment of the invention, adapter 100 also supports non-WAlT
byte, halfword and word data write accesses on PC card 110, as illustrated in the timing diagram of Figure 11. Adapter 100 has a l~bit wide data interface with system bus 55 and with extemal siziDg perforrned by host computer 10 for word-size vrite accesses using halfword ACKs. As ~liscu~sed above when computer 10 initiates a write access at an attribute or common mernory or VO address space, eard select line C0_RE~ is asserted low.
When a byte write of PC card 1 10 at~ibute or common memory is initiated by cou~u~f 10, 20 the BASE address value and the offset address value from system bus address lines SB_PA are presented onto card address lines C0_A, the data value on system bus data lines SB_DATA is drivco onto card data lines C0_D, and card output enab1e line C0_CE* is asserted low. Next, adapter 100 asserts a byte ACK thereby terrninating the write cycle OD system bus 55. L+1 elock cyclcs lateI, card write enable line C0_WE~ (shown as C0_WRCMD~ in Figure 11) is asserted low. After M~1 Signal is activc lo~.
~t l3,~92 -Page: 19 clock cycles, card writc enable line CO_WE* is de-asscrted low. P+1 clock cycles later, P e~gual to Recovery_delay value RECDLY, card output enable line CO_CE* is dc-asserted.
When a halfword (l~bits) wide write of attribute or common mernory is initi~q~, the value of the BAS~ address value and the offset address value on system bus address lines SB_PA are presented on card address lines CO_A, the data value on system bus data lines SB_DATA is byte-swapped before being presented onto card data lines CO_D, and card enable line CO_CE* is asserted low. Next, adapter 100 asserts a halfword ACK on system bus line SB_ACK*, thereby terrninating the write cycle on system bus S5. L+ 1 clock cycles later, card write enable line CO_WE*
(shown as CO_WRCMD* in hgure 11) is asserted low. After M+1 clocl~ cycles card, write enable 10 lineCO_WE*isde-asserted. Finally,P+lclockcycleslater,cardenablelineCO_CE*isde-asserted.
The sequence of events required for initiating a word sized writc of Attribute/Memory is sirnilar to that of a halfword write of PC card 110. The difference being that adapter 100 asserts a halfword ACK terrninating the system bus w~ite cycle, thereby inforrning host co~ ter 10 that sizing is required to complete the word-size write access. Cornputer 10 responds by initiating a write of the second halfword of data over system bus 55.
Referring to the timing diagrarn of Figure 12, adapter 100 also supports data write acc~sses to attribute or cornmon memory of PC card 110 using the WAlT featur When a write access is initiated at PC card 110 which utilize card wait line C~_WAlT*, the BASE address value and the offset address value on system bus lines SB_PA are presented on card address lines CO_A, the data 20 value on system bus data lines SB_DATA is driven onto card data lines CO_D, and card enablc signal CO_CE* is asserted low. Adapter 100 then sends an appropriate ACK, ic., byte ACK for byte write and halfword ACK for halfword or word write, thereby te~Tnin~ng the system bus vrite cycle.
L+1 clock cycles later, card enable line CO_WE~ (shown as CO_WRCMD* in Flgure 12) is asserted low. M+N+2 clock cycles later, card wait line CO_WAlT* is sampled. If card wait line CO_WAIT* is equal to "0", card 110 is requesting a delay in the completion of the memory access.
Signal is activc low.
214349~
Page: 20 As di~ ~d earU, the PCMCIA specification perrnits a ...~in~:.n wait penod of 12miclosecon-lc When PC card 110 de-asserts card wait line CO_WAlT*, adapter 100 de-asserts eard write enable Une (~O_WE* (see CO_WRCMD*). P+1 clock eyeles later, card enable line CO_OE~
is de-asserted!
In this embo~lin~nt, adapter 100 also supports non-WAIT UO write accesses of PC eard 110 with byte sizing, as illustrated by the tirn ng diagram of Figure 13. A byte VO write aceess of PC
card 110 is similar to that of a byte write of attribute or eommon memory with the exception that a card VO write line CO_IOWR* (shown as CO_WRCMD* in Flgure 13) is asserted instead of card write enable line CO_WE*. Sirnilarly, a half VO write ac~c4sses of PC card 110 begin as in the 10 halfword wTite of attribute or comrnon memory with the exception that card VO write line CO_IOWR* (see CO_WRCMD*) is asserted instead of card write enable line CO_WE*.
As discussed above, PC card 110 is configured for VO type operations by loading the appropriate Card Information Structure (CIS) into optional Configuration Registers located at the base of the PCMCIA cornmon address space. The VO access protocol is similar to common rnemory access protocol exoept that card VO lines CO_IORD* (shown as CO_RDCMD* in Flgure 9) and CO_IOWR* (see Flgure 13) are used for h~ndsh~l~;ng instead of card enable lines CO_OE* and CO_WE*, respectively (shown as CO_RDCMD* and CO_WRCMD* in Fgures 9, 11, respectively).
Referring again to Figure 13, PC card 110 asserts card line IOIS16* low (not shown) to indicate that card 110 is also capable of executing a 16 bit wide WTitC. In ~yonse~ adapter 100 20 asserts card enable line CO_CE1$ low so that both bytes of data presented on card data lines CO_D
are written into PC card 110.
Conversdy,ifPCcard llOdoesnotassertlineIOIS16*(notshown)10wduringtheVOwrite access, i.e., PC card 110 is not capable of perforrning a 16 bit 1/0 write, only card enable line CO_CE 1 * is asserted low so that only the even byte presented on card data lines CO_D from system bus data lines SB_DATA is written into PC card 110. Adapter 100 then completes the halfwo~ VO
Signal is activc lo~v.
2 1 43't~
Page: 21 write cyele by exocuhng one more VO byte write to PC eard 110 as ~lescr bed above. This seeond byte VO write access differs fiom the first byte write in that card address line CO_A [0] is set to "1"
and the odd byte value from system bus data lines SBpATA is presented onto card data lines COp.
Adapter 100 also supports VO write aecess of PC card 1 10 with the WAIT feature. Referring back to Flgure 11, the s~u~nc~ of events for VO write access with the WAlT feature is similar to that for write access of attribute or co~on memory vith the WAIT feature, with the e~ception that card VO write enable line CO_IOWR* (shown as CO_WRCMD* in Flgure 11) is assened instead of card write enable line CO_WE* dunng an VO write access. If PC card 110 asserts but fails to de-assen card wait line CO_WAlT* within 20 microseeonds, the V0 write access is tc.,~inal~d and card 110 generates a status change interrupt (SCINT) to host computer 10 with PC card access time-out (PCTO) bits set in the Interface Status Register, indicating that a WAIT time-out has occurred.
Appendix B is a detailed data sheet for one embodiment of adapter 100 and is inco"~lat~l herein. Appendix C are verilog files of this embodiment and is also incorporated herein.
As discussed above, PCMCIA socket 107 can be configwed either to operate in attribute/comrnon mernory mode or VO m~de depending on the capability of PC card 110. When PCMCIA socket 107 and is configured for at~ibute/cornmon mernory mode, adapter 100 generates a card status change interrupt whenever adapter 100 detects any of the following events:
PC card access time-out PC card write protect status change PC card ready-busy~ status change PC card battery status change PC card is inserted or removed 'Signal is active low.
- 21~3492 Page: 22 Converscly, whcn PCMCL~ socket 107 is configured for U0 mode, adaptcr 100 generates a card StdtUS change interrup~ whenever adapter 100 detects thc following events:
PC card access time-out PC card is inserted or removcd PC card gen.,ldtc,s a StdtUS change interrupt The interrupts generated by adapter 100 provides a variety of functionc For exa~p", when PC card 110 is configured as an VO canl, PC card 110 gen.,ldles a status change int~ pl to host computer 10 by asserting a card status change line STSCHG~ (not shown) whcnever a change in card status is detected. Adapter 100 detects card status line STSCHC* and in turn generates an interrupt over system bus 55 to computer 10. Host computer 10 reads the Pin Replacernent Register on (VO type) PCcard 110 to determine thc source of the PC card status change interrupt. Each sourcc of the card status change interrupt is individually maskable by adapter 100 and is available on system bus interrupt request line SB_INT[0]. Subsequently, the card status change interrupt is cleared by host computer 10 by writing a "1" to the corresponding staNs change bit in the Interfacc Status Register 0.
As ~liccusse~ above, this cmbodiment also includes hardware which supports PC card hot-plugging. Referring back to Flgure 6, adapter 100 provides control signals to a powcr switch 105 for applying and removing one of two power sources Vcc, Vpp to and from PC car~l 110. Such an arrangement enables PC card 110 to be hot-plugged, i.c., safely connected to or di~nected from socket 107 of adapta 110, without powering down host CollJputel 10 by continuously monitoring the prcsence and absencc of PC card 110 with respect to PCMCIA sockct 107 in thc following manna.
WhenhostcomputerlOisfirstpoweredup,adapterlOOdoesnotprovidepowertoPCMCIA
socket 107. Instead, upon detecting the existence of PC card in socket 107 during the powa-up se~uence, or de~ec~ing a subsequent insertion of PC card 110 after the powerup sequence, a power 'Signal is active low.
214:~492 -Page: 23 switching circuit 105 beg;ns to provide power to PC eard 110 by turning on the app,op,iate power MOSFETs of switching circuit 105. Conversely, when adapt 100 is int~ ..u~,t~,d and informed of the removal of PC card 110, adapter 100 sends the appropriate signal via Card_0_Pwr_Cntl line which causes power switching circuit 105 to turn off the appropriate power MOSl~-l s, thereby removing power from PCMCLA socket 107.
In some embc~ eu~, PC card 110 is a mass storage or network device, and PROM 106 is configured to boot host compuler 100 using boot irnages stored ~n or ,et-ic~ed over a network connection by PC card 110. PROM 106 also contains a separate CIS inte.y~ r for identifying tuples which provide device identification and configuration information for PC cards, e.g., eard 1 10, dunng booting. The PROM resident CIS interpreter then builds a device information tree with at least one device information node for each PC card, e.g., PC card 110. In addition PROM 106 contains information defining the capabilities and system resouTces of adapter 100. For more inforrnation on auto-boot process, see U.S. patent applicadon, Serial No. 07/842,007, entitled "ME~HOD AND APPARATUS FOR BOOT~NG A COMPUTER SYSTEM", filed February 2S, 1992, inco,yo,"ted herein by reference in its entirety.
lnanotherembodiment,a5voltto 12voltDC-DCconverteT107providesthehighervoltage required by some PC cards for operation, thereby further increasing the versatility of adapta 100.
As such, after power is provided to card 110, adapter 100 reads the card information sll uctu,~ (CIS) located in the attribute mernory space of card 1 10, to obtain information about PC card 1 10, thereby ensuring that PC card 110 is of the type that adapta 100 is able to SuppO~L In yet another embodiment, a test port provides internal diagnostics for adapter 100.
The PCMCIA spe~fi~ ;on Version 2.1 does not supportdirect memory access (DMA) type operations, and hence data transfers between host computa 10 and PC card 110 are essentially prog, ~llmed VO type operations. However, should a later version of the PCMCIA specification support DMA, one skilled in the art will be able to add DMA capability to adapter 100 and make 2i4~492 Page: 24 the appropriate modLfications to software driver 34, enabling host computer 10 to inidate data transfers between host rnernory 30 and PC card 110 independent of host CPU 20 after an initial setup.
While the invention has been described using specific cmbof~ ts~ other cmb~ime~tc>
alternatives and moflific~tionc will be apparent to those skilled in the art without deviating from thc scope and spirit of the invention. For eY~rnp~e~ the PCMCIA interfaceof the present invention may be implemented in varying proportions of hardware and software. Hence~ the abovc descripdon is merely illustratdve and not intended to be limiting. The true scope of the invention is inrlic~t~d by the following claims.
Field of the InvPnhor~
This invention relates to an interface between a host computer and a peripheral devicc. Morc particularly, thc invention relates to an interface between the host c~,~putc,- and a Personal Computer Memory Card International Accoci~tion (PCMCIA) peripheral card.
nescript;~n Of The R~l~t~ Art Figure lA is a block diagram showing the haldware co.llponents of a conventional non x86 based host col~p~l~r, such as a scalable processor architecture (SPARC) host co~ ur~el . (SPARC~!D
is a registered trademark of SPARC International, Inc.) Host computer 10 includes a host central processor unit (CPU) 20, a memory bus ~M-bus) 35, a host memory 30, a host bus controller S0, a standardized host system bus 55 and input/output (UO) devices such as a monitor/keyboard/mouse 41 and a hard disk drive 42. System bus 55 interconnects and provides co~ nication between CPU
20 and VO devices 41, 42. In some host computers, system bus 55 is a SPARC based SBus.
Figure lB illustrates the software components of the host computer of Flgure lA. A UNIX
user application 31 is coupled to a UN~C operating system (O/S) 130 having a kernd 32 and hardware-dependent drivers 33, and system bus 55. (UN~C(!9 is a registered tradernarlc of UN~C
System Laboratones, Inc., a wholly-owned subsi~ y of Novell, Inc.) System bus 55 is coupled to UO devices 41,42. Typically, when host computer 10 is first initi~li7~. UN~ O/S 130 is loaded into host memory 30.and remains resident until co,.~put- r 10 is powered down. Consequently, VO
device drivers 33 co"~s~onding to VO devices 41,42 are loaded and user application 31 has acccss to VO devices 41,42 by making the appropriate calls to kernel 32 which C0~ `9~5 thc access via device drivers 33, system bus 55 to UO devices 41, 42.
The increase in the processing power of computers such as host computer 10 has caused a corresponding increase in the complexity of user applications such as application 31. As a resul~, there is an increasing need for additional memory, mass storage and co~".~ ic~tion devices, the most convenient form being an extemal device coupled to system bus 55. Typic~lly, adding cxtemal 21434~2 Page: 2 memory or mass-storage devices to host computer 10 involves the insertion of an adapter in the form of a printed circuit board (PCB) into an available system bus slot located inside the housing of COIl" uler 10. When inserted into the system bus slot, the PCB is electrically coupled ~o system bus 55 and the adapter is therefore capable of co.. ",~ g with host CPU 20. Hence, the ..l~ ulllll number of external devices that ean be coupled to host computer 10 is limited by the total number of system bus slots available within computer 10. Further, a typical non-technical user is not trained to insert or remove PCBs, and a trained te~hnici~n or service person is reiquired to make such an upgrade or change.
Meanwhile, in a different hardware arena of computers based on Intel's x86 farnily of 10 microprocessors, such as the IBM personal co---l,ulc., a PCMCLA specification was developed to promote both compatibility and interoperability for adding external devices. antel(~ is a le6;~te-~trademark of Intel Corporation and IBMt9 is a rcgistered tr~lem~* of International Business Machines Corporation.) Typically a PCMCIA adapter provides standardized PCMCIA socket(s) for plugging in PCMCIA cards (PC cards), and is controlled by associated interface software running on the host computer. Hence, it is now possible for an end user to easily insert and interchange a wide variety of external peripheral and memory devices implemented in the PC card format into an x86-based host computer on demand.
Initially, the x8~based PCMCIA interface was designed for relatively fast random access memory (RAM) cards and hence the specified read/write protocol between the adapter and the 20 x86-based host computer is sirnilar to that neccssd- ~ for a mery-type access operation. PC cards with memory include RAM PC cards and hard disk drive PC car~s. More reeently, the PCMCL~
specification was extended to acco~ te PC cards requiring UO type data access protocol, such as FAX modem cards.
Figure 2 is a block diagram showing both the software and hardware components of one such prior art x86-based host computer having a PCMCIA interface specifically designed for an x86-based comput~,l system bus, such as an ISA or VESA bus. The software component includes 21~3~9~
Page: 3 user application 141, Microsoft's disk operating system (DOS) 142 and an x8~bascd hardwarc-dependent PCMCIA soflw~e driver 143. (Microsoft~D is a registcred trademark of Microsoft Corporation.) The hardware component includes an x86-based system bus 145 and an x86-based PCMCIA adapter 146 having a pair of PCMCIA sockcts 147a, 147b for housing a corresponding pair of PC cards 110, 120. Two examplcs of prior art integratcd circuits (ICs) for the x86 bascd PCMCLA adapter are Intel's 82365SL PC card inte~ce controller and Cirrus Logic's CL-PD6710/20.
Uscr application 141 accesscs PC card 110 or 120 by first making a standardized system call to DOS 142. Next, DOS 142 makes the appropriate PCMCIA call to x86-based PCMCL~ software driver 143 in order to co~ u"icate the access across x86-based system bus 145 to PCMCIA adapter 146. Upon receiving the access request over bus 145, adapter 146 translates the system bus signals into standardized PCMCLA signals for PC card 110 or 120.
Onc problem associated with the conventional PCMCIA interfacc is that the PCMCIAspecification was originally devcloped for computcrs based on Intcl's x86 farnily of r~ucroprocessors running operating systems such as DOS, MS-~mdows or OS/2. (MS-Windows~D
is a trademark of Microsoft Corporation.) Consequently, the PCMCLA spccification was optimized for softwarc drivers which are coded in whole or part in an x86 assembler language which cannot be easily ported to non-x86-based computer systems.
Another problem with most conventional operating systems, such as UN~ and DOS, is that 20 they arc not designed to arbitrarily allow hardware deviccs to be connectcd and flisconnected a random while the host COlllp~t~- is operating. Traditionally, at systcm boot tirne cach device drivcr is polled once to determinc if the corresponding hardware dcvice is present. If the device has been disconnccted or is non-functional, the device driver is either unloaded from the host computer memory, or if left in the mcmory, thc drivcr is never used. This particular conYcntional operating system characteristic prevents PC cards from bcing safcly "hot-plugged", i.e., the practice of inscrting or removing PC cards from a PCMCLA socket while the host coLIJpulcr is operating.
2143~9~
-Page: 4 Hencc, there is a need for a portablc PCMCIA interface which fully supports the software and hardware PCMCLA specific~ion and is independent of the host computer's bus architecture, proccssor or operating syste~ Such a portablc PCMCIA interface will cnablc other host computers based on hardware a,ckitect~s such as SPARC, and operating systems such as UNIX, to utilize the growing bank of standaldized PC cards, while fully supporting the PCMCIA featu~es such as hot-plugging.
21~3492 Page: S
SUMMA~Y OF THF Ir~lVF~1TION
The present invention provides a portable PCMCLA interface operational on many host computer architectures to couple a user application to a PC card~
In one embodiment, the user application runs in a host computer having a host system bus.
The PCMCLA interface includes both software and h~d~e col-~ponents. The PCMCL~ interface software includes a hardware-independent portion and a h~dwd~e-dependent portion, with a defined extemal interface between the user application and the hardware-independent portion. The external PCMCLA sonw~ interface provides PCMC~A Csrd Services and Socket Services to the user application in a manner l-~nsy~nt to the underlying har~lw~e, e.g., the PC card. In addition, 10 there is a defined internal interface between the hardware-independent and haldw~e-depender.t portions of the PCMCL~ intcrface software, enabling the entire PCMCLA interface to be easily ported to other host computers by merely adapting the hardware-dependent portion.
The PCMCLA interface hardware includes a PCMCLA adapter coupled to the system bus, the adapter having at least one PCMC~A socket for acc~ od~ting the PC card. The user application initiates all data transfers to and from the PC card, as dictated by the PCMCL~
specification. The host system bus compatible PCMCLA adapter s.Jypol~s 8 bit, 16 bit and 32 bit data transfers to and from attribute memory space, common mcmory space and UO space of the PC
ca~.
In sorne embodiments, the addition of power switching circuitry between the system bus 20 power supply and PCMCLA socket(s) of the PCMCIA adapter enables the PC card(s) to be safely inserted in and removed f~m the PCMCLA socket(s) without the need for powering down the host computer. An optional S volt to 12 volt DC-DC converter provides additional compatibility for PC
cards requiring a 12 volt supply.
The PCMCLA inter~ace of the present invention has a number of advantages over the prior arL By providing a defined internal interface between the hardware-independent and hardware-dependent portions of the PCMCLA interface software, the specific characteristics of the 21~3~
Page: 6 system bus, the adapter and the PC eard be,come transparent to the user applieation soflwue running on the host co.upu~c,r. In addition, by implem~nting the software in a high level proglamrning language, the entire PCMCLA in~erface software can be ported to other host eomputers having different operating systems and ha~ ; architectures by merely adapting the hardware-dependent portion. Accordingly, the PCMCIA interface of the present invention provides a hardware and software solution which can be easily ported to other host co-upU~
Pagc: 7 I)F~CR~ION OF THF DRAW~GS
The objects, featurcs and advantages of the system of the present invention will be sppal~n from the following description in which:
Figure lA illustratcs the hardware co-l-ponellts of a convcntional SPARC host COlllputCr.
Figure lB illustrates the softwarc components of the host computer of Figure lA.Figure 2 illustrates a prior art x8~based host comruter having a PCMCIA interface.
Figure 3A illustrates a PCMCIA interface coupled to a host co,llpùle ( in accoldancc with one e.,lbo~ ent of the present invention.
Figure 3B illustrates the PCMCIA interface software running on the host Co~ Jut~r of Figure 3A.
Figure 4 is a block diagram showing the PCMCLA interface softwa,e in greater detail.
Figure 5 is a flow chart illustrating an access of a PC card by a user application running on the host co"lyuter.
Figure 6 illustrates a PCMCIA hardware adapter of the present invention.
Figure 7 is an address map showing the SBus address space of the host computer allocated to PC cards. - -Figure 8 are two timing diagrams illustrating conventional PCMCIA read and write access cycles.
Figure 9 illustrates a PC card read access of an attribute or common memory space.
Figure 10 illust~ates a PC card read access of an attribute or co~ on memory space with the WAIT feature.
Figure 11 illustrates a PC c~ write access of an attribute or common memory space.
Figure 12 illustrates a PC card write access of an attribute or common memory spacc with the WAlT featurc.
Figure 13 illustrates a PC card write access of an VO space with byte sizing, but without the WAlT featurc.
Page: 8 nF~CR~ION OF THF PRFFF,RRFI) FI~RODrl~FNT
In Figune 3A, a scalable p,ocessol architecture (SPARC) based host coll-p~te. eoupled to a PCMCIA adapter of the present invention is shown. For more information on the SPARC complJter architeet -re, see the SPARC Arehite~tllre Manual, Version 8, 1992, available from SPARC
International, Menlo Park, California As the operation of SPARC-based host computer 10 is well known, a detailed description is not provided herein.
In acco,~nce with one embodiment of the invention, host cOIl~pllle( 10 is coupled to a PCMCIA adapter 100 via system bus 55 Adapter 100 has a pair of PCMCIA sockets 107, 108 for housing a corresponding pairof PC cards 110, 120. PC cards 110, 120 are inserted into adapter 100 via a eorresponding pair of 68-pin connectors located within PCMCLA sockets 107, 108.
It should be noted that adapter 100 rnay assume a variety of physical configurations. For example, in one embodiment for a desktop computer, adapter 100 includes an application specifie integrated circuit (ASIC) mounted on a peripheral printed cireuit board (PCB), with the PCB
oecupying a physical slot in system bus 55. An eleetrical eable intereonnects the ASIC to PCMCLA
soekets 107, 108. In another embodiment for a palm-top computer, adapter 100 ineludes an ASIC
which resides, together with CPU 20 on a r~in PCB. An eleetrical cable interconneets the~ASIC
to PCMCIA soekets 107, 108 which are attached to the palm-top computer housing. Alternatively, PCMCLA sockets 107, 108 are mounted together with the ASIC and CPU 20 on the main PCB of the desktop or lap top eomputer, thereby eliminating the need for an interconneeting electrical eable.
20 Other embodiments and variations are also possible and will be apparent to one skilled in the art in view of this disclosure.
For the purpose of describing the operation of a PCMCIA interface software driver running on host eomputer 10 and controlling PCMCIA adapter 100, reference is rnade mainly to PC eard 1 10 and its associated hardware and software drivers. Sinee both PC Cards 110, 120 are electrieally and physieally eoupled to PCMCIA sockets 107, 108"~s~lively, the description of the opc-ation of 214~92 Page: 9 thc software drivcr and adapter 100 with respect to first PC card 110 is cqually applicable to sccond PC card 120.
In this emborliment, as illustrated by the block diagram of Flgure 3B, an UNIX OpCI~tL.g system 135 which includes UN~ kernel 32 ~nd device drivers 33, also includes a PCMCLA interfa~c software driver 34. A UN~ compa~ible user application 31 accesses PC card 110 via PCMCL~
interface software driver 34, system bus 55 and adapter 100. Sofltware driver 34 includes a hardware-inAfvpendent portion 34a and a ha.~l~ale-dep,nden~ portion 34b.
Interface software driver 34 is coded in a suitable high level progrq~nming language, such as the "C" language, enabling source code of driver 34 to be easily ported to other host co...yu~
10 plaffonns by merely making source code changes to hardware-dependent portion 34b and recompiling drivcr 34. Exarnples of other possible host com~ut~ . configurations include the UNIX
operating system on an x86 rnicloploc~ssor based C01l'Ulf,~ . Otller variations and mo~ific~tion~ of host computer platforms are apparent to one skilled in the art.
Figure 4 is a block diagram- showing PCMCLA interface software driver 34 in gr~ater dctail.
Hardware-independent portion 34a includes a pair of PC card drivers 260, 270, a PCMCL~ nexus driver 210, an event manager 230 and a Card Services layer 220. Hardware-dependent portion 34b comprises a system bus compatible PCMCIA adapter dliver 250 for controlling adapter 100. By clearly defining an internal interface 215 between hardware-independent nexus driver 210 and hardware-dependent system bus compatible adapter driver 250, in accordance with one aspect of 20 the invention, the entirc PCMCIA interface can advantageously be portcd to different host co_, platforrns by merely adapting hardware-dependent portion 34b of interface soflw~e driver 34.
Before user application 31 can begin aessing PC card 110, PCMC~A interface software driver 34 must first be loaded into host memory 30. Loading of the various portions of software driver 34 is accomplished during initialization of host computer 10. When PCMCIA nexus dnver 210 is first loaded, nexus driver 210 searches through a list of aD possible adapter drivers stored in a configuration file, and attempts to load each adapter driver into the configuration file. For each 2143~92 -Page: 10 ~.,ccessful load of a specifie adapter driver, e.g., adapter driver 250, nexus driver 210 loeates a co,l~t,sponding driver app~t~s strueture, e.g. structure 251, associated with eaeh adapter, e.g., adapter driver 250. Adapter driver 250 then saves a pointer to the corresponding driver apparatus structure 251.
Next, PCMCLA nexus driver 210 queries PCMCIA adapter driver 250 to obtain its basie adapter char~cterisdcs and adds PCMCLA sockets 107, 108 to the list of available logical soekets.
Nexus driver 210 then exports the logical socket list to Card Services layer220. Consequently, Card Services layer 220 has access to a hardware-independe-nt Son~e interfaee 215 located between nexus driver 210 and adapter driver 250, enabling Card Services layer 220 to cont~1 and manage the resources of adapter 100 and PCMCLA socket 107 in a har~w~re-independent rnanner. Nexus driver 210 also exports the same logical socket list to adapter driver 250 thereby establishing a one-to-one logical socket communi~a~;on channel betwe~en Card Services layer 220 and adapter driver 250.
Card Services layer 220 also includes a Card Information Structure (CIS) interpreter 220a which enables PC card 110 to be self identifying independent of the host computer architecture and operating system, by requiring PC card 110 to maintain self-indentifying inforrnation in its-CIS.
The CIS is stored in an Attribute Memory space of PC card 110 and is made up of a singly-linked list of variable-length elements called tuples. Interpreter 220a is a tuple parser which is responsible for processing all of the tuple information. As such, PC card driver 260 does not need any tuple 20 parsing code.
In this embodiment, each tuple is one byte in Iength, with up to 256 distinct tuples stored in the CIS of PC card 110. ~hen a tuple is parsed and recognized by intc.~ tc. 220a, interpreter 220a causes the tuple data from PC card 110 to be copied into a tuple entry in an interpr~ter linked list 220b. Conversely, when interpreter 220a does not recognize the tuple, a flag is set in-lie~ting that the tuple was not recognized and that tuple data from PC card 110 should not be copied into a tuple entry in interpreter linked list 220b. Upon the successful parsing of the CIS of PC card 110, linked 2~3~9~
Pagc: 11 list 220b contains the configuration pa- ~l~cte~ of PC card 110, e.g., type of PC card, memory capacity and access speed. Subsequently, Card Services layer 220 uses linked list 220b for processing card service requests from PC card driver 260.
In some embodi- Je.-b, PCMCIA nexus driver 210 does not export its private interface 215 with adapter driver 250 to PC card driver 260. Interface 225 between Card Services layer 220 and PCMCIA nexus driver 210 is also private, e.g., PC card driver 260 does not make direct calls to PCMCLA nexus driver 210. Instead, whenever user application 31 accesses PC card 110, all calls to PC card driver 260 destined for PCMCIA nexus driver 210 are serviced through Card Services layer 220. As such, Card Services layer 220 provides PC card driver 260 a single entry point with 10 a variable ar~ ~m~ei.t list based on the function requested.
Next, in order to support a PCMCLA specified event callback feature, event manager 230 is loaded as a separate STREAMS, enabling nexus driver 210 to communicate PCMCIA events, sueh as PC card insertiontremoval (hot-plugging), to user application 31. (A STREAMS is a UN~C
full-duplex connection between a process and a device driver). Hence, nexus driver 210 is provided anefficienteventcallbackme~h~nismtouserapplication3l~witheventmanager23oobservingthe evenlsand managingbothadapter 100and PCcard llOviaadapterdriver250. Eventmanager230 is an efficient solution because the number of PC cards available make it unwieldy and inefficient for user application 31 to poll for every possible PCMCIA card~ More irnportantly, event manager 230 typically provi~es the sole me~h~nism (generally ~suppo~ied by UNIX) forimplementing the 20 PCMCL~ specified charmel for unsolicited feedback to user application 31.
For eY~ple~ when PC card 110 has been successfully inserted into PCMCIA socket 107, nexus driver 210 receives a "card insertion" event notification from adapter driver 250, enabling nexus driver 210 to koep ~ack of which type of PC card is present in socket la7. Subsequently, a corlesponding PC card driver, e.g., driver 260, is loaded and nexus driver 210 updates the corresponding driver apparatus structure, e.g., structure 251, thereby forming an association between PCMCIA socket 107 and PC card 110. A discussion of the PCMCIA interface hardware ., Page: 12 for supporting this event callbaek feature is ineluded in a detailed hardware description of adapter 100 below.
Onee the loading and ini~i~li7~tion of PCMCIA interfaee software driver 34 are eompleted, user applieation 31 has aceess to adapter 100 and PC eard 110. Figure 5 is a flow ehart illustrating an aecess of PC eard 110 by user application 31 running on host co~upuler 10 in acco~ance with one embodiment of the invention.
First, user applieation 31 makes an extemal hald~e-independent PCMCIA call to PC eard driver 260. Card driver 260 responds by requesting an appropriate eard service from Card Services 220. Card Services 220 is responsible for proeessing all eard services requests from PC eard driver 260 and making the app,op.iate calls into PCMCIA nexus dnver 210. PC card driver 200 provides Card Serviees 220 with a pointer to PC card driver's device inforrnation pointer (DIP) thereby uniquely identifying PC eard 110 and providing a path to PC card driver 260's parent proeess, i.e., nexus driver 210. Card Services layer 220 then uses the DIP to locate and to make the app,op,iate ealls into nexus driver 210. Such calls include adapter hardware configuration requests destined for socket services provided by adapter driver 250.
In,~ s~onsetotheappropriatecallsfromCardServiceslayer220,nexusdriver210generateseorresponding internal hardware-independent software calls to PCMCIA adapter driver 250. (For additional information on PC Card Serviees, please refer to Appendi~ A, whieh is ineorporated herein.) Hardware-dependent adapter driver 250 then converts the internal sofhvare ealls into appropriate system bus signals for adapter 100. Adapter 100 in turn gene,~tes the appropriate PCMCLA card signals for PC eard 110 located in PCMCIA socket 107.
In sum, user applieation 31 initiates data aceesses vith PC eard 110 by co~ icatillg the re~uest in the form of a ha, iwa~e-independent external PCMCIA call to PCMCIA interfaee software d-iver 34. In turn software driver 34, resident on host memory 30, receives the external PCMCIA
eall and causes the appropriate-dependent adapter specifie signals to be assened on system bus 55.
Hence, having described the operation and services provided by the various portions of interfaee 21~3~92 -Page: 13 software dnver 34 in converting an aeeess request from user application 31 into the appropriate system bus signals, the operation of the PCMCIA interface har~ c, i.e., adapter 100 and PC eard 110 is now deser~bed in detail.
In one embodirnent as illustrated by F~gure 6, PCMCL~ adapter 100 ineludes an applieation specificlC(ASI(~)lOOahavingahostbusinterfaccbufferlOl,anadaptercorelogiclO2,andacard interfaee buffer 103. Adapter 100 also ineludes a power switeh 10S, a PROM 106, and a pair of PCMCIAsoeketslOî,108. PROM106isanopenbootPROM(OBP)whiehprovidesstandardboot ROM funetionality for host compu~er 10.
Figure 7 is an address map showing three megabytes of the system bus address spaee in host memory30alloeatedtoeachofPCcards 110,120,i.e.,asL~tmegabytesofaddressspaceisdedicated to PC cards 110, 120.
In this embodiment, address spaee 0 to ~ h and 3~ -h to 4~ h of rnemory 30, are reserved for aecessing PROM 106, and the content of control and status registers (CSRs) 102a, respectively. The PCMCIA specifeation also supports up to 64 megabytes each for attribute memory, common memory and VO memory space. However, in the described embodiment of PC
card 110 only one megabyte of system bus address space each is reserved for attribute m~mory, common memory and I/O address spaee. As such, address mapping is required for transposing the system bus address space within specified PCMCLA address space. The address map for the 8 megabyte address.space of adapter 100 is stored in PROM 106.
CSRs 1 02a are used to store p~ ~ete. ~ for eonfiguring adapter 100 to operate with various type of PC eards. In addition, CSRs 102a also eontain the address offset tables necess~y for mapping each of the one megabyte system bus address spaces within each of the 64 megabyte PC
card address space. These address offset table values can be modificd by host computer 10 to suit a particular PC eard, e.g., a FAX modem eard~ a RAM memory car~, or a Winchester disk d rive card.
Configuradon pararneters stored in CSRs 102a include the data access speed of PC eard 110 which 21~3~92 .
Page: 14 can vary a great deal depending on the card function, ranging from a relatively slow modem card to a relatively fast RAM card Figure 8 shows two basic timing diagrarns illustrating conventional PCMCIA read and writc access cycles on system bus 55 in response to read and write ae~sses of PC card 110 by user application 31. Note that data transfers are inidated by user application 31 as defined by the PCMCL~ specification Version 2.1. For example, in response to a read access of PC card 110, adapter 100 asserts card address lines ADDR and card enable line CE* of PC~CLA socket 107.
Adapter 100 then asserts the output enable signal OE*, intlic~ting a read access of PC card 110 at the location indicated by card address lines ADDR. After a specific period of time (i.c., PC card 10 read access time), PC card 110 drives the requested data onto card data lines DATA. Similarly, in response to a write access of PC card 110, adapter 100 asserts card data lines DATA, card address lines ADDR and card enablc line CE*, followed by the assertion of card writc enable linc WE.
In accordance with one embodiment of the invention, adapter 100 supports byte, halfword (16-bit)andword(32-bit)dataaccessesofPCcard 110. SincePCMCIAsocket 107canonlysupport 16-bit data transfers, any sizing is performed external to PC card 110. Although thc described embodiment of adapter 100 does not perform any data packing ~I.e., adapter 100 does not generate multiple read accesses to card 110 in response to a single system bus read request), one sl~lled in the art will be able to extend the principles of operation to othcr embodiments of adapta 100 that supports data accesses of word lengths greater than l~bits without the need for external sizing by 20 host computer 10.
In addition, when an access is initiated at an attribute memory space or at an VO addrcss spacc of card 110, card mernory select line C0_REG* is asserted low. Conversely, when an access is initiated at a common memory space, card memory select line C0_REG* is assated high.
Referring to the timing diagrarn of Figurc 9, a byte widc read initiated by computer 10 via adapter 100 of an attribute or common memory space on PC card 110 is illustrated. First, a base 'Signal is acbve low.
2i.~3 192 -Pagc: lS
address value BASE stored in a eorresponding Window Control Register of control and status register 102a and the offset address value on system bus address lines SB_PA are presented on eard - address lines C0_A thereby mapping the system bus address into a PC card address. Next, a eard output enable line C0_CE* is asserted low. L+1 elock cycles later, L being the Command_StrobePelay value ChlDDLY stored in the Window Control Register, a eard output enable line C0_OE* (shown as C0_RDCMD* in Figure 9) is asserted low. The selected PC eard, i.e., PC card 110, then retrieves the requested memory data byte intemally and presents the data value onto card data lines C0p.
After another M+l clock cycles, where M is a Command_Strobe_Length value CMDLNG
10 stored in the Window Control Register, the data byte value on card data lines C0_D is latched by adapter 100 and card output enable line C0_RDCMD* is de-asserte~ One clock later, eard output enable line C0_CE* is de-asserted. Fmally, adapter 100 asserts a byte "ACK" on system bus line SB_ACK* for host computer 10, driving the latched data byte onto system bus data lines SB_DATA
another clock cycle later, thereby completing the byte wide read cycle.
A halfword wide attribute or corrlmon rnemory read of PC card 110 is as follows. Flrst, the BASE value u the Window Control Register is applied onto card address lines C0_A, the~offset address value on system bus address lines SB_PA is applied onto card address lines C0_A, and card enable line C0_OE* is asserted low. L+ 1 clock cycles later, card output enable line C0_OE*( shown as C0_RDCMD* in Figure 9) is asserted low. Selected PC card 110 then presents the col,es~nding 20 memory data bytes onto card data lines C0_D. Aher M+1 clock cycles, the valid data b~tes on card data lines C0p are latched into adapter 100 and card enable line C0_OE* (see C0_RDCMD*) is then de-asserted. One clock cycle later, card enable line C0_CE* is de-asserted. Adapter 100 asserts a halfword ACK onto system bus line SB_ACK* and dri~es the latched data byte-swapped onto system bus data line5 SB_DATA, thereby completing the halfword read cycle.
Signal is aclivc low.
Page: 16 A word wide attribute or co~ )on memory read of PC card 110 is sirnilar to the halfword read access up to and includine the asserdon of the halfword ACK back to host computer 10. The halfword ACK on system bus 55 informs host co,nputcr 10 that the word read requires sizing. As such, computer 10 must inidate another access via system bus 55 to read the other halfword of the desired word of data. The second read cycle of the second halfword occurs in the same manner with the eYception that the value on system bus address line SB_PA [1] and also card address line CO_A
[I] are now both "1" instead of "O", so that the appropriate next halfword of data is fetched.
Asdiccuccedearlier,thePCMCIAspecificationwasoriginaUydevelopedforcxternalRAM
memory cards. However, as other slower storage m~Aill~nc, e.g., hard disk drives, were physically 10 shrunk to fit the PCMCIA forrn factors, it became neccss~ y to enhance the PCMCIA spe~ifica~ioll to support another mode of operation, i.e., aCcessing PC card 110 using a "WAlT' feature. In this embodiment,theWAlTfeatureenablesadapterlOOtoallowaslowPCcardlOOtodelayrespondingto an access by assert a card wait signal CO_WAlT$, as iUustrated by Flgure 10.
When host computer 10 initiates a read access to PC card 110 which utilizes card wait line CO_WAIT*, (a wait_re~uest bit WA~lTREQ is enabled in the Window Control Register), the BASE
value and the offset address value on system bus address lines SB_PA are is applied ont~ card address lines CO_A, and card enable line CO_OE* is asserted low. L + 1 elock cycles later, card output enable line CO_OE* (shown as CO_RDCMD* in Figure 10) is asserted low.
M + N + 2 clock cycles later, N equal to a Wait_Delay value WAlTDLY in the Window 20 Control Register, adapter 100 samples card wait line CO_WAIT$. lf card wait line Cr)_WAlT$ is asserted PC card 110 ~quires a delay in the completion of the memory access. The PC~MCIA
specification permits card wait line C~_WAll * to be asserted for a n~Yimllm of 12 _ iCI~J~Con~l5 Since the rising edge of card wait line CO_WAlT* is asynchronous with respeet a system clock of host computer 10, when PC card 110 d~-asserts card wait line CO_WAlT~, adapter 100 has to synchronize incoming card wait line C~)_WAll-$.
'Signal is active low.
Page: 17 Next, PC eard 110 asserts the requested memory data bytes onto eard data lines C0_D before de-asserting eard wait line C0_WAll'*. Adapter 100 latehes the data and de-asserts eard output enable line C0_OE* (see C0_RDCMD* of Flgure 10). One eloek cyele later, eard enable line C0_CE* is de-asserted. Finally, adapter 100 asserts an "ACK" on system bus line SB_ACK~ and a clock eycle later, presents the latched data onto system bus data lines SB_DATA.
A non-wait byte UO read access of PC card 110 is similar to that of the byte read of an attribute or common memory deseribed above with the exception that a card VO ready line C0_IORD* (shown as C0_RDCMD* in Figure 10) is asserted low instead of card output enable line C0_OE*. Similarly, a halfword VO read access begins as in the halfword read of attribute or 10 com~Don rnemory with the exception that card line C0_IORD* (see C0_RDCMD*) is used instead of card enable line C0_OE*.
If PC card 110 is capable of performing a 16-bit VO access, card 110 asserts a cand VO_is_16_bit line IOIS16 (not shown) low during the read access, and both bytes of data are presented onto card data lines C0_D, i.e., all 16 data bit lines are valid. Adapter 100 then gene,~tcs a halfword ACK to host computer 10 via system bus line SB_ACK* and presents the latched data byte-swapped onto system bus data lines SB_DATA a clock cycle later. - -Conversely, if PC card 110 is only capable of byte sized VO read access, card 110 does notassert card line IOIS16* low during the read ae~ss, and only the data byte presented on thc responding 8 bits of card data lines C0P are valid Next, adapter 100 asserts a byte ACK to host 20 computer 10 via system bus line SB_ACK$ thereby in-liea~ing that the halfword VO access requircs sizing. Host co~ uter 10 then initiates another VO access on system bus 55 to read the second byte in order to complete the halfword VO access.
An VO read of PC card 110 with the WAIT feature is also similar to the read aceess of an attribute or co,.",.on memory with the WAIT feature, with the eYception that card VO ready line C0_IORD* (shown as C0_RDCMD~ in Fgure 10) is asserted low instead of card line C0_OE~.
Signal is actiYe Ic~v.
2l43~92 Page: 18 The PCMCIA spe~ifil~ation permits a m~Yimum of 12 mic,osceon-ls delay between the bcg,~n: ~g and end of a r~ad access. However, PC eard 110 ean delay completion of the read aeeess beyond the 12 rrUcrosecQnrlc by using eard line C0_WAlT~, requiring adapter 100 to support split rea~ls on system bus 55. Once a read is initiate~d by host computer 10 on system bus 5S, a rerun ACK is asserted by adapter 100 if a time out oeeurs while eard wait line C0_WAlT~ is asserted by PC eard 110. The split read aceess is eompleted during a subsequent read retry by host eomputer 10 on system bus SS. Next, PC eard 110 de-asserts eard wait line C0_WAIT~ with the read data is presented system bus data lines SB_DATA.
Conversely, if PC eard 110 asserts but fails to de-assert eard wait line C0_WAIT* within the 20 mieroseconds du~ing a read aeeess eycle, adapter 100 terrninates the read aceess eycle and generates an interrupt on system bus 5S. The interrupt signals to host computer 10 that 8 WAIT
time-out has oeeurred.
In aecoldance with this embodiment of the invention, adapter 100 also supports non-WAlT
byte, halfword and word data write accesses on PC card 110, as illustrated in the timing diagram of Figure 11. Adapter 100 has a l~bit wide data interface with system bus 55 and with extemal siziDg perforrned by host computer 10 for word-size vrite accesses using halfword ACKs. As ~liscu~sed above when computer 10 initiates a write access at an attribute or common mernory or VO address space, eard select line C0_RE~ is asserted low.
When a byte write of PC card 1 10 at~ibute or common memory is initiated by cou~u~f 10, 20 the BASE address value and the offset address value from system bus address lines SB_PA are presented onto card address lines C0_A, the data value on system bus data lines SB_DATA is drivco onto card data lines C0_D, and card output enab1e line C0_CE* is asserted low. Next, adapter 100 asserts a byte ACK thereby terrninating the write cycle OD system bus 55. L+1 elock cyclcs lateI, card write enable line C0_WE~ (shown as C0_WRCMD~ in Figure 11) is asserted low. After M~1 Signal is activc lo~.
~t l3,~92 -Page: 19 clock cycles, card writc enable line CO_WE* is de-asscrted low. P+1 clock cycles later, P e~gual to Recovery_delay value RECDLY, card output enable line CO_CE* is dc-asserted.
When a halfword (l~bits) wide write of attribute or common mernory is initi~q~, the value of the BAS~ address value and the offset address value on system bus address lines SB_PA are presented on card address lines CO_A, the data value on system bus data lines SB_DATA is byte-swapped before being presented onto card data lines CO_D, and card enable line CO_CE* is asserted low. Next, adapter 100 asserts a halfword ACK on system bus line SB_ACK*, thereby terrninating the write cycle on system bus S5. L+ 1 clock cycles later, card write enable line CO_WE*
(shown as CO_WRCMD* in hgure 11) is asserted low. After M+1 clocl~ cycles card, write enable 10 lineCO_WE*isde-asserted. Finally,P+lclockcycleslater,cardenablelineCO_CE*isde-asserted.
The sequence of events required for initiating a word sized writc of Attribute/Memory is sirnilar to that of a halfword write of PC card 110. The difference being that adapter 100 asserts a halfword ACK terrninating the system bus w~ite cycle, thereby inforrning host co~ ter 10 that sizing is required to complete the word-size write access. Cornputer 10 responds by initiating a write of the second halfword of data over system bus 55.
Referring to the timing diagrarn of Figure 12, adapter 100 also supports data write acc~sses to attribute or cornmon memory of PC card 110 using the WAlT featur When a write access is initiated at PC card 110 which utilize card wait line C~_WAlT*, the BASE address value and the offset address value on system bus lines SB_PA are presented on card address lines CO_A, the data 20 value on system bus data lines SB_DATA is driven onto card data lines CO_D, and card enablc signal CO_CE* is asserted low. Adapter 100 then sends an appropriate ACK, ic., byte ACK for byte write and halfword ACK for halfword or word write, thereby te~Tnin~ng the system bus vrite cycle.
L+1 clock cycles later, card enable line CO_WE~ (shown as CO_WRCMD* in Flgure 12) is asserted low. M+N+2 clock cycles later, card wait line CO_WAlT* is sampled. If card wait line CO_WAIT* is equal to "0", card 110 is requesting a delay in the completion of the memory access.
Signal is activc low.
214349~
Page: 20 As di~ ~d earU, the PCMCIA specification perrnits a ...~in~:.n wait penod of 12miclosecon-lc When PC card 110 de-asserts card wait line CO_WAlT*, adapter 100 de-asserts eard write enable Une (~O_WE* (see CO_WRCMD*). P+1 clock eyeles later, card enable line CO_OE~
is de-asserted!
In this embo~lin~nt, adapter 100 also supports non-WAIT UO write accesses of PC eard 110 with byte sizing, as illustrated by the tirn ng diagram of Figure 13. A byte VO write aceess of PC
card 110 is similar to that of a byte write of attribute or eommon memory with the exception that a card VO write line CO_IOWR* (shown as CO_WRCMD* in Flgure 13) is asserted instead of card write enable line CO_WE*. Sirnilarly, a half VO write ac~c4sses of PC card 110 begin as in the 10 halfword wTite of attribute or comrnon memory with the exception that card VO write line CO_IOWR* (see CO_WRCMD*) is asserted instead of card write enable line CO_WE*.
As discussed above, PC card 110 is configured for VO type operations by loading the appropriate Card Information Structure (CIS) into optional Configuration Registers located at the base of the PCMCIA cornmon address space. The VO access protocol is similar to common rnemory access protocol exoept that card VO lines CO_IORD* (shown as CO_RDCMD* in Flgure 9) and CO_IOWR* (see Flgure 13) are used for h~ndsh~l~;ng instead of card enable lines CO_OE* and CO_WE*, respectively (shown as CO_RDCMD* and CO_WRCMD* in Fgures 9, 11, respectively).
Referring again to Figure 13, PC card 110 asserts card line IOIS16* low (not shown) to indicate that card 110 is also capable of executing a 16 bit wide WTitC. In ~yonse~ adapter 100 20 asserts card enable line CO_CE1$ low so that both bytes of data presented on card data lines CO_D
are written into PC card 110.
Conversdy,ifPCcard llOdoesnotassertlineIOIS16*(notshown)10wduringtheVOwrite access, i.e., PC card 110 is not capable of perforrning a 16 bit 1/0 write, only card enable line CO_CE 1 * is asserted low so that only the even byte presented on card data lines CO_D from system bus data lines SB_DATA is written into PC card 110. Adapter 100 then completes the halfwo~ VO
Signal is activc lo~v.
2 1 43't~
Page: 21 write cyele by exocuhng one more VO byte write to PC eard 110 as ~lescr bed above. This seeond byte VO write access differs fiom the first byte write in that card address line CO_A [0] is set to "1"
and the odd byte value from system bus data lines SBpATA is presented onto card data lines COp.
Adapter 100 also supports VO write aecess of PC card 1 10 with the WAIT feature. Referring back to Flgure 11, the s~u~nc~ of events for VO write access with the WAlT feature is similar to that for write access of attribute or co~on memory vith the WAIT feature, with the e~ception that card VO write enable line CO_IOWR* (shown as CO_WRCMD* in Flgure 11) is assened instead of card write enable line CO_WE* dunng an VO write access. If PC card 110 asserts but fails to de-assen card wait line CO_WAlT* within 20 microseeonds, the V0 write access is tc.,~inal~d and card 110 generates a status change interrupt (SCINT) to host computer 10 with PC card access time-out (PCTO) bits set in the Interface Status Register, indicating that a WAIT time-out has occurred.
Appendix B is a detailed data sheet for one embodiment of adapter 100 and is inco"~lat~l herein. Appendix C are verilog files of this embodiment and is also incorporated herein.
As discussed above, PCMCIA socket 107 can be configwed either to operate in attribute/comrnon mernory mode or VO m~de depending on the capability of PC card 110. When PCMCIA socket 107 and is configured for at~ibute/cornmon mernory mode, adapter 100 generates a card status change interrupt whenever adapter 100 detects any of the following events:
PC card access time-out PC card write protect status change PC card ready-busy~ status change PC card battery status change PC card is inserted or removed 'Signal is active low.
- 21~3492 Page: 22 Converscly, whcn PCMCL~ socket 107 is configured for U0 mode, adaptcr 100 generates a card StdtUS change interrup~ whenever adapter 100 detects thc following events:
PC card access time-out PC card is inserted or removcd PC card gen.,ldtc,s a StdtUS change interrupt The interrupts generated by adapter 100 provides a variety of functionc For exa~p", when PC card 110 is configured as an VO canl, PC card 110 gen.,ldles a status change int~ pl to host computer 10 by asserting a card status change line STSCHG~ (not shown) whcnever a change in card status is detected. Adapter 100 detects card status line STSCHC* and in turn generates an interrupt over system bus 55 to computer 10. Host computer 10 reads the Pin Replacernent Register on (VO type) PCcard 110 to determine thc source of the PC card status change interrupt. Each sourcc of the card status change interrupt is individually maskable by adapter 100 and is available on system bus interrupt request line SB_INT[0]. Subsequently, the card status change interrupt is cleared by host computer 10 by writing a "1" to the corresponding staNs change bit in the Interfacc Status Register 0.
As ~liccusse~ above, this cmbodiment also includes hardware which supports PC card hot-plugging. Referring back to Flgure 6, adapter 100 provides control signals to a powcr switch 105 for applying and removing one of two power sources Vcc, Vpp to and from PC car~l 110. Such an arrangement enables PC card 110 to be hot-plugged, i.c., safely connected to or di~nected from socket 107 of adapta 110, without powering down host CollJputel 10 by continuously monitoring the prcsence and absencc of PC card 110 with respect to PCMCIA sockct 107 in thc following manna.
WhenhostcomputerlOisfirstpoweredup,adapterlOOdoesnotprovidepowertoPCMCIA
socket 107. Instead, upon detecting the existence of PC card in socket 107 during the powa-up se~uence, or de~ec~ing a subsequent insertion of PC card 110 after the powerup sequence, a power 'Signal is active low.
214:~492 -Page: 23 switching circuit 105 beg;ns to provide power to PC eard 110 by turning on the app,op,iate power MOSFETs of switching circuit 105. Conversely, when adapt 100 is int~ ..u~,t~,d and informed of the removal of PC card 110, adapter 100 sends the appropriate signal via Card_0_Pwr_Cntl line which causes power switching circuit 105 to turn off the appropriate power MOSl~-l s, thereby removing power from PCMCLA socket 107.
In some embc~ eu~, PC card 110 is a mass storage or network device, and PROM 106 is configured to boot host compuler 100 using boot irnages stored ~n or ,et-ic~ed over a network connection by PC card 110. PROM 106 also contains a separate CIS inte.y~ r for identifying tuples which provide device identification and configuration information for PC cards, e.g., eard 1 10, dunng booting. The PROM resident CIS interpreter then builds a device information tree with at least one device information node for each PC card, e.g., PC card 110. In addition PROM 106 contains information defining the capabilities and system resouTces of adapter 100. For more inforrnation on auto-boot process, see U.S. patent applicadon, Serial No. 07/842,007, entitled "ME~HOD AND APPARATUS FOR BOOT~NG A COMPUTER SYSTEM", filed February 2S, 1992, inco,yo,"ted herein by reference in its entirety.
lnanotherembodiment,a5voltto 12voltDC-DCconverteT107providesthehighervoltage required by some PC cards for operation, thereby further increasing the versatility of adapta 100.
As such, after power is provided to card 110, adapter 100 reads the card information sll uctu,~ (CIS) located in the attribute mernory space of card 1 10, to obtain information about PC card 1 10, thereby ensuring that PC card 110 is of the type that adapta 100 is able to SuppO~L In yet another embodiment, a test port provides internal diagnostics for adapter 100.
The PCMCIA spe~fi~ ;on Version 2.1 does not supportdirect memory access (DMA) type operations, and hence data transfers between host computa 10 and PC card 110 are essentially prog, ~llmed VO type operations. However, should a later version of the PCMCIA specification support DMA, one skilled in the art will be able to add DMA capability to adapter 100 and make 2i4~492 Page: 24 the appropriate modLfications to software driver 34, enabling host computer 10 to inidate data transfers between host rnernory 30 and PC card 110 independent of host CPU 20 after an initial setup.
While the invention has been described using specific cmbof~ ts~ other cmb~ime~tc>
alternatives and moflific~tionc will be apparent to those skilled in the art without deviating from thc scope and spirit of the invention. For eY~rnp~e~ the PCMCIA interfaceof the present invention may be implemented in varying proportions of hardware and software. Hence~ the abovc descripdon is merely illustratdve and not intended to be limiting. The true scope of the invention is inrlic~t~d by the following claims.
Claims (18)
1. A PCMCIA interface for providing communications between a user application running on a host computer and a PC card, said interface comprising:
a hardware-independent nexus for processing an external PCMCIA access request from said user application and generating a corresponding internal PCMCIA access request;
a hardware-dependent driver coupled to said hardware-independent nexus for processing said internal PCMCIA access request and for causing a corresponding system bus signal to be generated on said system bus; and a PCMCIA adapter coupled between said system bus and said PC card for convertingsaid system bus signal into a PC card signal for said PC card.
a hardware-independent nexus for processing an external PCMCIA access request from said user application and generating a corresponding internal PCMCIA access request;
a hardware-dependent driver coupled to said hardware-independent nexus for processing said internal PCMCIA access request and for causing a corresponding system bus signal to be generated on said system bus; and a PCMCIA adapter coupled between said system bus and said PC card for convertingsaid system bus signal into a PC card signal for said PC card.
2. The PCMCIA interface of claim 1 wherein said external PCMCIA access request is a PCMCIA card service request and said hardware-independent nexus includes a Card Services provider for processing said PCMCIA card service request.
3. The PCMCIA interface of claim 2 wherein said hardware-independent nexus further includes a PCMCIA nexus driver coupled to said Card Services provider for converting said card service request into said internal PCMCIA access request for said hardware-dependent driver.
4. The PCMCIA interface of claim 3 wherein said hardware-independent nexus further includes an events manager coupled to said PCMCIA nexus driver for providing a communication channel between said PC card and said user application enabling said PC card to generate an unsolicited event report to said user application.
Page: 26
Page: 26
5. The PCMCIA interface of claim 1 wherein said hardware-dependent driver includes an adapter driver for converting said internal PCMCIA access request into a system bus signal for said PC card.
6. The PCMCIA interface of claim 2 wherein said Card Services provider includes an interpreter for parsing an information tuple from said PC card.
7. The PCMCIA interface of claim 1 wherein said host computer is a SPARC based computer system.
8. The PCMCIA interface of claim 1 wherein said system bus is a SPARC based SBus.
9. The PCMCIA interface of claim 1 wherein said host computer is a UNIX based computer system.
10. A method of providing communications between a user application running on a host computer and a PC card coupled to a system bus of said host computer, said method comprising the computer implemented steps of:
processing said external PCMCIA access request;
generating an internal PCMCIA access request in response to said external PCMCIAaccess request;
processing said internal PCMCIA access request;
generating a system bus signal on said system bus in response to said internal PCMCIA access request; and converting said system bus signal into a PC card signal in response to said system bus signal.
Page: 27
processing said external PCMCIA access request;
generating an internal PCMCIA access request in response to said external PCMCIAaccess request;
processing said internal PCMCIA access request;
generating a system bus signal on said system bus in response to said internal PCMCIA access request; and converting said system bus signal into a PC card signal in response to said system bus signal.
Page: 27
11. The method of claim 10 wherein the step of processing said external access request includes the step of providing PCMCIA card services.
12. The method of claim 10 further comprising the computer implemented step of providing a communication channel for said PC card to generate an unsolicited event report to said user application.
13. The method of claim 10 further comprising the computer implemented step of parsing an information tuple from said PC card.
14. The method of claim 10 wherein the step of converting said system bus signalincludes the step of converting an SBus signal.
15. A PCMCIA adapter for interfacing between an SBus of a host computer and a PCcard, comprising:
a PCMCIA socket for accommodating said PC card;
a buffer for storing information to be transferred between said SBus and said PCMCIA card; and a core logic for controlling a transfer of said information.
a PCMCIA socket for accommodating said PC card;
a buffer for storing information to be transferred between said SBus and said PCMCIA card; and a core logic for controlling a transfer of said information.
16. The PCMCIA adapter of claim 15 further comprising a switch for applying and removing power between said SBus and said PCMCIA socket.
17. The PCMCIA adapter of claim 15 further comprising a DC-DC voltage supply coupled to said PCMCIA socket.
Page: 28
Page: 28
18. The PCMCIA adapter of claim 15 further comprising a boot PROM for booting said host computer with a boot image retrieved from said PC card.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/213,752 US5519851A (en) | 1994-03-14 | 1994-03-14 | Portable PCMCIA interface for a host computer |
| US08/213,752 | 1994-03-14 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2143492A1 true CA2143492A1 (en) | 1995-09-15 |
Family
ID=22796364
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002143492A Abandoned CA2143492A1 (en) | 1994-03-14 | 1995-02-27 | Portable pcmcia interface for a host computer |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US5519851A (en) |
| EP (1) | EP0672987B1 (en) |
| JP (1) | JPH0836539A (en) |
| CA (1) | CA2143492A1 (en) |
| DE (1) | DE69535028D1 (en) |
Families Citing this family (96)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1994011802A1 (en) * | 1992-11-12 | 1994-05-26 | New Media Corporation | Reconfigureable interface between a computer and peripheral devices |
| US5991530A (en) * | 1993-02-05 | 1999-11-23 | Canon Denshi Kabushiki Kaisha | Interface device receivable in card storage device slot of host computer |
| GB2287106A (en) * | 1994-02-16 | 1995-09-06 | Ibm | Connection of adaptors for multiple bus architectures |
| US5805834A (en) * | 1994-03-30 | 1998-09-08 | Zilog, Inc. | Hot reconfigurable parallel bus bridging circuit |
| US5664231A (en) * | 1994-04-29 | 1997-09-02 | Tps Electronics | PCMCIA interface card for coupling input devices such as barcode scanning engines to personal digital assistants and palmtop computers |
| US5687387A (en) * | 1994-08-26 | 1997-11-11 | Packard Bell Nec | Enhanced active port replicator having expansion and upgrade capabilities |
| US5848247A (en) | 1994-09-13 | 1998-12-08 | Hitachi, Ltd. | Microprocessor having PC card interface |
| US5802558A (en) * | 1994-09-30 | 1998-09-01 | Intel Corporation | Method and apparatus for upgrading reprogrammable memory contents in a PCMCIA card |
| EP0718751A3 (en) * | 1994-12-23 | 1997-02-12 | Ibm | Electronic circuit apparatus employing small disk drive with reconfigurable interface |
| US5812827A (en) * | 1995-01-30 | 1998-09-22 | Intel Corporation | Enhanced cardbus adapter and associated buffering circuitry for interfacing multiple cardbus/16 bit PC cards |
| USRE39052E1 (en) * | 1995-03-07 | 2006-03-28 | Tao Logic Systems Llc | System and method for expansion of a computer |
| ATE288107T1 (en) | 1995-03-07 | 2005-02-15 | Mobility Electronics Inc | SYSTEM AND METHOD FOR EXPANSION OF A COMPUTER |
| US5642481A (en) * | 1995-03-29 | 1997-06-24 | Microsoft Corporation | Method and system for validating a memory window in system address space |
| JPH08305814A (en) * | 1995-04-27 | 1996-11-22 | Mitsubishi Electric Corp | Pc card |
| WO1996038784A1 (en) * | 1995-06-02 | 1996-12-05 | Systemsoft Corporation | Digital data processing method and apparatus for peripheral device control |
| AU6763096A (en) * | 1995-07-27 | 1997-02-26 | Systemsoft Corporation | Systems and methods for accessing a data storage device |
| US5845282A (en) * | 1995-08-07 | 1998-12-01 | Apple Computer, Inc. | Method and apparatus for remotely accessing files from a desktop computer using a personal digital assistant |
| US6033257A (en) * | 1995-11-20 | 2000-03-07 | The Foxboro Company | I/O connector module for a field controller in a distributed control system |
| US5652832A (en) * | 1995-11-13 | 1997-07-29 | Systemsoft Corporation | Method and apparatus for diagnosis and correction of peripheral device allocation faults |
| EP0862755A4 (en) * | 1995-11-20 | 1998-12-30 | Foxboro Co | Expandable field controller in a distributed control system |
| US5754788A (en) * | 1995-12-28 | 1998-05-19 | Attachmate Corporation | Method and system for reconfiguring a communications stack |
| US5835772A (en) * | 1995-12-29 | 1998-11-10 | Intel Corporation | Method and apparatus for providing an interface between a system and a peripheral device |
| US5805929A (en) * | 1996-01-29 | 1998-09-08 | International Business Machines Corporation | Multiple independent I/O functions on a PCMCIA card share a single interrupt request signal using an AND gate for triggering a delayed RESET signal |
| US6058263A (en) * | 1996-06-03 | 2000-05-02 | Microsoft Corporation | Interface hardware design using internal and external interfaces |
| US6148346A (en) * | 1996-06-20 | 2000-11-14 | Peerless Systems Imaging Products, Inc. | Dynamic device driver |
| FI104920B (en) * | 1996-10-31 | 2000-04-28 | Nokia Mobile Phones Ltd | Electronic device, card interface and expansion card |
| US5941963A (en) * | 1997-02-14 | 1999-08-24 | Paul Charles | System and method for interconnection of computer peripherals via multiple interfaces |
| US6064660A (en) * | 1996-12-12 | 2000-05-16 | Optimay Corporation | GSM transceiver with portable protocol stack |
| US5790410A (en) * | 1996-12-12 | 1998-08-04 | Progressive International Electronics | Fuel dispenser controller with data packet transfer command |
| US6212576B1 (en) | 1997-01-27 | 2001-04-03 | Optimay Corporation | Operating system interface for use with multitasking GSM protocol stacks |
| US5887198A (en) * | 1997-04-07 | 1999-03-23 | The United States Of America As Represented By The Secretary Of The Navy | Programmable stand-alone drive apparatus for interfacing a host computer with PCMCIA memory cards having multiple formats |
| US6418492B1 (en) | 1997-05-13 | 2002-07-09 | Micron Electronics | Method for computer implemented hot-swap and hot-add |
| US6282673B1 (en) | 1997-05-13 | 2001-08-28 | Micron Technology, Inc. | Method of recording information system events |
| US6179486B1 (en) | 1997-05-13 | 2001-01-30 | Micron Electronics, Inc. | Method for hot add of a mass storage adapter on a system including a dynamically loaded adapter driver |
| US6249834B1 (en) | 1997-05-13 | 2001-06-19 | Micron Technology, Inc. | System for expanding PCI bus loading capacity |
| US6249885B1 (en) | 1997-05-13 | 2001-06-19 | Karl S. Johnson | Method for managing environmental conditions of a distributed processor system |
| US6363497B1 (en) | 1997-05-13 | 2002-03-26 | Micron Technology, Inc. | System for clustering software applications |
| US6163853A (en) * | 1997-05-13 | 2000-12-19 | Micron Electronics, Inc. | Method for communicating a software-generated pulse waveform between two servers in a network |
| US6243773B1 (en) | 1997-05-13 | 2001-06-05 | Micron Electronics, Inc. | Configuration management system for hot adding and hot replacing devices |
| US6269417B1 (en) | 1997-05-13 | 2001-07-31 | Micron Technology, Inc. | Method for determining and displaying the physical slot number of an expansion bus device |
| US6292905B1 (en) | 1997-05-13 | 2001-09-18 | Micron Technology, Inc. | Method for providing a fault tolerant network using distributed server processes to remap clustered network resources to other servers during server failure |
| US6330690B1 (en) | 1997-05-13 | 2001-12-11 | Micron Electronics, Inc. | Method of resetting a server |
| US5892928A (en) * | 1997-05-13 | 1999-04-06 | Micron Electronics, Inc. | Method for the hot add of a network adapter on a system including a dynamically loaded adapter driver |
| US6219734B1 (en) | 1997-05-13 | 2001-04-17 | Micron Electronics, Inc. | Method for the hot add of a mass storage adapter on a system including a statically loaded adapter driver |
| US6253334B1 (en) | 1997-05-13 | 2001-06-26 | Micron Electronics, Inc. | Three bus server architecture with a legacy PCI bus and mirrored I/O PCI buses |
| US6324608B1 (en) * | 1997-05-13 | 2001-11-27 | Micron Electronics | Method for hot swapping of network components |
| US6170028B1 (en) * | 1997-05-13 | 2001-01-02 | Micron Electronics, Inc. | Method for hot swapping a programmable network adapter by using a programmable processor to selectively disabling and enabling power thereto upon receiving respective control signals |
| US6304929B1 (en) | 1997-05-13 | 2001-10-16 | Micron Electronics, Inc. | Method for hot swapping a programmable adapter by using a programmable processor to selectively disabling and enabling power thereto upon receiving respective control signals |
| US6269412B1 (en) | 1997-05-13 | 2001-07-31 | Micron Technology, Inc. | Apparatus for recording information system events |
| US6195717B1 (en) | 1997-05-13 | 2001-02-27 | Micron Electronics, Inc. | Method of expanding bus loading capacity |
| US6499073B1 (en) | 1997-05-13 | 2002-12-24 | Micron Electronics, Inc. | System using programmable processor for selectively enabling or disabling power to adapter in response to respective request signals |
| US6202160B1 (en) | 1997-05-13 | 2001-03-13 | Micron Electronics, Inc. | System for independent powering of a computer system |
| US6145098A (en) | 1997-05-13 | 2000-11-07 | Micron Electronics, Inc. | System for displaying system status |
| US6338150B1 (en) | 1997-05-13 | 2002-01-08 | Micron Technology, Inc. | Diagnostic and managing distributed processor system |
| US6192434B1 (en) | 1997-05-13 | 2001-02-20 | Micron Electronics, Inc | System for hot swapping a programmable adapter by using a programmable processor to selectively disabling and enabling power thereto upon receiving respective control signals |
| US6243838B1 (en) | 1997-05-13 | 2001-06-05 | Micron Electronics, Inc. | Method for automatically reporting a system failure in a server |
| US6173346B1 (en) | 1997-05-13 | 2001-01-09 | Micron Electronics, Inc. | Method for hot swapping a programmable storage adapter using a programmable processor for selectively enabling or disabling power to adapter slot in response to respective request signals |
| US6189109B1 (en) | 1997-05-13 | 2001-02-13 | Micron Electronics, Inc. | Method of remote access and control of environmental conditions |
| US6247080B1 (en) | 1997-05-13 | 2001-06-12 | Micron Electronics, Inc. | Method for the hot add of devices |
| US6249828B1 (en) | 1997-05-13 | 2001-06-19 | Micron Electronics, Inc. | Method for the hot swap of a mass storage adapter on a system including a statically loaded adapter driver |
| US6202111B1 (en) | 1997-05-13 | 2001-03-13 | Micron Electronics, Inc. | Method for the hot add of a network adapter on a system including a statically loaded adapter driver |
| US6014714A (en) * | 1997-06-16 | 2000-01-11 | International Business Machines Corporation | Adapter card system including for supporting multiple configurations using mapping bit |
| US6175490B1 (en) | 1997-10-01 | 2001-01-16 | Micron Electronics, Inc. | Fault tolerant computer system |
| US6199173B1 (en) | 1997-10-01 | 2001-03-06 | Micron Electronics, Inc. | Method for mapping environmental resources to memory for program access |
| US6263387B1 (en) * | 1997-10-01 | 2001-07-17 | Micron Electronics, Inc. | System for automatically configuring a server after hot add of a device |
| US6212585B1 (en) * | 1997-10-01 | 2001-04-03 | Micron Electronics, Inc. | Method of automatically configuring a server after hot add of a device |
| KR100265704B1 (en) * | 1997-10-17 | 2000-09-15 | 윤종용 | Cable manager system and computer with the same |
| US6247081B1 (en) * | 1998-02-19 | 2001-06-12 | Nortel Networks Limited | Method and apparatus for installing drivers without requiring system re-boot |
| US6012063A (en) * | 1998-03-04 | 2000-01-04 | Starfish Software, Inc. | Block file system for minimal incremental data transfer between computing devices |
| US6205503B1 (en) | 1998-07-17 | 2001-03-20 | Mallikarjunan Mahalingam | Method for the hot swap and add of input/output platforms and devices |
| US6223234B1 (en) | 1998-07-17 | 2001-04-24 | Micron Electronics, Inc. | Apparatus for the hot swap and add of input/output platforms and devices |
| US6618767B1 (en) * | 1998-11-17 | 2003-09-09 | Sun Microsystems, Inc. | Mechanism by which devices on unforeseen platform variants may be supported without re-release of core platform kernel software |
| US6925513B1 (en) * | 1999-05-04 | 2005-08-02 | Apple Computer, Inc. | USB device notification |
| FI991167A (en) | 1999-05-24 | 2000-11-25 | Nokia Mobile Phones Ltd | Procedure for loading a user interface software |
| KR20010005141A (en) * | 1999-06-30 | 2001-01-15 | 이형도 | Interrup process method of pci adapter |
| JP2001265714A (en) * | 2000-01-13 | 2001-09-28 | Sony Computer Entertainment Inc | Interface device and information processing system provided with the same |
| US6823424B2 (en) * | 2000-01-26 | 2004-11-23 | Hewlett-Packard Development Company, L.P. | Rebuild bus utilization |
| JP2002351650A (en) * | 2001-05-22 | 2002-12-06 | Komatsu Ltd | Data communication equipment of pc card |
| AU2002314902A1 (en) * | 2001-06-02 | 2002-12-16 | Polycom, Inc. | System and method for point to point integration of personal computers with videoconferencing systems |
| WO2003003262A1 (en) * | 2001-06-27 | 2003-01-09 | Incorporated Technologies (Holdings) Limited | Multi input memory device reader |
| US7069365B2 (en) * | 2002-04-01 | 2006-06-27 | Sun Microsystems, Inc. | System and method for controlling multiple devices via general purpose input/output (GPIO) hardware |
| US20030217298A1 (en) * | 2002-05-17 | 2003-11-20 | Eric Oh-Yang | Method of a saving power mode by combining a smart card with a multi-function network card |
| US20030229743A1 (en) * | 2002-06-05 | 2003-12-11 | Brown Andrew C. | Methods and structure for improved fairness bus arbitration |
| EP1385080A1 (en) * | 2002-07-25 | 2004-01-28 | AboCom Systems, Inc. | Card reader and a network apparatus and corresponding power saving method |
| US20040034861A1 (en) * | 2002-08-19 | 2004-02-19 | Ballai Philip N. | System and method for automating firmware maintenance |
| KR100519360B1 (en) * | 2003-09-17 | 2005-10-07 | 엘지전자 주식회사 | Digital Cable Receiver |
| CN100354845C (en) * | 2003-10-24 | 2007-12-12 | 美国凹凸微系有限公司 | PC card controller with reduced number of terminals |
| US7386648B2 (en) * | 2003-10-24 | 2008-06-10 | 02 Micro International Limited | PC card controller with reduced number of terminals |
| TWI292533B (en) * | 2003-11-20 | 2008-01-11 | Sunplus Technology Co Ltd | System for accessing a plurality of devices by using single bus and control apparatus therein |
| US7730482B2 (en) * | 2004-06-08 | 2010-06-01 | Covia Labs, Inc. | Method and system for customized programmatic dynamic creation of interoperability content |
| US7685319B2 (en) * | 2004-09-28 | 2010-03-23 | Cray Canada Corporation | Low latency communication via memory windows |
| US7383460B2 (en) * | 2005-03-25 | 2008-06-03 | Microsoft Corporation | Method and system for configuring a timer |
| US7944890B2 (en) * | 2006-05-23 | 2011-05-17 | Interdigital Technology Corporation | Using windows specified object identifiers (OIDs) for an antenna steering algorithm |
| TWI378384B (en) * | 2008-10-15 | 2012-12-01 | Phison Electronics Corp | Mother board system, storage device for booting up thereof and connector |
| CN201348781Y (en) * | 2008-12-26 | 2009-11-18 | 鸿富锦精密工业（深圳）有限公司 | Circuit board |
| US8914498B2 (en) * | 2012-02-09 | 2014-12-16 | International Business Machines Corporation | Calculating a checksum with inactive networking components in a computing system |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5283889A (en) * | 1989-12-29 | 1994-02-01 | Zenith Data Systems Corporation | Hardware based interface for mode switching to access memory above one megabyte |
| US5305436A (en) * | 1990-04-02 | 1994-04-19 | Hewlett-Packard Company | Hose bus video interface in personal computers |
| US5228084A (en) * | 1991-02-28 | 1993-07-13 | Gilbarco, Inc. | Security apparatus and system for retail environments |
| US5319751A (en) * | 1991-12-27 | 1994-06-07 | Intel Corporation | Device driver configuration in a computer system |
| US5343319A (en) * | 1993-06-14 | 1994-08-30 | Motorola, Inc. | Apparatus for adapting an electrical communications port to an optical communications port |
| US5396602A (en) * | 1993-05-28 | 1995-03-07 | International Business Machines Corp. | Arbitration logic for multiple bus computer system |
-
1994
- 1994-03-14 US US08/213,752 patent/US5519851A/en not_active Expired - Lifetime
-
1995
- 1995-02-27 CA CA002143492A patent/CA2143492A1/en not_active Abandoned
- 1995-03-10 EP EP95301603A patent/EP0672987B1/en not_active Expired - Lifetime
- 1995-03-10 DE DE69535028T patent/DE69535028D1/en not_active Expired - Lifetime
- 1995-03-14 JP JP7080873A patent/JPH0836539A/en active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| EP0672987A3 (en) | 1995-11-22 |
| US5519851A (en) | 1996-05-21 |
| EP0672987A2 (en) | 1995-09-20 |
| EP0672987B1 (en) | 2006-06-07 |
| DE69535028D1 (en) | 2006-07-20 |
| JPH0836539A (en) | 1996-02-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2143492A1 (en) | Portable pcmcia interface for a host computer | |
| US6629157B1 (en) | System and method for virtualizing the configuration space of PCI devices in a processing system | |
| US5499378A (en) | Small computer system emulator for non-local SCSI devices | |
| US6321287B1 (en) | Console redirection for a computer system | |
| US6256691B1 (en) | Universal docking station | |
| US5835784A (en) | System for booting processor from remote memory by preventing host processor from configuring an environment of processor while configuring an interface unit between processor and remote memory | |
| US6185677B1 (en) | Automatic generation of ACPI source language for peripheral resource configuration | |
| US7546409B2 (en) | Deferring peripheral traffic with sideband control | |
| US7526578B2 (en) | Option ROM characterization | |
| EP0667581A2 (en) | Computer system with peripheral bus | |
| JP2008541214A (en) | Managing computer memory in a computing environment with dynamic logical partitioning | |
| KR100240922B1 (en) | Method for slave dma emulation on a computer system bus | |
| KR20030014353A (en) | Computer system including a memory access controller for using non-system memory storage resources during system boot time | |
| JPH04213715A (en) | Electronic apparatus | |
| US5968174A (en) | Method and apparatus for implementing a 32-bit operating system which supports 16-bit code | |
| US7484083B1 (en) | Method, apparatus, and computer-readable medium for utilizing BIOS boot specification compliant devices within an extensible firmware interface environment | |
| EP2370897A2 (en) | Composite device emulation | |
| US6211891B1 (en) | Method for enabling and configuring and AGP chipset cache using a registry | |
| CN114765051A (en) | Memory test method and device, readable storage medium and electronic equipment | |
| US6269459B1 (en) | Error reporting mechanism for an AGP chipset driver using a registry | |
| CN112486274B (en) | Computer expansion card and computer system | |
| US8239585B2 (en) | Systems and methods for improved hardware device connectivity | |
| US7694004B2 (en) | Bit-granular writes of control registers | |
| EP0810528B1 (en) | Apparatus for DMA-slave emulation on a computer systems bus | |
| US20030084137A1 (en) | Method for viewing, managing and controlling system specific hardware using industry standard tables uploaded to locally installed remote management devices |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |