Precautionary measures for data storage device environmental conditions

Description

BACKGROUND

Data Storage Devices (DSDs) are often used to record data onto or to reproduce data from a storage media. One type of storage media includes a rotating magnetic disk where a magnetic head of the DSD can read and write data in tracks on a surface of the disk, such as in a Hard Disk Drive (HDD). Another type of storage media can include a solid-state memory where cells are charged to store data.

Oftentimes an environmental condition of a DSD, such as vibration, mechanical shock, temperature, humidity, or air pressure, can cause problems when writing data to or reading data from a storage medium of a DSD. Such errors caused by environmental conditions can reduce the reliability and performance of the DSD. With respect to performance, a DSD may repeatedly attempt to perform a failed write command before aborting the write command. This type of error recovery may waste resources if an environmental condition causing the write error persists.

In addition, certain storage media may be particularly susceptible to errors caused by environmental conditions. For example, a disk using Shingled Magnetic Recording (SMR) may be more susceptible to errors caused by vibration, mechanical shock, or changes in temperature, humidity, or air pressure. SMR has been introduced as a way of increasing the amount of data that can be stored in a given area on a disk by overlapping tracks to increase the number of Tracks Per Inch (TPI). Although a higher number of TPI is ordinarily possible with SMR, the higher track density can lead to a greater vulnerability to errors caused by environmental conditions.

In addition, the number of write retries allowed in one location is often limited in SMR DSDs due to the greater effect of Adjacent Track Interference (ATI) and Wide Area Track Erasure (WATER) on SMR media. Write retries are therefore often made in different locations on an SMR media, which can be costly in terms of space on the media. Multiple write retries spread across the media can also increase the need for maintenance operations such as garbage collection to reclaim the portions of the media used for the failed write retries.

BRIEF DESCRIPTION OF THE DRAWINGS

The features and advantages of the embodiments of the present disclosure will become more apparent from the detailed description set forth below when taken in conjunction with the drawings. The drawings and the associated descriptions are provided to illustrate embodiments of the disclosure and not to limit the scope of what is claimed.

FIG. 1 is a block diagram depicting a system including Data Storage Devices (DSDs) according to an embodiment.

FIG. 2 is a block diagram depicting a DSD of FIG. 1 according to an embodiment.

FIG. 3 is a diagram illustrating a write unsafe threshold for a track according to an embodiment.

FIG. 4A is a flowchart for a write safe process according to an embodiment.

FIG. 4B is a flow chart for a test write process according to an embodiment.

FIG. 4C is a flow chart for a write redirection process according to an embodiment.

FIG. 4D is a flow chart for a delay process according to an embodiment.

FIG. 4E is a flowchart for an environmental change process according to an embodiment.

FIG. 5A is a flowchart for a write safe process performed by a DSD according to an embodiment.

FIG. 5B is a flowchart for a test write process performed by a DSD according to an embodiment.

DETAILED DESCRIPTION

In the following detailed description, numerous specific details are set forth to provide a full understanding of the present disclosure. It will be apparent, however, to one of ordinary skill in the art that the various embodiments disclosed may be practiced without some of these specific details. In other instances, well-known structures and techniques have not been shown in detail to avoid unnecessarily obscuring the various embodiments.

System Overview

FIG. 1 shows system 100 according to an embodiment which includes host 101, input device 102, display device 104 and Data Storage Devices (DSDs) 105, 106, and 107. System 100 can be, for example, a data storage center or other computer system that uses multiple DSDs. In addition, system 100 may be a stand-alone system or part of a network, such as network 50, which can, for example, be a local or wide area network, or the Internet. As shown in FIG. 1, the example embodiment of FIG. 1 also includes fan 103 and temperature sensor 109 connected to host 101 via network 50. Host 101 can control an environmental condition (e.g., temperature) of DSDs 105, 106, and 107 with the use of fan 103 and temperature sensor 109.

Those of ordinary skill in the art will appreciate that system 100 can include more or less than those elements shown in FIG. 1 and that the disclosed processes can be implemented in other environments. For example, other embodiments may only include one DSD.

In the example of FIG. 1, DSDs 105 and 106 are grouped together in one location, such as a storage rack, and DSD 107 is in a different location, such as in a different storage rack. In other embodiments, DSDs 105, 106, and 107 may be in different locations.

