USB: A neat package with a few loose ends
`Quinnell, Richard A
`EDN; Oct 24, 1996; 41, 22; ProQuest Central
`pg.38
`
`Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
`
`BLACKBERRY Ex. 1016, page 1
`
`

`

`, ~ J hen EDN's call for hands-on pro(cid:173)
`VV ject ideas came in late 1995, I
`
`chose the Universal Serial Bus (USB). At
`the time, the specification was still in
`draft stage as Revision 0.9, and compo(cid:173)
`nents were only a promise. Like most of
`you, I wanted to apply an emerging
`technology that looked like the next
`winner. By catching the bus too soon,
`however, I was in for a rough ride.
`I chose the USB for its potential. The
`bus can connect a standard, closed(cid:173)
`cover PC to industrial peripherals that
`now require an add-in card or embed(cid:173)
`ded PC. Connecting the peripheral
`device automatically configures both
`the peripheral and the PC and prepares
`the system to use its newly acquired
`capability. Further, that connection can
`supply power to run the peripheral
`device (see box, "USB fundamentals").
`You can use such a self-configuring,
`self-powered system for numerous
`applications. For example, you can add
`a diagnostic monitoring port. You can
`build a USB data-acquisition peripher(cid:173)
`al into a system without using system
`resources. The system under test need
`not have its own control CPU or power
`source. Connecting a PC to the USB
`device powers the device and allows
`the user to monitor system operation,
`regardless of the system's status. The
`ability to perform remote diagnostics
`over a telephone line, for example,
`requires only the connection of a
`modem-enabled PC to the diagnostic
`port. The need for system-hosted com(cid:173)
`munications capability vanishes.
`My hands-on project had two objec(cid:173)
`tives. The first was to build a USB
`peripheral device. The second was to
`use the device to "kick the tires" on the
`bus. In particular, I wanted to evaluate
`the bus's timing and data-bandwidth
`characteristics under severe load to
`learn how adaptable the USB would be
`to embedded needs.
`To meet these objectives, I planned
`to create a data-acquisition peripheral.
`Data acquisition is a typical embedded
`
`The USB for PCs can automatically configure and
`
`power peripherals. But, as I learned in this hands-
`
`on project, early USB adopters may face a sub-
`
`stantial system-level design effort. They also
`
`need to carefully examine USB data-bandwidth
`
`characteristics.
`
`application-one that could easily
`adapt to the USB. In addition, such a
`device would give me control over the
`device's data rate. That control would
`allow me to test the bus under various
`loads pushing the bus to its upper
`limit.
`Once I had my peripheral, I would be
`able to measure the system's attained
`bandwidth and compare it to the theo(cid:173)
`retical bandwidth. The USB Specifica-
`
`My hands-on protect
`had three mator compo(cid:173)
`nents. The IBM PC350
`(left) acted as the USB
`host. The other PC was
`the development plat(cid:173)
`form for the evaluation
`board In the middle.
`
`PHOTO COURTESY USB IMPLEMENTERS FORUM
`AND INTEL CORP
`www.ednmag.com
`
`EDN OCTOBER 24, 1996 • 39
`
`Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
`
`BLACKBERRY Ex. 1016, page 2
`
`

`

