Abstract:
A method and apparatus is provided which reduces the equipment and time requirements for hard disk drive performance testing during manufacturing. This invention executes self-contained performance testing code that resides within the drive&#39;s manufacturing firmware, rather than relying on external testers. The invention involves exercising the drive&#39;s enqueue, dequeue, and command execution firmware, as well as the physical process of reading and writing data by simulating the host interface in code. The invention enqueues commands that typify the desired workload, allows a command ordering algorithm to sort the commands for execution, and allows the drive side code to execute the commands just as if an external host interface were attached. The invention is advantageous because the performance testing can be done by only applying power to the drive. The present invention also lends itself to performance tuning that can be done in manufacturing, to reduce drive-to-drive performance variations.

Description:
FIELD OF THE INVENTION  
         [0001]    The present invention relates generally to computer systems, and more specifically to disk drives used for mass storage of data in computer systems.  
         BACKGROUND OF THE INVENTION  
         [0002]    Disk drives are well-known components of computer systems. Advances in disk drive technology have led to substantial increases in storage capacity and faster access times. Along with the increased capacity and speed, customers are also demanding consistency in drive-to-drive performance.  
           [0003]    Original equipment manufacturers typically set specific performance requirements for drives supplied by various vendors in a given drive generation. These performance requirements generally involve a 4% to 40% generation-to-generation performance improvement for each of several specific tests. In addition to meeting these requirements, drive vendors must insure that drive-to-drive variation requirements are also met. Typically, all drives from a single HDD supplier should perform within 5% of the overall supplier&#39;s mean performance. As data densities have typically doubled each generation, the challenge of manufacturing drives that yield similar performance is receiving a great deal of attention.  
           [0004]    In order to meet the 5% drive-to-drive performance variation requirement, vendors can either select very achievable (i.e., low performance threshold) targets and “slow down” drives that exceed these requirements, or implement performance testing and passing criteria for use in the manufacturing process. Typically, generation-to-generation improvement requirements and the goal of being the best-of-breed vendor force disk drive manufacturers to shoot for very challenging performance targets. Therefore, vendors typically do not have much extra performance margin relative to the targets and do not have the luxury of reducing performance of faster drives to lower the mean performance.  
           [0005]    In recent hard disk drive generations, performance tests and corresponding passing criteria have been put in place for use during the manufacturing process. Drives that do not pass the criteria after manufacturing are considered manufacturing fails and count against the overall drive yields. Overall drive manufacturing yields typically range from 40% to 80% depending on the number of heads and disks contained in the disk enclosure. These performance tests insure that the drive variation requirements are met by the overall drive population. The impact of the performance tests on the overall yields vary, but a yield reduction of 5% is typical for a given drive generation.  
           [0006]    One problem with testing performance during the manufacturing process involves the cost and time requirements. This testing procedure requires approximately ten minutes, but there are a limited number of testing slots available at a given time, so the time requirements are even more significant. In addition to the raw time requirements, the equipment required to test drives on a large scale is very costly. Performance requirements are usually set for a workload that is very susceptible to drive variations and involves a specific queue depth. In order to maintain a certain queue depth (usually  16 ), a relatively fast initiator system must be used. Although manufacturing testers supply one initiator system per drive, the testers and testing software typically are not optimized for performance. For example, the test suite is typically executed from a script that may not be precompiled. For this relatively slow initiator system, it is difficult to maintain the desired drive queue depth for many workloads. This makes testing some workloads very difficult. As drive performance continues to improve, this problem becomes more and more severe, thus stressing tester requirements.  
           [0007]    Thus, there is a need for a method and apparatus for testing the performance of disk drives during manufacturing which reduces equipment and time requirements.  
         SUMMARY OF THE INVENTION  
         [0008]    The present invention reduces the equipment and time requirements required for hard disk drive performance testing during manufacturing. This invention executes self-contained performance testing code that resides within the drive&#39;s manufacturing firmware, rather than relying on external testers. The invention involves exercising the drive&#39;s enqueue, dequeue, and command execution-firmware, as well as the physical process of reading and writing data by simulating the host interface in code.  
           [0009]    The invention enqueues commands that typify the desired workload, allows a command ordering algorithm to sort the commands for execution, and allows the drive side code to execute the commands just as if an external host interface were attached. The invention is advantageous because the performance testing can be done by only applying power to the drive. The present invention also lends itself to performance tuning that can be done in manufacturing, to reduce drive-to-drive performance variations.  
           [0010]    In a preferred embodiment, the present invention provides a method for performing in-situ performance testing of a disk drive. The method emulates data transfer operations between the disk drive and an associated computer system via a command simulation routine. The method also generates an in-situ set of read/write commands representative of a typical workload within the disk drive via a command generation routine. The method measures disk drive performance during concurrent execution of the command simulation routine and the command generation routine, and compares the measured disk drive performance results against a predefined set of performance parameters. If the measured disk drive performance results fall within a performance range defined by the predefined set of parameters, the results are logged to the disk drive. Alternatively, if the measured disk drive performance results do not fall within the performance range defined by the predefined set of parameters, operating parameters for the disk drive are tuned. In a preferred embodiment, the operating parameters are tuned by iteratively changing a set of disk drive performance settings and re-simulating the performance of the drive until the performance of the drive falls within a predetermined mean performance interval. Alternatively, the operating parameters of the disk drive may be tuned by de-tuning performance settings of the disk drive, if the results of the performance testing exceed the predetermined mean performance interval.  
           [0011]    The present invention also provides a disk drive having a magnetic disk for storing data, and a disk drive controller/interface processor coupled to the magnetic disk for translating data and commands sent to and from the magnetic disk. The disk drive also provides a memory coupled to the disk drive controller/interface processor. The memory includes self-test firmware which is executed by the disk drive controller/interface processor during the manufacturing process in order to perform in-situ performance testing. The self-test firmware includes a command generation routine for generating an in-situ set of read/write commands representative of a typical workload for the disk drive, and a command simulation routine for emulating data transfer operations between the disk drive and an associated computer system.  
           [0012]    The present invention further provides a computer program product having an in-situ performance testing mechanism which emulates data transfer operations between the disk drive and an associated computer system via a command simulation routine. The program product generates an in-situ set of read/write commands representative of a typical workload within the disk drive via a command generation routine, measures disk drive performance during concurrent execution of the command simulation routine and the command generation routine, then compares the measured disk drive performance results against a predefined set of performance parameters. The computer program product further includes computer-readable signal bearing media bearing the in-situ performance testing mechanism.  
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0013]    [0013]FIG. 1 is a block diagram of the electronics architecture for a typical hard disk drive system in accordance with the present invention.  
         [0014]    [0014]FIG. 2 illustrates a block diagram of a hard disk drive firmware/hardware system, in accordance with the present invention.  
         [0015]    [0015]FIG. 3 is a flow diagram of a command simulation routine in accordance with the present invention.  
         [0016]    [0016]FIG. 4 is a flow diagram of command generation routine in accordance with the present invention.  
     
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0017]    Turning to the Drawings, wherein like numbers denote like parts throughout the several views, FIG. 1 is a block diagram of the electronics architecture for a typical hard disk drive system in accordance with the present invention, shown generally at  100 . Indeed, those skilled in the art will recognize that other alternative embodiments may be used without departing from the scope and spirit of the present invention.  
         [0018]    Drive system  100  includes a disk stack  102  where customer data is magnetically stored and retrieved. Disk stack  102  is a circular-shaped data-storage medium that stores data on the flat surface of the platter as magnetic patterns in a metal coating. An actuator  104  is the internal mechanism that moves a read/write head to the proper position on the disk stack  102  to read/write customer data. Actuator  104  typically consists of a rotary voice coil and the head mounting arms. One end of each head mounting arm attaches to the rotor with the read/write heads attached at the opposite end of each arm. As current is applied to the rotor from Voice Coil Motor (VCM) driver  105 , the actuator rotates, positioning the read/write heads over the desired cylinder on the media.  
         [0019]    Actuator  104  is coupled to a read/write data channel  108  via arm electronics  106 . Arm electronics  106  drive the write heads on actuator  104  with the proper write current, and amplify the read signal obtained by the read heads. Read/write data channel  108  provides a conversion of the analog signals provided by arm electronics  106  to a digital data stream and vice-versa. Read/write data channel  108  is coupled to a controller/processor  110 . Controller/processor  110  is the chip or circuit that translates computer data and commands into a form suitable for use by the hard drive and vice-versa. Controller/processor  110  includes a hard disk controller  113 , which controls the general operation of the disk drive.  
         [0020]    Controller/processor  110  also includes an interface processor  112  which executes firmware for managing the hardware components to provide hard disk drive functions and interprets requests from an initiator (e.g., computer system) and controls the handling of these requests. Interface processor  112  executes special self-test performance testing firmware (an object of the present invention) during the manufacturing process to analyze and potentially tune the disk drive&#39;s performance characteristics. An initiator (e.g., computer system), not shown, is coupled to controller/processor  110  via host interface  111 . A flash memory  130  coupled to controller/processor  110  contains interface processor instructions executed by the interface processor  112 . In the case of the present invention, the self-test performance testing firmware is stored in memory (e.g., flash memory  130 ). A data buffer (DRAM)  132  coupled to controller/processor  110  contains variables and tables used by the controller/processor.  
         [0021]    Spindle  116  is a rotating hub structure to which disk stack  102  is attached. Spindle motor  118  is the electro-mechanical part of the disk drive that rotates disk stack  102  via spindle  116 . Spindle motor driver  120  is coupled to spindle motor  118  for driving its operation. Both spindle motor driver  120  and voice coil motor driver  105  are coupled to a VCM and Motor Predriver  122 , which in turn is coupled to controller/processor  110 . VCM and Motor Predriver  112  powers both spindle motor driver  120  and voice coil motor driver  105 , and provides spindle motor commutation.  
         [0022]    [0022]FIG. 2 illustrates a block diagram of a hard disk drive firmware/hardware system, in accordance with the present invention, shown generally at  200 . Disk system  200  includes the controller/processor hardware  110  previously illustrated in FIG. 1, along with associated firmware  202  residing in flash memory  130 . Controller/processor  110  is coupled to the outside world (i.e., a computer system/initiator)  204  via host interface  111 .  
         [0023]    Controller/processor  110  includes host interface logic  206  for managing communication between the controller/processor  110  and the computer system  204  via host interface  111 . Controller/processor  110  further includes a segment &amp; memory manager  208  for managing customer DRAM and maintaining the cache table. Controller/processor  110  also includes a drive controller  210  and servo assist hardware  212  which is responsible for actuator movements and managing motor control.  
         [0024]    Included within system firmware  202  is host interface firmware  214 . Typically, host interface firmware  214  is responsible for managing communication between the hard disk drive and the computer system (initiator)  204 . Host interface firmware  214  also provides support for interface functions, and supports command reception and notification to the queue manager. Queue manager firmware  216  is responsible for management of command queue  218 , more specifically enqueue, reordering, dequeue, abort handling, and other miscellaneous handling functions.  
         [0025]    Command tasking and execution firmware  220  is responsible for scheduling what task the code does next. Segment manager firmware  222  is responsible for managing customer DRAM, interfaces with segment &amp; memory manager hardware  208 , and maintains cache tables. Servo code firmware  224  is treated as a black box to the interface processor code and is responsible for actuator movements and managing motor control. File side code firmware  226  is responsible for managing back-end hardware (i.e., interfaces to the hard disk drive logic and channel), manages read/write operations between the media and the buffer, and provides special command support for manufacturing, channel integration, and failure analysis. Base code firmware  228 , the largest area of the code, is responsible for a number of responsibilities, including: memory mapping, reserved area layout and usage, power-on sequence (i.e., boot-up), command handlers, idle function, and error logging.  
         [0026]    Self-test performance testing firmware  230 , an object of the present invention, is used during the manufacturing process to analyze and potentially tune the disk drive&#39;s performance characteristics in-situ. More simply, self-test performance testing firmware  230  enables the disk drive to execute entirely self-contained performance testing procedures without the need for any external testers/initiators. This self-test performance testing firmware  230  is typically replaced by the released firmware level at the end of the manufacturing process. However, there may be occasion to utilize self-test performance testing firmware after the manufacturing process as well.  
         [0027]    Self-test firmware  230  exercises the disk drive&#39;s enqueue, dequeue, and command execution firmware  220 , as well as exercising the physical process of reading and writing data by simulating the normal function of host interface logic  206 /host interface firmware  214  in code. Self-test firmware  230  includes two special routines, a command generation routine  229  and a command simulation routine  231 . Command simulation routine  231  includes a special set of in-situ host interaction emulation functions  231  to simulate data transfers to and from a host system. Command simulation routine  231  essentially replaces host interface firmware  214  during this manufacturing self-test procedure. Command generation routine  229  generates commands that are representative of the desired workload, then queue manager  216  places the commands in the disk drive&#39;s command queue  218 . The commands are then sorted by a Rotational Position Ordering (RPO) algorithm, and executed normally. To insure an accurate performance representation, the normal code execution paths are used wherever possible. Host interactions (data transfers, command status, etc.) are handled with special functions specific to the invention.  
         [0028]    Workload information and performance criteria are stored in self-test firmware  230 . The disk drive runs the performance workload (e.g., 1 block random reads in a 2 gigabyte partition at queue depth  16 ) and tracks the performance throughout the test. In a preferred embodiment of the present invention, the performance metric is operations-per-second, but other performance metrics may be utilized, and still remain within the scope and spirit of the present invention.  
         [0029]    Self-test firmware  230  then compares the performance metric against the predefined values contained within the self-test firmware to determine if the performance requirements are met. If the requirements are met, the disk drive logs this information and these logs can be read in a later stage of the manufacturing process that involves an initiator system.  
         [0030]    At the conclusion of the performance test, self-test firmware  230  may also select from a predefined list of alternate performance parameters if the performance criteria is not met. In this instance, self-test firmware  230  re-initiates the self-test performance routine for each set of parameters until either the requirements are met, or the list is exhausted.  
         [0031]    Thus, the present invention uses special routines to replace interactions with an initiator (e.g., computer system) and data transfers across the drive&#39;s host interface. These routines simulate the host interface and the behavior of the initiator system as closely as possible. Aside from these special routines, all code execution paths remain the same.  
         [0032]    At this point, it is important to note that while the present invention has been and will continue to be described in the context of firmware present within a fully functional disk drive system, those skilled in the art will appreciate that the present invention is capable of being distributed as a program product in a variety of forms, and the present invention applies equally regardless of the particular type of signal bearing media used to actually carry out the distribution. Examples of suitable signal bearing media include, but are not limited to: recordable type media such as floppy disks, CD ROM, memory cards, chips, modules, sticks, and transmission type media such as digital and analog communications links.  
         [0033]    As described previously, two main routines are required to implement this invention: command generation routine  229  (shown in detail in FIG. 3), and command simulation routine  231  (shown in detail in FIG. 4). Both command generation routine  229  and command simulation routine  231  are initiated at the start of the performance simulation and are continuously run in separate threads of execution.  
         [0034]    Once the special firmware that contains the invention (i.e., self-test firmware  230 ) is loaded onto the drive, both command generation routine  229  and command simulation routine  231  may be initialized on either the next power cycle or immediately after the download. Command generation routine  229  generates a read and/or write command that otherwise would have been received from a host system. These commands are used to simulate workloads that are deemed to exhibit the highest drive-to-drive variation. These commands will be enqueued to the RPO command scheduling routine. RPO will operate normally to select the optimal command from the list of outstanding queued commands. Once RPO selects a command for execution, a seek to the target location is performed by the drive-side firmware. While this seek is being performed, command simulation routine  231  simulates a host transfer.  
         [0035]    Command generation routine  229  generates commands that are representative of the desired workload and places them in the disk drive&#39;s command queue  218 . Command generation routine  229  is responsible for maintaining the desired queue depth, or number of outstanding commands, and calculating the overall execution time during the test. This routine determines if the drive passed or failed the test by comparing the actual results with predefined values. If the drive fails the test, command generation routine  229  can change drive parameters and re-start the testing process. All test results are logged.  
         [0036]    Command simulation routine  231  is a simple routine that simulates host transfers by modifying the hard disk controller&#39;s buffer pointer registers. This serves to replace the host-side data transfers. FIG. 3 is a flow diagram of command simulation routine  231 , shown generally at  300 . At block  302 , the command simulation routine is initiated. At block  304 , the routine waits for a command to be selected for execution. After a command has been selected for execution, a seek is initiated within the disk drive to a target sector, as shown at block  306 . At block  308 , it is determined whether the selected command is a read command or a write command.  
         [0037]    If the command is a read command, the command simulation routine  231  sets the host buffer pointer registers such that the drive-side firmware sees buffer space available for the disk transfer, as shown at block  310 . The routine continues to modify the buffer pointer registers during the disk transfer, such that the drive-side code completes the disk transfer in a single operation, as shown at block  312 . For read operations, the actual read data is discarded. Since the data transfer across the host interface represents a relatively insignificant amount of time compared to the execution time of the disk operation, it can be ignored. However, if more precision is required, delays can be added in both command simulation routine  231  and command generation routine  229  to more accurately model the host interface behavior. Once the disk transfer is complete, this routine shall free the queue slot for a new command, as shown at block  314 . After the queue slot has been freed, control transfers back to block  304 , where the routine waits for a new command to be selected for execution, as shown at block  315 .  
         [0038]    If the command is a write command, the command simulation routine  231  sets the host buffer pointer registers such that a full cache segment is simulated, as shown at block  316 . During the disk transfer, the routine continues to modify the host buffer pointers to simulate the operation of the host interface data transfer, as shown at block  318 . At the completion of the disk transfer, the routine frees the command&#39;s queue slot for a new command, as shown at block  314 . After the queue slot has been freed, control transfers back to block  304 , where the routine waits for a new command to be selected for execution.  
         [0039]    [0039]FIG. 4 is a flow diagram of command simulation routine  229 , shown generally at  400 . The command simulation routine  229  is initiated at block  402 . At block  404 , a test timer is initiated, and a command counter is initialized to zero. At block  406 , it is determined if the current queue depth is equal to the target queue depth. Control passes to block  408  only when the current queue depth is not equal to the target queue depth. At block  408 , it is determined if the desired number of commands have been executed, by comparing the command counter against a variable containing the desired number of commands. If the command counter has not reached the desired number of commands, control passes to block  410  where a new command is generated that correlates with the simulated workload. At block  412 , this new command is issued to the RPO scheduling routine, and the command counter is incremented at block  414 . After the command counter is incremented, control passes back to block  406 , where it is once again determined if the current queue depth is equal to the target queue depth.  
         [0040]    If, at block  408 , the command counter indicates that the desired number of commands have been executed, control passes to block  416 , where the test timer is stopped. The routine then calculates a performance metric (e.g., the number of I/O operations per second). At block  418 , the performance results are logged. The current servo parameter values which generated this performance metric are also logged.  
         [0041]    At block  420 , it is determined if the test results indicate that the drive meets performance requirements. If not, control passes to block  422  where it is determined if there are any other servo parameter values that can be applied to the drive. If so, control passes to block  424 , where the servo parameters are set to the new values, and control then passes back to block  404 , where the test timer and command counter are re-initiated for the start of a new test. If all possible servo parameters have been exhausted, control passes to block  426 , where a log entry is written indicating that the drive has failed the performance test, and the command generation routine is terminated at block  428 .  
         [0042]    If, at block  420 , it is determined that the test results indicate that the drive meets performance requirements, control passes to block  430 , where the successful result for the performance test is logged, and the command generation routine is then terminated at block  428 .  
         [0043]    Additional modifications may be made to the illustrated embodiments without departing from the spirit or scope of the invention. Therefore, the invention lies in the claims hereinafter appended.