Input device 102 can be a keyboard, scroll wheel, or pointing device allowing a user of system 100 to enter information and commands to system 100, or to allow a user to manipulate objects displayed on display device 104. In other embodiments, input device 102 and display device 104 can be combined into a single component, such as a touch-screen that displays objects and receives user input.

In the embodiment of FIG. 1, host 101 includes Central Processing Unit (CPU) 108 which can be implemented using one or more processors for executing instructions including a microcontroller, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), hard-wired logic, analog circuitry and/or a combination thereof. A processor of host 101 as referenced hereinafter can be one or more of the foregoing processors or another processor configured to perform functions described herein. CPU 108 interfaces with host bus 112. Also interfacing with host bus 112 are Random Access Memory (RAM) 110, input interface 115 for input device 102, display interface 116 for display device 104, Read Only Memory (ROM) 118, network interface 111, and DSD interface 119 for DSDs 105, 106, and 107.

RAM 110 is a volatile memory of host 101 that interfaces with host bus 112 to provide information stored in RAM 110 to CPU 108 during execution of instructions in software programs such as DSD driver 10 or application 12. More specifically, CPU 108 first loads computer-executable instructions from a DSD into a region of RAM 110. CPU 108 can then execute the stored process instructions from RAM 110. Data to be stored in or retrieved from DSDs 105, 106, and 107 can also be stored in RAM 110 so that the data can be accessed by CPU 108 during execution of software programs to the extent that such software programs have a need to access and/or modify the data.

As shown in FIG. 1, RAM 110 can be configured to store DSD driver 10 and application 12. DSD driver 10 provides a software interface for DSDs 105, 106, and 107 on host 101, and can be used by host 101 to perform certain processes discussed below. Application 12 can provide a software interface for controlling fan 103 or monitoring a temperature input provided by temperature sensor 109.

DSD interface 119 is configured to interface host 101 with DSDs 105, 106, and 107, and can interface according to a Serial Advanced Technology Attachment (SATA) standard. In other embodiments, DSD interface 119 can interface with the DSDs using other standards such as, for example, PCI express (PCIe) or Serial Attached SCSI (SAS).

Each of DSDs 105, 106, and 107 are shown in FIG. 1 as storing DSD firmware 18 and a servo history (i.e., servo histories 26, 27, and 28). As discussed in more detail below, DSD firmware 18 can be used to control operation of the DSDs and to perform some of the safe write processes described below.

In some implementations, servo histories 26, 27, and 28 can be used to obtain environmental information about an environmental condition. Each of DSDs 105, 106, and 107 include a servo system (e.g., servo system 121 in FIG. 2) for controlling the positioning of a head (e.g., head 136 in FIG. 2) over a disk (e.g., disk 200 in FIG. 2). Servo histories 26, 27, and 28 can include a record for their respective DSD of a number of times the head was outside of one or more write unsafe thresholds during a predetermined period of time or an amount of time since the head was outside of one or more write unsafe thresholds. This information can indicate an environmental condition such as vibration or mechanical shock or a severity of an environmental condition. Examples of write unsafe thresholds are explained in more detail below with reference to FIG. 3.

FIG. 2 depicts a block diagram of DSD 106 according to an embodiment where DSD 106 includes Non-Volatile Memory (NVM) in the form of rotating magnetic disk 200 and solid-state memory 128. In this regard, DSD 106 can be considered a Solid-State Hybrid Drive (SSHD) since it includes both solid-state and disk media. In other embodiments, each of disk 200 or solid-state memory 128 may be replaced by multiple Hard Disk Drives (HDDs) or multiple Solid-State Drives (SSDs), respectively, so that DSD 106 includes pools of HDDs and/or SSDs. In addition, DSD 106 in other embodiments can include different types of recording media or may only include solid-state memory 128 or disk 200.

DSD 106 includes controller 120 which includes circuitry such as one or more processors for executing instructions and can include a microcontroller, a DSP, an ASIC, an FPGA, hard-wired logic, analog circuitry and/or a combination thereof. In one implementation, controller 120 can include a system on a chip (SoC).

Host interface 126 is configured to interface DSD 106 with host 101 and may interface according to a standard such as, for example, PCIe, SATA, or SAS. As will be appreciated by those of ordinary skill in the art, host interface 126 can be included as part of controller 120. Although FIGS. 1 and 2 depict the co-location of host 101 and DSD 106, in other embodiments the two need not be physically co-located. In such embodiments, DSD 106 may be located remotely from host 101 and connected to host 101 via a network interface.