`USB BAND8-0N PROJECf
`
`tion Revision 1.0 (Reference 1) calls for
`the host to allocate bandwidth for a
`bulk-transfer device based on the for(cid:173)
`mula:
`
`Bus time (nsec)=9107+83.54
`(Floor(3 .16 7 + BitStufffime(Data_bc)))
`+Host_Delay,
`where BitStufffime is the increase in
`
`raw bit count due to coding, Data_bc is
`the number of bits in the data packet,
`and Host_delay is the time the host
`needs between successive bus transac(cid:173)
`tions. For a 64-byte data packet, worst(cid:173)
`case bit stuffing, and minimum host
`delay, the formula yields a bus time of
`59.4 f.LSec. That time translates to 1.024
`Mbytes/sec because the number of bus
`
`transactions each millisecond must be
`an integer.
`This formula takes into account
`worst-case conditions for clock rate,
`signal delays, and data pattern (see
`box, "USB bandwidth analysis"). It also
`includes several host-system-depen(cid:173)
`dent unknowns. I intended to use my
`peripheral to estimate these unknown
`
`USB FUNDAMENTALS
`
`full-speed data include a shield; low-speed cables need not be
`shielded.
`USB cable connectors come in two types (Figure B). The
`Type-A connector is a flattened rectangle that plugs into
`downstream-port sockets on the USB host or a hub. Cables
`permanently attached to a device, such as on a keyboard or
`mouse, use a Type-A connector. The Type-B connector, rough(cid:173)
`ly square with beveled corners, plugs into upstream sockets on
`
`The developers of the Universal Serial Bus (USB) specification
`had two objectives. One was to collect all of a PC's 1/0 ports
`into one interface, providing live-insertion and automatic con(cid:173)
`figuration. The other was to provide sufficient bandwidth to
`handle telephony applications along with typical peripherals.
`The design they settled on is a four-wire, half-duplex serial bus
`running at either 1.5 Mbps (low speed) or 12 Mbps (full
`speed).
`From the outside, the USB appears
`simple. Plugging a peripheral device
`into the bus causes the PC to auto(cid:173)
`matically respond. The operating sys(cid:173)
`tem recognizes the device, loads the
`appropriate drivers, and configures
`the device for operation. The PC can
`distinguish between identical devices
`on the bus because the bus's physical
`configuration ensures a unique, iden(cid:173)
`tifiable connection path between
`device and host.
`The USB's physical configuration
`has a tiered-star topology (Figure A).
`The PC serves as the host system and
`root hub. Second-tier devices, either
`peripherals or hubs, connect to the
`root hub's ports. lower tiers connect
`through hubs in the tier directly
`above. There are no limits on the
`number of lower tier connection
`points a hub may offer. The specifica(cid:173)
`tion allows as many as five hubs in a
`chain and a total of 127 devices on the
`bus.
`A connection between a device and
`hub uses a four-wire, jacketed cable.
`Two wires form a twisted pair for data
`communications, the other two sup(cid:173)
`ply power and ground for hubs and
`devices without their own power
`source. Data flow in the cables may be
`downstream (hub to device) or
`upstream (device to hub). Power can
`flow only downstream and is limited
`to 500 mA at 5V. Cables intended for
`
`The USB's physical topology Is a tiered star that can accommodate flve layers and
`127 devices.
`
`40 • EDN OCTOBER 24, 1996
`
`Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
`
`BLACKBERRY Ex. 1016, page 3
`
`

`

`~I COVER STORY
`
`values for my system and accurately
`estimate achievable bandwidth.
`The first task, therefore, was to build
`a USB peripheral. Because the project
`began only a few months after the spec(cid:173)
`ification's final approval, I had few
`choices for hardware- and software(cid:173)
`development tools. Following the pro(cid:173)
`ject's genesis, more tools and improved
`
`versions became available (Table 1), so
`the choices I made represent availabili(cid:173)
`ty, not a comment on relative merit.
`I began my project by acquiring
`Intel's evaluation board for its 82930
`USB microcontroller. The 82930
`microcontroller blends an 80251 core
`with USB-specific hardware, including
`FIFO buffers, clock generation, and
`
`bit-stuffing and protocol hardware.
`The evaluation board includes the
`82930, clock circuits, USB line drivers,
`external memory, and a ROM-based
`reduced-instruction-set monitor
`(RISM). The board also has parallel
`and serial ports that I planned to use
`to connect the board to an ADC mod(cid:173)
`ule. One serial port links the board to
`
`devices and hubs. The Type-B connector is
`used only for the device end of a removable
`cable, such as between a hub and a printer.
`This two-connector scheme prevents a user
`from accidentally creating a loop.
`
`Simple operation, complex behavior
`Although the USB appears simple overall,
`its internal workings are complex. You need
`to carefully examine those workings if you
`intend to use the bus as a pathway into your
`PC. In particular, you need to understand
`how the USB operates logically and the
`nature of its data transfers so you can evalu(cid:173)
`ate its adaptability to your intended use.
`Even though the USB's physical architec(cid:173)
`ture has a tiered-star topology, its logical
`connection is point-to-point. The host sys(cid:173)
`tem establishes independent communica(cid:173)
`tions channels, or pipes, between application
`software and individual control or data ports on peripheral
`devices. Channels can carry data (stream) or control/status
`(message) information. Pipes have several attributes, including
`bandwidth allocation, packet size, information type (stream or
`message), and direction of stream data flow.
`The host establishes these pipes by assigning a unique 7-bit
`address to each device on the bus, a process called "enumer(cid:173)
`ation." Enumeration occurs on power-up and whenever a
`device attaches to the bus. During enumeration, the device
`reports its configuration to the host, identifying the device's
`accessible data and control pathways. Each pathway has its
`own 4-bit subaddress, called an "endpoint." The address and
`endpoint definitions allow the host to determine the corre(cid:173)
`spondence between application-software functions and
`device pathways and create the necessary pipes. An applica(cid:173)
`tion program, thus, has a direct logical connection to a
`device's data channels or control registers.
`Having multiple pipes on a single half-duplex bus requires
`some form of multiplexing. The USB uses time-domain multi(cid:173)
`plexing under control of the host system, working with 1-msec
`frames as the basic time segment. The host initiates all bus
`transfers, giving it control over the allocation of time within
`frames to each pipe. The allocation is not static, however, but
`varies from frame to frame. Specific allocation depends on the
`
`USB cable connectors come In two flavors. The flat connector Is for devices
`with built-In cables. The second connector type allows detachable cables with(cid:173)
`out the risk of cabling mistakes.
`
`type of information transfer the pipe must provide and
`whether the application software has requested a transfer.
`The USB specification recognizes four transfer types:
`isochronous-data, bulk-data, control, and interrupt. Isochro(cid:173)
`nous-data transfers typically carry time-critical information,
`such as audio, so the host must allocate time in each frame for
`an isochronous stream pipe. Interrupt transfers receive time
`slots every nth frame. All other transfers receive time on an as(cid:173)
`available basis.
`To ensure that all transfer types have access to the bus, the
`USB specification limits the time that the host can allocate to
`transfers. Isochronous-data and interrupt transfers together
`can occupy no more than 90% of available bus time. Control
`transfers have the next priority, with bulk-data transfers receiv(cid:173)
`ing any remaining time. The host is responsible for resolving
`contention among control-transfer requests and among bulk(cid:173)
`data-transfer requests for the time available.
`The host reserves bus bandwidth for isochronous and inter(cid:173)
`rupt transfers during device enumeration. If a transfer needs
`more bandwidth than is available, however, the host does not
`finish that device's enumeration. This inaction effectively
`denies the device access to the bus.
`Reservation of bandwidth does not allocate bus time but
`(continued on pg 42)
`
`Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
`
`EDN OCTOBER 24, 1996 • 41
`
`BLACKBERRY Ex. 1016, page 4
`
`

