Pith. sign in

REVIEW 4 major objections 5 minor 42 references

Addressing multiple bit/symbol errors in DRAM subsystem

T0 review · 4 major / 5 minor · reviewed 2026-08-14 · deepseek-v4-flash

Pith's one-line read The paper claims that storing a 32-bit CRC inside each Reed-Solomon codeword lets a DRAM controller correct every single-symbol error and detect multi-symbol errors, reducing silent data corruption to near zero under the modeled faults.

desk verdict A sensible hash-plus-RS scheme reduces multi-symbol SDC rates dramatically, but the paper overstates the guarantee: CRC-32 is linear, so fixed fault patterns can produce deterministic false negatives, and the table's zeroes are finite-run averages, not worst-case bounds. read the letter →

arxiv 1908.01806 v2 pith:3VAEYCXQ submitted 2019-08-05 cs.AR

classification cs.AR
keywords DRAMreliabilitysilentdatacorruptionReed-SolomonECCchipkillCRChashmulti-symbolerrordetectionmemorycontrollercorrectioncodes
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper proposes SSCMSD, a memory-controller scheme that pairs a single-symbol-correcting Reed-Solomon code with a 32-bit CRC hash stored inside the codewords. It claims this combination catches the multi-chip and multi-bus faults that current chipkill schemes silently miscorrect, while keeping the usual single-symbol correction and adding no read latency. The cost is one extra DRAM chip per rank, for 18.75 percent storage overhead, plus hash logic at the memory controller. If correct, the scheme converts silent-data-corruption risk into a small hash-collision probability instead of the several-percent miscorrection rates the paper measures for existing schemes.

What carries the argument

The load-bearing mechanism is the hash-before-encode combination: the CRC is computed over the data and then encoded with the data by the Reed-Solomon code, so the hash itself is correctable and cannot produce false positives. The RS(19,17,8) code over 8-bit symbols has minimum distance 3, giving single-symbol correction and partial multi-symbol detection, but by itself it miscorrects roughly 6 to 8 percent of two-to-four-symbol errors. The 32-bit CRC, chosen from HD-6 polynomials such as Castagnoli, guarantees detection of up to five bit flips and all odd-weight errors for the relevant key size, and its systematic, linear structure lets syndrome computation and hash computation overlap so the added detection does not slow the read path.

What would settle it

Inject a two-symbol error mask that moves a stored RS(19,17,8) codeword onto the radius-1 correction sphere of a different valid codeword while also altering data and the stored 32-bit hash so that the recomputed CRC still matches, and count how often the controller declares the cache-line error-free; a Monte-Carlo search over such CRC-preserving miscorrections gives the true residual SDC rate, and any rate above the few-per-ten-billion level reported would overturn the claim.

Watch

Extended reading notes

Core claim

The central claim is that a DRAM codeword can be made safe against both single-symbol errors and multi-symbol errors at the same time by putting a hash of the data inside the ECC codeword rather than beside it. SSCMSD computes a 32-bit CRC over the 64-byte cache-line, optionally including the address, splits the hash into four symbols, appends one hash symbol to each 16-symbol data block, and encodes each 17-symbol block with an RS(19,17,8) code. On read, syndrome calculation and hash calculation run in parallel; the Reed-Solomon decoder corrects one-symbol errors, and a hash mismatch flags the miscorrections or undetected multi-symbol errors that the decoder would otherwise pass through. In simulations over the paper's fault model, this brings the silent-data-corruption rate to zero or near zero across all tested fault modes, with only a handful of events per ten billion cache-lines attributable to hash aliasing.

Load-bearing premise

The evaluation rests on the error model in Table 2, which assumes real DRAM and bus faults produce at most three randomly corrupted symbols per codeword and do not corrupt the stored hash in a way that preserves the CRC; if field faults break that pattern, the detection guarantee falls back to a 32-bit hash-collision probability.

Editorial extensions