In the example of FIG. 2, disk 200 is rotated by a spindle motor (not shown) and head 136 is positioned to read and write data from the surface of disk 200. In more detail, head 136 is connected to the distal end of actuator 130 which is rotated by Voice Coil Motor (VCM) 132 to position head 136 over disk 200.

As shown in FIG. 2, disk 200 includes a number of radially spaced, concentric tracks 202 for storing data. In some implementations, tracks 202 may be written using Shingled Magnetic Recording (SMR) such that tracks 202 overlap. As noted above, such overlapping tracks can create a greater vulnerability to write errors caused by environmental conditions and can make write retries more costly in terms of space on disk 200 and performance of DSD 106. In other implementations, tracks 202 may not overlap or disk 200 may include both overlapping and non-overlapping tracks 202.

Servo system 121 controls the rotation of disk 200 with SM control signal 31 and controls the position of head 136 using VCM control signal 30. In more detail, FIG. 3 illustrates an example of a track 202 on disk 200 that includes servo wedges 208 spaced every five sectors as indicated by the servo wedge sectors with “SW” and user data sectors indicated with a “D.” Each servo wedge may include servo information that can be read from disk 200 by head 136 to determine the position of head 136 over disk 200. For example, each servo wedge may include a pattern of alternating magnetic transitions (servo burst), which may indicate a particular wedge number on disk 200.

FIG. 3 also depicts write unsafe thresholds 210 and 212 with dashed lines that are a predetermined distance from the center of track 202. In other embodiments, a different number of write unsafe thresholds can be used.

Write unsafe thresholds 210 and 212 can provide different margins of deviation from the center of track 202 when writing data. For example, if head 136 travels outside of write unsafe thresholds 212 while writing data, head 136 will stop writing data and treat the write as a write error. Such deviation from track 202 may occur, for example, during a vibration condition of DSD 106 (e.g., when a fan of host 101 is running) or during a mechanical shock event of DSD 106 (e.g., when system 100 is bumped).

Write unsafe thresholds 210, on the other hand, may be used as a warning that an environmental condition is close to causing a write error. To reduce future write errors, DSD 106 may use write unsafe thresholds 210 to predict a future write error and/or trigger a corrective action to reposition head 136 toward the center of track 202. In addition, write unsafe thresholds 210 and 212 may be dynamic in that they can change based on the detection of different environmental conditions. For example, the detection of a vibration condition from a sensor (e.g., sensor 122 in FIG. 2) may call for write unsafe thresholds 210 and 212 to move closer toward the center of track 202.

Servo system 121 can record in servo history 27 a number of times head 136 travels outside of write unsafe thresholds 210 and/or 212 during a predetermined period of time or an amount of time since head 136 was outside of write unsafe thresholds 210 and/or 212. Controller 120 can then use servo history 27 as environmental information about an environmental condition of DSD 106 such as a vibration or mechanical shock condition.

Returning to FIG. 2, disk 200 includes reserved area 204 for writing test data in accordance with a precautionary measure. In one embodiment, host 101 may send a test write command to write test data in reserved area 204 before sending a write command to determine if it is safe to write data on disk 200. An example of a test write process is discussed in more detail below with reference to FIG. 4B. In other embodiments, disk 200 may include multiple reserved areas for writing test data or reserved area 204 may be located in a different portion of disk 200 than that shown in FIG. 2. Reserved area 204 may also include a guard band to reduce the likelihood of writing in reserved area 204 having an effect on data stored near reserved area 204.

In the example of FIG. 2, DSD 106 also includes volatile memory 140. Volatile memory 140 can include, for example, a Dynamic Random Access Memory (DRAM) which can be used by DSD 106 to temporarily store data. Data stored in volatile memory 140 can include data read from NVM such as disk 200 or solid-state memory 128, data to be written to NVM, instructions loaded from DSD firmware 18 for execution by controller 120, and/or data used in executing DSD firmware 18.

As shown in FIG. 2, DSD 106 also includes sensor 122 for obtaining environmental information about an environmental condition of DSD 106. Sensor 122 can include one or more environmental sensors such as, for example, a mechanical shock sensor, a vibration sensor, an accelerometer (e.g., XYZ or YPR accelerometer), a temperature sensor, a humidity sensor, or an air pressure sensor. In addition, one type of sensor can be used to indicate multiple environmental conditions. For example, an accelerometer can be used to indicate both vibration and mechanical shock conditions or an air pressure sensor can be used to indicate changes in altitude and changes in air pressure.

