ADAPTEC.JUL–wy
SCSI test systems are changing
More complex SCSI peripherals and bus configurations are placing new
demands on SCSI testers
BY THOMAS W. MARTIN Adaptec, Inc. Milpitas, CA
The Small Computer System Interface (SCSI) is constantly evolving into a
faster and more intelligent peripheral interface. Manufacturers now
provide as standard in their peripherals such features as data caching and
command queuing. In the past, these features were managed by the host
computer. The off-loading of these and other features to the peripheral
has provided substantial benefits to system integrators. Probably most
important is that host computers have fewer I/O management tasks to
perform, with those tasks now performed where the maximum performance
benefits can be achieved. SCSI testing is changing, too. In most SCSI
peripheral testing applications, verifying data integrity is a priority.
On the one hand, SCSI peripheral designers must prove that their designs
are robust, providing correct data in every possible operating environment
in which their product might be used. (These environments include
asynchronous/synchronous/fast, 8-bit/16-bit, multithreading/single
threading, caching/non-caching, and queuing/non-queuing.) On the other
hand, system integrators must verify that the SCSI peripherals they choose
provide correct data in the specific environments of their systems.
Verifying the data integrity of the latest generation of SCSI peripherals
requires new test system features. Cache management and queue management
each add a new dimension of complexity to the data-integrity-testing
problem. Not only must traditional features such as logical block
management, dual-port buffer management, and parity generation/detection
be verified, but an entirely new class of algorithmic failures are now
possible. Before discussing test methods required to verify the
performance of the latest SCSI peripherals, it's important to review the
performance of the traditional SCSI test system that has been available
for many years. In a typical traditional SCSI test setup, the peripheral
unit under test is connected directly via the SCSI bus to a special
printed circuit board called a test adapter (see Fig. 1). The combination
of the test adapter, its control software, and a PC is called a SCSI
development system. Many test-specific features not possible with host
adapters are inherent in test adapters. For data integrity testing, the
key features are: (1) an on-board buffer, which allows data to move across
the SCSI bus independent of host processor and backplane speeds; (2)
software overlays, which allow test data to be tagged with the addresses
of the target logical blocks; (3) SCSI bus data rate control, which allows
designs to be tested across a broad range of performance; and (4)
on-the-fly hardware data compare, which allows miscompares to be detected
without influencing data-transfer rates.
Traditional SCSI test limitations Two recent developments in the
marketplace–more complex SCSI devices and more complex SCSI bus
configurations–reveal significant limitations in the traditional SCSI
test methods when testing the very latest SCSI devices.
SCSI devices SCSI device capacities not long ago were measured in tens
of megabytes, but they are now measured in gigabytes. The relatively small
on-board buffers of traditional test systems inhibit the use of
non-repeating test data, including overlays, for long transfers. Caching.
On caching peripherals, there are two possible locations for each block of
data–on the media itself or in the cache memory. At any one time, only
one location has the correct data. As a caching peripheral executes a
sequence of commands, the caching algorithms can get confused and use the
wrong location. A test system must provide sufficient control to uncover
these problems. Traditional test systems are limited in their ability to
test caching peripherals. They use an off-the-shelf chip for managing the
SCSI protocol. These chips, while able to transfer data without any
external support, require a processor to direct them through the overhead
portion of each command. Traditional test systems do not have an on-board
processor. This means that, while data transfers can be processed by the
test adapter without host computer intervention, the overhead portion of
each command, such as transferring the command descriptor block and
processing messages status, depends on host computer speeds. Because
caching tests require the execution of several commands in sequence, the
test results depend on the overhead processing of each command, in addition
to the data transfers. If the command overheads depend on the host
computer performance, so will the results of the caching tests. Queuing.
Peripherals that support queuing are now free to re-order their processing
of commands. Queue algorithm verification, like caching, requires the
execution of several commands. However, unlike caching, these commands are
executed in parallel instead of in sequence. Several commands are
submitted to the peripheral at once, and the peripheral is free to
re-order the commands to minimize the total service time for the group of
commands. Verifying queuing algorithms depends on command overheads,
similar to the testing of caching algorithms. Also important is the
management of the test data. Each command should have its own unique data.
Unfortunately, traditional SCSI test systems are limited to a single
on-board buffer, restricting each command to using the same test data.
SCSI buses SCSI buses are evolving into shared resources, connecting
multiple peripherals and host adapter. Less frequent are configurations
with a single peripheral connected to a dedicated host adapter. This has
many implications for verifying peripherals o be installed in these
complex bus configurations. Multiple host adapter. It is necessary to
verify a peripheral's ability to process simultaneously commands from
multiple host adapters. For example, if the peripheral is queuing commands
from two host adapters and a failure occurs, the peripheral must be able to:
(1) suspend all pending commands; (2) reserve itself to the host adapter
that initiated the failing command; (3) process the host adapter's error
recovery commands; (4) wait to be released by the host adapter; (5) resume
processing of the queued commands. Non-dedicated bus. Complex bus
configurations no longer guarantee that a peripheral will be able to
access the SCSI bus when it is ready to transfer data. There may be delays
because another peripheral is already using the bus. As a minimum, this
puts extra strain on the peripheral's dual-port buffer management.
Today's SCSI test systems To fully address the limitations described,
the new, emerging SCSI test systems require features like those shown in
Fig. 2. These features are: (1) a partitionable on-board buffer; (2)
hardware data pattern generation; (3) hardware overlay generation; (4) a
custom SCSI protocol manager; (5) an on-board processor.
Partitioned on-board data buffer A partitioned on-board data buffer
allows the on-board buffer to be divided into several independent
partitions. Each partition can have a different length with its own unique
data pattern, and each can be assigned to a different SCSI command. The
data buffer can be used to verify a peripheral's queuing algorithm. This
verification could involve (1) creating 10 partitions in the on-board
buffer; (2) filling the first partition with 1's, the second with 2's, and
so on; (3) with queuing disabled, writing each partition to a different
area of the peripheral's media; (4) with queuing enabled, submiting 10 read
commands to the peripheral with each command having different partition
assigned; (5) using hardware data compare to verify that each read command
returns the correct data. If a miscompare is detected, and, for example,
1's were expected but 2's were returned, then it can be concluded that the
peripheral has returned the data of another command.
Pattern generator Because the capacities of peripherals are constantly
increasing, no matter how large the test adapter's on-board buffer is,
there will always be a need for much longer non-repeating test data than
the buffer can provide. When random data patterns are sufficient, a
hardware circuit that generates data values on the fly provides a very
cost effective alternative to the on-board buffer. A pattern generator can
be used to generate long, non-repeating data streams with lengths of
multiple gigabytes, or larger. In choosing a test adapter with a pattern
generator, make sure that the pattern generator is re-seeded on every
logical block boundary. This guarantees that the generation of the data
for any block is independent of any other block's data. This is especially
important for test applications. Often a single command is used to write
a test pattern to a sequential set of blocks on the peripheral, and then
multiple commands are used to read the blocks back in random order. If the
pattern generator is not re-seeded at each block boundary, there will be
significant overheads on the reading back of all blocks except the first one
written. This is because it will be necessary to fast-forward the pattern
generator through the values of the preceding blocks in the sequential
write before reading the desired block.
Hardware overlays Hardware can also be used to generate the overlays of
logical block addresses in the test data. The largest logical block
address supported by standard SCSI is 32-bits, so a test adapter's
hardware overlay circuitry should be capable of generating 32-bit values;
any more is probably overkill. The overlay generator should be able to
overlay data originating from either the on-board buffer or the pattern
generator. Figure 3 shows the flow of data during a read operation with
hardware compare enabled: (1) the test data originates from either the
on-board buffer or the pattern generator, as specified by the user; (2)
the overlay generator places its user-specified overlay values at the
specified position of each block; (3) the resulting data is compared
against the data read from the drive; (4) miscompare information is
reported to the user by the control software through the PC backplane.
Custom SCSI protocol manager Not only must peripherals operate correctly
under legal conditions, they must also respond correctly to illegal
conditions. For example, parity errors must be detected, and the proper
corrective action must be taken to recover the data. Off-the-shelf SCSI
protocol chips are not designed to generate illegal conditions. The error
generation features of test adapters that use off-the-shelf protocol chips
must be implemented with logic external to the protocol chip. This has a
negative effect on SCSI bus performance, as the protocol chip is shut down
for the external circuitry to generate the illegal condition and then
re-started to continue from there. The latest SCSI test adapters provide
SCSI protocol managers designed specifically for test applications. Not
only are a wider range of data-transfer rate controls supported (such as
synchronous periods in 10-ns increments instead of 50), but fault
injection is designed in as well. Parity errors can be injected into the
data of a peripheral write command at full bus speeds.
On-board processor An on-board processor is the most important feature
of the latest SCSI test systems. It works with the custom SCSI protocol
manager to provide consistent and controllable command overhead times that
are independent of the host PC. In addition, the on-board processor can
manage not just the execution of a single SCSI command, but entire groups
of commands, without host PC intervention. Beyond the obvious benefits of
better control for the verification of caching and queuing devices, the
on-board processor can be used to verify the peripheral's operation in
complex SCSI bus configurations. While executing a group of commands, the
processor can change the emulation characteristics of the test adapter on
the fly. For example, one command may look to the peripheral as if it was
submitted by a very slow host adapter at SCSI address 1, while another
command may look as if was submitted by a high-performance host adapter at
address 2 (see Fig. 4). These commands may both be executed by the same
test adapter, and, as they execute, the on-board processor will manage the
switching between the two contexts automatically and quickly. This
provides a cost-effective means for testing a device in complex SCSI bus
configurations. It also gives the user a high degree of control.
OVERLINE:
SCSI testing
FIGURE CAPTIONS:
Fig. 1. In this typical SCSI test setup, the peripheral unit under test
is connected directly to the test adapter via the SCSI bus.
Fig. 2. Many features have been added to the test adapter to provide the
capabilities to test the latest SCSI peripherals.
Fig. 3.Test adapter data flow during a read operation, with hardware
compare enabled, originates from either the on-board buffer or the pattern
generator, as specified by the user.
Fig. 4. An on-board processor can change the emulation characteristics of
its test adapter on the fly.
Advertisement