If this is right

  • If SSCMSD is right, a server memory controller can keep chipkill-style single-chip correction and also catch faults that spread across two or three chips or bus lanes, so corrupted cache-lines are reported as uncorrectable instead of silently forwarded.
  • The same 32-bit hash can cover address bits, so a read that fetches from a corrupted address is detected without storing extra metadata.
  • Because syndrome computation and hash computation overlap in the systematic code, the added multi-symbol detection costs no extra memory cycles on the error-free path and about one cycle when correction is needed.
  • The scheme needs one extra DRAM chip and bus lane per rank, at 18.75 percent storage overhead, and hash logic at the memory controller, making it a controller-side upgrade to standard DDR4-style x4 ranks.
  • The enhanced detection can be enabled or disabled per application, giving selective error protection for workloads that prefer lower overhead.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A residual floor of order $2^{-32}$ per checked cache-line is intrinsic to any 32-bit hash, so extending SSCMSD to a 64-bit or keyed hash would be the natural next step if the extra storage or logic can be afforded.
  • Because the hash is stored in the same rank as the data, a fault that corrupts both in a coordinated way, such as returning a stale but internally consistent codeword from another address, could evade the CRC; combining SSCMSD with command/address protection is the obvious system-level completion.
  • The paper's near-zero SDC rates are simulation results under its Table 2 fault model, so an FPGA or silicon prototype injected with real field-derived DRAM error traces would be the direct test of whether the guarantee survives outside simulation.
  • The scheme effectively converts silent-data-corruption risk into hash-collision risk, so applications facing extremely rare or adversarial fault patterns should treat the guarantee as probabilistic rather than absolute.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper proposes SSCMSD, a scheme for DDRx memory that combines a single-symbol-correcting Reed-Solomon code RS(19,17,8) with a 32-bit CRC hash stored inside the codewords. It is designed to correct single-symbol errors, as in CHIPKILL, and to detect multi-symbol errors that would otherwise cause silent data corruption (SDC). The authors describe a write path that computes a hash of the 64-byte cacheline, splits the hash into four symbols, and stores each hash symbol with a 16-symbol data block; the read path computes the RS syndrome and hash in parallel and uses a decision table to accept, correct, or reject the cacheline. The evaluation uses an in-house simulator with an error model containing single-bit, single-pin, row/chip/bank, column, bus, correlated-bus, and combined faults, and compares SSCMSD with a baseline RS-SSC scheme, an extended baseline, Bamboo-ECC, and extended Bamboo-ECC. The paper also reports an analytical model for RS miscorrection rates that corroborates the simulator, and it claims that SSCMSD avoids SDCs in all tested fault modes with 18.75% storage overhead and no additional READ latency.

Significance. If the central claims hold, the paper offers a practical and inexpensive way to extend existing CHIPKILL-style protection to detect multi-symbol errors: 19 chips per rank instead of 18, with a CRC-32 hash check added after RS decoding. The address-error protection described in Section 6.3 is a useful additional contribution. The paper deserves credit for validating its simulator against an analytical miscorrection model (Section 4), for testing a broad set of fault modes, and for including a comparison with Bamboo-ECC under equal storage overhead. The main weakness is that the paper states the detection result as a categorical guarantee ('avoids SDCs in all fault modes') while the evidence is an average false-positive rate over random data and random error masks; for a linear CRC, false negatives are deterministic for a fixed error difference vector. This gap does not invalidate the scheme as a probabilistic detector, but it requires a major recharacterization of the claims.