In operation, host interface 126 receives host read and write commands from host 101 via host interface 126 for reading data from and writing data to NVM. In response to a write command from host 101, controller 120 may buffer the data to be written for the write command in volatile memory 140.

For data to be written on disk 200, a read/write channel (not shown) of controller 120 may encode the buffered data into write signal 32 which is provided to head 136 for magnetically writing data to a corresponding disk surface. Servo system 121 can provide VCM control signal 30 to VCM 132 to position head 136 over a particular track 202 for writing the data.

In response to a read command for data stored on disk 200, servo system 121 positions head 136 over a particular track 202. Controller 120 controls head 136 to magnetically read data stored in the track and to send the read data as read signal 32. A read/write channel of controller 120 can then decode and buffer the data into volatile memory 140 for transmission to host 101 via host interface 126.

For data to be stored in solid-state memory 128, controller 120 receives data from host interface 126 and may buffer the data in volatile memory 140. In one implementation, the data is then encoded into charge values for charging cells (not shown) of solid-state memory 128 to store the data.

In response to a read command for data stored in solid-state memory 128, controller 120 in one implementation reads current values for cells in solid-state memory 128 and decodes the current values into data that can be transferred to host 101 via host interface 126.

Host-Side Write Safe Examples

FIG. 4A is a flowchart for a write safe process that can be performed by CPU 108 of host 101 executing DSD driver 10 according to an embodiment. In other embodiments, the process of FIG. 4A may be performed by executing a file system of host 101, such as a file system for implementing SMR. In some embodiments, the process of FIG. 4A can be performed in preparation for sending a write command to one or more DSDs. In addition, the process of FIG. 4A can be performed periodically by host 101 or based upon an activation of one or more DSDs, a performance of one or more DSDs, or an indication of an error in storing data in one or more DSDs.

In block 402, CPU 108 optionally activates at least one DSD (e.g., DSD 106), monitors a performance of at least one DSD, or receives an indication of an error in storing data to a memory of at least one DSD. For example, the process of FIG. 4A can be initiated upon the startup of a DSD to check if there is an environmental condition that may make it unsafe to write data to the DSD. In another implementation, host 101 monitors a performance of a DSD in performing write commands to determine if it is taking too long to perform the write commands. In another implementation, the process of FIG. 4A is initiated after receiving an indication of a write error for a failed attempt to store data in a memory of a DSD. In other embodiments, block 402 may be omitted such that the process of FIG. 4A is initiated based on another indication such as a temperature read from temperature sensor 109, after a predetermined period of time, or after sending a certain number of write commands to a DSD.

In block 404, CPU 108 sends a request via DSD interface 119 to the at least one DSD to request environmental information indicating a current environmental condition. In the embodiment of FIG. 4A, CPU 108 sends the request in preparation for sending a write command. The request can include or form part of a Vendor Specific Command (VSC) to query the at least one DSD whether it is safe to write data to a memory (e.g., disk 200) of the at least one DSD.

In block 406, CPU 108 receives real-time environmental information from the at least one DSD via DSD interface 119. The environmental information can, for example, include a binary value indicating a certain environmental condition or the environmental information may include a value obtained from sensor 122 or servo system 121. The environmental information may include several different values indicating different types of environmental conditions such as acceleration values and temperature values.

In block 408, CPU 108 determines whether the environmental information received in block 406 is within a threshold. For example, CPU 108 may compare the received environmental information to high and low thresholds indicating an environmental condition such as a temperature, mechanical shock, acceleration, humidity, or air pressure condition. DSD 106 may have predetermined operating ranges for conditions such as temperature, humidity, and air pressure that can be used to define upper and lower thresholds. In some embodiments, the environmental information can be compared to different types of thresholds indicating different types of environmental conditions, such as both temperature and humidity conditions.

In some implementations, CPU 108 may assign a write safety level to the at least one DSD based on the comparison of the environmental information to a threshold. The write safety level corresponds to a relative likelihood of encountering an error when storing data due to an environmental condition. For example, environmental information received from DSD 106 in block 406 (e.g., a magnitude from an accelerometer) may be outside of a warning threshold but still within a critical threshold. In such a case, CPU 108 can assign a warning level to DSD 106 such that some but not all future write commands may be redirected away from DSD 106 until the environmental condition improves.

