• BCH Encoding/Decoding

    From Randy Yates@21:1/5 to All on Tue Nov 24 17:20:34 2020
    I've notieced that in order to decode a page of in-band data, the linux
    kernel code first computes the out-of-band ECC bytes on the given
    in-band data (calc_ecc). It is also passed the received oob data
    recv_ecc.

    If (byte-by-byte) the calc_ecc does not match the recv_data, then
    the page is decoded.

    Why not compute the decoded ECC and compute the locator
    vector/polynomial right off? Are these operations much
    more expensive than encoding and comparing?

    --Randyh

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Steve Pope@21:1/5 to [email protected] on Sat Nov 28 04:27:47 2020
    Randy Yates <[email protected]> wrote:

    I've notieced that in order to decode a page of in-band data, the linux >kernel code first computes the out-of-band ECC bytes on the given
    in-band data (calc_ecc). It is also passed the received oob data
    recv_ecc.

    If (byte-by-byte) the calc_ecc does not match the recv_data, then
    the page is decoded.

    Why not compute the decoded ECC and compute the locator
    vector/polynomial right off? Are these operations much
    more expensive than encoding and comparing?

    TL;dr it comes down to evaulating a lower-degree polynomial,
    thus requires less computation.

    Assume it is a systematic (n,k) BCH code, it is most efficient to
    re-encode the message part of the codeword, and then XOR the
    resulting (n-k) check symbols with the (n-k) received check
    symbols. Then the syndrome (power sum symmetric function)
    can be computed by evaluating using these (n-k) polynomial coefficients
    instead of all n coefficients.

    The quick exit if there is no mismatch is an optimization.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)