major comments (4)
  1. [Section 7, Table 5; Section 6.2] The claim that SSCMSD 'avoids SDCs in all of the above fault modes' is not supported by Table 5. The zero SDC entries are rounded counts from finite simulation runs: the text immediately below Table 5 states that in 10 iterations of 10 billion runs per iteration there were 'up to 5 SDCs for each iteration across all the fault modes.' Those nonzero counts are hidden by rounding to zero in the table. The paper should report the actual counts or rates with confidence intervals, and should not describe the result as zero SDC.
  2. [Section 6.4 and Eq. (7)] The false-negative analysis in Eq. (7) uses a birthday-paradox collision probability of 2^{-N/2} for an N-bit hash, but this is not the right model for a CRC-based detection check. CRC-32 is linear over GF(2), so after RS decoding the acceptance condition CRC(Δ) = e_hash depends only on the error difference vector (Δ, e_hash), not on the data content. For a permanent fault pattern with fixed Δ, the corrupted line is either accepted on every access or rejected on every access; there is no per-access 2^{-32} probability. The simulated rates in Table 5 are averages over random data and random error masks, not worst-case per-fault guarantees. The paper should either prove that no fault mode in Table 2 can produce an error difference vector that is a root of the CRC, or explicitly restate the claims in terms of average SDC rates rather than avoiding SDCs.
  3. [Abstract and Section 6.2] The abstract claims the scheme is achieved 'without introducing additional READ latency,' but Section 6.2 ends with 'the additional latency introduced per each READ miss our is expected to be one memory clock cycle.' These statements are in direct tension. If the intent is that the error-free case, where only syndrome and hash are computed in parallel, has no extra delay, that should be stated precisely; if the correction path adds one cycle, the abstract should say 'no additional latency in the common error-free case' or similar.
  4. [Section 5, Table 2; Section 7] The evaluation rests on a specific finite list of fault modes in Table 2, and the paper's SDC conclusions apply only within that model. For example, if a real fault produces correlated errors that corrupt both the data and the stored hash in a way that preserves the CRC relation, or if a multi-symbol error spans all four codewords in a pattern that the RS decoder mis-corrects and the hash does not catch, the SDC rate would be governed by the hash alias probability rather than by the near-zero averages in Table 5. The paper should explicitly state this modeling dependency as a limitation, or extend the evaluation to a broader/worst-case error space.
minor comments (5)
  1. [Section 4] The text says 'Table 2 lists the mean % across 10 iterations' for the RS experiments, but the results are actually in Table 1; Table 2 is the error model. The table cross-references should be corrected throughout.
  2. [Throughout] There are several typos, including 'galios' for 'Galois,' 'CHIKPILL' in the Section 8 heading, and 'the additional latency introduced per each READ miss our is expected to be' in Section 6.2. A careful proofreading pass is needed.
  3. [Table 5] The formatting of Table 5 is hard to read: the row 'Correlated 2 Bus fault' and the fault-mode rows have SDC and CF percentages in the same column, so it is difficult to tell which number belongs to which metric. Use separate subcolumns or explicit labels for SDC and CF.
  4. [Section 7] The simulation scale is described inconsistently: the text says 'one billion runs for every iteration' for the comparative experiments but later says '10 billion runs per iteration' for the SSCMSD hash-aliasing study. Clarify the run counts and report them consistently.
  5. [Section 6.2, Eq. (7)] Even as a loose upper bound, the use of 2^{-N/2} from the birthday paradox is not the natural alias probability for a hash check: for a single fixed error pattern, the random-data alias probability is closer to 2^{-N}. Using the looser 2^{-16} is acceptable for an upper bound, but the justification should be corrected.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: SSCMSD's SDC avoidance is simulation-based and its error-detection bound uses the baseline as an upper bound, not as a fitted target.

full rationale

The paper's central chain is self-contained. It first characterizes a baseline RS-SSC(18,16,8) decoder using both simulation and an independent analytical miscorrection count (Eqs. 1-6) that corroborate each other. SSCMSD then adds a 32-bit hash (CRC-32/SpookyHash/Lookup3) stored inside the RS(19,17,8) codeword and validates decoder output by recomputing the hash. The claimed false-negative upper bound in Eq. 7 uses the measured 8% baseline SDC rate as a conservative multiplier and the hash collision probability; this is an upper bound, not a fitted parameter used to produce Table 5. The Table 5 SDC entries are direct simulation outcomes over random data and random error masks, so they are not defined in terms of the bound. The only self-citation, [40], is the authors' PRDC prior version, used to attribute the interleaved baseline and hash-hardware analysis; it is not load-bearing for the SSCMSD correctness argument. The skeptic's linear-CRC concern identifies a possible worst-case alias pattern for deterministic faults, which is a correctness/coverage question rather than a circularity of the derivation; accordingly it does not raise the circularity score.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