The warning level or received environmental information can also be used for troubleshooting or indicating an environmental condition to a user of host 101 through a user interface. In one example, host 101 may request environmental information from multiple DSDs located throughout a room to help identify a source causing an environmental condition.

With reference to the process of FIG. 4A, CPU 108 sends a write command to the at least one DSD in block 410 if the environmental information is within the threshold. On the other hand, if the environmental information is not within the threshold, the process continues to block 412 where CPU 108 performs a precautionary measure.

FIGS. 4B to 4E provide examples of different precautionary measures that can be performed by CPU 108 executing DSD driver 10 or a particular file system according to various embodiments. In some implementations, the precautionary measures of FIGS. 4B to 4E can be combined and performed in different orders until it is determined that it is safe to send a write command to the at least one DSD.

FIG. 4B is a flow chart for a test write process that can be performed by CPU 108 as a precautionary measure according to an embodiment. CPU 108 may send a test write command to one or more DSDs to check if test data can be successfully written to the one or more DSDs.

In block 414, CPU 108 sends a test write command via DSD interface 119 to at least one DSD. The test write command can include test data to be written in a reserved area of a memory such as reserved area 204 on disk 200. The test write command may also indicate a length of time for performing the test write command. Reserved area 204 can be arranged so as to allow DSD 106 to continuously write test data for a predetermined period of time. The test data can later be overwritten with other test data for performing a new test write command.

In one implementation, reserved area 204 can include tracks at a different track pitch than tracks located elsewhere on the disk. For example, reserved area 204 can include tracks that are more closely spaced than other areas of disk 200 so that an environmental condition is more likely to affect the writing of the test data than data written elsewhere on disk 200.

In block 416, CPU 108 receives an indication via DSD interface 119 from the at least one DSD of whether the test data was successfully written in reserved area 204. If it is determined in block 418 that the test data was successfully written, CPU 108 sends a write command to the at least one DSD in block 420 since the indication received in block 416 indicates that it is safe to write data.

If it is determined in block 418 that the test data was not successfully written, CPU 108 performs an additional precautionary measure such as repeating the process of FIG. 4B or performing the precautionary measures of FIG. 4C, 4D, or 4E discussed below.

FIG. 4C is a flow chart for a write redirection process that can be performed as a precautionary measure by CPU 108 according to an embodiment. In block 424, CPU 108 sends an additional request for environmental information to a second DSD via DSD interface 119. For example, CPU 108 may have already performed the process of FIG. 4A with DSD 106 and determined that the environmental information received from DSD 106 was not within the threshold. As a precautionary measure, CPU 108 may consider sending a write command to DSD 107 instead of to DSD 106 since DSD 107 is in a different rack or location than DSD 106.

In block 426, CPU 108 receives environmental information from the second DSD (e.g., DSD 107) via DSD interface 119 indicating an environmental condition of DSD 107. In block 428, CPU 108 determines whether the environmental information is within a threshold. If so, CPU 108 redirects a write command from the first DSD to the second DSD in block 430. If the environmental information is not within the threshold, the process proceeds to block 432 where CPU 108 performs an additional precautionary measure such as repeating the process of FIG. 4C with a different DSD or performing a precautionary measure of FIG. 4B, 4D, or 4E.

FIG. 4D is a flow chart for a delay process performed as a precautionary measure by CPU 108 according to an embodiment. In block 434, CPU 108 delays sending a write command and sends a new request for updated environmental information to the at least one DSD in block 436. The delay process of FIG. 4D can be particularly effective for more transient environmental conditions such as a temporary vibration or mechanical shock condition.

In block 438, CPU 108 receives updated environmental information from the at least one DSD via DSD interface 119. In block 440, CPU 108 determines whether the updated environmental information is within the threshold. If so, CPU 108 sends the write command to the at least one DSD in block 442. If not, CPU 108 performs an additional precautionary measure in block 444. The additional precautionary measure can include repeating the process of FIG. 4D or performing any of the precautionary measures of FIG. 4B, 4C, or 4E.

FIG. 4E is a flowchart for an environmental change process performed as a precautionary measure by CPU 108 according to an embodiment. In block 446, CPU 108 causes a change in the environmental condition of the at least one DSD. This may be performed, for example, by CPU 108 executing application 12 to turn on fan 103 via network 50 to change a temperature or humidity of the environment of DSDs 105 and 106. Other changes caused by CPU 108 may include changing a temperature set point for a room housing the DSDs or turning on or off a fan for a particular rack of DSDs. In one example, CPU 108 may mute speakers that may cause a vibration of the DSD.

