Constrained codes are becoming increasingly popular in storage systems, such as hard disk drive storage systems. One example of a constrained code is a maximum transition run (MTR) code. MTR codes limit the number of consecutive transitions in a bit sequence. For example, the bit sequence (0, 1, 0, 1) has 3 transitions (i.e., a low-to-high transition, a high-to-low transition, and then a low-to-high transition) and a MTR limit of 2 would cause that bit sequence to be modified since it exceeds the maximum number of consecutive transitions. Another example of a constrained code is a run length limited (RLL) code where the number of consecutive bits with the same value is limited to some maximum. For example, the bit sequence (0, 0, 0, 0) has a run length of 4 (i.e., there are 4 bits in a row with the same value) and a run length limit of 3 would cause that bit sequence to be modified since its run length exceeds the maximum.
When constrained codes are used in storage systems, it is known that certain bit sequences cannot validly occur in the signal read back from storage since the constrained code would have prevented those sequences from being written to storage in the first place. Although some techniques may exist for incorporating this knowledge into a Viterbi detector, issues may arise when a design is actually implemented as a real world product. For example, some techniques may encounter issues when implemented using fixed point and/or modulo arithmetic. New techniques which do not have these issues when implemented in a real world product would be desirable.
Various embodiments of the invention are disclosed in the following detailed description and the accompanying drawings.
The invention can be implemented in numerous ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer readable storage medium; and/or a processor, such as a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention. Unless stated otherwise, a component such as a processor or a memory described as being configured to perform a task may be implemented as a general component that is temporarily configured to perform the task at a given time or a specific component that is manufactured to perform the task. As used herein, the term ‘processor’ refers to one or more devices, circuits, and/or processing cores configured to process data, such as computer program instructions.
A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.
In the example shown, before data is written to hard disk drive storage 110, it is passed to constraint encoder 100 which enforces one or more constrained codes on the unconstrained data input to constraint encoder 100. For example,
Returning to
In this example, Viterbi detector 120 takes in a read signal and generates decisions. In various embodiments, Viterbi detector 120 may be a soft output/decision Viterbi detector or a hard output/decision Viterbi detector, so soft or hard outputs/decisions may be generated. In this example, Viterbi detector 120 includes branch metric module 126, path metric module with pruning 124, and traceback module 122.
Viterbi detector 120 is a detector utilized for inter symbol interference (ISI) channels and may be described in terms of a finite state machine which, when “rolled out” in time, becomes a trellis. Denoting the ISI length of the channel by L, the channel output at time k may be written as:
where bk is the written data sequence, Tk is the target polynomial, and nk is the noise sequence. At each index or time instance, Viterbi detector 120 first expresses all possible previous bit sequences of length (L−1) (i.e., (bk−L+1, . . . , bk−1)) in terms of 2L−1 start states.
and the squared deviation (also referred to as the squared error) for each branch (not shown in
e2(b
Returning to
Path metric module with pruning 124 in
In addition to calculating path metrics (e.g., using an add, compare, and select process as described above), path metric module with pruning 124 also generates a pruned trellis using a pruning process. An example of a pruning process performed by path metric module with pruning 124 is described in further detail below.
Traceback module 122 uses the path metrics and pruned trellis generated by path metric module with pruning 124 and outputs a sequence of soft or hard decisions corresponding to each branch in the single surviving path (e.g., decides that a particular bit is a 0 or 1).
Some other techniques (in contrast to the technique described herein) have their branch metric module perform pruning. They do this by manipulate the branch metrics output so that certain branches or paths are selected compared to other, undesirable branches or paths. For example, if it is known that a downstream path metric module will select the branch with the lowest sum (e.g., because the branch, state, and/or path metrics represent or are associated with an error, so lower values are better), some other techniques modify their branch metric module to set branch metrics for undesirable branches to a maximum value. To put it another way, they artificially inflate branch metrics for undesirable branches, for example by setting it to some maximum value. If all goes according to plan, this will cause the resulting sum to be very large and a corresponding undesirable path which includes that branch will not be selected.
The problem with manipulating branch metrics in order to cause a path metric module to pick a certain path is that when it is implemented in some real world systems, it does not work as designed. This is because the addition of the state metric and the branch metric in many path metric modules is often implemented using modulo arithmetic with fixed point precision. For example, if 4 bits are available to represent the sum (e.g., corresponding to values between 0 and 15), a value or sum of 16 would wrap around to 0. Values can wrap around to zero as a result of the modulo operation and still maintain their ordering so long as the maximum and minimum values differ by (for this 4-bit example) no more than 7. The following figure illustrates this problem where this distance or separation is not maintained and the modulo represented values lose their proper greater than/less than relationship.
At state 404, a comparison is made between (2+7) mod 16 (corresponding to the branch coming from state 400) and (4+7) mod 16 (corresponding to the branch coming from state 401). The first sum is lower so the state metric for state 404 is set to 9 and the branch from state 400 is selected.
At state 405, a comparison is made between (3+7) mod 16 (corresponding to the branch coming from state 402) and (4+7) mod 16 (corresponding to the branch coming from state 403). Since the first sum is lower, the state metric for state 405 is set to 10 and the branch from state 402 is selected.
At state 406, a comparison is made between (9+7) mod 16 (corresponding to the branch coming from state 404) and (10+7) mod 16 (corresponding to the branch coming from state 403). Since the first sum (after the modulo operation) is 0 and the second sum (after the modulo operation) is 1, the first sum is selected and the state metric for state 406 is set to 0.
Note that the state metric for state G (406) is now less than that for state Z (450), at least as represented using 4 bits. This change in the ordering is improper and the state metric for state Z (450) should in fact be less than that for the state metric for state G (406). However, because the state metrics have violated the minimum distance requirement (i.e., they can differ by no more than 7 in order for the proper ordering to be maintained), the proper ordering is lost. As a result of this, states 400-406 and the branches between them (which were supposed to have been pruned as a result of setting the branch metrics to the maximum value) are now selected since they appear to have the best (in this case, lowest) metric. This is undesirable since the selected path will pass through states and branches which should have been pruned.
Although one solution to this problem is to increase the number of bits used to represent the metrics/sums, this undesirable because of the amount of additional routing space consumed in a semiconductor device. Adding bits is thus not a practical solution in real world systems. As such, having path metric module with pruning 124 in
At 500, a set of one or more branch metrics is generated for a trellis associated with a Viterbi detector. For example, branch metric module 126 in
At 502, a set of one or more path metrics associated with the trellis is generated based at least in part on the set of branch metrics, including by obtaining a pruned trellis by removing at least some portion of the trellis that is associated with an invalid bit sequence not permitted by a constrained code. For example, path metric module with pruning 124 in
At 504, a surviving path associated with the pruned trellis is selected based at least in part on the set of path metrics. A sequence of decisions associated with the surviving path is output at 506. For example, in
The example of
At 604, it is determined if two incoming branches are pruned.
After step 606 or step 607, it is determined if there are more objects in a trellis at 608. For example, if there are more states in the trellis which remain to be processed in the iteration or pass, then process goes from the decision at 608 to the decision at 604.
If it is determined at 608 that there are no more objects in the trellis, it is determined at 610 if a pruned trellis is in a steady state. For example, it may be decided that a pruned trellis is in a steady state if the entire trellis has been processed and no changes were made to the trellis in the last pass or iteration (e.g., in terms of which states are pruned and/or which branches are pruned). If it is determined at 610 that the pruned trellis is not in a steady state, the process returns to the decision at 604 (e.g., the process keeps working on the pruned trellis until a steady state is reached).
If it is determined at 610 that the pruned trellis is in a steady state, then it is determined at 612 if two incoming branches are pruned. If so, the incoming branches are marked as not pruned. In diagram 720 in
After step 614 or if it is determined at 612 that two incoming branches are not pruned or, it is determined at 616 if there are more objects in a trellis. If so, the process returns to the decision at 612. For example, if other states and/or branches remain to be processed, the process continues.
At 604, when a trellis stage is being processed there are 3 possibilities: none of the incoming branches are pruned, only one of the incoming branches are pruned, or both of the incoming branches are pruned. If only zero or one incoming branch going into a state is pruned, then no change is fed forward to the next trellis stage. Only when both incoming branches are pruned is that state is pruned, which amounts to pruning both of the outgoing branches from that state. This feed-forward mechanism is continued until the process is able to go through the trellis at least once without making any new (e.g., additional) changes to the trellis. This corresponds to a steady state (e.g., checked for at 610); one example is shown in
The “clean up” portion of
The following figures show an example of the process described in
Branches which are associated with bit sequences which violate at least one of the constrained codes are shown in trellis 800 with dashed lines. For the purposes of describing the technique, it is not necessary to explain the constrained codes in detail and for brevity the constrained codes are not described in detail herein.
For convenience, branches are uniquely numbered or labeled using the following system:
Graphically, this corresponds to going down a column of states and numbering the outgoing branches encountered beginning with branch number 0.
As such, the pruned branches in trellis 800 are:
There are no pruned states, at least as of yet, in diagram 800.
In column 1006, states 2, 5, 10, and 13 are pruned since those states have two incoming branches which are pruned (e.g., corresponding to step 606 in
In column 1106, states 5 and 10 are marked as pruned because both of the incoming branches to those states are pruned. Outgoing branches in column 1108 that come from those pruned states are also pruned (those branches in column 1108 were already pruned, so no change is made in column 1108).
Trellis 1200 is in a steady state, corresponding to the transition from step 610 (“Pruned trellis in steady state?”) to step 612 in
As can be seen by comparing Table 1 and Table 6, the initial set of pruned branches has been reduced in the final pruned trellis.
Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.
This application claims priority to U.S. Provisional Patent Application No. 61/620,259 entitled FIXED-POINT DETECTOR PRUNING FOR CONSTRAINED CODES filed Apr. 4, 2012 which is incorporated herein by reference for all purposes.
Number | Name | Date | Kind |
---|---|---|---|
6212661 | Rub et al. | Apr 2001 | B1 |
6708308 | De Souza et al. | Mar 2004 | B2 |
6788750 | Reuven et al. | Sep 2004 | B1 |
7088764 | Kaewell, Jr. | Aug 2006 | B2 |
7346836 | Ozdemir | Mar 2008 | B2 |
7426681 | Yamamoto | Sep 2008 | B2 |
7590927 | Shih et al. | Sep 2009 | B1 |
7831893 | Norris et al. | Nov 2010 | B2 |
8433975 | Hekstra et al. | Apr 2013 | B2 |
8548102 | Doan et al. | Oct 2013 | B2 |
8599959 | Krachkovsky et al. | Dec 2013 | B2 |
8904266 | Tang et al. | Dec 2014 | B2 |
20090089648 | Tsui et al. | Apr 2009 | A1 |
Number | Date | Country | |
---|---|---|---|
61620259 | Apr 2012 | US |