The central reliability claim depends on three kinds of inputs: standard Reed-Solomon coding theory, a domain-specific fault model (Table 2), and a hash collision model (Eq. 7). The design parameters (32-bit hash, 19 chips per rank, CRC polynomial) are chosen by the authors rather than derived from a stated reliability target.

free parameters (3)
  • Hash length = 32 bits
    Selected so the hash can be split into four 8-bit symbols and stored in four codewords; the false-negative bound in Eq. 7 scales as 2^-N/2, so this choice sets the residual SDC probability.
  • Storage redundancy = 19 chips per rank (18.75 percent)
    One extra chip and 12 redundant bus-lines over the 18-chip baseline; this design choice drives the overhead comparison with extended baseline and Bamboo-ECC.
  • CRC-32 polynomial = Castagnoli, koopman32k, or koopman32k2 (HD=6)
    Chosen among existing CRC-32 polynomials for minimum Hamming distance 6 and even parity; the paper does not derive a new polynomial.
assumptions (4)
  • standard math Reed-Solomon code with minimum distance n-k+1 can correct floor((n-k)/2) symbol errors and detects others probabilistically; the Berlekamp-Massey decoder implementation is correct.
    Used throughout Section 4 and Section 6; the miscorrection analysis and simulation depend on standard RS decoding properties.
  • domain assumption The fault modes in Table 2 (single and multiple chip, pin, bus, row/bank/column faults, and combinations) represent the dominant DRAM failure modes in field conditions.
    Section 5 defines the error model; the evaluation in Section 7 injects only these patterns, so the SDC-prevention claim is conditional on this model.
  • domain assumption A 32-bit non-cryptographic hash (CRC-32 with HD=6) detects arbitrary multi-symbol errors with probability approximately 1-2^-32, and the birthday-paradox bound 2^-16 upper-bounds the per-cacheline false-negative rate.
    Section 6.2 Eq. (7) uses this to upper-bound false negatives; hash aliasing is the only residual SDC mechanism in the design.
  • domain assumption Hash computation and RS syndrome calculation complete within five memory cycles, so READ latency is not increased beyond baseline.
    Section 6.2 and Figure 6 rely on reference [34] for a 0.48 ns syndrome delay and on combinatorial hash logic; no implementation or timing closure is provided.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Addressing multiple bit/symbol errors in DRAM subsystem." pith.science (2026). https://pith.science/paper/3VAEYCXQ

@misc{pith2026190801806,
  author       = {Pith},
  title        = {Pith review of: Addressing multiple bit/symbol errors in DRAM subsystem},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/3VAEYCXQ}},
  note         = {Machine review of arXiv:1908.01806}
}
read the original abstract

As DRAM technology continues to evolve towards smaller feature sizes and increased densities, faults in DRAM subsystem are becoming more severe. Current servers mostly use CHIPKILL based schemes to tolerate up-to one/two symbol errors per DRAM beat. Multi-symbol errors arising due to faults in multiple data buses and chips may not be detected by these schemes. In this paper, we introduce Single Symbol Correction Multiple Symbol Detection (SSCMSD) - a novel error handling scheme to correct single-symbol errors and detect multi-symbol errors. Our scheme makes use of a hash in combination with Error Correcting Code (ECC) to avoid silent data corruptions (SDCs). SSCMSD can also enhance the capability of detecting errors in address bits. We employ 32-bit CRC along with Reed-Solomon code to implement SSCMSD for a x4 based DDRx system. Our simulations show that the proposed scheme effectively prevents SDCs in the presence of multiple symbol errors. Our novel design enabled us to achieve this without introducing additional READ latency. Also, we need 19 chips per rank (storage overhead of 18.75 percent), 76 data bus-lines and additional hash-logic at the memory controller.

Figures

Figures reproduced from arXiv: 1908.01806 by the authors.