In block 448, CPU 108 sends a request for updated environmental information via DSD interface 119 to the at least one DSD. CPU 108 receives the updated environmental information via DSD interface 119 in block 450.

In block 452, CPU 108 determines whether the updated environmental information is within the threshold. If so, CPU 108 sends the write command to the at least one DSD in block 454. Otherwise, CPU 108 performs an additional precautionary measure in block 456. The additional precautionary measure can include repeating the process of FIG. 4E or performing any of the precautionary measures of FIGS. 4B to 4D.

DSD-Side Write Safe Examples

FIG. 5A is a flowchart for the DSD-side of a write safe process according to an embodiment. In one embodiment, the process of FIG. 5A can be performed by controller 120 of DSD 106 by executing DSD firmware 18.

In block 602, DSD 106 receives a request from host 101 via host interface 126 requesting environmental information. Host 101 may request the environmental information to determine a current environmental condition of DSD 106 in preparation for sending a write command to DSD 106.

In block 604, controller 120 obtains real-time environmental information, which can include obtaining a value from sensor 122, servo history 27, or another indication from servo system 121. In block 606, controller 120 sends the requested environmental information to host 101 via host interface 126.

FIG. 5B is a flowchart for a test write process performed by a DSD according to an embodiment. In one embodiment, the process of FIG. 5B can be performed by controller 120 of DSD 106 by executing DSD firmware 18. The process of FIG. 5B may be performed after performing the process of FIG. 5A if host 101 determines that the environmental information sent from DSD 106 is outside of a threshold. In other examples, DSD 106 may perform the process of FIG. 5B without having first sent environmental information to host 101. In such a case, host 101 may periodically test DSD 106 to determine whether it is safe to send a write command to DSD 106.

In block 608, controller 120 receives a test write command from host 101 via host interface 126. As noted above, the test write command can include test data for writing in reserved area 204. In other implementations, the test write command may only provide a command for controller 120 to perform a test write routine. The test data may then come from a memory of DSD 106 or may be encoded as part of DSD firmware 18 or controller hardware. The test write command may also specify a period of time for writing the test data.

In block 610, controller 120 controls head 136 via servo system 121 to write test data in reserved area 204. The test data may be written for a continuous period of time in reserved area 204 to better detect a transient environmental condition that may make writing unsafe.

In block 612, controller 120 determines whether any errors occurred in writing the test data in reserved area 204. This determination may be made by an indication from servo system 121 that head 136 travelled outside of write unsafe threshold 210 or may be made on the basis of a portion of servo history 27. In other implementations, controller 120 may attempt to read the test data written in reserved area 204 to check for errors.

In block 614, controller 120 sends an indication of whether any errors occurred in writing the test data. This indication may include a pass or fail status for the test write command or may include a portion of servo history 27 providing more detailed information on errors encountered when writing the test data in reserved area 204.

By providing host 101 with current and localized environmental information, it is ordinarily possible to reduce the cost in resources (e.g., repeated write retries) involved with write error recovery when an environmental condition has caused a write error. In addition, the precautionary measures discussed above can improve the performance of write error recovery.

Other Embodiments

Those of ordinary skill in the art will appreciate that the various illustrative logical blocks, modules, and processes described in connection with the examples disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. Furthermore, the foregoing processes can be embodied on a computer readable medium which causes a processor or computer to perform or execute certain functions.

To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, and modules have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Those of ordinary skill in the art may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

The various illustrative logical blocks, units, modules, and controllers described in connection with the examples disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

The activities of a method or process described in connection with the examples disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. The steps of the method or algorithm may also be performed in an alternate order from those provided in the examples. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable media, an optical media, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an Application Specific Integrated Circuit (ASIC).

The foregoing description of the disclosed example embodiments is provided to enable any person of ordinary skill in the art to make or use the embodiments in the present disclosure. Various modifications to these examples will be readily apparent to those of ordinary skill in the art, and the principles disclosed herein may be applied to other examples without departing from the spirit or scope of the present disclosure. The described embodiments are to be considered in all respects only as illustrative and not restrictive and the scope of the disclosure is, therefore, indicated by the following claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.