`

`USB HANDS-ON PROJECT
`
`the development system.
`The evaluation board is
`part of a peripheral develop(cid:173)
`er's kit available from Intel.
`The original kit comprised
`the evaluation board, a host
`system, driver software, and
`sample application software.
`Unfortunately, no host sys(cid:173)
`tems were available for me to
`borrow, so I had to locate my
`own USB-ready PC. The sam(cid:173)
`ple software was specific to
`the Intel host system, so I
`couldn't adapt it to my pro(cid:173)
`ject.
`The first USB host systems
`to enter production were the
`IBM PC 300 series PCs. I bor(cid:173)
`rowed a PC 350 from IBM. It
`has two USB ports on the
`back panel and BIOS exten(cid:173)
`sions that support the USB.
`To be completely ready as a
`USB host, however, the sys(cid:173)
`tem needed an updated ver(cid:173)
`sion of Windows 95. The
`commercially available ver-
`sion would not recognize the USB port
`or run USB device drivers. I obtained
`from Microsoft a beta version of the lat(cid:173)
`est Windows 95 OEM release for my
`system, along with some USB loop(cid:173)
`back test drivers.
`To turn the evaluation board into a
`
`peripheral device, I would have to pro(cid:173)
`gram the 82930. For that task, I needed
`software-development tools. The eval(cid:173)
`uation board came with demonstration
`tools from Keil Software, Production
`Languages Corp (PLC), and Tasking. I
`chose the Tasking software for its
`
`debugger and because its
`crippled-for-demo state was
`sufficient to meet my antici(cid:173)
`pated development needs.
`I also needed tools for
`developing device drivers
`and application software
`under Windows 95. This
`requirement, in turn, re(cid:173)
`quired that I obtain a copy of
`the Windows NT Driver
`Developer's Kit
`from
`Microsoft. I was able to
`obtain several sample dri(cid:173)
`vers but could not get what I
`needed to run Windows NT
`and develop the custom dri(cid:173)
`vers that my project would
`require.
`
`Too little, too late
`At this point, I had to re(cid:173)
`evaluate my approach to the
`project. Given my limited
`resources and a six-week
`deadline, I faced an impossi(cid:173)
`ble development effort. The
`pieces of this puzzle were all
`too new and had raw edges. These
`pieces weren't going to go together
`very well, and I had few tools at my dis(cid:173)
`posal that would let me trim the pieces
`to fit. And, I was missing a few pieces.
`Figure 1 helps illustrate the effort I
`faced. Of the six major blocks in a USB
`
`Deciphering the USB's activity with a basic logic analyzer
`would be a nightmare. Fortunately, bus-analysis tools, such as
`the CATC USB Detective, are available.
`
`USB FUNDAMENTALS (oontinued)
`
`merely tracks anticipated demand. The host system allocates
`time within a frame only if the application software has
`requested time. An audio CD device, for example, may have
`50 kbytes/sec reserved on the USB, but the host doesn't allo(cid:173)
`cate time if the CD is not playing. Any reserved, but unused,
`bus time becomes available for bulk-data transfers.
`The mix of transfer types offers design trade-offs among
`data rate, latency, and data integrity. Isochronous data trans(cid:173)
`fers have a guaranteed data rate and bounded latency. They
`receive time every frame, although a given transfer's position
`within the frame may vary. The drawback to isochronous
`transfer is that the data is not guaranteed. If data loss or error
`occurs, the USB does not resend isochronous data. Isochro(cid:173)
`nous transfers can have data packets as long as 1 023 bytes
`and must always run at full speed.
`Interrupt transfers also have a guaranteed data rate and
`bounded latency but may run at full or low speed. Every n
`frames, the host queries a device through its interrupt-stream
`
`pipe. If the device has interrupt information, it returns a sin(cid:173)
`gle data packet as long as 64 bytes. If an error occurs in trans(cid:173)
`mission, the device resends the information at the next query.
`Bulk data and control transfers have no guarantees on their
`data rate, although control transfers have the first claim to
`1 0% of the bus bandwidth. Errors in bulk data and control
`transfers prompt a retry. If several transfer requests are pend(cid:173)
`ing for the same pipe, the retry occurs before the pending
`transfers. Bulk- and control-data packets can be as long as 64
`bytes and may run at full or low speed.
`Understanding these trade-offs and the underlying logic of
`the USB's operation should allow you to estimate how well the
`bus can meet its intended application's interface needs. For
`more detailed design work, you need a copy of the specifica(cid:173)
`tion. It is available for $35 from the USB Implementer's Forum,
`JF2-51, 2111 NE 25th Ave, Hillsboro, OR, 97124. You can also
`download it free from the USB home page, http:/ I
`www.teleport.com/-usb.
`
`42 • EON OCTOBER 24, 1996
`
`Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
`
`BLACKBERRY Ex. 1016, page 5
`
`

`