Figure 1
Figure 1. Memory channel - Memory controller is connected to DRAM [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. N tuple space representation of Reed Solomon SSC code. Stars [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. CW A, CW B are two 18-symbol codewords which are HD = e [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: Possible hash and SSC combinations scheme) and pass on the requested 64-byte cache-line to the processor. Hence, applications waiting for this cache￾line can resume their execution almost immediately on the processor. But if there is a multi-symbol error in any of the …
Figure 5
Figure 5. Figure 5: SSCMSD Design. 32 bit hash is split into 4 symbols (red). Each [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]
Figure 6
Figure 6. Figure 6: SSCMSD Design. During Read operation, syndrome computation and hash calculation are done in parallel. If any of the syndromes are [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]
Figure 7
Figure 7. Figure 7: Simulation methodology. We used SpookyHash, Lookup3, CRC-32-Castagnoli (as a representative of HD=6, even parity polynomials), CRC￾32-IEEE 802.3 (as a representative of odd parity polyno￾mial) hash functions in our simulations shown in Table for SSCMSD design. Across a…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

42 extracted references · 42 canonical work pages

  1. [1]

    Revisiting memory er- rors in large-scale production data centers: Analysis and modeling of new trends from the field

    J. Meza, Q. Wu, S. Kumar, and O. Mutlu, “Revisiting memory er- rors in large-scale production data centers: Analysis and modeling of new trends from the field.” in DSN, 2015, pp. 415–426

  2. [2]

    Los Alamos National Laboratory

    Reliability data sets. Los Alamos National Laboratory. [Online]. Available: http://institutes.lanl.gov/data/fdata/ 12

  3. [3]

    Memory errors in modern systems: The good, the bad, and the ugly,

    V . Sridharan, N. DeBardeleben, S. Blanchard, K. B. Ferreira, J. Stearley, J. Shalf, and S. Gurumurthi, “Memory errors in modern systems: The good, the bad, and the ugly,” inASPLOS’15, Istanbul, Turkey, March 14-18, 2015, 2015, pp. 297–310

  4. [4]

    A white paper on the benefits of chipkill-correct ecc for pc server main memory,

    T. J. Dell, “A white paper on the benefits of chipkill-correct ecc for pc server main memory,” in IBM Microelectronics Division , 1997, pp. 1–23

  5. [5]

    Bios and kernel developers guide (bkdg) for amd family 15h models 00h-0fh processors

    “Bios and kernel developers guide (bkdg) for amd family 15h models 00h-0fh processors.” AMD Inc., 2013

  6. [6]

    Jacob, The Memory System: You Can’T Avoid It, You Can’T Ignore It, You Can’T Fake It

    B. Jacob, The Memory System: You Can’T Avoid It, You Can’T Ignore It, You Can’T Fake It. Morgan and Claypool Publishers, 2009

  7. [7]

    Jacob, S

    B. Jacob, S. Ng, and D. Wang, Memory Systems: Cache, DRAM, Disk. San Francisco, CA, USA: Morgan Kaufmann Publishers Inc., 2007, ch. 30

  8. [8]

    Tutorial on reed-solomon error correction coding

    W. A. Geisel, “Tutorial on reed-solomon error correction coding.” National Aeronautics and Space Administration, Lyndon B. John- son Space Center, 1990

Show all 42 references
  1. [9]

    Lot-ecc: Localized and tiered reliability mechanisms for commodity memory systems,

    A. N. Udipi, N. Muralimanohar, R. Balsubramonian, A. Davis, and N. P . Jouppi, “Lot-ecc: Localized and tiered reliability mechanisms for commodity memory systems,” ser. ISCA ’12, 2012

  2. [10]

    Bios and kernel developers guide for amd npt family 15h proces- sors

    “Bios and kernel developers guide for amd npt family 15h proces- sors.” AMD Inc., 2007

  3. [11]

    Opensparc t2 system-on-chip (soc) microarchitecture specifica- tion

    “Opensparc t2 system-on-chip (soc) microarchitecture specifica- tion.” Sun Microsystems, 2008

  4. [12]

    Bamboo ECC: strong, safe, and flexible codes for reliable computer memory,

    J. Kim, M. Sullivan, and M. Erez, “Bamboo ECC: strong, safe, and flexible codes for reliable computer memory,” in HPCA, 2015, pp. 101–112

  5. [13]

    All-inclusive ECC: thorough end-to-end protection for reliable computer memory,

    J. Kim, M. Sullivan, S. Lym, and M. Erez, “All-inclusive ECC: thorough end-to-end protection for reliable computer memory,” in ISCA, 2016, pp. 622–633

  6. [14]

    Ddr4 sdram standard, jesd79-4, joint electron device engineering council, sep. 2012

    “Ddr4 sdram standard, jesd79-4, joint electron device engineering council, sep. 2012.”

  7. [15]

    B. Jenkins. Spookyhash. [Online]. Available: https: //burtleburtle.net/bob/hash/spooky.html

  8. [16]

    H. Minsky. A c library for reed solomon code. [Online]. Available: http://rscode.sourceforge.net

  9. [17]

    A. Kleen. A c library for spookyhash. [Online]. Available: https://github.com/andikleen/spooky-c

  10. [18]

    B. Sklar. Reed-solomon codes. [Online]. Available: http://ptgmedia.pearsoncmg.com/images/art_sklar7_reed- solomon/elementLinks/art_sklar7_reed-solomon.pdf

  11. [19]

    Flipping bits in memory without accessing them: An experimental study of dram disturbance errors,

    Y. Kim, R. Daly, J. Kim, C. Fallin, J. H. Lee, D. Lee, C. Wilkerson, K. Lai, and O. Mutlu, “Flipping bits in memory without accessing them: An experimental study of dram disturbance errors,” inACM SIGARCH Computer Architecture News, vol. 42, no. 3. IEEE Press, 2014, pp. 361–372

  12. [20]

    Mentor Graphics

    Simultaneously switching noise-an overview. Mentor Graphics. [Online]. Available: https://www .mentor.com/pcb/blog/post/ simultaneously-switching-noise-an-overview-dff75b6d-6b41- 4d47-a231-1aafb29c07ad?cmpid=9049

  13. [21]

    A case for exploiting subarray-level parallelism (salp) in dram,

    Y. Kim, V . Seshadri, D. Lee, J. Liu, and O. Mutlu, “A case for exploiting subarray-level parallelism (salp) in dram,” ser. ISCA ’12, 2012

  14. [22]

    Intel Corp

    Intel R© xeon R© processor e7 v2 2800/4800/8800 product family datasheet - volume two. Intel Corp. [Online]. Available: http://www .intel.com/content/dam/www/public/ us/en/documents/datasheets/xeon-e7-v2-datasheet-vol-2 .pdf

  15. [23]

    Memguard: A low cost and energy effi- cient design to support and enhance memory system reliability,

    L. Chen and Z. Zhang, “Memguard: A low cost and energy effi- cient design to support and enhance memory system reliability,” ser. ISCA ’14, 2014

  16. [24]

    Performance of the most common non-cryptographic hash functions,

    C. Estébanez, Y. Saez, G. Recio, and P . Isasi, “Performance of the most common non-cryptographic hash functions,” Software: Practice and Experience, vol. 44, no. 6, pp. 681–698, 2014

  17. [25]

    Ramps: A reconfigurable architecture for minimal perfect sequencing,

    C. Nelson, K. R. Townsend, O. G. Attia, P . H. Jones, and J. Zam- breno, “Ramps: A reconfigurable architecture for minimal perfect sequencing,” IEEE Transactions on Parallel and Distributed Systems , vol. 27, no. 10, pp. 3029–3043, 2016

  18. [26]

    Jacob, S

    B. Jacob, S. Ng, and D. Wang, Memory Systems: Cache, DRAM, Disk. San Francisco, CA, USA: Morgan Kaufmann Publishers Inc., 2007, ch. 9

  19. [27]

    Analysis of memory errors from large-scale field data collection,

    T. Siddiqua, A. Papathanasiou, A. Biswas, and S. Gurumurti, “Analysis of memory errors from large-scale field data collection,” in In IEEE Workshop on Silicon Errors in Logic - System Effects (SELSE), 2013, 2013

  20. [28]

    A study of dram failures in the field,

    V . Sridharan and D. Liberty, “A study of dram failures in the field,” in In International Conference on High Performance Computing, Networking, Storage and Analysis (SC), 2012 , 2012

  21. [29]

    Soft errors in advanced computer systems,

    R. Baumann, “Soft errors in advanced computer systems,” in IEEE Design and Test of Computers, 2005, pp. 258–266

  22. [30]

    Hardware-software co-design to mitigate dram refresh over- heads,

    J. B. Kotra, N. Shahidi, Z. A. Chisthi, and M. T. Kandemir, “Hardware-software co-design to mitigate dram refresh over- heads,” in ASPLOS’15, 2017

  23. [31]

    Exploiting selective placement for low-cost memory protection,

    M. Mehrara and T. Austin, “Exploiting selective placement for low-cost memory protection,” in ACM Transactions on Architecture and Code Optimization, 2008

  24. [32]

    Evaluation and design of non- cryptographic hash functions for network data stream algo- rithms,

    G. Cheng and Y. Yan, “Evaluation and design of non- cryptographic hash functions for network data stream algo- rithms,” in 2017 3rd International Conference on Big Data Computing and Communications (BIGCOM), Aug 2017, pp. 239–244

  25. [33]

    Improving bank-level parallelism for irregular applications,

    X. Tang, M. Kandemir, P . Yedlapalli, and J. Kotra, “Improving bank-level parallelism for irregular applications,” ser. MICRO-49, 2016

  26. [34]

    Low delay single symbol error correction codes based on reed solomon codes,

    S. Pontarelli, P . Reviriego, M. Ottavi, and J. A. Maestro, “Low delay single symbol error correction codes based on reed solomon codes,” IEEE Transactions on Computers , vol. 64, no. 5, pp. 1497– 1501, May 2015

  27. [35]

    Incre- mental multiset hash functions and their application to memory integrity checking,

    M. v. D. B. G. G. E. S. Dwaine Clarke, Srinivas Devadas, “Incre- mental multiset hash functions and their application to memory integrity checking,” In Advances in Cryptology - Asiacrypt 2003 Proceedings, vol. 2894, pp. 188–207, 2003

  28. [36]

    Rockliff

    S. Rockliff. A c library for reed solomon code. [Online]. Available: www.eccpage.com/rs.c

  29. [37]

    A study of hardware implementations of the crc computation algorithms,

    Mytsko, Evgeniy, Malchukov, Andrey, Ryzova, Svetlana, and Kim, Valeriy, “A study of hardware implementations of the crc computation algorithms,” MATEC Web of Conferences , vol. 48, p. 04001, 2016. [Online]. Available: https://doi .org/10.1051/ matecconf/20164804001

  30. [38]

    B. Jenkins. Lookup3 hash function. [Online]. Available: https: //burtleburtle.net/bob/c/lookup3.c

  31. [39]

    32-bit cyclic redundancy codes for internet appli- cations,

    P . Koopman, “32-bit cyclic redundancy codes for internet appli- cations,” in 2002 International Conference on Dependable Systems and Networks (DSN 2002), 23-26 June 2002, Bethesda, MD, USA, Proceedings, 2002, pp. 459–472

  32. [40]

    SSCMSD - single-symbol correction multi-symbol detection for DRAM subsystem,

    R. Yeleswarapu and A. K. Somani, “SSCMSD - single-symbol correction multi-symbol detection for DRAM subsystem,” in 23rd IEEE Pacific Rim International Symposium on Dependable Computing, PRDC 2018, Taipei, Taiwan, December 4-7, 2018, 2018, pp. 15–24

  33. [41]

    Eruchalu

    N. Eruchalu. Reed-solomon (rs) encoder/decoder + channel simulation using euclidean algorithm. [Online]. Available: https://github.com/nceruchalu/reed_solomon Ravikiran Yeleswarapu is a Ph.D candidate at Iowa State University, Ames, Iowa. He worked at Qualcomm’s WLAN division ...

  34. [2014]

    His research interests include computer system design and architecture, memory, reliability and new computing paradigms

    He received the bachelor’s of engineering degree in electrical and electronics engineeering and the MSc degree in physics from Birla Institute of Technology and Science-Pilani, India, in 2010. His research interests include computer system design and architecture, memory, reli...

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.