Patent Application
20080005749
Disk drive unit 100 further includes one or more read/write heads 104 that are coupled to arm 106 that is moved by actuator 108 over the surface of the disk 102 either by translation, rotation or both. A disk controller 130 is included for controlling the read and write operations to and from the drive, for controlling the speed of the servo motor and the motion of actuator 108, and for providing an interface to and from the host device.
Disk controller 130 further includes a processing module 132 and memory module 134. Processing module 132 can be implemented using one or more microprocessors, micro-controllers, digital signal processors, microcomputers, central processing units, field programmable gate arrays, programmable logic devices, state machines, logic circuits, analog circuits, digital circuits, and/or any devices that manipulates signal (analog and/or digital) based on operational instructions that are stored in memory module 134. When processing module 132 is implemented with two or more devices, each device can perform the same steps, processes or functions in order to provide fault tolerance or redundancy. Alternatively, the function, steps and processes performed by processing module 132 can be split between different devices to provide greater computational speed and/or efficiency.
Memory module 134 may be a single memory device or a plurality of memory devices. Such a memory device may be a read-only memory, random access memory, volatile memory, non-volatile memory, static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, cache memory, and/or any device that stores digital information. Note that when the processing module 132 implements one or more of its functions via a state machine, analog circuitry, digital circuitry, and/or logic circuitry, the memory module 134 storing the corresponding operational instructions may be embedded within, or external to, the circuitry comprising the state machine, analog circuitry, digital circuitry, and/or logic circuitry. Further note that, the memory module 134 stores, and the processing module 132 executes, operational instructions that can correspond to one or more of the steps or a process, method and/or function illustrated herein.
Disk controller 130 includes a plurality of modules, in particular, device controllers 105, processing module 132, memory module 134, read/write channel 140, disk formatter 125, servo formatter 120 and host interface 150 that are interconnected via bus 136 and bus 137. Each of these modules can be implemented in hardware, firmware, software or a combination thereof, in accordance with the broad scope of the present invention. While a particular bus architecture is shown in
In one possible embodiment, one or more modules of disk controller 130 are implemented as part of a system on a chip (SoC) integrated circuit. In an embodiment, this SoC integrated circuit includes a digital portion that can include additional modules such as protocol converters, linear block code encoding and decoding modules, etc., and an analog portion that includes device controllers 105 and optionally additional modules, such as a power supply, etc. In a further embodiment, the various functions and features of disk controller 130 are implemented in a plurality of integrated circuit devices that communicate and combine to perform the functionality of disk controller 130.
When the drive unit 100 is manufactured, disk formatter 125 writes a plurality of servo wedges along with a corresponding plurality of servo address marks at equal radial distance along the disk 102. The servo address marks are used by the timing generator for triggering the “start time” for various events employed when accessing the media of the disk 102 through read/write heads 104.
In a possible embodiment, wireless communication device 53 is capable of communicating via a wireless telephone network such as a cellular, personal communications service (PCS), general packet radio service (GPRS), global system for mobile communications (GSM), and integrated digital enhanced network (iDEN) or other wireless communications network capable of sending and receiving telephone calls. Further, wireless communication device 53 is capable of communicating via the Internet to access email, download content, access websites, and provide steaming audio and/or video programming. In this fashion, wireless communication device 53 can place and receive telephone calls, text messages such as emails, short message service (SMS) messages, pages and other data messages that can include attachments such as documents, audio files, video files, images and other graphics.
From certain perspectives, various aspects of the invention are operable to provide for a better and/or optimal allocation of the real-time firmware requirements of a HDD controller using distributed, multiple processors. In some embodiments, three different processors are employed to support an effective implementation of the required processing resources such that the each of them can adequately perform its respective required functions very effectively. By using distributed, multiple processors, none of the processors is so overwhelmed that it is unable to perform its prescribed operations poorly. In addition, because of this distributed, multiple processor implementation, each of the required processing operations is provisioned with sufficient processing resources such that each of the required functions is performed effectively.
Generally speaking, the HDD controller system has three main hard real-time functions that need parallel execution: (1) servo control loop(s); (2) host interface lower-level protocol; and (3) channel interface lower-level protocol. As can be seen when considering prior art systems, prior art controllers either compromised performance, vastly increased firmware complexity, or added large amounts of hardware to achieve acceptable functionality. Beyond these real-time functions are a variety of background firmware operations that must be performed as well. In some embodiments, the servo control loops and the background firmware are assigned to a centralized, general purpose processor. The host and channel interface lower-level protocols are assigned to their own smaller processors to achieve true parallel execution for the real-time requirements of these interfaces.
In some embodiments described herein, a HDD controller (which can be implemented as a single IC if desired) employs a multiple, distributed processor arrangement for a much improved partition of the hard real time requirements of the system. In some embodiments, the HDD controller uses three processors to partition the hard real time requirements of the system.
Typical, prior art controllers utilize one or at most, two, general purpose processors aided by one or two small writable control stores. In various embodiments described herein, a central general purpose processor can be implemented for the servo real-time firmware (e.g., the servo related control loop(s)) and almost all other system firmware, aided by small host and disk protocol processors that are operable to execute their respective hard real-time functions. This multiple, distributed processor arrangement is a much better allocation of processing resources when compared to what is found in the prior art, and each of the various functions required to perform within the HDD system is not in a situation to be short-changed should some of the other functions be operating in such a way as to require a relatively larger amount of processing capability.
The prior art apparatus 500 of
The apparatus 600 includes a HDD controller 660. The HDD controller 660 can be implemented as an IC 659, if desired. The HDD controller 660 includes a processor 662, which can be implemented as a centralized, general purpose type processor in some embodiments, a disk manager module 610, and a host manager module 670.
The processor 662 is dedicated to support and execute instructions associated with a servo control loop, as shown by reference numeral 663. When and if the processor 662 has sufficient available processing resources, it can service “policy” firmware 664 (e.g., as background processes that can be viewed as non-servo firmware).
The host manager module 670 and the disk manager module 610 show their embedded individual protocol processors, namely, the protocol processor 614 within the disk manager module 610 and the protocol processor 672 within the host manager module 670. The protocol processor 614 within the disk manager module 610 can be implemented to support and execute instructions associated with a channel interfacing control loop, as shown by reference numeral 616, which correspond to the channel interface 601. The protocol processor 672 within the host manager module 670 can be implemented to support and execute instructions associated with a host interfacing control loop, as shown by reference numeral 676, which correspond to the host interface 602.
The processor 662 is operable to access each of the protocol processor 614 within the disk manager module 610 and the protocol processor 672 within the host manager module 670 through that respective protocol processor's register and memory space. In some embodiments, the processor 662 is operable to perform direct pipe access of each of the protocol processor 614 within the disk manager module 610 and the protocol processor 672 within the host manager module 670 thereby providing coherency.
As can be seen within this diagram, a distributed approach is made such that each of the various control loops has its own dedicated processor. This way, each of these various control loops will be provisioned with sufficient processing resources, and those processing resources will always be available to service the respective control loop (as each processor is not competing with multiple control loops or trying to service multiple control loops).
Referring the apparatus 700 of the
The host interface 702 is controlled with the host manager module 770 that is operable to move data between the host interface 702 and a buffer 790 through a buffer manager module 767. The disk manager module 712 controls many of the various components that eventually couple to the channel interface 701 and moves data between the channel and the buffer 790 through the buffer manager module 767. The buffer manager module 767 arbitrates access to the shared buffer 790, which can be implemented in the DRAM.
The host manager module 770 also includes a host personality module 776 that is operable to perform and enable host interfacing with various types of hosts via the host interface 702. The host protocol processor 772, implemented within the host manager module 770, is operable to support soft key mapping which allows the host personality module 776 to emulate more than one type of host compatible interface. For example, the soft key mapping employed therein allows the host personality module 776 to interface properly with a first type of host device and to interface properly with a second type of host device, depending on which soft key is employed. This way, a singular piece of hardware can be employed across a wide range of platforms.
A host first-in/first-out (FIFO) buffer 774 is implemented within the host manager module 770 as well, and it interacts with the host personality module 776. The host FIFO 774 interfaces with the buffer manager 767 in the manner as described above, in that, the host manager module 770 is operable to move data between the host interface 702 and the buffer 790 through the buffer manager module 767 via the host personality module 776 and the host FIFO 774.
The disk manager module 712 can also be implemented to include a servo formatter module 731 that is operable to format commands and functions into the appropriate format for execution within the servo control loop. The disk manager module 712 also includes a disk datapath module 736 that is operable to interface with the buffer manage module 767. The disk datapath module 736 is operable to perform modulation encoding/decoding as indicated by ended 737. The error correction code (ECC) 735 is encoded during disk write processes and with an ECC symbol generator that is located in a disk formatter module 734. If desired, the ECC 735 can be decoded in a two step process: (1) syndromes are generated during disk reads in a syndrome generator that is located in the disk formatter module 734 and then (2) the error correction is performed in an on-the-fly ECC computer in the disk datapath module 736. The ended 737 can be viewed as being the reverse-ECC modulation ENDEC, in that, the ended 737 is operable to perform the modulation encoding/decoding on the reverse side of the ECC system from the perspective of the channel through which disk read and write accesses are performed. In doing this, error propagation can hopefully be reduced, if not eliminated completely. The modulation encoding/decoding as indicated by endec2 is employed to encode the ECC (and the endec1 generated redundancy bits) as the reverse ECC encoding of the ECC symbols can be burdensome and cost ineffective from certain points of view.
The disk formatter module 734 that is implemented within the disk manager module 712 is operable to perform the appropriate formatting for information to be written to the disk via a write path and de-formatting of information that is read from the disk via a read path.
The path for writing into the disk from the disk formatter module 735 is shown as first passing through an encoder 716 that performs the modulation encoding, shown as according to endec2. The encoded information is then provided to a parity encoder 717, whose output couples to a write precompensation module 718 that eventually couples to an analog front end (AFE) 731, that is operable to perform any of a variety of analog processing functions including digital to analog conversion, scaling (e.g., gain or attenuation), digital filtering (before converting to continuous time domain), continuous time filtering (after converting to continuous time domain), or other signal processing functions required to comport the signal into a format compatible with the channel interface 701. The AFE 731 also includes a preamp 732 that is often implemented as part of the read head assembly.
The path for reading from the disk is the converse of the write path to the disk. For example, when coming from the channel interface 701, the signal is provided initially to the AFE 731, in which the converse of many of the signal processing operations within the write process is performed. For example, an analog to digital conversion is performed, scaling, and/or filtering, among other signal processing operations.
After passing from the AFE 731 during a read process, the signal passes through a finite impulse response filter (FIR) 728, a Viterbi decoder 727 that is operable to employ the soft output Viterbi algorithm (SOVA) to determine a soft output that is indicative of the reliability of the information within the digital signal. For example, the Viterbi decoder 727 is operable to determine whether the digital signal provided to it is reliable or not. In addition, the Viterbi decoder 727 can be viewed as performing the parity decoding processing in the read path in response to the parity encoding processing (that is performed by the parity encoder 717) in the write path. The output from this Viterbi decoder 727 as provided to a decoder 726 that employs the same code as the encoder 716, namely, the second ECC, shown as endec2. The output from this decoder 726 is provided to the disk formatter module 734.
It is also noted with respect to the embodiment of
Referring the apparatus 800 of the
The disk protocol processor 814 and the host protocol processor 872 are dedicated to executing the hard real-time control functions of their respective interface protocols, namely, with respect to the disk interface via the channel 831 and the preamp interface 801 and the host interface 802. The disk protocol processor 814 and the host protocol processor 872 un-burden the main processor 862 (which can be implemented as a general purpose type processor), allowing the processor 862 to execute servo hard real-time control functions and background operations (e.g., background related firmware related functions). The main processor 862 manages the disk protocol processor 814 and the host protocol processor 872 through direct connections and shared memory communications.
The apparatus 800 includes a HDD controller 860. The HDD controller 860 can be implemented as an IC 859, if desired. The host manager module 870 and a disk manager module 812 show their embedded individual protocol processors, namely, the disk protocol processor 814 within the disk manager module 812 and the host protocol processor 872 within the host manager module 870. To facilitate inter-processor communication, a shared data cache 864 is included in the apparatus 800. Each of the 3 processors can read and write shared data structures (stored in the buffer) to help manage the real-time functions performed by the two protocol processors (disk protocol processor 814 and the host protocol processor 872). The shared data cache 864 provides for hardware-enforced coherency of these shared accesses.
The shared cache 864 is a common multi-processor structure. To provide for coherency of multi-location data structure updates, additional multi-processor communication mechanisms are provided in the system. One such mechanism can be semaphores.
Referring the apparatus 900 of the
The apparatus 900 includes a HDD controller 960 (which can be implemented as an IC 959, if desired). The HDD controller 960 includes a first processor 962, which is dedicated to support and execute instructions associated with a servo control loop, as shown by reference numeral 963. When and if the processor 962 has sufficient available processing resources, it can service “policy” firmware 964 (e.g., as background processes that can be viewed as non-servo firmware).
The HDD controller 960 also includes a second processor 914 and a third processor 972. The second processor 914 is operable to support and execute instructions associated with a channel interfacing control loop, as shown by reference numeral 916, which correspond to the channel interface 901. The third processor 972 is operable to support and execute instructions associated with a host interfacing control loop, as shown by reference numeral 976, which correspond to the host interface 902.
As can be seen within this diagram, a distributed approach is made such that each of the 3 various control loops has its own dedicated processor. This way, each of these 3 control loops is provisioned with sufficient processing resources, and those processing resources will always be available to service the respective control loop (as each processor is not competing with multiple control loops or trying to service multiple control loops).
Referring the method 1000 of the
Referring the method 1100 of the
As can now be understood, by applying a tailored and better amount of processing hardware to perform each of the hard real-time functions of a HDD controller, better overall performance is achieved. By using protocol processors in place of state machines or writable control stores the task of developing firmware for the hard drive is simplified, and system flexibility is increased.
It is noted that the various aspects presented herein can be applied across a very wide range of media storage devices, includes those that employ optical drive controllers.
It is also noted that the methods described within the preceding figures may also be performed within any appropriate system and/or apparatus designs without departing from the scope and spirit of the invention.
In view of the above detailed description of the invention and associated drawings, other modifications and variations will now become apparent. It should also be apparent that such other modifications and variations may be effected without departing from the spirit and scope of the invention.