`implementation, I had only two: the
`USB interface and the host controller. I
`also had only part of the software I
`needed to turn the evaluation board
`into a USB logical device. I had expect(cid:173)
`ed to program the evaluation board to
`provide the function but thought the
`logical device, system software, and
`client software would be available in a
`form I could use or adapt. They weren't.
`I also couldn't create my own system
`software or client software without
`Windows NT. I would have to adapt my
`evaluation peripheral to match the dri(cid:173)
`vers already in hand.
`Early adopters of USB can expect to
`face similar problems, especially the
`need to create client software and
`device drivers for Windows 95. Few
`examples are currently available,
`although the situation continues to
`improve. One looming improvement is
`the pending release of device-class
`specifications.
`Device classes allow standard soft(cid:173)
`ware to handle common peripherals.
`The standard-class device drivers work
`for all devices within the class. Device
`classes for human-input devices, such
`as a keyboard, a mouse, or a joystick;
`monitors; and audio devices are under
`development. These classes and the
`associated software were still under def(cid:173)
`inition during my project, however,
`and were unavailable to me. Once
`device-class specifications exist, off(cid:173)
`the-shelf drivers and client software
`should quickly become available. Still,
`designs that fall outside device classes
`are on their own for software.
`I decided to work with the software I
`had, rather than try to develop every(cid:173)
`thing I needed from scratch. I would
`have to design the peripheral to work
`with the loop-back-test software
`Microsoft had given me. That problem
`settled, I was finally able to get to work,
`with four weeks left in the project
`schedule. The first step was to set up the
`host system. This step was also the first
`stumbling block.
`I unpacked my borrowed computer
`and turned it on but was faced with a
`dead monitor. The monitor's power(cid:173)
`saving circuitry was holding the device
`in a standby state. By swapping moni(cid:173)
`tors and PCs, I was able to determine
`that the monitor was OK, but there
`seemed to be no video coming from the
`
`lllliilllll COVER STORY
`
`USB host PC. Reinserting and wiggling
`cables had no effect. A call to IBM's
`technical-marketing-support group
`
`revealed that the system I had received
`had an SVGA card installed, which dis(cid:173)
`abled the motherboard's built-in
`
`TABLE l-USB PRODUCTS
`-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-
`Product type
`Company
`Product
`Comments
`BIOS
`AMI
`AMIBIOS 95+
`Award Software
`Phoenix
`Technologies
`
`Phoenix Bios 4
`
`Connectors
`
`Devices
`
`Amp
`Methode Electronics
`Newnex Technology
`Northstar Systems
`Siemens
`
`Advanced Gravis
`Alps Electric
`
`Cherry
`KeyTronic
`Logitech
`Mite!
`Philips Consumer
`Electronics
`USAR Systems
`
`Host PCs
`
`ICs
`
`Compaq
`IBM
`Sony
`Ziatech
`
`Atmel
`
`CAE Technology
`CMD
`Intel
`
`Mitsubishi
`
`NEC
`Philips
`Semiconductor
`Texas
`Instruments
`
`Virtual Chips
`
`Tools
`
`CATC
`
`Digital System
`Associates
`FuturePius
`
`Hewlett-Packard
`Intel
`
`PLC
`Tasking
`
`Annabooks
`System Soft
`
`Training
`
`Gamepad
`Keyboard,
`gamepad
`Keyboard
`Keyboard
`joystick
`Telephone
`Monitor
`Speakers
`USBAdapt
`
`PC300 series
`PCV70, PCV90
`ZT5510
`
`AT43311
`
`AT43351
`
`ASIC
`
`430HXNX
`82930AX
`37960
`
`PCIUSB11
`
`TUSB2070
`
`TUSB2040
`USB functions
`
`Molded cable assemblies
`
`Hub/monitor
`Digital audio speakers
`PS2/USB keyboard
`adapter
`
`Compact PCI CPU board I
`
`I
`
`Five-port USB hub
`controller
`Low-speed USB device
`microcontroller
`USB synthesizable core
`USB-PCI host ASIC
`PCI/USB host controller
`USB microcontoller
`MPU core,
`evaluation board
`USB host core
`USB line drivers
`
`Seven-port USB hub
`device
`Four-port USB hub devicE
`Synthesizable cores,
`test simulator
`
`USB Detective
`USB Traffic
`Generator
`DSA-2001
`
`Bus analyzer
`
`Traffic simulator
`Bus analyzer
`
`USB
`Bus analyzer, works with
`HP logic analyzers
`Preprocessor
`Logic analyzer
`16500B
`Device-configuration too
`Apbuilder
`Software development
`Keil Software
`Software development
`Compass/ 251
`MCS 251 Toolset Software development
`
`Books, seminars
`Software consulting/
`training
`
`.I
`
`EDN OCTOBER 24, 1996 • 43
`
`Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
`
`BLACKBERRY Ex. 1016, page 6
`
`

`

`USB HANDS-ON PROJECT
`
`graphics port. I had connected the
`cable to the motherboard port in accor(cid:173)
`dance with the instructions, but it was
`the wrong port.
`Now that the monitor was active, I
`had another problem. The system
`
`wouldn't boot. Apparently, Windows
`95 automatically executes a disk scan
`on boot-up if the previous session
`didn't exit properly. While trying to
`find the monitor problem, I had turned
`power to the computer on and off sev-
`
`eral times. One of those times must
`have been during a disk access, and I
`corrupted the boot record. Now, I had
`to reconstruct my system files.
`Reconstruction proved a significant
`challenge. My software came pre-
`
`USB BANDWHYfH ANALYSIS
`
`The Universal Serial Bus (USB) offers a raw data rate of 12
`Mbps, suitable for low- to medium-speed data transfers. At
`first glance, that data rate suggests a data bandwidth
`approaching 1.5 Mbytes/sec. However, protocol overhead
`and system delays steal a significant fraction of that rate. To
`find the achievable data bandwidth, you need to consider
`many factors.
`The analysis of USB bandwidth must begin with the frame
`rate. The USB specification calls for the host to segment data
`transfers into 1-msec frames, nominally containing 1500 bytes
`(12 kbits). However, the specification allows the host controller
`to adjust the frame's bit count to synchronize the frame rate
`to an external clock. Adjustments as great as± 16 bits (2 bytes)
`are permissible.
`Each USB frame begins with a start-of-frame (SOF) marker.
`That marker, together with system delays that give bus devices
`time to react, occupies approximately 6 bytes of the frame.
`USB frames also have an end-of-frame (EOF) period during
`which no bus transactions may occur. The EOF period allows
`the system to detect and shut down failed peripheral devices
`that are babbling, or transmitting without permission. The EOF
`period occupies approximately six byte-times. Together, the
`SOF, EOF, and frame adjustments take up 14 bytes. The remain-
`
`ing 1486 bytes in the frame are available for bus transactions.
`Figure A shows the composition of a typical bus transac(cid:173)
`tion, in which the host receives bulk data from a peripheral
`device. The transaction has three steps: a request by the host
`for data, a transmission of a data packet by the peripheral, and
`an acknowledgment from the host. Each of these steps has
`protocol overhead, as well as some system delays.
`The host's request for data comes as an IN token. The token
`consists of an 8-bit synchronization field (sync), an 8-bit pack(cid:173)
`et identification (PI D) field, an 11-bit address field, and a 5-bit
`CRC character. In addition, the token has an end-of-packet
`(EOP) signal two bit-periods in length. The IN token's total
`duration is at least 34 bit-periods. Bit-stuffing can increase that
`duration.
`
`Bit-stuffing adds overhead
`Bit-stuffing occurs as a result of data encoding. The USB sig(cid:173)
`nal uses an NRZ invert (NRZI) coding scheme, which allows
`the signal to carry both data and clock information. NRZI cod(cid:173)
`ing calls for the output signal to change state each bit-period
`if the data bit is zero. If the data is a one, the signal remains
`steady. The state-change transitions at each zero bit allow a
`PLL to recover the bit clock. A long sequence of ones, howev-
`
`i$i4Mi!l ~-------------- 1 TRANSACTION - - - - - - - - - - - - - - - - -1
`
`--·····-·-
`
`I BIT STUFF
`
`I
`
`IN TOKEN I SYNC I PID I ADDR I CRC I
`
`~~8-L~8~~1~1~~5~ D EOP
`
`2
`
`11DLEI
`
`BIT STUFF
`
`DATA
`
`ACKNOWLEDGE
`
`~~~ I SYNC I PID I B'7E I sv;E llnll_6_v,J_E'I--c-R-C--,
`16 D EOP
`
`8
`
`8
`
`8
`
`8
`
`8
`
`2
`
`IIDLEI
`
`8
`
`:i.5 ,,...S-Y-NC...,,r--P-ID-,1
`8 D EOP
`2DHosT
`
`A single transaction between the USB host and a device has several parts, including built-In
`idle periods. The labels for each data block show the block name and bit length.
`
`DELAY
`
`;>2
`
`44 • EDN OCTOBER 24, 1996
`
`Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
`
`BLACKBERRY Ex. 1016, page 7
`
`

`

`lllmllll COVER STORY
`
`loaded, and I had no start-up disk. Win(cid:173)
`dows 95 includes DOS as a subprogram,
`rather than as its foundation. I replaced
`the DOS boot record with a copy from
`my other computer, but Windows 95
`doesn't run when called by an earlier
`
`DOS version. The CD-ROM version of
`Windows 95 I had was useless to me
`because the IBM PC 350 had no DOS
`drivers for the CD; it ran under Win(cid:173)
`dows 9 5. I finally found-after a
`painstaking file-by-file examination of
`
`the hard drive under my earlier version
`of DOS-some compressed installa(cid:173)
`tion-disk copies of Windows. Execut(cid:173)
`ing those files restored my system.
`With my host system back in opera(cid:173)
`tion and the evaluation board hooked
`
`1200-
`
`1000-
`
`ATTAINABLE BOO(cid:173)
`BUS
`BANDWIDTH
`(kBYTES/SEC) 600
`
`400
`
`200-
`
`l§l§Q;ij:l
`
`64-BYTE PACKETS
`
`32-BYTE PACKETS
`
`16-BYTE PACKETS
`
`8-BYTE PACKETS
`
`2
`
`5
`4
`3
`TOTAL DELAY (f!SEC)
`
`6
`
`7
`
`er, generates no transitions, and the
`dock-recovery scheme fails.
`To ensure an adequate number of tran(cid:173)
`sitions, the USB protocol calls for the data
`transmitter to insert a zero bit after six
`consecutive ones. This inserted, or
`stuffed, bit serves only to provide a state
`transition. The receiver automatically
`removes stuffed bits from the data stream.
`The sync's bit pattern and the PID fields
`have enough zeros that, by themselves,
`they never need bit-stuffing. The last 3
`bits of the PID can be ones, however, and
`may combine with subsequent fields to
`require a stuffed bit. Address, data, and
`CRC fields all have the potential for con(cid:173)
`taining a long sequence of ones, so are
`subject to bit-stuffing overhead. Figure
`B marks the transaction sections that
`might contain bit-stuffing.
`Following the IN token, the bus goes
`idle for a time. Two factors set this first idle
`period: the time it takes the peripheral device to tum from
`receiver to transmitter and the round-trip propagation delay for
`the host's EOP signal to reach the device and the response to
`return. The USB specification calls for the minimum device turn(cid:173)
`around time to be two bit-periods, allowing the bus to settle
`following the token. The maximum allowable round-trip prop(cid:173)
`agation delay, including turnaround time, is 16 bit-periods.
`Thus, the first idle period is two to 16 bit-periods long.
`Upon receipt of the IN token, the peripheral device sends
`its data packet. The packet consists of sync and PID fields fol(cid:173)
`lowed by a number of data bytes, a 16-bit CRC field, and the
`
`The achievable bandwidth of a USB system depends on several factors. These
`curves show the effect of idle time and packet size on the bandwidth of trans(cid:173)
`actions with little bit stuffing.
`
`EOP signal. The USB specification allows non isochronous data
`packets to be 8, 16, 32, or 64 bytes long, as set during device
`enumeration. Three bits of the PID, the CRC character, and the
`data bytes are all subject to bit-stuffing.
`The USB again goes idle as the host turns its interface around
`from receiver to transmitter. The turnaround period is at least
`two bit-periods long and must be no longer than 7112 bit-peri(cid:173)
`ods. The host then transmits an acknowledgment token that
`consists of a sync field, a PID field, and an EOP signal.
`Transmission of the acknowledgment token concludes the
`(continuecl on pg 46)
`
`TABLE A-ACHIEVABLE USB BANDWIDTH (KBYTESISEC)
`
`Packet
`size
`8
`16
`32
`64
`
`Minimum delay
`Typical
`Maximum
`bit-
`bit-
`stuff
`stuff
`608
`544
`848
`768
`1056
`928
`1216
`1088
`
`Typical delay
`Typical
`Maximum
`bit-
`bit-
`stuff
`stuff
`584
`528
`832
`736
`1056
`928
`1216
`1024
`
`Maximum delay
`Typical Maximum
`bit-
`bit-
`stuff
`stuff
`488
`536
`784
`704
`1024
`896
`1152
`1024
`
`Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.
`
`EDN OCTOBER 24, 1996 • 45
`
`BLACKBERRY Ex. 1016, page 8
`
`

`

`USB HANDS-ON PROJELi
`
`in, I was ready to try out the develop(cid:173)
`ment tools. A simple routine would do,
`so I wrote an assembly-language loop
`that activated LEDs connected to the
`82930's output port 1. After several
`attempts to load the program into the
`evaluation board, however, I realized
`that the demo software was invoking
`not the debugger, but a simulator. Calls
`to the Tasking help line finally revealed
`that the demo version I had would not
`work with the RISM version on my
`evaluation board.
`My contacts at Intel, who were pro(cid:173)
`viding guidance and answers on my
`project, were accustomed to the Com(cid:173)
`pass/25 1 software from PLC and
`couldn't answer questions about the
`Tasking tools. To be consistent with my
`mentors, I secured a loaner copy of the
`full development tool from PLC, mak(cid:173)
`ing sure that the version (Revision
`3.03) the company sent me would work
`with the Revision 0.2 RISM I had on the
`evaluation board. This tool allowed me
`to load a program of my own creation
`into the board, and I used that program
`for the remainder of the project.
`
`liB I coveR STORY
`
`_______ ,L. ______ _
`
`I
`
`1iH'M11
`
`FUNCTION
`LAYER
`
`DEVICE
`LAYER
`
`______ j _______ - - - - - - - - - -
`1
`
`BUS-INTERFACE
`LAYER
`
`NOTES: • • • • • ACTUAL COMMUNICATIONS FLOW.
`
`<
`
`> LOGICAL COMMUNICATIONS FLOW.
`
`A complete USB
`device has six
`functional parts,
`Including applica(cid:173)
`tion (client) and
`system software
`within the host
`PC. Developers
`should ensure
`that they have
`sources for all the
`parts they do not
`want to design.
`
`Finally, something was happening
`with my project hardware. My program
`illuminated the LEDs on the board in
`sequence. Of course, at 12 MHz, the
`result was a blur. The Compass/251
`
`debugger allows a self-timed single-step
`mode, however, so I could slow the
`blinking LEDs and verify the pattern.
`Two weeks' design effort just to get
`blinking lights. Thrilling.
`
`USB BANDWI1111J ANALYSIS (continued)
`
`transaction, but the host system must delay at least two bit(cid:173)
`periods before initiating another transaction. In practice, this
`delay can be longer. The host controller may need to access
`system memory, for example, to retrieve data for the next
`transaction. This host delay following a transaction is imple(cid:173)
`mentation-dependent.
`
`Achieved bandwidth a random variable
`Adding all the bit-periods and delays gives the time
`required for one transaction. Unfortunately, that time is vari(cid:173)
`able. Some variations, such as propagation delay and bus
`turnaround time, are a function of the specific implementa(cid:173)
`tion and remain constant for a given system. The time lost to
`bit-stuffing, however, depends on data patterns and varies
`frame to frame. A statistical estimate of random data suggests
`that bit-stuffing typically occurs with 0.8% of the data. A
`worst-case data pattern, however, results in bit-stuffing one(cid:173)
`sixth (16.67%) of the time.
`An estimate of achievable data bandwidth, therefore, must
`necessarily be a range. Table A shows the achievable data
`bandwidth for a sequence of bulk transactions using various
`packet lengths and a worst-case clock frequency. The entries
`account for typical